Ultima introducere în managementul agil de proiect

Scurtul

Sunteți responsabil cu livrarea celei mai recente și mai bune inițiative a companiei dvs., care va schimba pentru totdeauna fața „Widgets International”. Este un proiect software care va implica și va captiva clienții dvs., va ușura viața colegilor și va face companiei venituri de milioane. Există multă anticipare, fervoare, entuziasm și așteptare. Trebuie să o faci cât mai repede posibil, astfel încât afacerea ta să poată începe să culeagă beneficiile. Succesul viitor al companiei depinde de tine. Toate privirile sunt asupra ta. Nu poți da greș.

La început, te gândești pentru tine: „Genial, sunt pregătit pentru provocare. Să terminăm chestia asta!” Te oprești pentru o clipă, dai înapoi și te gândești „Bine, deci cum facem asta?” Începi să vorbești cu colegii și colegii tăi. Petreceți timp căutând cele mai bune practici de dezvoltare software și tehnici de management de proiect, dar opțiunile și abordările sunt nenumărate. Există acronime și metodologii din abundență. Cele notabile se ridică în vârf. Se strecoară îndoiala. Pe care ar trebui să-l folosim? Cum pot garanta succesul? Ce se întâmplă dacă iau decizii greșite?

Când vine vorba de gestionarea proiectelor software, există un amestec amețitor de opțiuni susținute de nenumărate opinii. Voci din colțurile camerei șoptesc: „Încearcă să faci așa”; alții strigă: „Acesta este singurul mod de a face asta”; iar restul doar scâncește: „Nu te descurca deloc, mergi mai departe”. În realitate, toate acele voci spun ceva adevăr. Dar ceea ce este important este să găsești ceea ce este potrivit pentru nevoile tale, echipa, afacerea și clienții tăi.

Pregatind scena

A fost o perioadă în care managementul proiectelor software stătea drept într-una din cele trei tabere. Au existat cadre grele care vă permit să luați decizii cu privire la modul în care executați și livrați, oferind în același timp o structură pentru a menține controlul și guvernanța. Au existat metodologii secvențiale prescriptive, cum ar fi cascada, care v-au forțat să planificați proiecte de lungă durată, să înțelegeți și să vă implicați în toate cerințele, să proiectați și să semnați sisteme complexe, să scrieți o mulțime de coduri și apoi să testați (totul înainte ca clientul să-l vadă pentru prima dată). timp). Și, în sfârșit, ciclurile de viață de dezvoltare a software-ului (SDLC) mai puțin prescriptive, dar iterative, care încurajează proiectarea, construirea și livrarea sistemelor mai mari de prototipuri rapide, în etape incrementale, fiecare construindu-se deasupra celuilalt.

Dezvoltarea agilă de software și managementul agil al proiectelor s-au născut din insuficiența cascadei și beneficiile abordărilor iterative ale furnizării de software. Își pot urmări rădăcinile în anii 1950, conducerea gândirii în anii 70, maturitatea în anii 90 și adoptarea până în anii 00. În 2001, un grup de practicieni și experți a creat Manifestul Agile, care vizează definirea a 4 valori și 12 principii directoare care urmăresc să întruchipeze spiritul dezvoltării software Agile și să încurajeze evoluția acestuia. Și cu siguranță a evoluat.

Acum, pur și simplu numirea ceva Agile nu este deosebit de utilă. Cuvântul, chiar și într-un context software, înseamnă lucruri diferite pentru diferiți oameni sau organizații. Există multe fațete, definiții, implementări și interpretări. Fiecare corp care îmbrățișează Agile tinde să încerce să-i dea propria sa definiție.

Este suficient să spunem că dezvoltarea software-ului Agile și managementul de proiect sunt un grup de comportamente, cadre, tehnici și concepte înrudite care favorizează în mod fundamental livrarea software-ului potrivit cât mai devreme și cât mai frecvent posibil în mod realist.

Am menționat mai devreme că Agile, așa cum este aplicat dezvoltării software sau managementului de proiect, poate fi lucruri diferite. Pe scurt, dezvoltarea software Agile se ocupă de dezvoltarea unui software excelent într-un context de business ca de obicei (BAU) sau de proiect. Managementul agil al proiectelor, pe de altă parte, are grijă de guvernanța și controlul necesar pentru a livra proiecte complexe, inclusiv, dar fără a se limita la software.

Există multe metode de dezvoltare software Agile disponibile, cum ar fi Scrum, Kanban, XP și Lean Software Development. Dar la fel cum jocul de rugby este mai mult decât scrum, la fel este și Agile. În mod izolat, aceste paradigme Agile nu abordează întregul ciclu de viață al managementului de proiect necesar în proiecte complexe, cum ar fi guvernanța, resursele, managementul financiar, explicit al riscului și multe alte concepte importante de management de proiect. Pentru acestea, ați putea dori să luați în considerare PMI Agile sau PRINCE2 Agile - gândiți-vă la asta ca fiind „agilitate guvernată”.

De ce trebuie să fim agili?

Cu mult timp în urmă, cutreieram pământul pentru a aduna hrană și adăpost pentru a supraviețui. Erau nevoi simple, dar destul de agile. Un timp mai târziu, țările și economiile au crescut și au prosperat pe spatele revoluției industriale. Aceasta a fost nașterea managementului și controlului și pierderea agilității. Acum suntem în era informațională sau revoluție, în care întreprinderile angajează lucrători în cunoștințe. Lucrătorii de cunoaștere sunteți tu, partenerii tăi și colegii și colegii tăi, care se străduiește să creeze soluții excelente pentru problemele clienților, de afaceri, sociale, economice și mondiale. Lucrătorii de cunoaștere aplică analiza, cunoștințele, raționamentul, înțelegerea, expertiza și abilitățile la nevoi adesea vag definite și în schimbare. Aceste întreprinderi și lucrători au nevoie de metode și tehnici care nu pot fi îndeplinite de procesele și procedurile vechi ale epocii industriale. Agile sprijină interacțiunile.

Practic, niciun proiect de software nu poate porni cu încredere de la început și știe tot ce are nevoie pentru a furniza software valoros, fără modificări. Schimbarea prezintă atât oportunități, cât și riscuri pentru succesul unui proiect. Oportunitățile negestionate pot însemna diferența dintre o companie grozavă și o companie minunată. Riscul negestionat înseamnă dezastru și ruină. Agile gestionează schimbarea.

