17

Nov

Äkki on selle kohta teenus!

Priidik Vaikla 5 kommentaari

On teada üks kutsehaigus, kus igat ettejuhtuvat probleemi püüab spetsialist lahendada vastavalt oma professioonile. Juristid arvavad, et kõik probleemid saab lahendada vettpidavate lepingutega. Programmeerijad arvavad, et iga probleemi lahendamiseks on vaja kirjutada programm. Hiljem kui programm on valmis, tuleb seda hooldada ja käigus hoida, aga administreerimine ei ole arendajatele motiveeriv tegevus. Tutvustan Saikus kasutatavaid teenuseid, mis aitavad meil igapäevaselt oma töödega hakkama saada ilma, et peaksime pool (jah, ma pingutan üle) tööajast toetavate tegevuste tarkvarade haldamisega tegelema.

Ajaträkkimine

Pole vaja programmeerida projektijuhtimissüsteem, mille üks osa oleks tööaja träkkimine. Kasutasime varem Slimtimer lahendust, kuna aga see oli vahepeal katki, siis liikusime üle Paymo nimelise teenuse kasutajaks. Teenus areneb meist sõltumata ning saame keskenduda oma põhitegevusele.

Versioonihaldus

Mõned hetked tagasi olime otsuse ees, kas hoida ise üleval oma lähtekoodi versioonihaldust või leida väike summa analoogse teenuse kasutamiseks. Olles kogenud, et vastava teenuse ülevalhoidmine enda serveris tekitab ikka aeg-ajalt probleeme ja tegevusi, mis ei lisa tellijale väärtust ning, mida võiks nimetada raiskamiseks, valisime Github-i. Las nemad tegelevad oma teenuse ülevalhoidmisega ning meie lahedate projektide arendusega.

Projektijuhtimissüsteem

Kas me peaksime looma oma spetsiaalse projektijuhtimistarkvara? Muidugi, sest meie projektide läbi viimise väärtusahel on ju nii erinev. Olen seda juttu kuulnud küll. Meie valisime kasutajalugude haldamiseks ja prioritiseerimiseks AgileZen-i. Võibolla peab sellest loobuma kui me kunagi kontori saame, sest tegelikult tahaks seda sama tööd teha käsitsi ja märkmepaberitega.

Mailiserver

Google. Aga noh isegi Exchange-t on võimalik rentida tänapäeval.

E-kirjade postitustarkvara

Me küll uudiskirju ei saada, aga oma klienditel oleme soovitanud kasutada MailChimp-i. Ei olnud keeruline leida mõistlik lahendus, ei pidanud hakkama järjekordset tarkvara looma. Lisaks ei pea me tegelema loodud lahenduse üleval hoidmise ja muu sellisega. Neid asju teevad meist palju motiveeritumad inimesed.

Kokkuvõtteks

Niisamuti nagu on disainimustritega lahendatud paljud tarkvara arenduses tekkivad probleemid, on mitmed ärimaailmas tekkivad probleemid juba praegu töötavate teenustega lahendatud. Ära leiuta oma jalgratast, su olukord ei ole nii erinev.

Loe veel sarnastel teemadel:

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , , ,

5 kommentaari

1

Ma olen oma isiklikuks otstarbeks kasutanud http://www.toggl.com ajaträkkerit

Siim
10:43, 17. november

2

Soovitaksin oma kogemusest ka Togglit: http://www.toggl.com ning meilinduse jaoks tasuta Google Appsi: http://www.google.com/a

Tõnu
22:23, 17. november

3

Väga asjakohane postitus. Küll aga jääb kajastamata, kuidas kõik teenused terviklikult kokku tuua (koodihoidla, versioonihaldus, vigade ja töödehaldus jne). Näiteks http://unfuddle.com/ lahendus katab nii koodihalduse kui ka tööde halduse.

Tõsi küll, SCRUM osas see on osutunud ebamugavamaks ja kui kellelgi on soovitusi mida koos SVNiga SCRUM jaoks kasutada, andke palun teada.

Kristjan
15:28, 20. november

4

Eelmise kommentaari märkuseks – ei midagi isiklikku, pigem juhtisin just tähelepanu, et teenuste lõppväärtus on seda suurem, mida rohkem neid ühildada õnnestub.

Kristjan
15:43, 20. november

5

Kõiki teenuseid ei ole vaja kokku tuua.

Vähemalt tasub alati küsida endalt, kas näiteks koodihaldust on vaja taskide halduse juurde liidestada. Võibolla tõesti annab see mingeid eeliseid, aga kas ta annab rohkem eeliseid kui ühildunud komplektse süsteemi ebamugavus toob miinuseid.

Kõikide teenuste tsentraliseerimisel on oht, et suur süsteem on kallutatud ühe või teise vaate poole. Ärikeskne või on ta koodikeskne või on ta vigade ticketite keskne.

Ma ei väida, et erinevad teenused ei peaks omavahel suhtlema, aga ma väidad, et see suhtlus ei ole iseenesest mõistetavalt vajalik.

Priidik Vaikla
15:10, 24. november

Lisa kommentaar

  • * Kuvatakse kommentaari juures
  • * Ei publitseerita