Share
În timp ce obiectivul principal al Scrum este organizarea și managementul de proiect, A se sprijini este mai mult despre optimizarea proceselor pentru a produce rapid produse de calitate. Acesta poate fi primul pas spre adoptarea principiilor Agile, sau poate fi ceva la care echipa dvs. evoluează, când Scrum nu este suficient. Vă invit să citiți povestea echipei mele și cum am evoluat de la Scrum la un proces de dezvoltare Lean-ish.
Lean este un set de principii definite de industria japoneză de producție a automobilelor în anii 1980. Inginerul de calitate Toyota, John Krafcik, a inventat termenul, observând procesele și instrumentele utilizate eliminarea deșeurilor în producția de automobile în masă. Pana in 2003, Mary si Tom Poppendieck au introdus Lean ca un proces de dezvoltare de software in cartea lor, Lean Software Development: Un Toolkit Agile.
În timp ce Scrum este un set de reguli și roluri, Lean este un set de principii și concepte cu o mână de instrumente. Ambele sunt considerate tehnici Agile, și aceștia împărtășesc aceeași ideologie de a livra rapid, reducând în același timp defectele și erorile. Subliniez mereu adaptabilitatea lui Agile, dar nu pot ignora faptul că Scrum se prezintă ca un set obligatoriu de reguli. De fapt, fanii religioși ai lui Scrum ar striga blasfemia pentru că nu au respectat regulile lui Scrum la scrisoare.
Lean, pe de altă parte, este mai deschis; adepții săi prezintă procesul ca un set de recomandări extrem de adaptabile.
Încurajează echipa sau compania să ia decizii și se adaptează deciziilor și surprizelor de zi cu zi pe care echipa și compania dvs. le întâmpină.
Pe măsură ce echipa mea a maturizat și a exploatat Scrum, am simțit că unele aspecte ale ei ne-au ținut înapoi. Am devenit o echipă destul de disciplină și omogenă. Unele întâlniri nu mai erau potrivite pentru noi și am început să înțelegem că întâlnirile zilnice nu erau eficiente. Am aflat că problemele ar trebui rezolvate mai repede și am simțit nevoia de a evita aceste proceduri care ne-au ținut înapoi.
Am continuat.
Lean expune două concepte majore, dar ideile principale sunt: eliminarea deșeurilor și îmbunătățirea fluxului de lucru.
Dacă ceva se va rupe, se va rupe vineri.
Tot ceea ce stă în calea producției este risipă. Acestea includ timpul pierdut, materialele rămase și o forță de muncă neutilizată. Defectele produsului final sunt deșeuri; pierde timp pentru a le repara, pierde bani pentru a le înlocui și pierde resurse pentru a găsi alte soluții.
Conceptul de deșeuri se traduce frumos în lumea dezvoltării software. Deșeurile pot fi descrise prin livrări târzii, bug-uri și programatori care nu au nimic de a face (nu confundați acest lucru cu "programatorii ar trebui să programeze opt ore pe zi fără pauză și youtube").
Conceptul Lean al Toyota se concentrează pe fluxul de producție. Într-o instalație de producție, fluxul este un lanț de proceduri care transformă materiile prime în produsele lor finale. Aceste proceduri pot fi foarte diferite unul de celălalt și pot dura diferite sume pentru a fi finalizate, dar fiecare poate fi îmbunătățit pentru a le face mai eficiente. Este o constatare constantă a bătăliei și îmbunătățirea blocajelor în acest proces.
Un flux ideal este unul în care fiecare etapă are același timp și efort pentru a produce aceeași cantitate de produse.
Acest lucru nu înseamnă că fiecare proces ar trebui să costă aceeași sumă de bani, dar fiecare proces ar trebui să poată fi completat cu aceeași cantitate ușoară.
În mod ironic, Scrum a fost instrumentul care ne-a dus în cele din urmă să realizăm deșeurile din proiectul nostru. Deși am aderat la scrumul pur în anumite zone ale producției noastre, am început să identificăm erori și / sau întârzieri pe care le-am putea evita cu ușurință prin adoptarea unei abordări diferite.
Știam puțin despre Lean în acel moment. Am citit câteva articole pe această temă, dar am făcut ceva greșit și i-am ignorat, pentru că ne-am concentrat atât de mult asupra procesului nostru Scrum. Am fost aproape convinsi că Scrum a fost Sfântul Graal, dar "mitraliera noastră Scrum" a început să se rătăcească. Trebuia să ne deschidem mințile.
Pentru dezvoltarea de software, principiile Lean au fost adaptate în următoarele șapte.
Schimbarea de la Scrum la Lean a fost de fapt eliberatoare.
În dezvoltarea de software, puteți găsi și elimina deșeurile prin recunoașterea lucrurilor care trebuie îmbunătățite. Într-un sens pragmatic, nimic care nu este o valoare directă pentru client este deșeu. Pentru a oferi câteva exemple: deșeurile sunt un bug, un comentariu în cod, o caracteristică neutilizată (sau rar utilizată), echipele care așteaptă alte echipe, luând un apel personal ... obțineți ideea. Orice vă țineți pe dvs., echipa dvs. sau produsul înapoi este o risipă și ar trebui să luați măsurile corespunzătoare pentru ao elimina.
Îmi amintesc că una dintre problemele noastre a fost necesitatea frecventă de a reacționa mai repede decât două sprinteze. Dezvoltarea în sprint și respectarea regulilor lui Scrum vă interzic să schimbați povestirile atribuite sprintului actual. O echipă trebuie să se adapteze atunci când un utilizator găsește un bug și are nevoie de o reparație sau când cel mai important client dorește o caracteristică care poate fi ușor compilată în două zile. Scrum nu este suficient de flexibil în aceste cazuri.
Plasați o valoare ridicată în educație.
Aveți deșeuri și, desigur, doriți mai puține deșeuri în viitor. Dar de ce există deșeuri? Este mai mult decât probabil că provine de la un membru al echipei care nu știe cum să abordeze o anumită problemă. E bine; nimeni nu știe totul. Plasați o valoare ridicată în educație.
Identificați domeniile care necesită cea mai mare ameliorare (cunoaștere) și începeți pregătirea. Cu cât știți mai mult cu echipa dvs., cu atât este mai ușor să reduceți risipa.
De exemplu, învățarea Test Driven Development (TDD) poate reduce numărul de bug-uri din codul dvs. Dacă aveți probleme cu integrarea modulelor diferitelor echipe, poate doriți să aflați ce Integrare continuă înseamnă și pune în aplicare o soluție adecvată.
De asemenea, puteți învăța din feedback-ul utilizatorului; acest lucru vă permite să aflați cum utilizatorii utilizează produsul dvs. O caracteristică frecvent utilizată poate fi accesibilă numai prin navigarea prin cinci meniuri. E un semn al pierderii! Puteți să dați vina inițial unor astfel de deșeuri programatorilor și designerilor (și este posibil să fiți corecți), dar utilizatorii tind să utilizeze software-ul dvs. în moduri pe care nu ați intenționat niciodată. Învățarea utilizatorilor dvs. ajută la eliminarea acestui tip de deșeuri. De asemenea, vă ajută să eliminați cerințele greșite sau incomplete. Feedback-ul utilizatorilor poate conduce un produs pe căi pe care nu le-ați fi considerat altfel.
La un moment dat, echipa mea a identificat faptul că anumite module ar fi putut fi mai bine scrise dacă vom afla mai multe despre domeniu la început. Desigur, nu există nici o modalitate de a vă întoarce timpul și rescrierea unei bucăți mari de cod nu este practică. Am decis să investim timp pentru a învăța despre domeniu atunci când este însărcinat cu o caracteristică mai complexă. Acest lucru poate necesita câteva ore sau chiar săptămâni, în funcție de complexitatea problemei.
Fiecare decizie are un cost. Este posibil să nu fie imediată și materială, dar costul este acolo. Amânarea deciziilor vă ajută să vă pregătiți pe deplin pentru problemele cu care trebuie să vă confruntați. Probabil cel mai frecvent exemplu de decizie întârziată este proiectarea bazei de date.
Deciziile nu trebuie să aibă un caracter tehnic; comunicarea cu clienții vă ajută să luați decizii care influențează modul în care abordați caracteristicile produselor dvs..
Dar utilizatorii nu știu mereu ce vor. Prin amânarea deciziilor privind caracteristicile până când utilizatorii au nevoie de această caracteristică, veți avea mai multe informații despre această problemă și veți putea oferi funcțiile necesare.
Alege metodologia Agile care funcționează cel mai bine pentru tine și echipa ta.
Cu paisprezece ani în urmă, echipa a decis să stocheze configurația aplicației într-o bază de date MySQL. Ei au luat această decizie la începutul proiectului și acum echipa actuală (echipa mea) are o povară dificilă de purtat. Din fericire, produsul nu mai este în curs de dezvoltare, dar trebuie să îl menținem din când în când. Ce ar trebui să fie o sarcină simplă se sfârșește prin a fi un monumental imens.
Pe partea strălucitoare, am învățat din greșelile predecesorilor noștri. Realizăm deciziile de programare, arhitectură și proiect cât mai târziu. De fapt, am învățat această lecție greu înainte de a adopta Lean. Scrieți codul deschis și decuplat și scrieți un design care este persistența și configurația agnostică. Este cu siguranță mai greu de făcut, dar în ultimă instanță vă economisește mult timp în viitor.
Cu ceva timp în urmă, am adăugat o caracteristică pentru produsul nostru care comprimă date pe disc. Știam că ar fi util și vroia să o adăugăm la produsul nostru cât mai repede posibil. Am început cu o funcționalitate simplă, evitând deciziile privind opțiunile și configurația până la o dată ulterioară. Utilizatorii au început să furnizeze feedback după câteva luni și am luat aceste informații pentru a lua decizii cu privire la opțiunile și configurația opțiunii. Am modificat caracteristica în mai puțin de o zi, și nici un utilizator nu sa plâns sau a solicitat mai multe funcționalități. A fost o modificare ușor de făcut; am scris codul, știind că vom face o modificare în viitor.
Trăim într-o lume în continuă schimbare. Programele pe care le scriem astăzi sunt pentru computerele care vor fi depășite în doi ani. Legea lui Moore este încă valabilă și va continua să fie așa.
Viteza de livrare este totul în această lume rapid-paced.
Livrarea unui produs în trei ani vă pune în spatele ambalajului, deci este foarte important să oferiți clienților dvs. o valoare cât mai curând posibil. Istoria a dovedit că un produs incomplet cu o cantitate acceptabilă de bug-uri este mai bun decât nimic. În plus, aveți un feedback neprețuit al utilizatorilor.
Compania noastra a avut un vis: livra dupa fiecare sprint. Firește, acest lucru nu este practic în cele mai multe cazuri. Utilizatorii noștri nu au dorit un produs actualizat în fiecare săptămână sau lună. Deci, în timp ce ne străduim să lansăm fiecare versiune a codului nostru, nu avem. Am aflat asta "rapid" este ceea ce percepe utilizatorul - nu ceea ce suntem fizic capabili să facem. În industria produsului nostru, rapid înseamnă actualizări regulate la fiecare câteva luni și remedierile critice de eroare în câteva zile. Acesta este modul în care utilizatorii noștri percep "rapid"; alte tipuri de produse și industrii au definiții diferite de "rapid".
Programatorii obișnuiesc să fie resurse încapsulate în cabine, îndeplinind în mod silențios sarcinile pentru compania lor. Aceasta a fost imaginea proeminentă a unui programator la sfârșitul anilor 1990, dar cu siguranță acest lucru nu mai este cazul.
Istoria a demonstrat că această abordare și managementul tradițional al proiectelor cascade nu este potrivit pentru software.
A fost atât de rău la un moment dat că numai aproximativ 5% din toate proiectele software au fost livrate efectiv. Afacerile și produsele de miliarde de dolari au eșuat în proporție de 95% din timp, ducând la pierderi uriașe.
Lean a identificat că programatorii nemotivați au cauzat deșeurile. Dar de ce lipsa de motivare? Ei bine, programatorii și echipele de dezvoltare nu au fost ascultate. Compania a stabilit sarcini și a micromanizat angajații care au fost văzuți doar ca resurse care produc cod sursă.
Lean încurajează managerii să asculte programatorii și încurajează programatorii să-i învețe pe managerii lor despre procesul de producție de software. De asemenea, încurajează programatorii să lucreze în mod direct cu clienții și utilizatorii. Acest lucru nu înseamnă că dezvoltatorii fac totul, dar le dă puterea de a influența evoluția producției. În mod surprinzător, având acel sentiment de "Știți acea caracteristică extraordinară pe care o iubesc utilizatorii? A fost ideea mea!"este un mare factor motivator.
Dar nu credeți că acest lucru funcționează numai pentru echipe mari; echipa noastră este mică. Compania noastră are doar o mână de dezvoltatori, așa că am fost mereu aproape de utilizatorii noștri. Această relație ne-a permis să influențăm produsul nostru dincolo de ceea ce inițial imaginau conducătorii noștri.
Tot ceea ce stă în calea producției este risipă.
Integritatea se referă la robustețea produsului dvs. și clienții văd produsul în ansamblul său. Integritatea se referă la uniformitatea UI, fiabilitatea și securitatea, iar utilizatorul se simte în siguranță prin utilizarea produsului dvs. Integritatea este imaginea completă pe care utilizatorul o creează pentru produsul dvs. De exemplu, integritatea UI implică aspectul și simțul între pagini, ecrane, module sau chiar între interfața utilizator a sistemului dvs. și site-ul web al companiei.
Dar integritatea poate fi observată și practicată la nivelul codului sursă. Integritatea poate însemna că modulele, clasele și alte piese sunt scrise în mod similar. Utilizați aceleași principii, modele și tehnici în întreaga bază de cod - chiar și între diferite echipe. Integritatea înseamnă că trebuie să refacționați frecvent codul. Este o muncă continuă și nesfârșită și trebuie să vă străduiți, dar să nu o atingeți niciodată.
Menținerea integrității în codul sursă este o sarcină dificilă. Ne-am dat seama că găsirea unui cod duplicat este cel mai dificil lucru de făcut și, prin duplicare, nu vreau să spun câteva linii de cod duplicat în aceeași metodă sau clasă.
Nu este vorba chiar de căutarea în diferite module pentru același cod; este vorba despre găsirea acelor bucăți de logică comună, despre extragerea lor în propriile clase și despre utilizarea lor în mai multe locuri.
Găsirea duplicării logice este foarte dificilă și necesită cunoașterea intimă a codului sursă.
Am fost pe același proiect de mai mult de un an și sunt încă surprins când găsesc un cod duplicat. Dar este un lucru bun; am ajuns la un punct când vedem aceste lucruri și luăm măsuri asupra lor. De când am început să eliminăm în mod activ logica duplicată la nivel înalt, calitatea codului a crescut. Suntem cu un pas mai aproape de atingerea integrității.
Utilizatorii nu știu mereu ce vor.
Când creați aplicația dvs., trebuie să vă gândiți la componentele terță parte pe care vă bazați pentru a vă dezvolta produsul, precum și la celelalte părți terțe cu care comunică produsul dvs. Aplicația dvs. trebuie integrată cu proiectarea unui dispozitiv sau a sistemului de operare pe un PC desktop. Nu este mai ușor să utilizați o aplicație care se integrează cu sistemul de notificare al smartphone-ului dvs., iar interfața de utilizare reflectă interfața de utilizare a sistemului?
Da, văzând totul nu este atât de ușor. Trebuie să vă detașați de detaliile minuscule și să vă uitați la produsul dvs. de departe. Unul dintre momentele memorabile în dezvoltarea produsului nostru a fost atunci când am realizat că trebuie să ne bazăm pe ce produc alți programatori în alte proiecte. Am realizat că nucleul sistemului, programat de alții, este una dintre aceste componente ale terților pe care ne bazăm.
La un moment dat, componenta terță parte sa schimbat. Am fi putut aplica doar aplicații de bandă sau am fi putut lua drumul ușor și am învinovățit programatorii care au scris acea componentă. În schimb, am luat problema cu ajutorul coarnei și am rezolvat problema în kernel-ul terț. Văzând întregul și lucrul cu acesta poate fi dezordonat, dar poate face diferența între un produs și un produs grozav.
Există mai multe instrumente și tehnici pentru a face munca Lean. Prefer Kanban, un instrument bazat pe bord, care este similar cu placa de planificare a lui Scrum. Imaginați-vă o placă Kanban ca o pâlnie dublă.
În stânga sunt lista de povestiri pe care nu trebuie să le rezolvăm niciodată. Toate poveștile terminate se încarcă în dreapta și managerul sau proprietarul produsului determină când să publice o nouă versiune, pe baza acestei liste.
În mijloc este procesul nostru eficient Kanban. Produsul trebuie să fie într-o stare stabilă și pregătită pentru eliberare atunci când vom completa o poveste. Acest lucru nu înseamnă neapărat că o caracteristică este făcută; produsul poate avea câteva caracteristici parțial implementate. Dar stabilitatea, securitatea și robustețea produsului ar trebui să fie calitatea producției.
Făceam destul de bine cu sprintul nostru actual. A fost o zi obișnuită, o zi liniștită, cu puțină entuziasm, dar am început să vedem câteva probleme până miercuri. E în regulă, se întâmplă tot timpul. Depășirea acestor dificultăți a necesitat ceva timp suplimentar. Proprietarul nostru de produse a fost de acord cu noi să continuăm să lucrăm la caracteristicile actuale și să extindem actualul sprint cu aproximativ trei sau patru zile suplimentare.
Vineri a venit cu o surpriză. Știi regula: dacă ceva se va rupe, se va rupe vineri. Un client important și potențial a solicitat o anumită caracteristică înainte de a semna un contract cu compania. A trebuit să reacționăm (și repede!). O nouă versiune a fost obligatorie ... Dar așteptați! Suntem într-un mijloc de sprint. Produsul trebuie să fie pregătit pentru eliberare până la sfârșitul sprintului. Ce facem? Scrum ar spune să facă noua facilitate în următorul sprint, dar deja am întârziat cu sprintul actual! Acesta a fost momentul în care am început să realizăm că trebuie să gândim mai puțin decât un sprint individual. Trebuie să fim capabili să ne adaptăm mai rapid și trebuie să ne eliberăm mai devreme, dacă este necesar.
O placă Kanban arată destul de asemănătoare cu o placă de planificare Scrum, dar cu câteva adăugiri pentru o mai bună adaptare la procesul Lean.
Prima coloană din stânga este întârzierea completă: tot ce trebuie să facem la un moment dat. În extrema dreaptă, aveți alta pâlnie, care conține toate poveștile completate (dar nu eliberate).
În mijloc este procesul nostru. Aceste coloane pot diferi în funcție de fiecare echipă și proces. De obicei, este recomandat să aveți cel puțin o coloană pentru următoarele câteva sarcini și o altă coloană pentru povestirile aflate în curs de dezvoltare. Imaginea de mai sus demonstrează mai multe coloane pentru a prezenta mai bine procesul de dezvoltare.
A face coloana afișează sarcinile pe care trebuie să le finalizăm. Atunci noi avem Proiecta, unde dezvoltatorii lucrează la proiectarea poveștilor curente. A patra coloană este Dezvoltare, codarea reală. În cele din urmă, Testarea coloana afișează sarcinile care așteaptă examinarea de către un alt coleg de echipă.
Nimeni nu știe totul.
Dacă comparăți această placă Kanban cu o placă de planificare a scrumului, veți observa imediat diferențele evidente. Mai întâi, fiecare coloană are un număr, reprezentând numărul maxim de povestiri cărora li se permite să locuiască în coloana respectivă. Avem patru mandate, patru în proiectare, trei în dezvoltare și două în testare. Sarcinile restante și cele finalizate nu au o astfel de limită.
Valoarea fiecărei coloane trebuie să fie definită de echipă. În imaginea de mai sus, am atribuit numere arbitrare coloanelor; numerele dvs. pot diferi semnificativ. De asemenea, numerele nu sunt definitive. Adaptați numerele atunci când identificați și eliminați blocajele.
Una dintre cele mai uimitoare calități ale lui Kanban și Lean este importanța colaborării și a realocării efortului. După cum puteți vedea în bord, fiecare coloană a procesului nostru conține cărți cu oameni pe ele. Există opt dezvoltatori pe tabla de exemplu - o echipă destul de mare! Bordul prezintă întotdeauna starea actuală a cine face ceea ce se întâmplă la un moment dat.
Potrivit consiliului nostru, există trei persoane care lucrează la proiectare, două perechi care lucrează în domeniul dezvoltării și un test de dezvoltare. Poveștile trec la următoarea coloană, locul în care lucrarea din coloana actuală este completă și, în funcție de tipul de dezvoltare și organizare a echipei, același dezvoltator poate continua să lucreze la aceeași poveste pe măsură ce se mișcă prin proces.
Să presupunem că avem oameni specializați. Deci, funcția principală a celor trei designeri este proiectarea, cei patru dezvoltatori scriu cod, iar testerul singuratic testează în primul rând produsul / caracteristica. Dacă un designer termină o poveste, povestea se îndreaptă către dezvoltare, iar o altă poveste din lista de sarcini este trasată în design.
Acesta este un proces normal. O poveste a fost mutată de la proiectare la dezvoltare, iar acum dezvoltarea este la povești maxime. Dar dacă un alt designer termină o altă poveste? Aceasta oferă echipei de dezvoltatori patru etaje - o situație nedorită.
Lean vrea să evite aglomerația. Este interzis să mutați o poveste în următoarea coloană dacă depășește valoarea maximă a coloanei. În acest caz, resursele trebuie să fie realocate; proiectantul care și-a terminat sarcina trebuie să aleagă ce trebuie să facă în continuare. Prima sa optiune este de a trage o alta sarcina din coloana de rezolvare, dar nu poate face asta pentru ca trebuie sa treaca sarcina recent terminata echipei de dezvoltare (pe care nu o poate face). Singura sa opțiune este să începi să lucrezi la o poveste de dezvoltare. El nu poate fi cel mai bun dezvoltator, dar eforturile sale vor ajuta la mentinerea fluxului de procese.
Dacă testerul termină ultima poveste din coloana sa, el ar putea ajuta proiectantul să-și îndeplinească sarcina de dezvoltare.
Asta e super! Echipa se poate reorganiza în zbor! Vedeți o pierdere? Vedeți o strangulare în flux? Luați măsuri imediate!
Odată ce o poveste din coloana de dezvoltare este finalizată, testerul revine la testare, designerul la proiectare, iar dezvoltatorii preiau povestea pe care lucrau designerul și testerul. Dar rețineți că nu trebuie să urmați acea prescripție exactă; dezvoltatorul ar putea începe proiectarea ca designer și tester terminat să-și dezvolte povestea. Depinde de tine!
Bordul nostru este din nou la normal.
Este interzis să mutați o poveste în următoarea coloană dacă depășește valoarea maximă a coloanei.
Am urmărit cu nostalgie, în timp ce comandantul nostru de scrumuri ne-a dezmembrat tabla. Bucăți de bucată, ne-a rupt bordul prețios, care apoi a devenit un munte de hârtie încurcată.
Un alt coleg intră în cameră, în mâinile sale cîteva coli uriașe de hârtie albă proaspătă. Consiliul nostru era pe punctul de a fi renăscut în ceva diferit, ceva mai potrivit pentru nevoile noastre. După ce foile de hârtie erau pe perete, am început o întâlnire ad-hoc pentru a defini coloanele necesare pentru a defini procesul nostru. Am dezbătut apoi numărul de povestiri care ar trebui să fie în fiecare coloană. După ce totul a fost atent pictat și aranjat pe perete, am experimentat acel sentiment ciudat ... tristețe pentru vechea, dar fericire pentru noul.
Am făcut ceva ce numesc mulți oameni, Scrum-Ban. Am pastrat cateva concepte de scrum, cum ar fi masterul de scrum si rolurile proprietarului de produs, iar noi inca estimam si evaluam povestile. Dar ne concentrăm acum pe Lean și Kanban, păstrând fluxul, descoperind și reparând deșeurile și blocajele.
Schimbarea de la Scrum la Lean a fost de fapt eliberatoare. Membrii echipei au devenit mult mai prietenoși unul cu celălalt și am înțeles că ar trebui să oferim ajutor imediat ce nu există nimic în coloana noastră. Acest sentiment care contează de dezvoltatori ne-a determinat să ne gândim la proiect ca un întreg; ne pasă mai mult de proiect decât am avut vreodată.
Lean nu a fost întotdeauna considerat Agile. Chiar și astăzi, unii agiliști refuză să o recunoască ca o metodă Agile. Dar, din ce în ce mai mult, programatorii acceptă Lean ca una dintre metodologiile finale Agile.
După cum a subliniat unul dintre colegii mei înțelepți, Lean și Kanban vă permit să urmați această metodologie pe cont propriu. Deci, dacă sunteți un dezvoltator singuratic și aveți nevoie de niște instrumente pentru a vă ușura viața, încercați niște instrumente gratuite Kanban.
Site-ul AgileZen oferă un cont gratuit, permițându-vă să urmăriți un singur proiect.
Am descoperit că este unul dintre cele mai bune instrumente Kanban online gratuite; Îl folosesc chiar și în fiecare zi pentru a urmări și a planifica progresul articolelor și cursurilor pe care le ofer pentru Tuts +. Desigur, puteți oricând să vă actualizați contul AgileZen, dacă aveți nevoie să urmăriți mai multe proiecte.
În acest articol, am revizuit Lean și Kanban ca o evoluție a lui Scrum. Asta înseamnă că Lean este mai bun decât Scrum? Absolut nu! Depinde de proiectele și de persoanele cu care lucrați. Ca întotdeauna, alegeți metodologia Agile care funcționează cel mai bine pentru dvs. și echipa dvs..
Accentsconagua