Adoptarea Agile vă permite să răspundeți la cerințele în schimbare sau noi. Dă putere echipelor de dezvoltare să fie experți și să ia decizii susținute de o afacere implicată, de încredere și informată. Vă permite să oferiți clienților ceea ce își doresc cu adevărat. În cele din urmă, vă pune pe dvs. și organizația dvs. controlul furnizării de software valoros, de înaltă calitate, care să răspundă nevoilor și așteptărilor clienților, obținând în același timp o rentabilitate a investiției dvs. cât mai curând posibil. Agile creează valoare.

Există un cost pentru adoptarea Agile. Nu vine gratis. Transformarea la o abordare Agile pentru livrarea de software poate fi o cale greu de urmat. Cu toate acestea, dacă interiorizezi filozofia Agile, mergi cu atenție, angajezi echipa potrivită cu atitudinea potrivită, descompune lucrurile, o faci realizabilă și realistă și răspunzi la feedback, vei culege recompense. Agile pune accent pe colaborare.

Următoarele enumeră câteva beneficii la care vă puteți aștepta:

• Viteză la piață
• Generarea de venituri mai devreme
• Livrare regulată a valorii reale
• Protecție pentru investiția ta
• Date, date, date
• Calitate mai bună a produsului
• Așteptări gestionabile
• Satisfacție mai mare a clienților
• Echipe mai performante
• Vizibilitate îmbunătățită asupra progresului
• Previzibilitate, transparență și încredere
• Risc gestionabil

Succesul nu este definitiv, eșecul nu este fatal: curajul de a continua este cel care contează.

Poate că Winston Churchill nu a spus niciodată asta, dar cred că este o rezumare destul de bună a Agile. Știm că Agile este cel mai bun pas înainte pentru majoritatea proiectelor. Te încurajează să te străduiești pentru succes, dar mereu repetăm ​​și continuăm să construim pe el. Agile te va încuraja să eșuezi, dar eșuează devreme și mergi mai departe. A avea curajul de a continua și de a construi soluția potrivită bazată pe perspectivă informată de clientul tău este ceea ce aduce recompensa.

Lucrul de reținut este că puteți adapta Agile la nevoile dvs. Utilizați metoda și guvernarea potrivite pentru afacerea dvs. Oriunde începeți, fiți fidel conținutului, contextului și spiritului metodei pe care o utilizați - păstrați-o vanilie. Dacă abia ești la început, învață . Dacă o faci de ceva vreme, înțelege . Dacă devii minunat, aplică . În cele din urmă, dacă afacerea și proiectele tale sunt complexe și interdependente, guvernează . De-a lungul timpului, tu și echipele tale veți afla ce funcționează cel mai bine pentru afacerea dvs.

Fezabilitate

Așa că acum te gândești: „Bine, am înțeles. Cum sa incep? De unde să încep?” Ei bine, cu toate lucrurile bune, începem de la început. Și cu Agile, este prin a te întreba „Ce valoare de afaceri vreau să ofer?” Până la urmă, de aceea întreprindem proiecte, pentru a genera valoare de afaceri. Pentru a stabili dacă proiectul merită întreprins pentru a obține valoarea afacerii, trebuie să înțelegeți dacă este fezabil.

Viziune

Proiectul dumneavoastră este proiectat să crească veniturile, să intre pe o nouă piață, să dobândească mai mulți clienți, să îmbunătățească percepția clienților sau să ușureze viața pentru o anumită problemă pe care ați identificat-o? Având în vedere acest lucru, vă puteți declara „viziunea”.

• Viziunea dvs. poate proveni din diferite surse - propriul dvs. startup îndrăzneț pentru a rezolva o problemă comună, strategia de management al afacerii, proiectul de companie al CEO-ului dvs., o anumită echipă de produs sau chiar nevoile clienților dvs.
• Încercați să faceți un pas înapoi de la pantofii dvs. și „vedeți” cum arată viitorul cu noul dumneavoastră produs sau serviciu în mâinile clienților dumneavoastră.
• Implicați-vă părțile interesate - CEO-ul, tipul de produse și clienții. Atelierează-l, nu încerca asta izolat. Provocați ipotezele și validați argumentele.
• Notează-l, păstrează-l scurt. Concentrați-vă pe valoarea afacerii.
• Rafinați-l până când sunteți cu toții de acord că viziunea rezonează cu toată lumea și întâlnește o interpretare comună care afirmă încotro vă îndreptați.
• Viziunea ta, dacă este valabilă, se schimbă rar. Cum vei ajunge acolo cu siguranță va fi.

Oamenii nu cumpără ceea ce faci sau cum faci asta. Ei cumpără „de ce” o faci. Acesta este ceea ce creează legătura emoțională între afacerea dvs. și clienții dvs. Viziunea va ajuta la ilustrarea acestui lucru.

Este fezabil?

Fezabilitatea vine în cel puțin câteva nuanțe. De obicei, veți dori să înțelegeți dacă viziunea dvs. despre un viitor mai luminos pentru afacerea dvs. și pentru clienți este fezabilă din punct de vedere tehnic și că este fezabilă pentru afacerea dvs. să o realizeze.

• Dacă viziunea dvs. este să călătoriți oriunde în lume în mai puțin de o oră, este posibil să aveți o problemă cu fezabilitatea tehnică. Deoarece știința, fizica și tehnologia nu au ajuns încă din urmă cu acel vis, soluția ta tehnică poate să nu fie viabilă în altceva decât în ​​teorie. În plus, dacă soluția dvs. ar fi nouă, aceasta ar depăși cu mult ideea unui produs minim viabil (MVP).

• Pentru a testa fezabilitatea tehnică a produsului dvs., luați în considerare fie să îl explorați în continuare într-un proiect prototip Discovery, fie prin executarea unui vârf în primele etape ale proiectului. Veți ști ce metodă să utilizați gândindu-vă la amploarea sau complexitatea soluției pe care o aveți în vedere.

  „Unele dintre cele mai bune cunoștințe pe care echipele mele le-au dobândit în înțelegerea fezabilității tehnice provin din efectuarea unui vârf. Și adesea, este cea mai simplă soluție care câștigă!”

