Ülevaade

Tänapäeval kasutatakse tarkvaraarenduses paljusid metoodikaid. Võib-olla olete kuulnud moesõnu nagu Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming jne.

Selles artiklis määratlen need mõisted, arutlen, kuidas need on omavahel seotud ja kuidas nad üksteisest erinevad. Paljud eelnimetatud moesõnad põhinevad mõistetel alates Lean tootmine mis algselt põhines Toyota tootmissüsteem (TPS) nii et kõigepealt räägime sellest.

Lean metoodika

Lean ja Lean tootmise päritolu

Mõiste “Lean” pärineb tootmisest, kus see võeti kasutusele Sakichi Toyoda, Kiichiro Toyoda ja Taiichi Ohno algselt välja töötatud Toyota tootmise süsteemil (TPS) põhineva tootmismudeli kirjeldamiseks, mille algselt inspireerisid Henry Ford. TPS keskendus filosoofiale „kõigi jäätmete täielik kõrvaldamine” ja muutis tootmise 1950. – 1970. TPS sai nimeks Lean Manufacturing 1990. aastal, kui 'Masin, mis muutis maailma' ilmus.

TPS tuvastas Toyotas kolm suurt liiki jäätmeid:

• Noor: tõlgitud kui “raisk”. Toyotas tuvastati seitse muda tüüpi ja hiljem lisati kaheksas. Need on:
  • Defektid: defektide leidmise ja parandamisega seotud jõupingutused
  • Ületootmine: tootmine enne nõudlust
  • Ootel: järgmise tootmisetapi, katkestuste jms ootamine
  • Kasutamata talent: võimete alakasutamine, ebapiisav väljaõpe jne
  • Transport: liikuvad osad või tooted, mida pole töötlemiseks vaja
  • Varud: valmis inventuur ja pooleliolevad tööd
  • Liikumine: liikumine või kõndimine rohkem kui töötlemiseks vajalik

  • Liigne töötlemine: halbadest tööriistadest või toote disainist

    

• Sisse: tõlgitud kui 'ülekoormatud'. Muri tuleneb tavaliselt murast, kuid võib tuleneda mudast. Muri avaldub lagunemises, töölt puudumises, ohutusprobleemides jne.
• Kui: tõlgitud kui 'ebatasasused'. Mura võib leida kliendi nõudluse kõikumisest, toote töötlemisaegadest või erinevate operaatorite tsükliaegade variatsioonist. Kui mura ei vähene, suureneb muri ja seega ka muda võimalus. Mura saab vähendada, luues tarneahelas avatust, muutes toote disaini ja luues kõigile operaatoritele standardtöö.

TPS töötas jäätmete kõrvaldamiseks, rakendades neid kahte põhimõistet:

• Jidoka: lõdvalt tõlgituna kui “inimliku puudutusega automatiseerimine” sätestab, et “Tootmisprotsessi käigus tuleb kvaliteet sisse ehitada!” mis tähendab, et probleemi ilmnemisel seiskub seade koheselt, takistades defektsete toodete tootmist.
• Täpselt õigeks ajaks: Valmistades ainult seda, mida on vaja, millal on vaja, ja vajalikus koguses.

TPSi arenedes tuginesid need põhisammastele ja väärtustele Jidoka ja JIT ja kinnistus:

• Pidev täiustamine:
  • Väljakutse: pikaajalise visiooni kujundamine ja väljakutsetele vastamine julguse ja loovusega unistuste elluviimiseks
  • Kaizen: äritegevuse pidev täiustamine, püüdes alati innovaatilisuse ja evolutsiooni poole, kõrvaldades korraga ühe muda
  • Genchi Genbutsu: harjutades genchi genbutsu, minnes allikale faktide leidmiseks õigete otsuste langetamiseks, konsensuse saavutamiseks ja eesmärkide saavutamiseks meie parima kiirusega
• Austus inimeste vastu:
  • Austus: teiste austamine ja igati jõupingutused üksteise mõistmiseks, vastutuse võtmine ja endast oleneva andmine vastastikuse usalduse loomiseks
  • Meeskonnatöö: stimuleerides isiklikku ja ametialast kasvu, jagades arenguvõimalusi ning maksimeerides üksikisiku ja meeskonna tulemuslikkust
• Ja edasi: staatuse või probleemide visuaalne näitaja
• Heijunka: tähendab tasandamist või tootmise tasandamist
• Hansei: tähendab eneserefleksiooni. Efektiivsuse parandamiseks peaksid töötajad parimate leidmiseks vaidlustama praeguste protsesside aluseks olevad eeldused.
• Kanban: silt, mida kasutatakse visuaalse tööriistana tootmise kontrollimiseks
• Poka-ike: Seda nimetatakse ka vigade tõendamiseks või tõendamiseks
• Tõmmake süsteem: Materjal tõmmatakse tööjaama just nii nagu vaja
• Seiri: on põhimõte, mis peegeldab jäätmeid. Seiri dikteerib, et mittevajalik tuleks eemaldada. See hõlmab kõiki algseid seitset TPS-i jäätmeid
• Standardimine: korraldab kõik töökohad inimese liikumise ümber ja loob efektiivse tootmisjärjestuse ilma mudata. See aitab saavutada kvaliteeti, ühtlast tempot ja võimaldab pidevat parendamist.

Alltoodud diagramm näitab, kuidas põhimõisted ja põhiväärtused on omavahel seotud.

Lean juhtimine

Toyota tootesüsteem ja Lean Manufacturing arenesid aja jooksul ning neid rakendati paljudes valdkondades, sealhulgas juhtimises.

Lean juhtimine rakendas pideva paranemise ja inimeste austamise põhiväärtusi ning destilleeris selle viie ettekirjutava lean-põhimõtte hulka, mida jäätmete pidevaks parandamiseks ja kõrvaldamiseks korratakse mitu korda:

