Judrus ir lieknas, koks skirtumas?

Neseniai vienas draugas mokytojas paklausė, ar aš ką nors žinau apie judrųjį, ir ar kuris nors iš tų judrių ar liesų metodų padės organizuoti projektus ir žmones švietimo aplinkoje.

Aš žinojau, ką reiškia mano draugas, tačiau neaiškumas dėl skirtumo tarp liesos ir judrios privertė mane visiškai paaiškinti, todėl norėjau apie tai ką nors parašyti. Tai, ką parašiau, buvo iš esmės tai, ir man buvo rekomenduota ja pasidalyti plačiau.

Agile / Scrum / Kanban iš tikrųjų nėra tas pats dalykas, tačiau jie pateikiami su panašiais įrankiais ir matomais ženklais, todėl jie dažnai susipainioja.

„Agile“ - tai tiesiog bendras rankdarbis, skirtas daugiausiai programinės įrangos kūrimo metodikų kolekcijai, kurioje visi sutelkti dėmesį į tai, kad nesudarytumėte projekto iš anksto, ką mes dabar vadiname krioklio stiliumi, arba šiuolaikiniams specialistams - V modelio kūrimo modelį. Visi judrūs metodai turi keletą bendrų principų, iš esmės tariant, kad jūs nežinote, ar jūsų kuriama programinė įranga yra gerai, kol kas nors nepamatys, neišbandys ir nepateikia atsiliepimų. Tai reiškia, kad jie daugiausia dėmesio skiria iteracijai, ankstyvųjų programinės įrangos versijų pateikimui, grįžtamojo ryšio gavimui ir komandų įgalinimui bendrauti ir kt.

„Scrum“ yra viena judri metodologija, ji būna geriausiai žinoma, tačiau yra ir kitų. „Scrum“ pirmiausia yra skirtas projekto, paprastai programinės įrangos, pristatymui, tačiau jis buvo pakartotinai panaudotas daugeliui kitų tipų projektų. Konkrečios jūsų ieškomos funkcijos yra:
* Galite nustatyti, kada baigsite (arba kai kada būsite baigti ir nustosite veikti)
* Jūs turite komandą žmonių, kuriems reikia bendradarbiauti įgyvendinant projektą
* Galite suskaidyti numatomus rezultatus į žingsnius arba mažus funkcionalumo vienetus.

Tai reiškia, kad scrum veikia tikrai gerai, kai jūsų projektas turi šiuos požymius.

Taigi planas padalinti modulius tarp mokytojų ir mokyti juos koncertuoti gali pasiteisinti. Galite padalinti užduotis kaip kiekvieną modulį ar rinkinį, kiekvienai užduočiai galite priskirti savininką ir žinosite, kada tai bus padaryta.

„Kanban“ arba, kaip aš labiau norėčiau tai vadinti, „Lean“, yra kilęs iš originalios gamybos. „Toyota“ gamybos sistema yra „Lean“ šalininkė. Tiesą sakant, perėjimas prie liesos gamybos vis dar yra dalykas, kurį matote šiandien JK gamyklose (prieš gerą dešimtmetį aš kurį laiką nedirbau gamykloje!) .

Lean veikia tai, kas turėtų būti traukimo pagrįsta sistema. Daugelis gamybos linijų laikomos stumiamomis. Jūs patraukiate krūvą žaliavų viename gale, pastumkite jas per keletą žingsnių ir gaukite gatavų produktų kitame gale.
Protingas dalykas, kurį pasieksite, yra apversti šį mąstymą ir iš esmės pasakyti, kad gamykla turėtų gaminti tik tiek, kiek užsako klientai. Viskas daugiau tampa pertekliumi, kainuojančiu pinigus saugoti, ir jo vertė ardyti, arba nuvertėti.
Kiekviena gamybos linijos stotis nori ištraukti iš ankstesnės stoties kiekį, reikalingą jų darbui atlikti, o traukimas turėtų grįžti per sistemą iki žaliavų.