• A doua nuanță de fezabilitate pe care trebuie să o luați în considerare este dacă dvs., echipa sau afacerea dvs. aveți abilitățile și motivația pentru a o face să funcționeze. Folosind un exemplu, dacă ești grozav la coacerea prăjiturii acasă de ziua copiilor tăi, este dulce. Dar dacă doriți să transformați acest lucru într-o afacere care vinde cele mai bune prăjituri lumii, trebuie să înțelegeți dacă puteți să o extindeți, să vă ocupați de afacere, precum și de producție, să gestionați distribuția și îndeplinirea și să vă ocupați de serviciul pentru clienți.
• Acest tip de viziune ar putea fi realizabil pe termen lung. Dar deocamdată, poate că nu. Așadar, scalați-l înapoi, gândiți-vă mic, luați o bucată mică care pare realistă și concentrați-vă pe furnizarea celei mai mici aspirații posibile. Dacă acest lucru reușește să atragă și să încânte clienții, fă-i să revină pentru mai multe și să le spună prietenilor, apoi extinde-l de acolo folosind feedback-ul clienților ca ghid și busolă.
• De asemenea, trebuie să știi dacă proiectul tău este fezabil din punct de vedere al bugetului și al intervalului de timp. Îți poate permite afacerea să livreze acest proiect? Este intervalul de timp realizabil? Timpul și banii sunt două dintre cele trei constrângeri ale unui proiect Agile care sunt remediate. Ne propunem să livrăm într-un anumit timp fix și într-un anumit buget fix.
• Calitatea unui produs se referă la produsul final pe care îl folosesc clienții tăi și la practicile de inginerie pe care echipa ta le folosește pentru a oferi un software excelent, robust și de încredere. Calitatea este, de asemenea, ceva pe care nu îl schimbăm pe scurt. Criteriile de calitate, pe de altă parte, se pot schimba. Dacă nu vă propuneți să construiți un Ferrari, este posibil ca produsul să nu aibă o percepție de înaltă calitate. Dacă nu construiți rachete spațiale, atunci toleranțele atinse în termeni de producție pot fi mult mai mari. Stabiliți devreme tonul și așteptările adecvate.

Așa că acum ați confirmat că visul dvs. este mai mult decât fantezie de ciocolată, începeți să vă testați presupunerile și să le demonstrați oamenilor că merită să investiți în acest demers.

Justificare

Acum, în funcție de circumstanțele dvs., justificarea va veni sub diferite forme. Dar, în esență, doriți să demonstrați că acest proiect va satisface criteriile de succes ale clienților, are șanse de succes, va oferi valoare și este accesibil.

• Spuneți ipotezele dvs. în funcție de nevoile clienților dvs., apoi validați-le. Lean Startup oferă îndrumări excelente pentru identificarea și demonstrarea faptului că produsul dvs. este necesar pentru clienții dvs. și va crea valoare.

• Scrieți, testați și validați-vă planul de afaceri. Acum, acestea nu seamănă deloc cu cele pe care banca dumneavoastră sau directorul de afaceri și finanțe v-au spus să le produceți. Nu le folosiți - vor fi depășite înainte ca cerneala să se usuce. În schimb, consultați Business Model Canvas. Acesta este în esență un plan de afaceri scurt, care vă menține concentrarea pe propunerea dvs. de valoare, clienții, veniturile și costurile. Folosiți-l pentru a valida dacă aveți o afacere care va funcționa.

  „Am ignorat acest sfat o dată și am petrecut mult timp scriind un plan tradițional de afaceri lung de 50 de pagini. Nu m-a dus nicăieri. Toate ipotezele pe care le făcusem au fost nefondate și toate proiecțiile pe care le-am făcut nu au putut fi validate. A fost o experiență dureroasă și costisitoare care m-a învățat să nu o mai fac niciodată.”

• Dacă sunteți într-o afacere matură, cu portofolii de proiecte livrate într-un mediu complex, atunci poate fi necesară modelarea financiară. Dacă trebuie, faceți acest lucru numai după ce ați dovedit cele de mai sus.
• Odată ce v-ați construit MVP-ul, poate exista un caz pentru crearea unui plan de afaceri mai tradițional, de exemplu, dacă trebuie să căutați finanțare sau selecție în portofoliul companiei dvs. de proiecte și resurse concurente. Dar acesta va fi un plan de afaceri bazat pe și informat de instrumentele folosite mai sus. Va fi si mai usor.
• În orice caz, utilizați aceste instrumente ca artefacte vii, care respira. Folosiți-le ca ghid și ca punct de plecare. Nu sunt niciodată statice. Consultați-le și revizuiți-le pe măsură ce proiectul sau afacerea dvs. evoluează.

Odată ce ai justificarea și toate părțile interesate sunt la bord, vei fi în flăcări.

Faza de fezabilitate se desfășoară de obicei o dată în viața proiectului dumneavoastră. S-ar putea să descoperiți că revizuiți viziunea și fezabilitatea proiectului, mai ales dacă datele, clienții, piața sau afacerea dvs. indică acest lucru. Cel puțin, acestea vor fi luminile tale de ghidare pe tot parcursul.

Iniţiere

Minunat. Decizia a fost luată, proiectul are undă verde și ești gata să construiești. Ei bine, aproape. Știu că te gândești: „Hai deja, într-adevăr? Dacă nu facem asta acum, nu o vom face niciodată. Să punem acest spectacol pe drum!” Dar luați în considerare acest lucru: Agile nu înseamnă decât să oferiți valoare devreme și adesea, în timp ce vă încântați clienții pe parcurs. A-ți lua ceva timp pentru a descoperi cea mai bună modalitate de a-ți livra proiectul este cea mai bună bază pentru succes.

Echipa

În sport, gândindu-vă la jocul preferat de echipă, veți putea recunoaște rolurile cheie care permit echipei să performeze așa cum o fac. În mod tradițional, vei găsi un manager, un căpitan și restul echipei. În afară de aceasta, veți găsi antrenori, kinetoți, nutriționiști și un sortiment de personal de sprijin. Dar dacă ne uităm la jocul de rugby, există o echipă în cadrul unei echipe: jucătorii care alcătuiesc scrumul. Acest pachet este format din jucători desemnați a căror sarcină este să recâștige mingea și să continue jocul. Când este în joc un scrum, jucătorii din fiecare parte lucrează, fără lider, ca o singură unitate, cât mai colaborativ, comunicativ și eficient posibil pentru a recupera mingea în posesie. Jocul de rugby l-a inspirat pe Jeff Sutherland să-și numească metodologia de dezvoltare software „Scrum”.