1. Väärtuse tuvastamine: Määrake väärtus lõpptarbija vaatepunktist tooteperekonniti.
2. Kaardi väärtuse voog: Tuvastage iga tooteperekonna väärtusevoo kõik etapid, välistades võimaluse korral need toimingud, mis väärtust ei loo.
3. Loo voog: Tehke väärtuse loomise etapid tihedas järjestuses, nii et toode voolab sujuvalt kliendi suunas.
4. Pull'i loomine: Kui voog on kasutusele võetud, laske klientidel hankida väärtust järgmisest ülesvoolu tegevusest.
5. Püüa täiuslikkust: Väärtuse täpsustamisel tuvastatakse väärtusvood, eemaldatakse raisatud sammud ning juurutatakse vool ja tõmme, alustatakse protsessi uuesti ja jätkatakse seda seni, kuni on saavutatud täiuslikkuse seisund, kus täiuslik väärtus luuakse ilma jäätmeteta.

Need põhimõtted ja muud Lean-juhtimise aspektid vormistati, kui Womack & Jones avaldas 1996. aastal raamatu 'Lean Thinking'.

Lean tarkvaraarendus

Sellest ajast alates on Lean rakendatud juhtimisse, tarkvaraarendusse ja muudesse valdkondadesse.

1980. ja 1990. aastatel oli tarkvaraarenduse tööstus lähenemas kriisile, kuna traditsiooniliste juga metoodikate abil teostatud projektid venisid järjest kauemaks. Selle tulemuseks oli sageli suur vahe ärivajaduse kindlakstegemise ja tarkvaralahenduse tarnimise vahel. Mõnikord mõõdeti seda mahajäämust mitme aasta jooksul või isegi aastakümnete jooksul teatavates erinõuetega tööstusharudes, näiteks lennundustööstuses.

Nende mitme aasta jooksul muutusid nõuded, süsteemid või isegi terved ettevõtted. Sageli tühistati projektid poolel teel või lõpetati nende ulatus, et saada teada, et nende pakutav ei vasta enam projekti alguses tuvastatud ärivajadustele.

The Juga metoodika premeerisid sidusrühmi selle eest, et nad mõtlesid kõigele, kui nad olid sunnitud lepingut kirjutama, kuigi nad polnud ilmselt kindlad, mida nad vajavad. Juga metoodika sundis otsuseid langetama nõuete või projekteerimise etapis ning neid otsuseid oli väga raske muuta ilma lepingut muutmata ja projektile kulusid lisamata. Suur osa tarkvaraprojekte ebaõnnestus täielikult või viidi läbi hilinenult ja üle eelarve või ei suudetud pakkuda vajalikku.

See üldine pettumus viis selleni, et erinevad mõtteliidrid üritasid koske paremaks muuta. Varasemad näited hõlmavad järgmist Kiire rakenduste väljatöötamine (RAD) mis keskendus jäätmete vähendamisele nõuete ja projektide etappide otsetee abil, arendades kiiresti prototüübi ja tehes koostööd ettevõtetega nõude edasiarendamiseks. Samuti tehti iteratiivse arenduse suunas, kus valmis väike projekt ja funktsioone lisati pidevates kordustes. Kuigi need metoodikad aitasid, ei lahendanud need juga seotud põhiprobleemid .

1990. aastatel ja 2000. aastate alguses avaldasid mitmed autorid raamatuid Leani põhimõtete rakendamisest tarkvaraarenduses. Dr Robert Charette avaldas Lean tarkvaraarendus aastal 1993 ja “12 Lean tarkvaraarenduse põhimõtet” 2003. aastal.

Tom ja Mary Poppendieck avaldasid „Lean tarkvaraarendus: vilgas tööriistakomplekt” aastal. Selles raamatus kirjeldati üksikasjalikult seitset Lean Developmenti põhimõtet, mis on otseses vastavuses Lean Manufacturingu seitsme jäätmevormiga. Kahe erineva Leani väljaande ja Agile'i sarnasused ja erinevused (käsitletakse järgmises osas) on esitatud allpool toodud diagrammil.

Lean ja Agile erinevused

Dr Charette'i sõnul on Lean ja Agile üks peamisi erinevusi selles, et Agile on alt üles, samas kui Lean ülalt alla.

Eesmärgid

Charette'i Lean tarkvaraarendus	Agile manifest	Poppendiecki Lean
1/3 Inimese pingutus 1/3 Arendustunnid 1/3 aega 1/3 investeering 1/3 pingutus kohanemiseks	Isikud ja suhtlemine Töötav tarkvara Klientide koostöö Muutustele reageerimine

Põhimõtted

Charette'i Lean tarkvaraarendus	Agile manifest	Poppendiecki Lean
Kliendirahulolu Raha väärtus Kliendi osalus Meeskonnatöö Kõik on muutlik Domeen, mitte punktlahendused Täielik, ära ehita 80% lahendus täna Minimalism on hädavajalik Vajadused määravad tehnika Toote kasv on funktsioonide kasv Pidage meeles piire	Kliendirahulolu Tere tulemast muutuvad nõuded Sagedased tarnetsüklid Sidusrühmade koostöö Usalduse, toetuse ja motivatsiooni kultuur Näost näkku suhtlemine Töötav tarkvara on mõõdik Jätkusuutlik arendus Tehniline tipptase Lihtsus Iseorganiseeruvad meeskonnad Meeskonna mõtisklus	Kõrvaldage jäätmed Võimendage õppimist Toimetage nii kiiresti kui võimalik Otsustage võimalikult hilja Võimaldage meeskonda Ehitage toote terviklikkus Vaadake kogu protsessi

Agile Framework

Agile päritolu ja Agile manifest

Umbes samal ajal, kui Charette ja Poppendiecks oma raamatuid avaldasid, loodi Agile Framework samade probleemide lahendamiseks. 2001. aasta veebruaris kohtus rühm agiilseid pioneere kurikuulsal Lumelinnu kohtumisel Utahis Snowbirdis, et proovida lahendust leida.

