Archive

Tipiški ScrumButs

AOE media agentūra jau 2007-ais metais pradėjo įgyvendinti pirmus projektus su agile metodų pagalba ir padarė pirmą praktinę patirtį su planavimais, atsiliepimais ir retrospektyvomis – ir pasiekė pirmus rezultatus. Retrospektyvos greitai parodė, kad Scrum galima nuolat gerinti. Tačiau šioje vietoje reikėtų būti atsargiems: kas įveda Scrum, tam dažnai kyla didelė pagunda, tiesiogiai daryti savo Scrum pakeitimus (ScrumButs) ir svarbius elementus pašalinti dėl racionalumo. Tačiau dažnai pasirodo, kad paprasčiausiai buvo nesuprasta šių elementų svarba, kurie yra svarbūs sėkmei pasiekti. Tipiški ScrumBut pavyzdžiai yra:

Mes naudojame Scrum, tačiau mes…

  • atsisakome Scrum meistro, kadangi kolektyvas per mažas.

  • mums nereikia sudėtingo atskirų užduočių apimties vertinimo.

  • prailginame sprintus, kol pasiekiame tikslą.

  • apsieiname be retrospektyvų.

Absoliutus Scrum privalumas yra reguliarūs, nustatyti laikotarpiai (Timeboxes). Jeigu darbas nustatytos iteracijos metu nesuspėjamas atlikti, kolektyvas jokiu būdu neturėtų prailginti laikotarpio. Daugiau reikėtų galvoti apie tai, kaip suskirstyti projektą į mažesnius prieaugius. Šūkis yra: „Kaip padalinti dramblį?“. Kita rizika yra, kad Scrum meistras elgsis kaip projekto vadovas ir įsivaizduos save kolektyvo vadovu. Tačiau Scrum atveju kolektyvas yra autoritetas. Šalia to klientas turi būti pasiruošęs agile plėtrai – taigi nebegyventi ir nebegalvoti plano varoma plėtra, bet perimti produkto savininko rolę. Jei tai neįvyksta, projektą galima tik sunkiai įgyvendinti su Scrum pagalba. Visa tai priveda prie to, kad organizacijos (tiek kliento, tiek paslaugų teikėjo pusėje) su blogomis Scrum interpretacijomis greitai linksta link to, metodą mesti kaip netinkamą per bortą ir padaryti atsakingu už projekto nepasisekimą. Tačiau Scrum reikia būtinai įgyvendinti tiksliai. Vėliau galima padaryti prasmingus, įmonei tinkamus pakeitimus. Šie neturėtų būti tokie radikalūs kaip ScrumBut, tačiau pavyzdžiui galima pritaikyti Scrum meistro rolę. AOE media pavyzdžiui rado savo kelią ir žiūri į Scrum kaip į pagrindą, kurį galima pritaikyti skirtingiems projektams ir situacijoms.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/2/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

 

Scrum ir Kanban

Kaip veikia Scrum?

Kiekvienas Scrum projektas prasideda tuo, kad taip vadinamas produkto savininkas sukuria produkto neatliktų darbų sąrašą, pirmenybinį užduočių sąrašą kolektyvui. Jei produkto savininkas yra netiesiogiai klientas, šis gali užduotį perleisti ir proxy produkto savininkui, kurį pasiūlo užsakovas. Visos užduotys sudarytos iš sprintų (iteracijų), tiksliai nustatytų dviejų savaičių laikotarpių. Planavimo fazėje – sprinto „planavime“ – kolektyvas pasiima užduotis iš produkto neatliktų užduočių sąrašo, kurias realiai galima įgyvendinti nustatytu laiku. Bendrai nusprendžiama, kaip bus dirbama (kolektyvo susitarimas).

Kai produkto savininkas yra atsakingas už projekto sėkmę ir investicijų grįžimą, Scrum meistras rūpinasi tuo, kad visi suprastų procesą ir jo laikytųsi. Taip pat jis prižiūri, kad kolektyvas galėtų netrukdomai dirbti. Kiekvieno sprinto rezultatas yra projekto prieaugis (pavyzdžiui veikiantis kliento prisijungimas), kurio kokybė atlaikė peržiūros procesą ir kurį galima tiekti klientui. Toliau sekanti retrospektyva tikrina pabaigtą sprintą, atsižvelgiant į Scrum proceso kokybę: Kaip jaučiasi kolektyvas? Ar veikia priemonės? Kito sprinto pradžioje kolektyvas renkasi sekančias užduotis iš produkto neatliktų darbų sąrašo, kurias produkto savininkas nustatė kaip ypatingai svarbias – ir sekantis sprintas prasideda.