• Scrum nu este singura metodă de dezvoltare software din manualul Agile. Dar este cel care descrie cel mai bine conceptul și comportamentele Agile de lucru în echipă, motivarea indivizilor, crearea de relații de încredere, auto-organizare, servitor-leadership, comunicare, transparență și colaborare.
• Echipa dvs. va fi formată în mare parte din circumstanțele în care vă aflați. Este posibil să aveți dezvoltatori la dispoziție. Unii, niciunul sau toți ar putea fi familiarizați cu Agile în diferite grade. Poate doriți să angajați o nouă echipă sau un partener cu o terță parte.
• Vor fi necesare și alte roluri, dar despre acestea le vom discuta mai târziu.
• S-a spus că dacă formați echipa de dezvoltare, atunci v-ați ales tehnologia. În funcție de locul de unde vă reuniți echipa, acestea vor veni cu seturi de abilități specifice. Așadar, gândiți-vă cu atenție cum vă formați echipa de dezvoltare și dacă trebuie să efectuați o evaluare tehnică înainte de a ajunge la acest punct al călătoriei dvs.
• Acest lucru ne aduce la echipe interfuncționale. Echipele funcționează cel mai bine atunci când lucrează împreună, când indivizii intervin pentru a-și îndeplini treaba, indiferent de titlul lor. Încercați să construiți o echipă care să fie autosuficientă și indivizi care să-și asume mai multe roluri.
• Construiți un mediu, cultură și centru de relații - un loc în care echipa poate livra, fără constrângeri sau restricții. Oferiți echipei instrumentele, oamenii, resursele și spațiul pentru a fi eficiente și performante.
• Păstrați dimensiunile echipei la cel mult șapte sau opt. Dacă aveți nevoie de mai mulți dezvoltatori, împărțiți echipa în mai multe echipe noi. Fiecare echipă ar putea fi responsabilă pentru o anumită zonă funcțională. Dacă aveți mai multe echipe în mai multe locații, luați în considerare un Scrum of Scrums. Și acolo unde acestea sunt numeroase în medii complexe, utilizați managementul de proiect Agile.
• Asigurați-vă că echipa, afacerea, părțile interesate și chiar clienții au acces unul la altul. Asigurați-vă că comunică și colaborează și eliminați orice împiedică progresul. Comunicarea zilnică este cel mai bun remediu pentru afecțiunile proiectului. Când oamenii vorbesc, termină lucrurile.

Există multe moduri în care o echipă poate fi formată pentru a furniza software.

Rezumatul proiectului

În etapa de fezabilitate, v-ați dat seama de „de ce” proiectul dvs. și fie v-ați creat încrederea pentru a merge mai departe cu startup-ul, fie ați primit sprijin pentru a continua. Brief-ul proiectului este documentul viu care reunește „de ce” cu „ce” și „când” și „cine”. Este „viu” pentru că, pe măsură ce progresezi, cunoștințele, înțelegerea și calea ta se pot schimba. A lăsa acest document scris o dată și a nu mai reveni niciodată la el doar îți trimite gândurile la un moment dat. Într-o lume Agile, referința la un moment dat se poate schimba săptămânal sau chiar zilnic la început, așa că este important să păstrați acest lucru actual.

• Un instrument excelent pentru încapsularea și menținerea rezumatului proiectului este ceva pe care Jonathan Rasmusson îl numește „deck inception” în cartea sa The Agile Samurai . Aici veți găsi sfaturi grozave pentru a vă asigura că toți cei interesați, afectați sau implicați în proiectul dvs. sunt pe aceeași pagină.
• Cel mai mare dușman al realizării proiectelor este acela de a avea o înțelegere neclară, inconsecventă sau pur și simplu diferită a proiectului și a „cerințelor” care trebuie îndeplinite. Dacă chiar și o parte interesată importantă are o înțelegere sau o viziune diferită asupra a ceea ce faci, consecințele pot fi substanțiale.
• Un scurt proiect bun comunică:
  1. O așteptare comună și convenită între părțile interesate și membrii echipei.
  2. O înțelegere a proiectului, cu aceeași înțelegere între toate părțile.
  3. Scopul, viziunea, obiectivul, domeniul de aplicare și contextul proiectului.
• Veți avea o mulțime de informații bune pentru brief-ul adunat din fezabilitate. Rezumatul proiectului vă va ajuta să definiți și să găsiți răspunsurile la întrebările de căutare. Acesta va reuni părțile interesate, rațiunea dvs. de a fi, domeniul de aplicare la nivel înalt, riscurile, soluția țintă, bugetul, calendarul, așteptările și prioritățile.

Un coleg m-a oprit odată pe un coridor și m-a întrebat de unde poate obține brief-ul proiectului pentru proiect. Am glumit: „Nu avem nevoie de un brief, suntem Agile”. Părea confuz, de parcă ar fi pus sub semnul întrebării mintea mea sau autoritatea. A avut dreptate să facă asta.

Înainte de a continua, asigurați-vă că îi aveți pe toți pe aceeași pagină, pregătiți-vă, puneți întrebările dificile și găsiți-l undeva unde oamenii se pot opri, citi, comenta și ajuta la revizuirea lui.

Cultura și moduri de lucru

Știți cum funcționează afacerea dvs. și cultura ei, felul în care îi place să facă lucrurile. Agile, prin însăși natura sa, poate provoca unele dintre aceste moduri de lucru pe care afacerea dvs. le-a cultivat de-a lungul anilor. Nu vă așteptați ca Agile să fie implementat și ca toată lumea să-l adopte cu dragoste de la început. Unii oameni s-ar putea să-l considere confuz și să îl privească doar cu teamă și teamă. Unii oameni pot refuza în mod deschis să se implice în asta. Acestea sunt provocări și percepții pe care trebuie să le depășiți. Dar la începuturile tale, nu umbla cu băţul Agile, bătând pe oricine care nu vrea să asculte cu el. Asta nu va genera încredere, adopție sau implicare.

Odată am fost un fan a flutura bețe proverbiale mari și mi-a câștigat multă presă negativă. Am întors-o, dar nu înainte de a suferi mai întâi o durere considerabilă.

Pe măsură ce porniți pe calea adopției, mergeți cu atenție, respect și empatie. Dacă sunteți într-o afacere tradițională veche, poate că nu va fi cea mai bună abordare pentru a alinia întreaga afacere. Începeți cu puțin și câștigați treptat respect și recunoaștere. Începe doar cu echipa ta. Odată ce începeți să oferiți software mai rapid și cu o calitate mai bună decât oricând, oamenii vor începe să observe și vor dori să vină să vă joace jocul. Când o fac, oferă-le mingea, scoate-le la o cafea și introdu-le în noua ta lume. Ajuta-i.