Tulemuseks oli Vilgas manifest mis pani paika väärtuste ja põhimõtete kogumi metoodikale, mis proovib järk-järgult läheneva lähenemisviisi abil kohaneda muutuvate nõuete ja klientide vajadustega, vähendada jäätmeid ja tuua kasu kiiremini.

Agile manifest kõlab järgmiselt:

„Me avastame paremaid viise tarkvara arendamiseks, tehes seda ja aidates teistel seda teha. Selle töö kaudu oleme väärtustanud:

• Isikud ja suhtlemine protsesside ja tööriistade üle
• Töötav tarkvara üle põhjaliku dokumentatsiooni
• Klientide koostöö lepingu läbirääkimiste üle
• Muutustele reageerimine plaani järgimise üle

See tähendab, et kuigi paremal asuvatel üksustel on väärtus, hindame vasakpoolseid üksusi rohkem. '

Manifesti väärtustega joondatakse Agile manifesti 12 põhimõtet:

'Me järgime neid põhimõtteid:

1. Meie peamine prioriteet on rahuldada klienti väärtusliku tarkvara varajase ja pideva tarnimisega.
2. Tere tulemast muutuvad nõuded, isegi arenduse hilises staadiumis. Agiilsed protsessid muudavad kliendi konkurentsieeliseid.
3. Tarnige töötavat tarkvara sageli, paarist nädalast paari kuuni, eelistades lühemat ajakava.
4. Äriinimesed ja arendajad peavad kogu projekti vältel igapäevaselt koostööd tegema.
5. Ehitage projekte motiveeritud inimeste ümber. Andke neile vajalik keskkond ja tugi ning usaldage neid tööd tegema.
6. Kõige tõhusam ja tõhusam viis teabe edastamiseks arendustiimile ja selle raames on näost näkku vestlemine.
7. Töötav tarkvara on edasimineku esmane mõõdupuu. Väledad protsessid soodustavad säästvat arengut.
8. Sponsorid, arendajad ja kasutajad peaksid suutma lõputult ühtlast tempot hoida.
9. Pidev tähelepanu tehnilisele tipptasemele ja heale kujundusele suurendab väledust.
10. Lihtsus - tegemata töö hulga maksimeerimise kunst - on hädavajalik.
11. Parimad arhitektuurid, nõuded ja kujundused tekivad isekorraldavate meeskondade hulgast.
12. Korrapäraste ajavahemike järel mõtiskleb meeskond selle üle, kuidas tõhusamaks muuta, seejärel häälestab ja kohandab oma käitumist vastavalt sellele. ”

Ülaltoodud väärtused ja põhimõtted on selliste Lean põhimõtete rakendamine nagu Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka ja jäätmete vähendamine.

Tarkvara arendamisel rakendatavad väledad põhimõtted

Agile on katusraamistik, mis kehtib kõigi protsesside jaoks, mis rakendavad Agile väärtuste ja põhimõtete kogumit.

Mõned näited on:

• Äärmuslik programmeerimine
• Scrum
• Kanban

Scrum

Lühike ajalugu saast

Scrum on Agile'i põhimõtteid rakendav raamistik, mille leiutasid eraldi mitu inimest, kellest paljud kirjutasid Agile manifestile alla:

• Hirotaka Takeuchi ja Ikujiro Nonaka tutvustasid oma valges raamatus „Uus tootearenduse mäng” algselt tootmise kontekstis mõistet „scrum”. avaldatud 1986. aastal Harvardi ettevõtlusülevaates.
• Jeff Sutherland, John Scumniotales ja Jeff McKenna rakendasid Scrumi korpuses Easel 1993. aastal.
• Ken Schwaber kasutas 1990-ndatel aastatel oma ettevõttes Advanced Development Methods sellest, millest saab Scrum.

Schwaber ja Sutherland tegid 1990. aastatel koostööd raamistiku arendamiseks ja täiustamiseks tarkvaraarenduse kontekstis, esinedes erinevatel konverentsidel. Schwaber töötas koos Mike Beedle'iga meetodi kirjeldamiseks raamatus “Agile Software Development with Scrum” 2001. aastal.

Schwaber jätkas mõlema peamise Scrumi sertifitseerimisasutuse loomist:

• Scrumi liit : loodud 2001. aastal Sertifitseeritud Scrum akrediteerimissari.
• Scrum.org : loodud 2009. aastal pärast seda, kui Schwaber lahkus Scrum Alliance'ist. Pange paralleel üles Professionaalne Scrum akrediteerimissari.

Aja jooksul loodi mitu raamistikku / sertifitseerimisasutust, et tegeleda Scrumi raamistiku laiendamisega suurematele meeskondadele ja projektidele, kuna Scrum oli algselt mõeldud väikestele meeskondadele (7 pluss või miinus 2 liiget):

• SAFe : Mastaabiline vilgas raamistik
• LeSS : Suur skaala skaala
• [meiliga kaitstud] e: Scrum at Scale, mille on loonud Jeff Sutherland

Scrumi väärtused

Scrumi alliansi andmetel:

Scrum on lihtne, kuid uskumatult võimas põhimõtete ja tavade kogum, mis aitab meeskondadel tooteid tarnida lühikese tsükliga, võimaldades kiiret tagasisidet, pidevat täiustamist ja kiiret muutustega kohanemist.

Scrum on ettekirjutav, inkrementaalne ja iteratiivne raamistik Agile põhimõtteid rakendava tarkvara väljatöötamiseks. Scrumi väärtused ja põhimõtted on toodud allolevates diagrammides ning on olulisel määral kooskõlas Lean ja Agile väärtuste ja põhimõtetega.

Scrumi ülevaade