Kaip galima pritaikyti Kanban?

Daugybė agentūrų naudoja Scrum ir Kanban skirtingiems projektams ir kolektyvams. Priešingai nei Scrum, Kanban yra metodas, kuris turi užtikrinti nepertraukiamą darbo eigą (Flow). Tam yra vizualizuojamos visos užduotys ir procesai (taigi ir problemos, kurios šiom trukdo) ir daromos suprantamomis. Tai vyksta iškabos pagalba, kuri yra padalinta į eilutes ir skiltis (Lanes). Į šią iškabą keliauja visos užduotys bilietų virš atskirų skilčių forma. Kiekviena skiltis reiškia darbo žingsnį. Taip projekto dalyviai gali bet kuriuo momentu matyti, koks statusas yra priskirtas kokiai užduočiai.

Šalia to yra riba paraleliai vykstančioms užduotims. Tai reiškia, kad skiltyje „Plėtra“ pavyzdžiui vienu metu gali būti tik keturi bilietai. Tikslas yra, kad kiekvienas darbuotojas pagal galimybes dirbtų tik su viena užduotimi, o ne su keliomis paraleliai. Už to slypi darbo eigos mintis: bilietai turi eiti pagal galimybes vienodai ir be didelių laukimo pauzių arba blokadų per neatliktų užduočių sąrašą. Kas trukdo darbo eigą, yra analizuojama ir galimai šalinama. Šiuo būdu galima vizualizuoti proceso problemas ir jas viena po kitos išspręsti. Priešingai nei Scrum, Kanban vizualizuoja tik aktualų procesą, tačiau šio reikšmingai nekeičia.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile projektų valdymas

Agile projektų valdymo metodai kaip Scrum ir Kanban žada efektyvius procesus, motyvuotus darbuotojus ir patenkintus klientus. Tačiau neteisingas jų naudojimas gali paveikti ir į priešingą pusę. Praktinis tyrimas leidžia pažvelgti į sėkmės metodus taip pat į įgyvendinimo rizikas.

Scrum ir Kanban yra populiarūs agile metodai, kurie sparčiai plinta ir agentūrų pasaulyje. Priežastis: jie padeda IT užsakymus atlikti greičiau, saugiau ir sėkmingiau, nei tai būtų įmanoma su standartiniu projektų valdymu. Už žodžio „agile“ slypi idėja, plėtoti projektą arba produktą žingsnis pro žingsnio ciklais su save patį organizuojančiu, tarpdisciplininiu kolektyvu. Prasmė yra, užsakymą laikyti kuo mažesniu, dedant prioritetus, klientų norus įgyvendinti greitai ir vėlesnėse projekto fazėse lanksčiai reaguoti į pasikeitimus.

Idėjos varoma plėtra

Klasikiniame projektų valdyme planavimo ir specifikacijos fazė yra pagrindas, taip vadinamas „Big Design Up-Front“, pirmiausia nustatoma viso atliktino sprendimo apimtis. Dažnai projektų vadovai plėtodami projektą pastebi, kad neužtenka laiko ir biudžeto, kad viską įgyvendintų. Arba jie nustato, kas projekto kolektyvas dirbo šalia kliento ar rinkos poreikių. Pasekmės šios „Plano varomos plėtros“ yra stresas, nepasitenkinimas ir nepakankamas ekonomiškumas.

Agile prielaida apibrėžia jau pradžioje biudžetą kaip konstantą – ir žiūri kartu su klientu, kokius reikalavimus šioje apimtyje galima įgyvendinti. Čia kalbama apie „Idėjos varomą plėtrą“. Šio metodo privalumai aiškiai matomi: klientas gali nuo pat projekto pradžios dalyvauti ir atskiroms užduotims nuo iteracijos iki iteracijos suteikti prioritetą (Apimties valdymas). Išsamios specifikacijos būna tik tuomet, kai jos tikrai reikalingos. Be to kolektyvas gali tiesiogiai sekantiems žingsniams panaudoti mokymosi efektus iš praėjusių iteracijų. Reguliarus naujų versijų tiekimas, didelis skaidrumas ir aiški projekto pažanga, kurios metu sprendimo apimtis ir kokybė auga sulig kiekviena iteracija, padeda tiek plėtros kolektyvui tiek klientui – ir todėl, kad reguliarios retrospektyvos kuria geresnę nuotaiką kolektyve.

Šaltinis: http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile kritinis įvertinimas

Į klausimą, kaip agile vertybės gali būti paverčiamos į procesus ir metodus, gali duoti atsakymą agile įvertinimas.