Cu echipa ta, acum că știu despre ce este proiectul și că planurile tale pentru adoptarea Agile sunt convenite, lasă-i echipa să decidă cum dorește să se comporte și să opereze ca o echipă.

• Ghidați-vă echipa să identifice conceptele, tehnicile, comportamentele și cadrele Agile care considerați că se potrivesc nevoilor dumneavoastră colective.
• Acceptați solicitările membrilor echipei dvs. cu privire la cerințele pe care le au pentru a-i ajuta să performeze cât mai bine. Unele dintre aceste solicitări, le veți putea rezolva imediat. Alții, s-ar putea să aveți nevoie de buget sau ajutor extern. Fă tot ce poți ca să se întâmple.
• Aceștia sunt primii tăi pași pentru a deveni un adevărat slujitor-lider.
• Luați în considerare organizarea unor instruiri adecvate în conceptele și tehnicile pe care echipa dvs. alege să le adopte. Acesta este cel mai bun mod de a vă asigura că toți membrii echipei, chiar și părțile interesate, sunt pe aceeași pagină și primesc același mesaj. Lucrați cu o organizație de furnizori care își poate adapta oferta la nevoile dvs.
• Fii prudent. Nimeni nu va fi un ninja Agile după câteva zile într-un atelier care învață cum să devină Agile. Drumul tău va fi lung. Cuvântul „deveni” este destul de definitoriu. Numai atunci când îmbrățișați cu adevărat Agile îi veți vedea valoarea. Ar trebui să te entuziasmeze. Dacă te entuziasmează, atunci du-te să entuziasmezi și pe alții.
• Acum că echipa dvs. a căzut de acord asupra conceptelor și tehnicilor, și-a îndeplinit dorințele și sunt în curs de formare Agile, îndreptați atenția echipei dvs. asupra ei înșiși și a ceea ce așteaptă de la dvs., de la afacere și de la unii alții.
• Definirea unor moduri de lucru (WoW) în cadrul și de către echipă ajută la construirea încrederii, a relațiilor și a așteptărilor. WoW nu este război și pace . Ar trebui să fie scurt și la obiect, între șapte și zece propoziții cu marcatori. Aceste propoziții indică clar modul în care oamenii se comportă, comunică, colaborează, susțin, livrează și performează împreună. De asemenea, ar trebui să precizeze ce așteptări echipa de la afacere.

• Agile este atât de mult o mentalitate, cât și principii și concepte călăuzitoare. Vă ajută să vă dezvoltați în modul în care vă comportați, gândiți, negociați, interacționați, comunicați, performanța și îmbunătățirea. Se bazează pe indivizi motivați care se sprijină reciproc pentru a atinge un scop comun, împreună ca una singură. Există un proverb african:

Până acum, echipa ta ar trebui să fie super entuziasmată, plină de energie și motivată. Acum, implicați-i și mai mult cu acumularea de povești ale utilizatorilor.

Restante

Nu ai nicio îndoială în mintea ta că există incertitudine implicată în proiectul tău. Nu poți ști exact ce va fi nevoie pentru a construi produsul potrivit pentru clienții tăi atât de devreme în viață. Nu poți privi cu tristețe o minge de cristal și să prezici viitorul.

„Arama” sau „produs” este locul unde trăiesc cerințele dvs. Agile favorizează scrierea de declarații scurte și concise, care surprind esența unei „cerințe”. Restul este pur și simplu o listă lungă de intrări, fiecare intrare definind o singură „cerință” discretă ca poveste de utilizator. Și de acum înainte, vom folosi cuvântul user story, și nu „cerință”. Probabil te întrebi „de ce?” Asta e o intrebare buna. Pentru ceea ce pare a fi pentru totdeauna, indicarea caracteristicilor sau fațetelor necesare într-un proiect software de către un client a fost întotdeauna menționată ca o cerință. Acest cuvânt are o interpretare care nu are valoare în Agile. Dicționarul Oxford îl definește astfel:

Un lucru care este necesar sau dorit. Sau, Un lucru care este obligatoriu; o conditie necesara.

Și, din păcate, dacă ne propunem să definim care ar trebui să fie soluția noastră, afirmând că lucrurile sunt „obligatorii”, vom ajunge în necazuri. Este prea ușor să spui că toate aceste povești de utilizator sunt obligatorii. Dacă luăm acest punct de vedere, riscăm să depășim programul și bugetul în încercarea de a livra întregul domeniu de aplicare. Nu este o problemă să spunem că, pentru acest produs, aceste povești sunt necesare pentru ca soluția să fie viabilă, vrem doar să evităm interpretarea cuvântului respectiv.

• Scrieți întotdeauna povești din perspectiva unei persoane. O persoană reprezintă un utilizator sau o parte interesată a soluției. Este o idee bună să dezvolți această persoană înainte de a începe un restanțe.
• În această etapă, scrieți doar declarații scurte și simple care sugerează practic un memento pentru a avea o conversație mai profundă despre povestea utilizatorului atunci când este momentul potrivit.
• Oamenii adevărați gândesc în termeni de sarcini pe care trebuie să le facă pentru a atinge un obiectiv. Scrieți-vă poveștile din perspectiva personalității și în ceea ce privește ceea ce trebuie să se realizeze.
• Nu trebuie să scrieți întregul backlog - doar scrieți atât cât vă puteți imagina că vor avea nevoie clienții dvs. pentru ca produsul dvs. să fie viabil.
• Veți descoperi mai târziu, de-a lungul vieții produsului, că poveștile utilizatorilor se vor schimba, vor deveni mai mult sau mai puțin importante sau pot fi șterse complet. Eliberarea des, obținerea de feedback și evaluarea a ceea ce este o prioritate va informa acest comportament.
• Nu scrie povești izolat. Implicați-vă echipa, părțile interesate, chiar și clienții. Poveștile pot fi actualizate în orice moment în viața unui proiect, dar ar trebui să evite să fie schimbate odată ce a început munca de dezvoltare a acestora.
• Unele dintre poveștile tale pot fi considerate „epopee”. Acestea sunt povești mari care acoperă multe și vor fi împărțite mai aproape de momentul livrării în povești mai mici.
• Luați în considerare utilizarea modelului INVEST, o listă de verificare pentru validarea calității unei bune povești de utilizator.
• Oricine poate adăuga o poveste la restanța. Ar trebui să fie plasat în partea de jos sau într-o „parcare” special creată. Această poveste adăugată servește ca un prompt pentru a discuta cu echipa și afacerea. Dacă afacerea și echipa îl susțin, atunci poate fi estimat și prioritizat
• De asemenea, puteți lua în considerare acele părți ale sistemului care sunt cele mai riscante. Dacă aveți o poveste de utilizator sau o funcție care este complexă, nouă sau necunoscută din punct de vedere tehnic, acordați prioritate acestora în partea de sus a stocului dvs. În acest fel, nu veți încerca să livrați părțile provocatoare și critice ale produsului dvs. cu doar câteva săptămâni înainte de prima lansare.

