Agile ja kõhn, mis vahe on?

Kooliõpetaja sõber küsis hiljuti, kas ma teadsin Agile'ist midagi ja kas mõni neist tundlikest või lahjatest meetoditest töötab projektide ja inimeste hariduskeskkonnas korraldamise abiks.

Ma teadsin, mida mu sõber mõtles, kuid selguse puudumine lahja ja agiilsuse vahel pani mind täielikult selgitusrežiimi minema ja seetõttu tahtsin sellest midagi kirjutada. See, mida ma kirjutasin, oli sisuliselt see ja mul soovitati seda laiemalt jagada.

Agile / Scrum / Kanban pole tegelikult üldse üks ja sama asi, kuid need esinevad sarnaste tööriistade ja nähtavate märgistustega, nii et nad satuvad sageli segadusse.

Agiilne on lihtsalt tarkvara arendamise metoodikate kogumi üldine kättetoimetamine, mis kõik keskenduvad sellele, et ei tehtaks projektide ette planeerimist, mida me praegu nimetame jugastiiliks, või tänapäevastele praktikutele V-arendusmudelit. Agiilsed meetodid jagavad mõnda ühist põhimõtet, öeldes, et te ei tea, kas teie tarkvara on midagi head, kuni keegi seda näeb, proovib ja tagasisidet annab. See tähendab, et nad keskenduvad iteratsioonile, tarkvara varasemate versioonide edastamisele, tagasiside saamisele ja meeskondade suhtlemise võimaldamisele jne.

Scrum on üks vilgas metoodika, see juhtub olema kõige tuntum, kuid on ka teisi. Scrum on peamiselt keskendunud projekti, tavaliselt tarkvara, tarnimisele, kuid seda on kasutatud paljudes teistes projektitüüpides. Konkreetsed omadused, mida otsite, on järgmised:
* Saate tuvastada, millal olete lõpule viidud (või siis tehakse mingil hetkel teie töö ja lakkate töötamast)
* Teil on meeskond inimesi, kes peavad projekti nimel koostööd tegema
* Saate kavandatud tulemused jagada etappideks või väikesteks funktsionaalsusühikuteks.

See tähendab, et scrum töötab tõesti hästi, kui teie projektil on need atribuudid.

Nii et plaan jagada moodulid õpetajate vahel ära ja õpetada neid üheskoos õpetama võiks toimida. Saate ülesanded jaotada iga moodulina või üksusena, igale ülesandele saate määrata omaniku ja teate, millal see on tehtud.

Kanban, või nagu ma eelistaksin seda nimetada, Lean, pärineb algselt tootmisest. Toyota tootmissüsteem on Lean'i looja ja tegelikult on kõhnatootmisele üleminek ikka selline asi, mida näete Suurbritannias praegu tehastes (kümmekond aastat tagasi ei ole ma mõnda aega tehases töötanud!) .

Lean töötab välja selle, mis peaks olema tõmbepõhine süsteem. Enamikku tootmisliinidest peetakse tõukepõhiseks. Haarake ühest otsast hunniku tooraineid, lükkate need läbi mitme sammu ja saate teises otsas valmistooteid.
Nutikas asi on see mõtlemine ümber pöörata ja sisuliselt öelda, et tehas peaks tootma ainult nii palju, kui kliendid on tellinud. Kõik enam muutub ülejäägiks, mille ladustamiseks kulub palju raha ning mille väärtus kipub kas lagunema või odavnema.
Iga tootmisliini jaam soovib eelmisest jaamast oma töö tegemiseks vajamineva koguse ära tõmmata ja see peaks süsteemi kaudu tagasi tooreste koostisosade juurde minema.

Lahjad meeskonnad kasutavad Kanbani tahvlit, et anda märku sellest, mis neil radaril on ja mille kallal nad töötavad. See aitab meeskondadel vaadata järgmist lauda allapoole jne.

Lean / Kanban on seetõttu tõesti hea probleemide korral, mis:
* On pidevad, kus protsessi võib täiustada, kuid mitte muuta, ja teid ei tohi kunagi "valmis teha"
* Kui pooleliolevate tööde ladustamine või mis veelgi hullem, on protsessi etappide vahel ladustatud töö kulukas või mingil moel raiskav
* Seal, kus saate hõlpsalt mõõta ja täiustada seda, kus protsessiprotsessis muudatusi võib olla

Eriti keskendub Lean paarile peamisele põhimõttele:
* Tsükli aeg, st aeg algusest lõpuni on halb
* Pooleliolevad tööd peaksid olema piiratud, tagamaks, et lükate tööd järgmisse etappi kiiremini, kui nad suudavad seda tarbida
* Töö salvestamine töötlemisetappide vahel on raiskav või keeruline

Ma kasutaksin lahjat protsessides, nagu märgistamis- ja kinnitamisprotsessid või mis tahes mitmeastmelised protsessid. Iga inimene või meeskond sõltub ühest või mitmest teisest meeskonnast saadud teabest ning kogub ja koordineerib tööd, mida edasi arendada.

Leanilt on tõesti huvitav õppida seda, et kohalik optimeerimine võib olla täiesti kasutu. Nii et kui teil on 5-etapiline protsess ja üks etapp suudab päevas töödelda ainult 10 eset, siis on täiesti mõttetu töötada selle nimel, et mõni teine ​​etapp saaks päevas töödelda 25 eset, kui te ei saa ka aeglast etappi kiirendada. See aitab teil keskenduda parenduste tegemisele. Kanbani termin selleks on Kaizen, mille eesmärk on teha ahela kõige aeglasema, nõrgima ja madalaima kvaliteediga (vali oma meetermõõdustik) osa väikeste järkjärguliste parandustega ja seejärel korrata järgmisel nädalal / iteratsiooni.

See, kuidas ma õpetajate jaoks administraatoritööd korraldaksin, sõltub täielikult sellest, kas inimesed teevad koostööd ja kui palju nad üksteisest sõltuvad. Tean koolitööde tegemisest väga vähe, kuid arvan, et kodutööd, kursuste märkimine ja muud asjad ei ole enamasti ühised. Muud asjad, mida ma arvan, on ühekordsed projektid, nii et reiside või uute suurte projektide korraldamine on selline asi.

Ma kahtlustan, et kindla ulatusega projektide puhul, kus mitu inimest teevad koostööd, läheksin tõenäoliselt Scrumi stiilis teele. Võtke inimesed kokku, mõelge, mida soovite edastada, ja jälgige seda suure nähtava tahvli abil koos post-iti või registrikaartidega ja viige ülesanded üle nii, nagu nad valmis saavad. Te ei kasuta tõelist nühkimist, kuid saate mõningaid agiilsuse eeliseid, näiteks nähtavat tagasisidet, põlemisprognoosi (see on aeg lõpetada, kui olete lõpetanud) ja muud sellist.

See, et teete sama asja, kuid suure protsessina, näiteks paberite või aruannete saatmine paljude inimeste ümber, sisendite saamine või muutmine igaühe poolt ja sama toimimine igal ametiajal või aastal, siis võib Lean / Kanban sobida sa parem.

Muidugi, kui see, mida teete, on projekt, kus on hästi aru saada ja kuidas väljund teada on, siis tõenäoliselt ei aita vilgas tehnika teid üldse kasutada ja peaksite selle asemel kasutama traditsioonilist projektihalduskomplekti. tehnika asemel.