Yra pasiūlymas su taip vadinamu agile matavimo indeksu programinės įrangos projektus vertinti taip pat kaip CMMI su pastoviais faktoriais. Panašiai pavadintas agile matavimo indeksas vertina programinės įrangos projektus 5 skirtingais matmenimis (trukmė, rizika, atradimai, pastangos ir sąveika). Toliau yra agile savęs įvertinimas, kad nustatytume, ar kolektyvas dirba agile būdu (Nokia testas, Karlskrona testas).

Yra ginčytina, ar programinės įrangos kūrimas taip gerai suprantamas, kad būtų galima tai daryti planiniu būdu: kritikai argumentuoja, kad programinė įranga yra ne kas kito kaip „vykdomos žinios“. Tačiau žinių negalima pagaminti inžineriniu būdu, kaip pavyzdžiui galima pastatyti tiltą arba namą, jos gaunamos kūrybingo proceso metu. Su tikslu, kad tiek tikslai, tiek aplinka (dalyvaujantys žmonės, rinkos reikalavimai, techninė aplinka, sąsajos) yra lankstūs ir gali pasikeisti su laiku.

Su agile metodais galima labai greitai reaguoti į pasikeitusius reikalavimus, kadangi kūrimo ciklai paprastai nuo pat pradžių yra trumpalaikiai. Reikalavimai paprastai nustatomi trumpais aprašymais ir suformuluojami tiktai prieš pat projekto įgyvendinimą ir testavimą. Trumpo laiko dėka reikalavimai yra pakankamai atskirti nuo vėlesnių pakeitimų.

Tiesą sakant nei V Modelis nei RUP nedraudžia agile elementų kaip Greitas Prototipas panaudojimo nei prieš reikalavimų kūrimą bei dizaino aprašymą nei jų vykdymo metu. Bendrai pažiūrėjus projektams reikalingas agile procesas, vien tam, kad atsižvelgtume ir integruotume pasikeitimus, kurie iškyla projekto metu. Procesų modeliai padeda, šiuos pasikeitimus įtraukti į projektą.

Sudarant sutartį turi būti atsižvelgta į agile proceso būdų savybes. Aiškūs turinio nurodymai yra nelabai įmanomi, kadangi reikalavimai vystomi projekto eigos metu.

Dėl sąmyšio apie agile metodus į šiuos kartais neteisingai žiūrima kaip į visagales priemones iškilus projektų problemoms. Taip aišku nėra: pagrindinės kliūtys galioja tiek agile tiek tradiciniams procesams.

Pasak Standish Chaoso ataskaitos 2011-ais metais, projektai, kurie buvo sukurti su agile metodika, turi ženkliai didesnę tikimybę būti sėkmingai užbaigtais. Jei krioklio metodikos panaudojime tik 14 procentų projektų yra sėkmingi, 57 procentai probleminiai ir nepavykę 29 procentai, priešingai tam projektai su agile metodika yra 42 procentai sėkmingi, 49 procentai probleminiai ir tik 9 procentai nepavykę. Koblenco universiteto, Vokietijos Projektų Valdymo Bendrijos ir Tarptautinio Projektų Valdymo Status Quo Agile tyrimas parodė visų tirtų krypčių pagerintą agile metodų efektyvumą palyginus su klasikiniu projektų valdymu. Tuo tarpu Scrum buvo įvertintas ypač gerai. Tyrime dalyvavo daugiau nei 600 dalyvių iš 30 šalių.

Šaltinis: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile metodų ir procesų privalumai

Agile metodas

Griežtai pažiūrėjus agile metodas reiškia į judrumą nutaikytą programinės įrangos kūrimą.

Agile metodų požymis yra tai, kad jie viename procese gali tarnauti palaikant kuo mažesnes pastangas. Jų šūkis yra: kuo daugiau tu dirbsi pagal planą, tuo daugiau gausi to, ką susiplanavai, bet ne tai, ko tau reikia. Iš ten kilo keli agile modeliavimo ir ekstremalaus programavimo principai.

Agile metodus galima padalinti į dvi grupes: į tikrus metodus ir į principus, kuriais pagrįsti metodai.

Agile metodų pavyzdžiai:

  • Programavimas poromis

  • Į testus orientuotas kūrimas

  • Nuolatinis pertvarkymas

  • Istorijos kortelės

  • Greita kodo apžvalga

Agile procesas

Veikimo tikslas yra, programinės įrangos kūrimą padaryti efektyvesniu, atsisakant biurokratijos ir daugiau atsižvelgiant į žmogiškus aspektus.

