Šį penktadienį (2010-05-21) dalyvavau IT 2010 konferencijos (http://www.isd.ktu.lt/it2010) Industrial Tutorials dienoje (http://www.isd.ktu.lt/it2010/media/IT2010_IndustrialTutorials_Programme.pdf). Visų pirma norėčiau pasidžiaugti kad KTU ėmėsi iniciatyvos ir šalia jų tradicinės mokslo konferencijos vieną dieną suteikė galimybę verslo žmonėms pasidalinti praktine patirtimi. Šauni universiteto iniciatyva! Taigi trumpai mano mintys po konferencijos.
Agile Microsoft‘e
Konferenciją pradėjo Tautvydo Dagio (Microsoft) pranešimas „Software Development Process: Microsoft Aproach”. Pradžioje Tautvydas paminėjo, kad Microsoft yra labai didelė kompanija, tad ir joje naudojami procesai yra labai skirtingi. Jis mums pristatė Visual Studio 2008 kūrimo proceso pavyzdį, kuris iš esmės rėmėsi Agile principais.
Pirma, produktas buvo kuriamas iteracijomis (6-10 savaičių). Kiekviena iteracija turėjo būti pabaigta pilnu tam tikro funkcionalumo (feature) pabaigimu, potencialiai pristatoma (potentially shipable) Scrum terminais. Be to jie vadovavosi 2 svarbiais principais: “Get Clean” ir “Stay Clean”. Tai reiškė, jog pradedant kiekvieną iteraciją pirmiausia turėjo būti išvalomas kodas nuo visų žinomų klaidų ar „techninės skolos” (kažkas neoptimaliai techniškai įgyvendinta, nors ir veikia). Iteracijos metu toks „švarus” kodas turėjo būti palaikomas visomis galimomis priemonėmis (nekuriant didelio klaidų sąrašo kurį „vėliau sutvarkysime”).
Antra, jų komandos buvo tarpfunkcinės, dažniausiai sudarytos iš: vieno programos vadovo, kuris dirbo kaip projektų vadovas/analitikas; 5 ar mažiau programuotojų; 5 ar mažiau testuotojų. Testuotojai, jų atveju, ne tik tipiškai testavo funkcionalumą iš vartotojo sąsajos, bet ir programavo automatizuotus testus, testavo stabilumą, programos greitumą ir pan.
Trečia, jie kodo saugyklą valdė labai panašiai kaip kad aš jau aprašiau straipsnyje Kodo versijų ir saugyklos valdymas judriuose (agile) projektuose. Jie turėjo funkcionalumo šakas (feature branches) kuriose dirbdavo komandos kol pilnai pabaigdavo funkcionalumą. Tada jie įliedavo jį į pagrindinę kodo saugyklos šaką, aišku, atlikdami tarpinius integracijos testavimus. Taip būdavo užtikrinama, kad pagrindinėje šakoje yra tik visiškai pabaigtas funkcionalumas ir jis yra visada potencialiai pristatomas (potentially shipable).
Antroje prezentacijos dalyje Tautvydas pristatė Microsoft Solution Framework (MSF). Turbūt daugelis žinote, jog MSF v4 jau turėjo apibrėžtus pavyzdžius (templates) Agile tipo produkto kūrimui: MSF for Agile Software Development. Šiuos pavyzdžius buvo galima pritaikyti prie savo naudojamo Agile metodo (pvz. Scrum, FDD, XP). Nepaisant to, šiemet Microsoft išleido MSF v5, kuriame MSF for Agile yra pilnai suderintas su Scrum metodologija. Jis pilnai aprašo patį Scrum metodą, artefaktus, taisykles, roles ir susirinkimus. Pasak Tautvydo, tai turėtų stipriai palengvinti kompanijoms diegti ir naudoti Scrum metodą, nes pats procesas, pavyzdžiai, įrankiai bus jau paruošti ir reikės tiesiog juos teisingai taikyti.
Taigi apibendrinant, mano asmenine nuomone, yra labai džiugu kad tokios didelės kompanijoskaip Microsoft mato Agile teikiamas naudas, pačios pradeda naudoti šiuos metodus ir kuria įrankius kad kitiems būtų lengviau juos įsisavinti. Nepaisant to, siūlyčiau nepamiršti, kad Agile yra apie žmones. Pats pirmas Agile manifesto (http://agilemanifesto.org) teiginys sako: „Žmonės ir jų bendradarbiavimas yra svarbiau nei procesai ir įrankiai”. Tad neužmirškit diegiant Agilemetodus pirmiausia galvoti apie žmones ir ar jie supranta esminius Agile principus. Įrankiai yra reikalingi tik vėliau, palaikyti procesą kurį jau išbandėte, prisitaikėte ir naudojate, ne atvirkščiai.
Agile IBM‘e
Antrąjį pristatymą „Pragmatic Agile: Gradual Tailoring of Agile Practices to Existing Processes” skaitė IBM atstovė Marija Tiurina. Iš esmės pranešimas buvo apie tai, jog didelėse kompanijose neįmanoma Agile taikyti tiesiogiai, reikia Agile metodus adaptuoti. IBM tai vadina „Agile@Scale”.
Drįsčiau teigti jog tai nėra visiškai tiesa. Mano asmenine nuomone, tai yra tik naujas vardas jau egzistuojantiems Agile metodams ir geroms praktikoms. Pavyzdžiui kompanijoje kurioje šiuo metu dirbu, produkto kūrimo skyriuje (kuriame dirba virš 40 darbuotojų) mes sėkmingai taikome Scrum pagal visas aprašytas taisykles. Esame susiorganizavę į 7 tarpfunkcines Scrum komandas. Taigi, pagal darbuotojų skaičių galime lygintis su gan dideliais projektais. Scrum mums veikia tikrai gerai. Mūsų patirtis parodė, kad tikrai sunku yra teisingai įgyvendinti aprašytas metodų taisykles, tačiau tai padarius, nauda pasimato labai greitai. Jeigu ką plačiau domina ši tema siūlyčiau perskaityti Ken Schwaber (vieno iš Scrum bendraautorių ) knygą „The Enterprise and Scrum” (http://www.amazon.com/Enterprise-Scrum-Ken-Schwaber/dp/0735623376). Joje Ken detaliai ir su pavyzdžiais aprašo būtent kaip diegti ir taikyti Scrum didelėse kompanijose.
Kas buvo tikrai įdomu šiame pristatyme, jog Marija pateikė nemažai įdomios statistikos Agile tematika. Dalį šios statistikos galite rasti Dr. Dobb’s elektroniniame žurnale: “Agile Survey Results Released” (http://www.drdobbs.com/architecture-and-design/210201475) ir “Survey Says: Agile Works in Practice” (http://www.drdobbs.com/architecture-and-design/191800169)
Agile kituose pranešimuose
Nors kiti konferencijos pranešimai buvo apie SOA, Programinės įrangos testavimą, Kritinės grandinės projektų valdymą, kurį įsidiegė Alna Software, tačiau pristatymų kontekste vis iškildavo mintys ir klausimai susiję su Agile. Man klausant jų kilo šios išvados.
Agile dar yra “mistinis” terminas daugelyje kompanijų, dažnai naudojamas „nežinomai siekiamybei” arba „nežinomai baimei” apibrėžti. Dar nedaug kompanijų yra išsiaiškinę kas iš tikrųjų yra Agile, kas yra Agile metodai, o kas yra Agile praktikos. Taigi gal bus naudinga dar kartą pasikartoti.
Agile yra tiesiog bendras „skėtinis” terminas, apibrėžiantis produktų kūrimo metodus, kurie remiasi iteratyviu kūrimu. Jame reikalavimai ir sprendimai vystosi kūrimo procese glaudžiai bendradarbiaujant tarpfunkcinėms savarankiškoms komandoms. Šis terminas buvo įtvirtintas 2001 metais kai buvo suformuluotas Agile manifestas (http://agilemanifesto.org/).
Agile metodai yra konkrečios Agile principų realizacijos. Jie visi vadovaujasi tais pačiais Agile manifeste apibrėžtais principais, tačiau jų siekia skirtingais būdais. Keli Agile metodai: Scrum, Extreme Programming (XP), Feature Driven Development (FDD), Open Unified Process (OpenUP), Lean Software Development ir t.t.
Agile praktikos yra tiesiog geros techninės praktikos kurios gimė kartu su Agile metodais. Nepaisant to, tai yra tiesiog geros praktikos, tad jas taikyti galima bet kokiame procese. Keli Agile praktikų pavyzdžiai būtų: Test Driven Development (TDD), Behavior Driven Development (BDD), Code Refactoring, Continuous Integration, Pair Programming, Planning poker ir t.t.
Agile sutartys
Kita labai aiškiai jaučiama Agile „baimė” iš konsultacinių kompanijų (kompanijų kuriančių IT sprendimus pagal užsakymus) buvo: mes negalime dirbti pagal Agile nes mums reikia pasirašyti sutartis su klientais, kurie reikalauja fiksuotos kainos, funkcionalumo ir laiko apibrėžimo. Bet apie tai gan plati tema, tad palieku ją kitam blogo straipsniui ;)
Lauksiu jūsų komentarų, klausimų, pasiūlymų!