Odată ce aveți un stoc care vă satisface nevoile, puteți estima poveștile din acesta, le puteți clasifica în ordinea priorităților și puteți construi un plan de lansare.

Estimare și prioritizare la nivel înalt

Estimarea la nivel înalt este procesul de dimensionare a restanțelor. Cât de „mare” este proiectul și ce valoare oferă? Prioritizarea este procesul de decizie care sunt cele mai importante pentru tine, viabilitatea produsului și interesele clienților tăi. Dorim să livrăm articolele de cea mai mare valoare cât mai curând pentru a oferi cea mai mare valoare afacerii, pentru a primi feedback de la client și pentru a nu transpira lucrurile mici. Rezultatul va fi un stoc ordonat care este clasat în prioritate și dimensionat corespunzător.

• Poveștile din partea de sus sunt considerate cele mai valoroase. Dorim să livrăm cele mai valoroase articole cât mai curând posibil.
• Există multe tehnici de dimensionare și estimare, dar în acest moment, doriți doar să obțineți o senzație indicativă bună a dimensiunii unei povești.
  • Folosiți mărimile tricourilor, mărimea relativă, zilele ideale sau punctele de poveste.
• Nici în acest moment nu veți avea toate informațiile disponibile și este în regulă. Doar fugi cu el.
• Angajați părțile interesate de afaceri sau managerul de produs, dacă aveți unul, și echipa care va face treaba.
• Îi dorim pe cei care vor proiecta, dezvolta și testa lucrarea să o dimensioneze, deoarece cei mai buni oameni de estimat sunt experții.
• Echipa poate începe să descompună poveștile în părți mai mici. Dacă se întâmplă acest lucru, scrieți povești mai granulare, dar discrete.
• Echipa poate începe, de asemenea, să clasifice unele povești, deoarece, desigur, unele lucruri trebuie să fie livrate înaintea altora pentru a sprijini tehnologia sau o anumită călătorie a utilizatorului.
• Între tine și echipă, s-ar putea, de asemenea, să începi să găsești găuri în restanța care trebuie umplute. Doar umple acele găuri cu povești noi și estimează și prioritizează după caz.
• Prioritizarea se realizează cel mai ușor folosind o analiză MoSCoW. MoSCoW este o tehnică simplă care vă ajută să decideți ce povești sunt „must have” pentru ca produsul dumneavoastră să aibă succes.
• Puteți face o trecere de prioritizare înainte de a începe estimarea. Cu toate acestea, dimensionarea anumitor elemente poate determina și o decizie privind prioritatea și valoarea reală a afacerii. Așa că jucați estimarea și prioritizarea una de cealaltă, dar nu vă certați!
• Nu există două povești la fel de importante ca cealaltă. Povestea de la rangul 1 este mai importantă sau mai valoroasă decât povestea de la rangul 2.
• O modalitate excelentă de a demonstra importanța sau valoarea unei povești este aceea de a adăuga o valoare monetară acesteia. Dacă, de exemplu, se crede că povestea A aduce un venit suplimentar de 5000 USD, iar povestea B ar putea atrage 100 USD, atunci povestea A este mai valoroasă. De asemenea, dacă povestea C salvează afacerea mai mult decât povestea D, povestea C este mai valoroasă.
• Odată ce v-ați dimensionat acumularea, veți rămâne cu un număr. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Lucrul în trepte mici are un beneficiu imens. Înseamnă că vă concentrați doar pe viitorul imediat al livrării și, cu noi intrări, feedback și învățare, puteți răspunde la schimbare într-un scurt ciclu iterativ.
• La începutul unei lansări, efectuați un sprint 0. Acest lucru permite echipei, afacerii și lansarea proiectului dvs. să se pregătească și stabilește mentalitatea pentru livrarea cu succes. Desenați cadrul tehnic de bază și arhitectura care vor sprijini fundația pentru lansare. Configurați medii, conturi și instrumente. Efectuați vârfuri pentru a înțelege problemele dificile sau necunoscute. Elaborați poveștile dvs. de utilizator în pregătirea pentru sprintul 1. Sprintul 0 este despre a vă pregăti.
• În timpul unei lansări, continuați să rafinați restul. Pe măsură ce înțelegeți mai multe sau învățați ceva nou, prioritățile dvs. se pot schimba, se pot dezvolta noi cerințe și ceea ce credeați anterior că este o funcție grozavă poate fi eliminată complet.
• Nu începe lucrul care nu are șanse să se termine într-un sprint. Dacă nu poate, împărțiți-l în bucăți mai mici. Și nu începeți lucrări noi când lucrările începute anterior nu au fost finalizate. Nu creezi nicio valoare pornind o mulțime de lucruri care nu pot fi considerate complete. În plus, evitați schimbarea contextului. Aceasta este activitatea de a începe o sarcină, de a fi deranjat, de a începe o alta și, cel mai problematic, de a nu finaliza nici una.
• Limitați cantitatea de muncă care este în desfășurare de către echipă în orice moment. De exemplu, dacă aveți trei dezvoltatori și un tester, puteți pune o limită WIP pentru dezvoltatori și pentru tester.
• Nu adăugați niciodată mai multă muncă la un sprint după ce a fost planificat. Nu opri niciodată un sprint la jumătatea drumului. Excepțiile de la aceasta sunt:
  • Dacă ați avut rezultate mai rapide decât vă așteptați, luați în considerare următoarea poveste din partea de sus a restanțelor, atâta timp cât este pregătită corespunzător.
  • Dacă sprintul funcționează atât de prost încât nu se va finaliza. Acest lucru se întâmplă de obicei numai acolo unde a avut loc o catastrofă de o anumită descriere.
  • Dacă obiectivul de sprint nu mai poate fi susținut din cauza nevoilor imediate în schimbare ale afacerii.