Töö jaguneb lühikesteks aegseteks kordusteks, mida nimetatakse sprindideks ja mis tavaliselt kestavad 1-3 nädalat. See on täielikus vastuolus juga põhjaliku kavandamisega. Praeguseks sprindiks kavandatud töö valitakse prioriteetsete tööde mahajäämuse ülaosast nimega Product Backlog (Pull System, Heijunka) ja see fikseeritakse pärast sprindi algust. Eesmärk on, et iga sprindi lõpus oleks toimiv tarkvara, mis võimaldab kiiret tagasisidet.

Sprindi lõpus kohtub meeskond, et vaadata läbi tehtud tööd, kuidas sprint kulges ja planeerida järgmine sprint. Sprindi pikkus, samuti sprindirituaalid ja kadents on fikseeritud iga sprindi jaoks.

Sprindid viivad läbi funktsionaalsed meeskonnad, mis sisaldavad kõiki sprindis töö lõpetamiseks vajalikke oskusi. Igapäevane kavandamine ja edasiliikumise jälgimine toimub visuaalsete esemete abil, nagu scrum board ja sprint burndown diagrammid.

Töö sprindis on valitud prioriteetsest mahajäämusest. Nende meetodite järgimine võimaldab nõudmisi aja jooksul muuta ja soodustab lõppkasutajate pidevat tagasisidet.

Allpool olev mõttekaardi diagramm kirjeldab mõningaid peamisi Scumi mõisteid, mida arutatakse järgmistes osades.

Scrumi rollid

Scrumil on kolm rolli:

• Scrum Master : Scrum Master on Scrumi meeskonna sulane. Nad on meeskonna treener, kes aitab hõlbustada koostööd, kõrvaldab takistused, rakendab ja kaitseb Scrumi protsessi ning kaitseb meeskonda. Tavaliselt tähendab see, et nad korraldavad ja hõlbustavad sprindirituaale, tagavad, et toote omanikul on korralikult prioriseeritud ja hoolitsetud mahajäämus, tagab, et meeskonda ei survestata sprindile üle pühenduma, ning tagab, et ulatust ei lisata sprint, tagab, et järgitakse määratlust Valmis. Nad ei määra meeskonna liikmetele (Genchi Genbutsu) ülesandeid ja nad ei vastuta projekti elluviimise eest
• Toote omanik : toote omanik on toote kohaletoimetamise eest vastutav „üks keeratav kael”. Tooteomanik määratleb visiooni, mida nad tahavad ehitada, ja edastab selle visiooni meeskonnale ja organisatsioonile. Tooteomanik omab äri- ja turunõudeid ning seab esikohale kogu töö, mis tuleb läbi viia toote mahajäämuse loomisel ja haldamisel. Nad otsustavad, milliseid funktsioone millal saata. Nad teevad koostööd meeskonna ja teiste sidusrühmadega, et kõik saaksid aru toote mahajäämusest. Nad võtavad sprindidemos sprindis tehtud töö vastu või lükkavad selle tagasi.
• Meeskonna liige : Scrumi meeskond on iseorganiseeruv ja funktsionaalne meeskond, mis koosneb tavaliselt viiest kuni seitsmest liikmest. Kõik projektis osalejad teevad koostööd ja aitavad üksteist ning pole tingimata seotud erinevate rollidega, nagu arhitekt, programmeerija, disainer või testija. Kõik lõpetavad koos komplekti tööd. Scrumi meeskond kavandab, kui palju tööd nad saavad iga sprindi läbida, ja omab plaani (Genchi Genbutsu).

Scrumi voog, tegevused ja tseremooniad

Nagu eespool arutletud, on Scrumil määratletud voog ning komplekt rituaale ja tegevusi. Sprindi voog on järgmine.

Sprindi planeerimine:

Enne sprindi algust hõlbustab Scrum Master kohtumist scrumi meeskonna ja tooteomanikuga, mida nimetatakse sprindi planeerimise koosolekuks, kus tooteomanik tuvastab eelseisva sprindi eesmärgid ning meeskond kavandab seejärel oma tööd vastavalt eesmärkidele.

Tavaliselt tehakse seda järgmiste tegevustega:

• Sprindi maht: võistkond määrab sprindi läbilaskevõime, võttes arvesse päevade arvu, võistkonna liikmete arvu, puhkusi jne.
• Sprindi eesmärgid: toote omanik teeb kindlaks sprindi eesmärgid. On kriitiline, et toodete mahajäämus seatakse prioriteetide järgi vastavalt eesmärkidele (st asjakohased lood on üleval) ja hoolitsetakse.
• Töö valik: lood või ülesanded tõmmatakse mahajäämuse ülaosast sprindisse, kuni hinnanguline maht on saavutatud. Kui lood on sisse tõmmatud, selgitab toote omanik lugu ja vastab meeskonna küsimustele, ajakohastades lugu vastavalt vajadusele, kuni toote omanikul ja Scrumi meeskonnal on loost hea ühine arusaam. Kui see tegevus on lõpetatud, on meeskonnal pakutud esialgne sprindi ulatus.
• Ülesande jaotus: Scrumi meeskond arutab iga lugu üksikasjalikult, pannes rõhku loo lõpuleviimise kavandamisele ning kõigi vastuvõtukriteeriumide ja dokumendi käsitlemisele. Nad koostavad loo lõpuleviimiseks vajalikest alamülesannetest. Kui alamülesannete loend on valmis, vaadatakse loo hinnang üle ja vajadusel täiendatakse.
• Sprindi kohustus: kui kõik lood on jaotatud ja hinnangud uuendatud, vaadatakse üle pakutud esialgne sprindi ulatus. Lood võidakse sprindist eemaldada ja mahajäämusse tagasi panna ja / või lisada täiendavaid lugusid. Kui see on tehtud, kohustub AINULT Scrumi meeskond (ja mitte Scrum Master või tooteomanik) sprindis töö lõpetama ja sprint alustatakse.

Sprindiks pühendatud töö või ulatuse koguarv mõõdetakse loo punktides.

Sprindi täitmine