Liesos komandos naudoja „Kanban“ lentą, norėdamos parodyti, ką jos turi savo radare ir ką dirba. Tai padeda komandoms žiūrėti į kitą lentą žemyn ir pan.

Taigi Lean / Kanban yra tikrai tinkamas problemoms, kurios:
* Yra tęstiniai, kur procesas gali būti patobulintas, bet nekeičiamas, ir jūs niekada negalite būti „padarytas“
* Jei saugomas nebaigtas arba, dar blogiau, darbas, saugomas tarp proceso etapų, yra brangus arba tam tikra forma yra eikvojamas
* Kur galite lengvai įvertinti ir patobulinti, kur gali būti proceso pokyčiai

Ypač „Lean“ dėmesys sutelkiamas į keletą pagrindinių principų:
* Ciklo laikas, ty laikas nuo pradžios iki pabaigos yra blogas
* Vykdomi darbai turėtų būti ribojami, kad užtikrintumėte, jog darbus perkeliate į kitą etapą greičiau, nei jie gali sunaudoti
* Saugoti darbą tarp perdirbimo etapų yra beprasmiška arba sudėtinga

Aš naudoju liesą procesus, tokius kaip žymėjimo ir patvirtinimo procesai ar bet kuris daugiapakopis procesas. Kiekvienas asmuo ar komanda priklauso nuo informacijos, kurią teikia viena ar kelios kitos komandos, ir kaupia bei koordinuoja darbą, kurį reikia tęsti toliau.

Iš tiesų įdomus Lean mokymasis yra tas, kad vietinis optimizavimas gali būti visiškai nenaudingas. Taigi, jei jūs turite 5 etapų procesą ir vienas etapas gali apdoroti tik 10 elementų per dieną, tada visiškai beprasmiška dirbti tam, kad kitas etapas galėtų apdoroti 25 elementus per dieną, nebent taip pat galite pagreitinti lėtą etapą. Tai padeda susikoncentruoti, kur tobulėti. „Kanban“ terminas yra „Kaizen“, tai yra padaryti nedideli pamatiniai patobulinimai lėčiausioje, silpniausioje ir žemiausios kokybės (pasirinkite metriką) grandinės dalyje, o po to pakartoti kitą savaitę / iteracija.

Kalbant apie tai, kaip organizuosiu administratorių darbą mokytojams, visiškai priklauso nuo to, ar žmonės bendradarbiauja, ir kiek jie priklauso vienas nuo kito. Aš labai mažai žinau, kaip atliekami mokykliniai darbai, bet spėju, kad namų darbai, kursų žymėjimas ir kiti dalykai dažniausiai nebendradarbiauja. Kiti dalykai, kuriuos aš suprantu, yra vienkartiniai projektai, todėl organizuoju keliones ar naujus didelius projektus.

Įtariu, kad vykdant fiksuotos apimties projektus, kuriuose bendradarbiauja keli žmonės, tikriausiai einu Scrum stiliaus keliu. Susiburkite žmonėms, supraskite, ką norite pristatyti, ir stebėkite tai naudodami didelę matomą lentą su atvirukais ar rodyklės kortelėmis ir perkelkite užduotis atlikdami jas atlikdami. Nenaudosite tikros „įbrėžimo“, tačiau gausite kai kuriuos judrumo pranašumus, pavyzdžiui, matomą grįžtamąjį ryšį, įvertinsite perdegimą (dar reikia laiko įvertinti įvertinimus, kada baigsite) ir panašius dalykus.

Jūs darote tą patį dalyką, tačiau kaip didelis procesas, pvz., Perduodamas dokumentus ar ataskaitas apie daugybę žmonių, gaudamas įvestį ar pakeitimus iš kiekvieno, jūs darote tą patį kiekvieną kadenciją ar metus, tada Lean / Kanban gali tikti. tu geriau.

Galiausiai, žinoma, jei tai, ką darote, yra projektas, kai gerai suprantate, kaip tai darote, o išėjimas yra žinomas, greičiausiai judrūs metodai jums visai nepadės, todėl turėtumėte naudoti tradicinį projekto valdymo rinkinį. vietoj metodų.