• Dacă anulați un sprint, faceți-l cu grație, acordați-vă timp pentru a vă reorienta și începeți un nou sprint la fel ca oricare altul.
• Spre sfârșitul unei lansări, luați în considerare un sprint final de lansare. Nu sunt scrise funcții noi, unele erori pot fi curățate și se pot face pregătiri pentru a lansa efectiv o nouă versiune a produsului dumneavoastră clienților dumneavoastră. Asta nu înseamnă că nu poți face lansări incrementale pentru clienți între timp - doar că acesta este un mecanism de lansare controlat, măsurat și durabil.
• La sfârșitul unei lansări, ați putea lua în considerare un sprint de o săptămână. În acest sprint, ați putea lucra cu echipa pentru a defalca câteva idei noi sau a descoperi o tehnologie nouă. Acestea sunt instrumente grozave care beneficiază de afaceri și oferă echipei un spațiu de informare pentru a gândi și a fi creativ. Nu este pentru a prost și va crea în continuare valoare. În egală măsură, toată lumea are nevoie de o pauză. A lua o vacanță în acest moment vă ajută să vă mențineți cadența și viteza în formă bună atunci când sunteți la jumătatea eliberării.

Definirea gata

Definirea a ceea ce înseamnă cu adevărat „terminat” este foarte importantă. Există multe versiuni ale „terminat” în timpul vieții proiectului tău – ce înseamnă „terminat” cu o poveste, o lansare sau un întreg proiect. Totul se rezumă la ceea ce dvs., echipa dvs. și afacerea veți considera ca fiind complet la nivelul potrivit de calitate pentru a satisface disponibilitatea pentru expediere.

Pentru echipa ta, definiția unei povești „terminate” va fi ceva de genul întregului cod complet, revizuit de colegi, îndeplinește criteriile de acceptare definite, testat în unitate, UAT și trimis în depozitul tău de cod. Pentru a permite transmiterea unei povești de la designer la dezvoltator la tester, definițiile „terminat” vor trebui să fie acceptate de următoarea persoană din lanț. Proprietarul dvs. de produs va avea așteptări cu privire la ce înseamnă acest lucru pentru ei, pentru a oferi clienților dvs. creșterea de produs. În orice caz, toată lumea trebuie să fie conștientă de ceea ce înseamnă „a făcut” și să fie o parte responsabilă pentru a se asigura că sensul este îndeplinit. Definiți-vă definiția pentru „terminat”, comunicați-o, acordați-o și evoluați-o. Gata gata.

Măsurare continuă

Dacă nu o poți măsura, nu o poți gestiona. Același lucru este valabil și pentru îmbunătățiri. Necesitatea de a aduna date empirice într-un proiect Agile este aproape la fel de vitală ca și a avea sânge prin vene! De unde știi ce trebuie gestionat, corectat sau îmbunătățit dacă nu există date? Ei bine, pur și simplu, te vei baza pe simțul instinctului și pe presupuneri nefondate, care se destramă destul de repede sub control. Și, în funcție de cine examinează, acesta poate fi un loc destul de inconfortabil. Deci, încă de la începutul proiectului, asigurați-vă că știți cum veți demonstra progresul și prin ce măsuri vă vor vedea alții succesul.

Din fericire, Agile vine încărcat cu instrumente și tehnici utile. Primul lucru de făcut este să te întorci la Manifestul Agile, să tastați următoarele cuvinte în procesorul de text preferat, să le aruncați în aer până la 96 de puncte, să imprimați și să aplicați pe perete pentru ca toți să le vadă:

Cea mai mare putere demonstrabilă a ta în furnizarea de software este să-l arăți oamenilor care lucrează, făcând ceea ce ar trebui să facă. Acest lucru nu numai că va face clienții fericiți, ci va câștiga echipei dvs. un mare respect și va unge roțile pentru o mai mare adoptare prin intermediul afacerii.

Iată și alte instrumente:

• Standup-ul zilnic: Există câteva variante ale acestei ceremonii, dar esența este ca toți membrii echipei să vorbească unul cu celălalt față în față: ține-l scurt, ține-l concentrat și ține-l ușor. Dacă ceva are nevoie de discuții pe larg, parcă-l pentru o conversație mai lungă între cei de care au nevoie după standup. Dacă apar impedimente, scrieți-le ca pe o poveste, adăugați-le la acumularea dvs. și rezolvați-le cât mai curând posibil. Orice lucru care împiedică echipa ta încetinește progresul și va fi demonstrat cu o viteză redusă și software care nu corespunde așteptărilor.
• Viteza: este un instrument istoric. Este un pic ca acele avertismente financiare pe care le primești și care spun că performanța trecută nu este o garanție a performanței viitoare. Dar în cazul lui Agile, sperăm să atingem o viteză de echipă care este în mare parte lină. Este viteza care ne permite să proiectăm performanța viitoare și să avem încredere în planurile noastre. Pot exista influențe în afara controlului dvs. care ar putea reduce numărul de puncte de poveste pentru un anumit sprint. Dacă se întâmplă acest lucru, probabil vă veți putea recupera. Nu folosiți niciodată viteza ca un băț cu care să vă învingeți echipa; nu-ți va câștiga nicio favoare. Un lucru sigur este că viteza va fi neregulată pentru primele 2-4 sprinturi. Undeva în acel interval de timp, totuși, ar trebui să începeți să vedeți consistență și stabilitate. Dacă viteza ta variază de la o extremă la alta, ai o problemă pe care va trebui să o rezolvi cu echipa ta.
• Diagrama de ardere: Acum această măsură a progresului este una spinoasă. Din acest motiv, nu am oferit un link pentru a afla mai multe – va trebui să faci propriile cercetări și să fii de acord ca o echipă și o afacere care funcționează pentru tine. Motivul pentru care este spinos? Ei bine, nicio resursă de acolo nu spune aceeași poveste! Un lucru asupra căruia s-a convenit este că va arăta, într-un sprint sau într-o lansare, cum ai performanță față de timebox. Dacă este întreținut zilnic, va arăta dacă sunteți pe drumul cel bun sau deviați. Unele echipe îl folosesc pentru a reprezenta câtă valoare mai rămâne de creat, de cele mai multe ori, altele îl folosesc pentru a arăta câtă muncă mai rămâne de finalizat. Primul este o sărbătoare a succesului și a generării de valoare, cel de-al doilea este mai puțin inspirator și motivant.
• Graficul de ardere: dacă trebuie să afișați ratele de finalizare a lucrărilor, utilizați pentru asta graficul de ardere. Dar utilizarea diagramei de ardere vă permite să arătați câtă valoare a fost creată și câtă valoare mai mult intenționați să creați până la sfârșitul sprintului. Un instrument mult mai motivant pentru o echipă care să demonstreze atât afacerii ce s-a făcut (sau puțin dacă lucrurile nu merg atât de bine…) cât și spre ce are încă obiectivul. În orice caz, utilizați graficele pentru a identifica unde progresul nu este urmărit conform așteptărilor și căutați modele sau abateri și treceți peste ele pentru a remedia problema de bază cât mai curând posibil. Actualizați-le zilnic pentru sprinturi și o dată la sfârșitul unui sprint pentru diagramele versiunilor de lansare.
• Taskboards: Acestea sunt radiatoare vizuale excelente pentru a demonstra valoarea creată. Când sunt actualizate zilnic, sau în orice moment al zilei, ele arată imediat progresul realizat. Dacă sunt combinate cu Kanban, acestea sunt, de asemenea, instrumente excelente pentru vizualizarea fluxului și a blocajelor din sistem. Dacă puteți vedea că multe dezvoltări au fost finalizate, dar testarea nu este la fel de productivă, puteți vedea că problema se întâmplă și puteți răspunde în mod corespunzător și rapid.