Sprindi ajal tõmbavad meeskonnaliikmed sprintide ülesandeloendi ülaosast tööelemente (kasutajalugusid, ülesandeid jne), millega töötada. Erinevad meeskonnaliikmed tegelevad erinevate tööülesannete või nende alaülesannetega. Nad värskendavad üksuse olekut, kui see on asjakohane, teisaldades selle ühest veerust teise (tavaliselt Toiming> Pooleli> Testimine> Valmis või mõni selle variatsioon) Scrum Boardil, kuni see on tehtud.

Edenemist jälgitakse läbipõlemisdiagrammi abil, mis näitab lõpetatud ja järelejäänud töö hulka mõõdetuna jutupunktides. Ülejäänud jutupunktid kuvatakse Y-teljel ja ülejäänud aeg X-teljel. Põlemisskeemi värskendatakse lugude valmimisel.

Scrum Master keskendub igapäevaselt:

• Hõlbustab igapäevast ettevalmistuskohtumist päeva planeerimiseks ja edusammude ülevaatamiseks (vt allpool)
• Tagab, et meeskonnal on päevaplaan
• Eemaldab teetõkked
• Kaitseb sprindi ulatust ja meeskonda häirete eest
• Aitab meeskonnal säilitada läbipõlemise graafikut ja muud Scrumi statistikat

Igapäevane püsti

Iga sprindipäeva alguses hõlbustab Scrum Master lühikest 15-minutilist kohtumist scrumi meeskonna ja tooteomanikuga, et päev planeerida ja sprindi edenemine üle vaadata. See on lühike koosolek, kus kõik seisavad Scrumi juhatuse ees ja iga koosolekul osalev inimene vastab 2 minutiga või vähem järgmistele küsimustele, viidates sprindilaua konkreetsetele punktidele:

• Mida sa eile tegid?
• Mida kavatsete täna teha?
• Kas on mingeid takistusi, mis takistavad teil oma tööd lõpule viia?

See võimaldab kõigil näha, millega kõik tegelevad, näha, milliseid edusamme tehakse või mida ei tehta, ning tuvastada vajalikud takistused ja / või abi.

Sprindi lõpetamine

Enne järgmise sprindi kavandamist hõlbustab Scrum Master kahte tseremooniat sprindist sulgemiseks.

Sprindi demo

Sprindi lõpus hõlbustab Scrum Master sprindi demo koosolekut, kus iga valminud lugu demonstreeritakse töötaval tarkvaral tooteomanikule ja ülejäänud meeskonnale. Tooteomanik aktsepteerib loo, kui kõik aktsepteerimiskriteeriumid on täidetud, või lükkab loo tagasi. Loo tagasilükkamise korral tuvastatakse puudujäägid ja lugu pannakse tagasi toote mahajäämusse selle prioriteetses järjekorras, mis tuleb hiljem lõpule viia või mitte. Sageli jaotatakse loo osad, mida tooteomanik ei aktsepteeri, eraldi loo (de) ks ja algne lugu suletakse.

Arvutatakse läbitud jutupunktide koguarv sprindi kohta (kiirus) ja sprint on suletud. Kiirust kasutatakse meeskonna väljundtase jälgimiseks ja selle abil hinnatakse, millal funktsioonid või väljalasked valmivad.

Sprindi retrospektiiv

Pärast sprindidemot, kuid enne järgmist sprindi planeerimise koosolekut hõlbustab Scrum Master sprindi retrospektiivi, kus meeskond mõtiskleb äsja lõppenud sprindis ja arutab, mis läks hästi ja mis ei läinud hästi, et nad saaksid protsessi pidevalt ja järk-järgult parandada ja kvaliteeti ajas (Kaizen, Hansei). On palju tagasiulatuvaid vorminguid või harjutusi, mida saab kasutada meeskonnal arutelu tekitamiseks.

Koostatakse loend parendustoimingutest ja nende tulemusel lisatakse mõnikord üksused toote mahajäämusse, muudatusi DoD või meeskonna põhikirjas jne.

Toote mahajäämuse haldamine

Toote mahajäämuse loomine

Enne sprindi kavandamist või teostamist peab tooteomanik looma toote mahajäämuse. Mahajäämus algab tavaliselt funktsioonide väljatöötamise üksustest, mida nimetatakse toote omaniku kirjutatud lugudeks, ja aja jooksul asustatakse ka arendus- või kvaliteedi tagamise ülesandeid, piike ja defekte jne, mille potentsiaalselt võivad luua kõik meeskonna liikmed. Kõik mahajäämuse üksused on järjestatud prioriteetses järjekorras.

Mahajäänud hoolitsus

Kui toote esialgne mahajäämus on loodud ja prioriteetide seatud, võtab käimasolev mahajäämuse peigmehe protsess üle. Eesmärk on, et mahajäämusest oleks alati piisavalt palju hoolealuseid hooldatud ja hinnatud, et nad oleksid valmis sprindi planeerimise koosolekul sprindiks tõmbama. Tavaliselt tehakse seda regulaarsete käimasolevate mahajäämuste hoolduskoosolekutega tootejuht ja meeskond, keda aitab Scrum Master.

Enne koosolekut saadetakse meeskonnale nimekiri lugudest, et nad saaksid hoolduskoosolekut üle vaadata ja ette valmistuda. Peibutamiskoosolekul arutatakse iga punkti aktsepteerimise kriteeriumide, keerukuse, riski, suuruse, rakendamisstrateegia jms osas. Loo vastuvõtukriteeriumid ja muud üksikasjad vaadatakse läbi ja muudetakse, kuni meeskond, tooteomanik ja Scrum Master on loost ühine arusaam. Sel hetkel hinnatakse lugu loo punktides, kasutades tehnikat, mida nimetatakse pokkeri planeerimiseks.

Jutupunkti hindamine