Dauguma agile procesų paremti tuo, kad jie bando gryną projektavimo etapą sumažinti kaip galima daugiau ir kūrimo procese kuo greičiau tiekti veikiančią programinę įrangą, kuri reguliariais, trumpais laikotarpiais gali būti pateikta klientui bendram aptarimui. Šiuo būdu bet kuriuo momentu turi būti įmanoma, lanksčiai reaguoti į kliento norus, tuo padidinant kliento pasitenkinimą. Tuo jie skiriasi nuo klasikinių veiksmo modelių kaip V Modelis arba Rational Unified Process.

Visiems agile procesams yra bendra, kad jie remiasi daugybe metodų, palaikyti kuo mažesnes pastangas. Tuo tarpu jau yra galybė agile procesų. Prie žinomiausių priskiriami:

  • Prisitaikančios programinės įrangos kūrimas
  • Crystal

  • Ekstremalus programavimas

  • Ypatybe varomas kūrimas

  • Kanban

  • Scrum

  • Agile testavimas

  • Elgesiu varomas kūrimas

Rational Unified Process daugumos agile metodų atstovų (dauguma jų pasirašė Agile Manifestą) yra traktuojamas kaip ne agile, sunkiasvoris procesas. Tiesa, tai yra ginčytina arba buvo bandoma su Agile Unified Process išvystyti agile RUP variantą.

Šaltinis: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime

Agile vertybės, metodai ir principai

Agile vertybės sudaro fundamentą. Agile principai pagrįsti agile vertybėmis ir sudaro veiksmo pagrindus. Agile metodai yra konkretūs procesai programinės įrangos kūrimo metu, kurie remiasi vertybėmis ir principais. Agile procesas yra visų pritaikomų metodų sąranka ir tarnauja agile programinės įrangos kūrimui.

Agile vertybės

Agile programinės įrangos kūrimo vertybės sudaro fundamentą. 2001-ais metais 17 pirmųjų pasirašiusiųjų suformulavo šias vertybes kaip Agile Manifestą.

Mes atrandame geresnius kelius, kurti programinę įrangą, darydami tai patys ir padėdami kitiems. Šios veiklos metu mes išmokome šių vertybių:

1. Žmonės yra svarbiau nei procesai ir priemonės

2. Veikianti programinė įranga yra svarbiau nei išsamios dokumentacijos

3. Bendradarbiavimas su klientu yra svarbiau nei derybos dėl sutarties

4. Reagavimas į pasikeitimus yra svarbiau nei plano sekimas

Tai reiškia, kad nors mes vertiname vertybes dešinėje pusėje, vertybes kairėje pusėje vertiname labiau.“

Manifestas nurodo autorius ir pirmuosius pasirašiusiuosius, kurie dirba įvairiose agile programinės įrangos kūrimo srityse. Pasirašiusiųjų sąrašas apima tūkstančius asmenų ir toliau auga.

Agile principas

Agile principas yra agile darbo šūkis.

Kartais agile principai vadinami ir metodu. Iš esmės neteisingas sąvokos metodas panaudojimas principams agile metodų atstovų yra naudojamas tikslingai. Sunkių procesų metu sudėtingų metodų aprašymai užgožia principus ir dažnai principai yra pamirštami. Šalia to procesai anksčiau buvo aprašomi pagrinde per metodus, o ne per principus. Principų kaip metodų išvardijimas turi suteikti principams daugiau vertės nei formaliems metodams. Agile Manifeste išvardinti dvylika principų.

1. Kliento patenkinimas išankstiniu ir nepertraukiamu vertingos programinės įrangos tiekimu

2. Agile procesai naudoja pasikeitimus (netgi vėliau kūrime) kliento pranašumui

3. Veikiančios programinės įrangos tiekimas reguliariais, ypač trumpais laikotarpiais (kelios savaitės arba mėnesiai)

4. Beveik kasdienis bendradarbiavimas su ekspertais ir kūrėjais projekto metu

5. Aplinkos paruošimas ir parama, kuri reikalinga motyvuotiems individams užduoties atlikimui.

6. Informacijos teikimas pagal galimybę pokalbyje akis į akį

7. Svarbiausias pažangos rodiklis yra programinės įrangos veikimas

8. Užsakovų, kūrėjų ir vartotojų vienodo darbo tempo laikymasis tvariam kūrimui

9. Pastovus techninio pažangumo ir gero dizaino stebėjimas

10. Paprastumas yra svarbiausia (KISS principas)

11. Kolektyvo saviorganizacija planavimo ir įgyvendinimo metu

12. Kolektyvo savirefleksija yra svarbiau nei savo veiksmų pritaikymas efektyvumo gerinimo atžvilgiu

Perėjimas tarp principų ir metodų yra laisvas.

Šaltinis: https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Planuojate vertingus pokyčius savo organizacijoje?

Susisiekime