Alte instrumente de luat în considerare sunt valoarea Agile câștigată, timpul ciclului și diagramele de flux cumulate (CFD).

Păstrați aceste măsuri, diagrame și alte instrumente vizibile, de preferință tare și mândru pe un perete pentru ca toți să le vadă. Echipa, părțile interesate și alte părți interesate pot vedea imediat stadiul unui proiect. Este transparent și servește ca un instrument de comunicare valoros. Dacă nu puteți pune aceste artefacte pe un perete, utilizați instrumente care pot fi partajate și colaborative și asigurați-vă că cei care doresc accesul le au.

Imbunatatire continua

De-a lungul vieții tale Agile, încearcă să identifici și să înveți unde pot fi aduse îmbunătățiri. Lecțiile nu sunt captate și învățate la sfârșitul unui proiect. Este ca și cum ți-ai promovat examenul de conducere și ți-ai fi luat prima mașină fără instructor. Veți ști ce funcționează și ce ar trebui să faceți, dar cu timpul vă veți adapta abilitățile și capacitățile de conducere, învățând noi tehnici. Vei lua chiar și obiceiuri proaste. Căutați-le, înțelegeți-le și găsiți modalități de îmbunătățire.

Există multe oportunități de a identifica ceea ce nu funcționează și de a aplica remedii. Abordarea încorporată a acestui lucru în Agile este retrospectiva. Acesta este instrumentul principal de reflecție și ajustare. La sfârșitul fiecărui sprint, fă-ți timp cu echipa pentru a îmbunătăți modul în care se realizează munca, cum este furnizată calitatea, cum poate fi maximizată eficiența, cum poate fi minimizată risipa și cum este crescută capacitatea. Când identificați măsuri de îmbunătățire, nu fiți tentați să vă remediați imediat toate problemele. Identificați-le pe cele care vor avea cel mai mare impact și pot fi implementate în următorul sprint. Măsurați și observați. Dacă a avut impactul dorit, blocați-l, scrieți-l în modurile dvs. de lucru și definițiile de gata. Dacă nu funcționează, mai gândește-te. Orice lecții învățate care nu sunt puse în sprintul următor pot fi parcate și prioritizate pentru atenție în următorul sprint.

Personalizați procesul. Eliminați orice nu funcționează. Eliminați impedimentele. Maturitatea ta ca echipă Agile nu va cunoaște limite dacă o lași.

Dincolo de managementul agil de proiect

Este important să știți ce se întâmplă după livrarea proiectului. Suportul și întreținerea sunt esențiale pentru a ne asigura că, odată ce proiectul este în mâinile clienților, acesta rămâne performant; feedback-ul clienților poate fi luat în considerare în versiunile viitoare; iar problemele clienților sunt tratate în mod corespunzător. Un proiect este un efort unic, limitat de timp. Produsul pe care îl livrează are o viață după ce echipa de proiect a fost desființată. Asigurați-vă că sunteți capabil să susțineți produsul odată ce acesta este activ.

Proiectele agile coexistă cu abordări mai tradiționale. Echilibrarea cerințelor pentru controlul bugetar și vizibilitatea părților interesate cu obiectivele Agile de flexibilitate și receptivitate.

Un cadru de guvernare sau un model de guvernanță Agile este utilizat împreună cu procese Agile standard, cum ar fi Scrum. Ele funcționează în două moduri specifice:

• Ele oferă un înveliș pentru un proiect Agile prin clarificarea proceselor care apar în afara iterațiilor de dezvoltare (sprinturi). Aceasta include furnizarea de criterii clare pentru finalizarea cu succes a inițierii proiectului și validarea adecvată a deciziilor și a planului.
• Ele schimbă accentul pe anumite părți ale procesului Agile standard și evidențiază anumite principii și tehnici care necesită guvernare sau sprijină guvernarea.

În lumea de astăzi în continuă schimbare, organizațiile și întreprinderile sunt dornice să adopte o abordare mai flexibilă pentru realizarea proiectelor și doresc să devină mai Agile. Cu toate acestea, pentru organizațiile care livrează proiecte și programe și acolo unde procesele formale de management al proiectelor există deja, informalitatea multor abordări Agile este descurajantă și uneori este percepută ca prea riscantă. Aceste organizații axate pe proiecte au nevoie de o abordare agilă matură - agilitate în cadrul conceptului de livrare a proiectelor - management agil de proiect .

Învățați și creșteți odată cu adoptarea Agile. Faceți întotdeauna ceea ce echipa dvs. se simte confortabil, asigurați-vă că vocea lor este auzită și acționează conform solicitărilor lor. Încurajați-vă echipa să adopte tehnici noi și mai valoroase atunci când este momentul potrivit. Negociați cu afacerea și încurajați-i să înțeleagă ce înseamnă să fii o organizație Agile.

Călătorie plăcută.