Jutupunktid on pingutusühik, mis kasutab suhtelist suurust, kus lugusid võrreldakse varasemate, tuntud, hästi mõistetavate teostega. Te esitate alati küsimuse 'kas see lugu on suurem, väiksem või umbes sama suur' kui mõni muu teos.

Fibonacci skaala (1, 2, 3, 5, 8, 13, 21…) on kõige sagedamini kasutatav skaala, kus iga juurdekasv on ligikaudu kaks korda suurem kui eelmine (st viiepunktiline lugu on enam-vähem kaks korda suurem) suur kui kolmepunktiline lugu). Mõnikord kasutatakse muid kaalusid nagu T-särgi suurused (XS, S, M, L, XL) või isegi kalu (minnow, kuldkala, forell, tuunikala, vaal jne). Toimib iga skaala, mis võimaldab teil võrrelda millegi suurust teise suhtes.

Jutupunktid esindavad meeskonna kogu jõupingutusi loo rakendamiseks, sealhulgas arendamine, testimine, kujundamine ja muud mitmesugused ülesanded, mis on vajalikud määratletud valmis. Hinnangus võetakse arvesse töö hulka, keerukust ja riski. Kui loo suhteline suurus on kindlaks määratud, määratakse hinnanguks suurus skaalal.

Võistkonnad valmistuvad jutupunktide hindamise protsessiks, luues kõigepealt hinnangu andmise lähtejoone, valides kõige keskmise suurusega loo, mida kogu meeskond mõistab kui võrdluslugu. Valitakse ka mõned täiendavad teatmeteosed, mis on suuremad ja väiksemad.

Jutupunktide hindamine toimub peibutamiskoosolekutel ja mõnikord ka Sprindi planeerimisel sprindi planeerimisel:

1. Igal meeskonnaliikmel / hindajal on kaartide komplekt.
2. Mahajäämusobjekte arutatakse ükshaaval, nagu eespool kirjeldatud.
3. Kui üksus on täielikult läbi arutatud, valib iga hindaja privaatselt kaardi, et oma hinnangut näidata.
4. Kui kõik hinnangulised on oma hinnangud teinud, paljastavad nad oma kaardid samal ajal.
   • Kui kõik hinnangud vastavad, valivad hindajad teise mahajäämusüksuse ja kordavad sama protsessi.
   • Kui hinnangud erinevad, arutavad hindajad teemat konsensuse saavutamiseks.

Jutupunktide hindamise eelised on järgmised:

• Kiire: hinnangud on seotud juba lõpetatud toodete mahajäämuse üksustega.
• Piisavalt täpne: piisavalt täpne, et anda ülevaade ulatusest, kavandada edasist tööd, seada prioriteedid ja hallata ootusi.
• Haarab ebakindlust: Jutupunktid määravad tundmatu ajavahemiku. Kindla Fibonacci-laadse jutupunktide järjestuse valimine võimaldab tabada ebakindlust.
• Meeskonnasport: Kaasab kõiki (arendajad, disainerid, kvaliteedikontroll, tootejuhid). Kasutab töö suuruse määramiseks mitut perspektiivi, kuid hinnata saavad ainult seda tööd tegevad meeskonnaliikmed
• Mõõdab meeskonna kiirust: mõõdab, kui palju tööd teeb meeskond sprindis versus töö tegemisele kulutatud aeg. Kui meeskond paraneb, viivad nad sama suurusega lood kiiremini lõpule, mille tulemuseks on aja jooksul suurem loo punktikiirus.

Väljalaske hindamine ja jälgimine

Jutupunktide hindamist kasutatakse ka väljalaske kavandamise kontekstis, kasutades järgmist tehnikat:

1. Loetlege kõik lood, mille suurus peaks olema
2. Pange need järjest väikseimast suuremani
   • Võtke esimene ja teine ​​kasutaja lugu.
   • Otsustage, kumb on suurem, ja pange suurem alla
   • Seejärel võtke järgmine ja otsustage, kuhu see ülejäänud kahe jaoks sobib
   • Korrake toimingut seni, kuni kõik lood on nüüd loendis (järjestuses väikseimast suuremani)
3. Suurendage lugusid

Kõigi väljalaske lugude hinnangud koos meeskonna kiirusega võimaldavad teil hinnata, millal väljaanne on valmis, ja jälgida selle edenemist. Seda näidatakse sageli väljalaske läbipõlemise tabelis.

Scrumi artefaktid ja tingimused

