Share
Hoewel Scrum primair streeft naar organisatie en projectmanagement, Mager gaat meer over het optimaliseren van processen om snel hoogwaardige producten te produceren. Het kan je eerste stap zijn naar het adopteren van Agile-principes, of het kan iets zijn waar je team naar toe evolueert, wanneer Scrum niet genoeg is. Ik nodig u uit om het verhaal van mijn team te lezen, en hoe we zijn geëvolueerd van Scrum naar een meer Lean-achtig ontwikkelingsproces.
Lean is een set principes die in de jaren tachtig door de Japanse automobielindustrie zijn gedefinieerd. De kwaliteitsingenieur van Toyota, John Krafcik, bedacht de term, terwijl hij tegelijkertijd de processen en gereedschappen observeerde afval elimineren in massale autoproductie. Het duurde tot 2003 voordat Mary en Tom Poppendieck Lean introduceerden als softwareontwikkelingsproces in hun boek Lean Software Development: An Agile Toolkit.
Terwijl Scrum een aantal regels en rollen is, is Lean een verzameling principes en concepten met een handvol tools. Beiden worden beschouwd als Agile-technieken en ze delen dezelfde ideologie van snel leveren, en tegelijkertijd fouten en fouten verminderen. Ik benadruk altijd het aanpassingsvermogen van Agile, maar kan niet voorbijgaan aan het feit dat Scrum zichzelf presenteert als een verplichte set regels. De religieuze fans van Scrum zouden godslastering schreeuwen omdat ze de regels van Scrum niet letterlijk hadden opgevolgd.
Lean daarentegen is meer open; zijn volgelingen presenteren het proces als een reeks zeer aanpasbare aanbevelingen.
Het moedigt het team of bedrijf aan om beslissingen te nemen en past zich aan aan de beslissingen en dagelijkse verrassingen die uw team en bedrijf tegenkomen.
Toen mijn team volwassen werd en Scrum uitbuitte, voelden we dat sommige aspecten ervan ons tegenhielden. We werden een tamelijk gedisciplineerd en homogeen team. Sommige vergaderingen waren niet meer geschikt voor ons en we begonnen ons te realiseren dat dagelijkse vergaderingen niet efficiënt waren. We hebben geleerd dat problemen sneller moeten worden opgelost en we hebben de noodzaak gevoeld om deze procedures te vermijden die ons tegenhielden.
We zijn verder gegaan.
Lean legt twee belangrijke concepten bloot, maar de kernideeën zijn: het elimineren van verspilling en het verbeteren van de workflow.
Als er iets gaat breken, zal het vrijdag breken.
Alles wat productie in de weg staat, is afval. Dit omvat verloren tijd, overgebleven materialen en een ongebruikte werkkracht. Defecten in het eindproduct zijn afval; het verspilt tijd om ze op te lossen, verspilt geld om ze te vervangen en verspilt middelen om andere oplossingen te vinden.
Het concept van afval vertaalt zich netjes in de wereld van softwareontwikkeling. Afval kan worden beschreven door late afleveringen, bugs en programmeurs die niets te doen hebben (niet te verwarren met "programmeurs moeten acht uur per dag programmeren zonder pauze en YouTube").
Het Lean-concept van Toyota concentreert zich op de productiestroom. In een productie-installatie is de stroom een keten van procedures die de grondstoffen omzetten in hun eindproducten. Deze procedures kunnen heel verschillend zijn en verschillende hoeveelheden tijd in beslag nemen, maar ze kunnen allemaal worden verbeterd om ze efficiënter te maken. Het is een constante strijd vinden en het verbeteren van knelpunten in het proces.
Een ideale flow is een flow waarbij elke stap evenveel tijd en moeite kost om dezelfde hoeveelheid producten te produceren.
Dit betekent niet dat elk proces hetzelfde bedrag zou moeten kosten, maar elk proces zou met hetzelfde gemak moeten kunnen voltooien.
Ironisch genoeg was Scrum de tool die ons uiteindelijk leidde om het afval in ons project te realiseren. Hoewel we in sommige delen van onze productie aan pure Scrum hebben deelgenomen, zijn we begonnen om bugs en / of vertragingen te identificeren die we gemakkelijk konden voorkomen door een andere aanpak te kiezen.
We wisten op dat moment weinig over Lean. We lazen enkele artikelen over het onderwerp, maar we deden het verkeerde en negeerden ze, omdat we zo gefocust waren op ons Scrum-proces. We waren er bijna van overtuigd dat Scrum de Heilige Graal was, maar ons 'Scrum machinegeweer' begon te mislukken. We moesten onze geest openen.
Voor softwareontwikkeling zijn de principes van Lean aangepast in de volgende zeven.
De overgang van Scrum naar Lean was eigenlijk bevrijdend.
In softwareontwikkeling kunt u afval vinden en elimineren door de dingen te herkennen die moeten worden verbeterd. In pragmatische zin is alles wat geen directe waarde voor de klant is verspilling. Om een paar voorbeelden te noemen: verspilling is een bug, een opmerking in de code, een ongebruikte (of zelden gebruikte functie), teams die wachten op andere teams, een persoonlijk gesprek voeren ... je snapt het. Alles wat u, uw team of uw product tegenhoudt, is een verspilling en u moet de juiste acties ondernemen om het te verwijderen.
Ik herinner me dat een van onze problemen de frequente noodzaak was om sneller te reageren dan twee sprints. Door te ontwikkelen in sprints en de regels van Scrum te respecteren, kun je de verhalen die aan de huidige sprint zijn toegewezen niet veranderen. Een team moet zich aanpassen wanneer een gebruiker een fout ontdekt en een oplossing nodig heeft, of wanneer de belangrijkste klant een functie wil die eenvoudig in twee dagen kan worden voltooid. Scrum is gewoon niet flexibel genoeg in deze gevallen.
Veel waarde hechten aan onderwijs.
Je hebt afval en je wilt natuurlijk in de toekomst minder afval. Maar waarom is er afval? Het komt meer dan waarschijnlijk van een teamlid dat niet precies weet hoe een bepaald probleem moet worden aangepakt. Dat is in orde; niemand weet alles. Veel waarde hechten aan onderwijs.
Identificeer de gebieden die de meeste verbetering behoeven (kennis-wijs) en begin met trainen. Hoe meer jij en je team weten, hoe gemakkelijker het is om afval te verminderen.
Het leren van Test Driven Development (TDD) kan bijvoorbeeld het aantal bugs in uw code verminderen. Als je problemen hebt met het integreren van de modules van verschillende teams, wil je misschien weten wat Continue integratie betekent en implementeert een passende oplossing.
Je kunt ook leren van gebruikersfeedback; Hiermee kunt u leren hoe gebruikers uw product gebruiken. Een veelgebruikte functie is mogelijk alleen toegankelijk door vijf menu's te doorlopen. Dat is een teken van verspilling! U kunt in eerste instantie dergelijk afval de schuld geven van programmeurs en ontwerpers (en misschien bent u gelijk), maar gebruikers hebben de neiging uw software te gebruiken op manieren die u nooit van plan was. Leren van uw gebruikers helpt dit soort afval te elimineren. Het helpt u ook om verkeerde of onvolledige vereisten te elimineren. Gebruikersfeedback kan een product besturen op paden die u anders nooit zou hebben overwogen.
Op een gegeven moment ontdekte mijn team dat bepaalde modules beter hadden kunnen worden geschreven als we in het begin meer over het domein hadden geweten. Natuurlijk is er geen manier om de tijd terug te draaien, en het herschrijven van een groot stuk code is niet praktisch. We hebben besloten om tijd te investeren om meer te weten te komen over het domein als het om een complexere functie gaat. Dit kan enkele uren of zelfs weken duren, afhankelijk van de complexiteit van het probleem.
Elke beslissing heeft kosten. Het is misschien niet onmiddellijk en materieel, maar de kosten zijn aanwezig. Uitstelbeslissingen helpen je om je volledig voor te bereiden op de problemen waarmee je geconfronteerd moet worden. Waarschijnlijk het meest voorkomende voorbeeld van een vertraagde beslissing is met databaseontwerp.
Beslissingen hoeven niet technisch van aard te zijn; communiceren met klanten helpt u beslissingen te nemen die van invloed zijn op de manier waarop u de functies van uw producten benadert.
Maar gebruikers weten niet altijd wat ze willen. Door functiekeuzes uit te stellen totdat de gebruikers de functie daadwerkelijk nodig hebben, hebt u meer informatie over het probleem en kunt u de benodigde functionaliteit bieden.
Kies de Agile-methode die het beste werkt voor u en uw team.
Veertien jaar geleden nam het team een beslissing om de configuratie van de applicatie op te slaan in een MySQL-database. Ze hebben deze beslissing aan het begin van het project genomen en nu heeft het huidige team (mijn team) een moeilijke last om te dragen. Gelukkig is dat product niet langer in actieve ontwikkeling, maar we moeten het wel van tijd tot tijd onderhouden. Wat een eenvoudige taak zou moeten zijn, wordt uiteindelijk een enorm monumentaal monument.
Aan de positieve kant hebben we geleerd van de fouten van onze voorgangers. We maken programmerings-, bouwkundige en projectbeslissingen zo laat mogelijk. In feite hebben we deze harde les geleerd voordat we Lean adopteerden. Schrijf open en ontkoppelde code en schrijf een ontwerp dat persistentie - en configuratie - agnostisch is. Het is zeker moeilijker om te doen, maar uiteindelijk bespaart u veel tijd in de toekomst.
Enige tijd geleden hebben we een functie aan ons product toegevoegd die gegevens op de schijf comprimeert. We wisten dat het nuttig zou zijn en wilden het zo snel mogelijk aan ons product toevoegen. We zijn begonnen met eenvoudige functionaliteit, waarbij beslissingen over opties en configuratie tot een later tijdstip worden vermeden. Gebruikers begonnen na enkele maanden feedback te geven en we namen die informatie om beslissingen te nemen over de opties en configuratie van de functie. We hebben de functie in minder dan een dag aangepast en geen enkele gebruiker heeft geklaagd of om meer functionaliteit gevraagd. Het was een gemakkelijke aanpassing om te maken; we hebben de code geschreven, wetende dat we in de toekomst een wijziging zouden aanbrengen.
We leven in een constant veranderende wereld. De programma's die we vandaag schrijven, zijn voor computers die over twee jaar overbodig zijn. De wet van Moore is nog steeds geldig, en dat zal zo blijven.
De snelheid van levering is alles in deze snelle wereld.
Als u een product binnen drie jaar levert, bent u achter het pack aan. Het is dus erg belangrijk om uw klanten zo snel mogelijk waarde te geven. De geschiedenis heeft aangetoond dat een incompleet product met een acceptabel aantal fouten beter is dan niets. Bovendien heb je waardevolle feedback van gebruikers.
Ons bedrijf had een droom: leveren na elke sprint. Natuurlijk is dat in de meeste gevallen onpraktisch. Onze gebruikers wilden niet elke week of maand een bijgewerkt product. Dus terwijl we ernaar streven elke versie van onze code vrij te geven, doen we dat niet. Dat hebben we geleerd "snel" is wat de gebruiker waarneemt - niet wat we fysiek kunnen doen. In de branche van onze producten betekent snel: regelmatige updates om de paar maanden en kritische bugfixes binnen enkele dagen. Dit is hoe onze gebruikers "snel" ervaren; andere soorten producten en industrieën hebben verschillende definities van 'snel'.
Programmeurs waren middelen die waren ingepakt in cellen en hun taken stilletjes uitvoerden voor hun bedrijf. Dit was het prominente beeld van een programmeur aan het einde van de jaren negentig, maar dat is zeker niet langer het geval.
De geschiedenis heeft aangetoond dat die aanpak en het traditionele watervalprojectbeheer niet geschikt is voor software.
Het was op een gegeven moment zo slecht dat slechts ongeveer 5% procent van alle softwareprojecten daadwerkelijk werd opgeleverd. Miljoen dollar bedrijven en producten faalden 95% van de tijd, wat leidde tot enorme verliezen.
Lean stelde vast dat ongemotiveerde programmeurs dat afval veroorzaakten. Maar waarom het gebrek aan motivatie? Nou, er is niet naar programmeurs en ontwikkelingsteams geluisterd. Het bedrijf heeft taken ingesteld en de medewerkers geminimaliseerd die alleen werden gezien als bronnen die broncode produceerden.
Lean moedigt managers aan om naar programmeurs te luisteren en moedigt programmeurs aan om hun managers het proces van softwareproductie te leren. Het stimuleert ook programmeurs om rechtstreeks met klanten en gebruikers te werken. Dit betekent niet dat de ontwikkelaars alles doen, maar het geeft hen wel de mogelijkheid om de evolutie van de productie te beïnvloeden. Verrassend, met dat gevoel van, "U kent die geweldige functie waar gebruikers van houden? Het was mijn idee!"is een grote motivatiefactor.
Maar denk niet dat dit alleen werkt voor grote teams; ons team is klein. Ons bedrijf heeft slechts een handvol ontwikkelaars, dus we zijn altijd dicht bij onze gebruikers geweest. Die relatie heeft ons in staat gesteld om ons product te beïnvloeden buiten wat onze managers in eerste instantie hadden gedacht.
Alles wat productie in de weg staat, is afval.
Integriteit gaat over de robuustheid van uw product en het is hoe klanten uw product als geheel zien. Integriteit gaat over UI-uniformiteit, betrouwbaarheid en beveiliging, en de gebruiker voelt zich veilig bij het gebruik van uw product. Integriteit is het volledige beeld dat de gebruiker voor uw product maakt. UI-integriteit omvat bijvoorbeeld het uiterlijk van pagina's, schermen, modules of zelfs tussen de gebruikersinterface van uw systeem en de website van het bedrijf..
Maar integriteit kan ook worden waargenomen en geoefend op het broncodeniveau. Integriteit kan betekenen dat uw modules, klassen en andere stukken op dezelfde manier worden geschreven. U gebruikt dezelfde principes, patronen en technieken overal in uw codebasis - zelfs tussen verschillende teams. Integriteit betekent dat je vaak je code moet refactoren. Het is een continu en eindeloos werk en je moet ernaar streven, maar nooit bereiken.
Het behouden van integriteit in onze broncode is een moeilijke taak. We realiseerden ons dat het vinden van dubbele code het moeilijkste is om te doen, en door duplicatie, bedoel ik niet een paar regels duplicaatcode in dezelfde methode of klasse.
Het gaat zelfs niet over het zoeken in verschillende modules naar exact dezelfde code; het gaat om het vinden van die stukjes van de gemeenschappelijke logica, ze extraheren in hun eigen klassen en ze op verschillende plaatsen gebruiken.
Het vinden van logische duplicatie is erg moeilijk en vereist een grondige kennis van de broncode.
Ik zit al meer dan een jaar in hetzelfde project en ik ben nog steeds verbaasd als ik dubbele code aantref. Maar dat is een goede zaak; we hebben een punt bereikt waarop we deze dingen daadwerkelijk zien en actie ondernemen. Sinds we actief begonnen met het verwijderen van dubbele logica op hoog niveau, nam onze codekwaliteit toe. We zijn een stap dichter bij het bereiken van integriteit.
Gebruikers weten niet altijd wat ze willen.
Wanneer u uw toepassing maakt, moet u nadenken over de componenten van derden waarop u vertrouwt om uw product te ontwikkelen, evenals de andere derden waarmee uw product communiceert. Uw toepassing moet worden geïntegreerd met het ontwerp van een apparaat of besturingssysteem op een desktop-pc. Is het niet eenvoudiger om een app te gebruiken die is geïntegreerd met het meldingssysteem van uw smartphone, en de gebruikersinterface weerspiegelt de gebruikersinterface van het besturingssysteem?
Ja, het zien van het geheel is niet zo eenvoudig. Je moet jezelf losmaken van de kleine details en je product van een afstand bekijken. Een van de gedenkwaardige momenten in de ontwikkeling van ons product was toen we ons realiseerden dat we moeten vertrouwen op wat andere programmeurs in andere projecten produceren. We realiseerden ons dat de kern van het systeem, geprogrammeerd door anderen, een van deze componenten van derden is waarop we vertrouwen.
Op een bepaald moment veranderde dat onderdeel van derden. We hadden net pleisters op onze applicatie kunnen toepassen, of we hadden de makkelijke route kunnen nemen en de programmeurs de schuld gegeven die dat onderdeel schreven. In plaats daarvan hebben we het probleem bij de hoorns aangepakt en het probleem opgelost in de kern van de derde partij. Het geheel zien en ermee werken kan rommelig zijn, maar het kan het verschil maken tussen een product en een geweldig product.
Er zijn verschillende tools en technieken om Lean te laten werken. Ik geef de voorkeur aan Kanban, een op een bord gebaseerde tool die vergelijkbaar is met het planbord van Scrum. Stel je een Kanban-bord voor als een dubbele trechter.
Aan de linkerkant staan de eindeloze lijst met verhalen die we moeten behandelen. Alle voltooide verhalen stapelen zich rechts op en de manager of producteigenaar bepaalt wanneer een nieuwe release wordt gepubliceerd op basis van deze lijst.
In het midden bevindt zich ons effectieve Kanban-proces. Het product moet in een stabiele en release-ready staat zijn wanneer we een verhaal voltooien. Dit betekent niet noodzakelijk dat een functie is voltooid; het product heeft misschien een paar gedeeltelijk geïmplementeerde functies. Maar de stabiliteit, veiligheid en robuustheid van het product moeten de productiekwaliteit zijn.
We deden het redelijk goed met onze huidige sprint. Het was een gewone maandag, een rustige dag met weinig opwinding, maar we begonnen tegen woensdag wat problemen te zien. Dat is OK, het gebeurt de hele tijd. Het overwinnen van deze moeilijkheden vereiste echter wat extra tijd. Onze producteigenaar was het met ons eens om verder te werken aan de huidige functie en de huidige sprint over drie of vier extra dagen uit te breiden.
Vrijdag kwam met een verrassing. U kent de regel: als er iets gaat breken, zal het vrijdag breken. Een belangrijke en potentiële klant had een bepaald kenmerk nodig voordat hij een contract tekende met het bedrijf. We moesten reageren (en snel!). Een nieuwe release was verplicht ... Maar wacht! We zitten midden in een sprint. Het product zou tegen het einde van de sprint klaar moeten zijn. Wat doen we? Scrum zou zeggen om de nieuwe functie in de volgende sprint te doen, maar we zijn al laat met de huidige sprint! Dat was het moment, toen we begonnen te beseffen dat we kleiner moeten denken dan een individuele sprint. We moeten ons sneller kunnen aanpassen en we moeten eerder vrijgeven als dat nodig is.
Een Kanban-bord lijkt veel op een Scrum-planningsbord, maar met een paar toevoegingen om het Lean-proces beter te kunnen accommoderen.
De eerste kolom aan de linkerkant is de volledige reserve: alles wat we op een bepaald moment moeten doen. Helemaal rechts hebt u de andere trechter, met alle voltooide (maar niet vrijgegeven) verhalen.
In het midden zit ons proces. Deze kolommen kunnen verschillen, afhankelijk van elk team en proces. Het wordt meestal aanbevolen om ten minste één kolom te hebben voor de volgende paar taken en een andere kolom voor de verhalen die momenteel worden ontwikkeld. De bovenstaande afbeelding laat nog een aantal kolommen zien om het ontwikkelingsproces beter te presenteren.
De Te doen kolom geeft een lijst van de taken die we moeten voltooien. Dan hebben we Ontwerp, waar ontwikkelaars werken aan het ontwerpen van de huidige verhalen. De vierde kolom is Ontwikkeling, de eigenlijke codering. eindelijk, de testen kolom geeft de taken weer die wachten op beoordeling door een andere teamgenoot.
Niemand weet alles.
Als je dit Kanban-bord vergelijkt met een scrumplanningsbord, zul je meteen de voor de hand liggende verschillen opmerken. Ten eerste heeft elke kolom een nummer dat het maximumaantal verhalen vertegenwoordigt dat in die kolom mag verblijven. We hebben vier taken: vier in ontwerp, drie in ontwikkeling en twee in testen. De achterstand en voltooide taken hebben geen dergelijke limiet.
De waarde van elke kolom moet door het team worden gedefinieerd. In de bovenstaande afbeelding heb ik willekeurige getallen aan de kolommen toegewezen; uw aantallen kunnen aanzienlijk verschillen. Ook zijn de cijfers niet definitief. Pas de aantallen aan wanneer u knelpunten identificeert en verwijdert.
Een van de meest verbazingwekkende eigenschappen van Kanban en Lean is het belang van samenwerking en herverdeling van inspanningen. Zoals je op het bord kunt zien, bevat elke kolom van ons proces kaarten met mensen erop. Er zijn acht ontwikkelaars op het voorbeeldbord - een behoorlijk groot team! Het bord toont altijd de huidige status van wie wat doet op een bepaald moment.
Volgens onze raad werken drie personen aan ontwerp, twee paar werken aan ontwikkeling en één ontwikkelaarstest. Verhalen gaan naar de volgende kolom, hun werk in de huidige kolom is voltooid en afhankelijk van het type ontwikkeling en organisatie van het team, kan dezelfde ontwikkelaar aan hetzelfde verhaal blijven werken als het door het proces beweegt.
Laten we aannemen dat we gespecialiseerde mensen hebben. Dus de primaire functie van de drie ontwerpers is ontwerp, de vier ontwikkelaars schrijven code en de eenzame tester test hoofdzakelijk het product / kenmerk. Als een ontwerper een verhaal voltooit, wordt het verhaal verplaatst en wordt een ander verhaal uit de takenlijst in het ontwerp getrokken.
Dit is een normaal proces. Een verhaal werd verplaatst van ontwerp naar ontwikkeling, en nu is de ontwikkeling maximaal. Maar wat als een andere ontwerper een ander verhaal afmaakt? Dat geeft het ontwikkelaarsteam vier verhalen - een ongewenste situatie.
Lean wil congestie voorkomen. Het is verboden om een verhaal naar de volgende kolom te verplaatsen als dit het maximum van de kolom overschrijdt. In dit geval moeten middelen opnieuw worden toegewezen; de ontwerper die zijn taak heeft voltooid, moet kiezen wat hij vervolgens moet doen. Zijn eerste optie is om een andere taak uit de taakkolom te trekken, maar hij kan dat niet doen omdat hij zijn nieuw voltooide taak moet doorgeven aan het ontwikkelingsteam (wat hij niet kan doen). Zijn enige andere optie is om aan een ontwikkelingsverhaal te gaan werken. Hij is misschien niet de beste ontwikkelaar, maar zijn inspanningen zullen helpen de processtroom in stand te houden.
Als de tester het laatste verhaal in zijn column heeft voltooid, kan hij de ontwerper helpen bij zijn ontwikkelingstaak.
Dit is geweldig! Het team kan on the fly reorganiseren! Zie je een verspilling? Zie je een knelpunt in de stroom? Onderneem onmiddellijk actie!
Zodra een verhaal in de ontwikkelingskolom is voltooid, test het testapparaat opnieuw, ontwerpt de ontwerper en nemen de ontwikkelaars het verhaal waar de ontwerper en tester aan werkten op. Maar onthoud dat u dat exacte recept niet hoeft te volgen; de ontwikkelaar zou kunnen gaan ontwerpen als de ontwerper en tester klaar zijn met het ontwikkelen van hun verhaal. Het is aan jou!
Ons bord is nu weer normaal.
Het is verboden om een verhaal naar de volgende kolom te verplaatsen als dit het maximum van de kolom overschrijdt.
Ik keek met nostalgie terwijl onze scrummeester ons bord ontmantelde. Stukje bij beetje scheurde hij onze geliefde plank neer, die toen een berg verfrommeld papier werd.
Een andere collega kwam de kamer binnen, een paar enorme vellen vers wit papier in zijn handen. Ons bord stond op het punt herboren te worden in iets anders, iets beter geschikt voor onze behoeften. Nadat de papieren vellen aan de muur waren, zijn we een ad-hocvergadering gestart om de kolommen te definiëren die we nodig hadden om ons proces te definiëren. Vervolgens hebben we gedebatteerd over het aantal verhalen dat in elke kolom moet staan. Nadat alles zorgvuldig was geschilderd en op de muur was aangebracht, ervoeren we dat vreemde gevoel ... verdriet voor het oude, maar geluk voor het nieuwe.
We hebben iets gedaan dat veel mensen noemen, Scrum-Ban. We hielden een aantal scrumconcepten, zoals de rol van scrummaster en producteigenaar, en we schatten en evalueren de verhalen nog steeds. Maar we richten ons nu op Lean en Kanban, waarbij de stroom wordt bewaard en verspillingen en knelpunten worden ontdekt en vastgesteld.
De overgang van Scrum naar Lean was eigenlijk bevrijdend. Teamleden werden veel vriendelijker voor elkaar en we begrepen dat we hulp moesten bieden zodra er niets in onze column staat. Dit gevoel dat ontwikkelaars ertoe doen, deed ons nadenken over het project als geheel; we geven meer om het project dan ooit tevoren.
Lean werd niet altijd als Agile beschouwd. Zelfs vandaag weigeren sommige Agilisten het te erkennen als een Agile methodologie. Maar meer en meer accepteren programmeurs Lean als een van de ultieme Agile-methodologieën.
Zoals een van mijn wijze collega's opmerkte, laten Lean en Kanban je toe om deze methodiek alleen te volgen. Dus, als je een eenzame ontwikkelaar bent en een paar tools nodig hebt om je leven gemakkelijker te maken, probeer dan een paar gratis Kanban-tools.
De AgileZen-website biedt een gratis account waarmee u één project kunt volgen.
Ik vond het een van de beste gratis online kanban-tools; Ik gebruik het zelfs elke dag voor het bijhouden en plannen van de voortgang van de artikelen en cursussen die ik voor Tuts + aanbied. Natuurlijk kunt u uw AgileZen-account altijd upgraden, als u meer projecten wilt bijhouden.
In dit artikel hebben we Lean en Kanban beoordeeld als een evolutie van Scrum. Betekent dit dat Lean beter is dan Scrum? Absoluut niet! Het hangt af van de projecten en mensen met wie je werkt. Kies zoals altijd de Agile-methode die het beste werkt voor u en uw team.
Accentsconagua