• Toote mahajäämus: Antud toote kõigi tööüksuste mahajäämus, mis võib sisaldada funktsioone (lugusid), tehnilisi ülesandeid, piike ja defekte
• Vabastage läbipõlemine: Graafiline diagramm, mida kasutatakse edusammude kuvamiseks väljalasketasemel ja prognoosimiseks, millal väljaanne lõpetatakse Sprint Velocity abil. Lõppenud jutupunktid on näidatud Y-teljel ja sprindid X-teljel.
• Sprindi mahajäämus: Kõigi antud sprindis täidetavate tööde loetelu. Sprindi mahajäämuse sisu lepitakse kokku sprindi planeerimise koosolekul.
• Scrum Board: Laua stiilis tahvel, mis jälgib sprindi jaoks tehtud töö edenemist. Staatusi kuvatakse vertikaalsete veergude ülaosas ja tööüksusi liigutatakse igas olekus seni, kuni need on tehtud. Vaateplaat täidetakse sprindi planeerimise koosoleku ajal ja lähtestatakse sprindi lõpus.
• Sprindi läbipõlemine: Graafiline diagramm, mis näitab lõpetatud ja järelejäänud töö hulka, mõõdetuna jutupunktides kogu sprindi pikkuse jooksul. Ülejäänud jutupunktid kuvatakse Y-teljel ja ülejäänud aeg X-teljel.
• Sprindi kiirus: Lugude punktide arv, mille Scrumi meeskond sprindis läbib.
• Takistuste mahajäämus: Nimekiri takistustest, millega Scrum Master peab tegelema, et meeskond saaks tööd jätkata. Kui meeskonnaliige on blokeeritud, lisavad nad takistuste mahajäämusse üksuse, et tagada meeskonnale ja Scrum Masterile nähtavus.
• Eepos: Eepos on suur töö, mis koosneb mitmest seotud kasutajalugust.
• Kasutaja lugu: Kasutaja lugu on tarkvara funktsiooni kirjeldus lõppkasutaja vaatenurgast. Kasutaja lugu kirjeldab kasutaja tüüpi, mida nad tahavad ja miks. Kasutaja lugu aitab luua nõude lihtsustatud kirjelduse ja sisaldab aktsepteerimise kriteeriume. Kasutajate lugusid loob ja haldab toote omanik.
• Ülesanne: Ülesanne on töö, mille sisestab Scrum Master või meeskonnaliige, mis võib olla otseselt või kaudselt seotud kasutajate lugudega. Need on tavaliselt oma olemuselt tehnilised ja sisaldavad vastuvõtukriteeriume.
• Spike: Spike on eritüüp ülesanne, mida kasutatakse siis, kui peate millalgi uurima, prototüüpi ja / või arhitekti tegema, enne kui saate otsustada, kuidas kasutaja lugu rakendada või hinnata.
• Alaülesanne: Alaülesanne on ülesanne, mis sisestatakse rakendusetapina kasutajaloo või ülesande täitmise suunas. Tavaliselt siseneb meeskond sprindi planeerimise koosolekul.
• Jutupunktide hinnangud: Suhteline suuruse hindamise skaala, mis põhineb Fibonacci skaalal (1, 2, 3, 5, 8, 13, 21…)
• Vastuvõetavuse kriteeriumid: Igas loos sisalduvate loospetsiifiliste ja testitavate üksuste loend, mis tuleb täita enne, kui tooteomanik aktsepteerib loo valmimist.
• Valmis (DoD) määratlus: Loetelu ühistest toimingutest või kriteeriumidest, mis tuleb täita enne, kui loo võib lugeda valmis. Meeskond lepib selles kokku ja dokumenteerib selle, et seda ei peaks igas loos loetlema.

Scrumi eelised ja puudused

Scrumi esmane eelis on nii väledate väärtuste ja põhimõtete kui ka Lean-kontseptsioonide nagu Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System ja Iterations rakendamine. Nende põhimõtete rakendamine võimaldab projektimeeskondadel saada pidevat tagasisidet, kohaneda kiiresti muutuvate nõuete ja ebakindlusega, vähendada raiskamist, suurendada nähtavust ja läbipaistvust ning püüelda pideva täiustamise poole. Keskendudes alati toote mahajäämusest kõige olulisematele üksustele ja töötades ainult lühikeste kordustega, mis toodavad alati töötavat tarkvara, on Scrum kliendikesksem ja võimaldab klientidel näha, mis neile meeldib (ja mis ei meeldi) ning vajadusel muudatusi teha. Protsessi ja juhtimise üldkulud on väiksemad, mis toob kaasa kiiremad ja odavamad tulemused.

Scrum on suurepärane metoodika projektide jaoks, mille nõuded pole selgelt teada ja / või eeldatavasti muutuvad. See kehtib enamiku projektide kohta. Scrum on suurepärane ka kogenud, motiveeritud meeskondadele, kuna see võimaldab meeskondadel ise tööd korraldada ning see tagab nähtavuse, läbipaistvuse ja vastutuse nii edasimineku kui ka probleemide eest. Kõik see toob kaasa meeskondade paremuse ja aja jooksul produktiivsema tulemuse.

Scrumil on siiski mõned puudused ja see pole mõnes olukorras parim metoodika:

• Läbipaistvus: Scrum suurendab läbipaistvust ja vastutust, mis on nii eelis kui ka puudus, kuna probleemid ja kehv tulemuslikkus meeskonnas ja väljaspool seda on avatud. See võib olla ebamugav ja põhjustada vastupanu, kui sellega ei tegeleta Scrumi pideva parendamise raames korralikult.
• Meeskonna kogemus ja pühendumus: Kogemusteta ja / või pühendumata Scrumi meeskonnad või Scrum Masters võivad Scrumi metoodika valesti rakendamise kaudu põhjustada tõsiseid probleeme. Scrumi meeskonnas pole määratletud rolle, kuna kõik teevad kõike, nii et selleks on tehnilise kogemusega pühendunud meeskonnaliikmetel vaja Scrum'i protsessi jälgida ja aja jooksul täiendada. Samuti võib see olla väga kahjulik, kui organisatsiooni teised osad on Scrumile vastupidavad.
• Reguleerimisala roomamine: On oht, et ulatus ulatub ligi, eriti kui pole kindlaks määratud lõppkuupäeva, kuna huvirühmadel on lubatud reguleerimisala laiendada. Ulatus ja prioriteetide muutmise võimalus on Scrumi üks peamisi eeliseid, kuid see võib olla ka puuduseks, kui distsipliini ei kasutata.
• Halvasti määratletud töö: Halvasti määratletud ja arusaadavad kasutajalood või ülesanded võivad viia ümbertöötamiseni, ebatäpsete hinnangute ja ulatuseni. Ehkki Scrum on keskendunud töötavale tarkvarale, mitte dokumentatsioonile, peab tooteomanikul olema selge, mida ta tahab, ja olema võimeline seda vestlustes ja kasutajalugudes selgelt edastama.
• Skaleerimine: Scrumi raamistiku vastuvõtmine suurtes meeskondades on keeruline, kuna Scrum on mõeldud väiksematele meeskondadele.

Kanban

Mis on Kanban?

Kanban on kergem kaaluprotsess, mis rakendab paljusid Lean ja Agile väärtusi, samuti Scrumi väärtuste ja põhimõtete alamhulka, kuid on ka mõningaid põhimõttelisi erinevusi. Kanban keskendub visualiseerimisele, voolule ja pooleliolevate tööde piiramisele.

Kanban on jaapani keeles „silt“ või „stend“. Toyota liinitöölised kasutasid kanbani (s.t. tegelikku plaati), et anda tootmisprotsessi erinevates etappides märku lisavõimsusest. Tarkvaras tehakse seda Kanbani tahvliga, mis on Scrumi tahvliga väga sarnane. Iga oleku jaoks, millel tööelement võib olla, on prioriteetsed mahajäämised Ülesannete üksustest ja vertikaalsed veerud. Nagu ka Scrum, viiakse tööesemed ühest olekust teise; Kanbanis on aga pooleliolevate tööde maht rangelt piiratud maksimaalse üksuste arvuga igas staatuses, lähtudes meeskonna võimekusest. Uut tööd ei saa sisse tõmmata enne, kui olemasolevad tööd on viidud protsessi järgmisse etappi. Scrumis on pooleliolevad tööd kaudselt piiratud, kontrollides sprindiks kavandatud tööde hulka.

Kanbanis ei ole fikseeritud kordusi ega spurte, lihtsalt pidev voog, kus tööesemeid tõmmatakse ühest etapist teise. See tähendab, et Kanbani plaati ei lähtestata kunagi. See tähendab ka seda, et paljusid Scrumi rituaale ei kasutata. Kanbani meeskondadel on sageli igapäevased koosolekud, kuid neile pole ette nähtud. Puuduvad regulaarselt planeeritud sprindi planeerimise koosolekud, sprindidemod või sprindi retrospektiivid, seega on protsess kergem. Mõningaid nende rituaalide tegevusi võidakse mitte teha mitteametlikul tasandil. Pidev paranemine saavutatakse, jälgides ja analüüsides üksuste voogu ühest olekust teise ning tehes pidevaid järkjärgulisi täiendusi selle põhjal, milliseid probleeme paljastatakse.

Kanban ei määra ka rolle, mida Scrum teeb. Ainus vajalik roll on meeskonnaliikme roll, kuid sageli on olemas ka projektijuht mis haldab meeskonda ja mahajäämust. Sageli võib üks Kanbani juhatus teenida mitut funktsioonipõhist rolli ja / või meeskonda, kes töötavad ainult kindlas olekus olevate üksustega. Näiteks võib arendusmeeskond tõmmata üksused jaotisest To Do to Progress ja viia see testimisse ning testimeeskond võib testida üksusi Testing'is ja viia need jaotisse Done.

Paljud esemete tähtsuse järjekorda seadmise ja hoolitsemise mahajäämuse haldamise tegevused tuleb siiski teha, et tagada konkreetse tööartikli mõistmine ja töötamiseks valmisolek, kuid tööüksuste hindamine on valikuline.

Kanban vs Scrum

Järgmises tabelis võrreldakse Scrumi ja Agile'i:

Kanban	Scrum
Pidev kohaletoimetamine	Timeboxed Sprints
Vähem protsessi ja üldkulusid	On ette kirjutanud Sprindi rituaalid ja rollid
Keskendub üksikute esemete kiirele valmimisele	Keskendub partii töö kiirele lõpuleviimisele
Mõõdab tsükli aega	Mõõdab sprindi kiirust
Keskendub tõhusale voolule	Keskendub prognoositavusele
Piirab üksikute üksuste WIP-i	Piirab WIP-i Sprindi tasemel
Üksikud tööesemed tõmmatakse	Sprinti planeerimisel tõmmatakse töö partiidena
Pole ette nähtud rolle	On määranud rollid (Scrum Master, tooteomanik, meeskonnaliige)
Kanbani juhatus võib olla organiseeritud ühe ristfunktsionaalse meeskonna või mitme spetsialiseeritud meeskonna ümber	Scrum Board on korraldatud ühe funktsionaalse meeskonna ümber
Muudatusi saab teha igal ajal -> paindlikumalt	Muudatused on lubatud ainult toote mahajäämuses. Sprindisisesed muudatused pole lubatud
Nõuab vähem koolitust	Nõuab rohkem koolitust
Hea meeskondadele, kus on vaja ainult täiendavaid parandusi	Hea meeskondadele, kus on vaja põhimõttelisi muudatusi

Kokkuvõte: 1. osa lõpp

Selles osas vaatasime üle mõned tarkvaraarenduses kasutatavad kõige populaarsemad metoodikad. Nüüd peaksite olema hästi kursis Lean, Agile, Scrum ja Kanban ning nende ajalooliste juurtega Lean Manufacturingis ja TPS-is. Sarja järgmises osas jätkame teiste tarkvaraarenduse metoodikate, nagu näiteks, ülevaatamist ja võrdlemist Juga , JTBD ja SAFe (ja muud skaleerimisraamistikud), samuti hübriidmetoodikad, nii et teil on kõik need mugavalt ühes kohas lahti seletatud.

Põhitõdede mõistmine

Mis on vilgas?

Agile on katusraamistik, mis kehtib kõigi protsesside jaoks, mis rakendavad Agile väärtuste ja põhimõtete kogumit. Mõned näited on: Extreme Programming, Scrum ja Kanban.

Mis on Scrum?

Scrum on lihtne, kuid uskumatult võimas põhimõtete ja tavade kogum, mis aitab meeskondadel tooteid tarnida lühikeste tsüklitena. Scrum on Agile põhimõtteid rakendav raamistik, mille leiutasid eraldi mitu inimest, kellest mitmed kirjutasid alla Agile Manifestile.

Mis on Kanban?

Kanban on kergem kaaluprotsess, mis rakendab paljusid Lean ja Agile väärtusi, samuti Scrumi väärtuste ja põhimõtete alamhulka, kuid on ka mõningaid põhimõttelisi erinevusi. Kanban keskendub visualiseerimisele, voolule ja pooleliolevate tööde piiramisele.