Veikls un liess, kāda ir atšķirība?

Skolotājas draugs nesen vaicāja, vai es kaut ko zināju par veiklību un vai kāda no šīm veiklām vai vienkāršām metodēm noderēs, lai palīdzētu organizēt projektus un cilvēkus izglītības vidē.

Es zināju, ko nozīmē mans draugs, bet skaidrības trūkums par atšķirību starp liesu un veiklu lika man pilnā mērā izskaidrot, un tāpēc es gribēju kaut ko par to uzrakstīt. Tas, ko es uzrakstīju, būtībā bija šāds, un man ieteica ar to dalīties plašāk.

Agile / Scrum / Kanban patiesībā nav tas pats, taču tie ir ar līdzīgiem rīkiem un redzamiem marķējumiem, tāpēc tos bieži sajauc.

Agile ir tikai vispārīga rokassprādze lielākoties programmatūras izstrādes metodoloģiju kolekcijai, kas koncentrējas uz to, ka netiek veikta projekta plānošana pa priekšu, to, ko mēs tagad saucam par ūdenskrituma stilu, vai mūsdienu praktiķiem - V attīstības modeli. Agile metodēm ir daži kopīgi principi, galvenokārt sakot, ka jūs parasti nezināt, vai jūsu veidotā programmatūra ir laba, kamēr kāds to neredz, neizmēģina un nesniedz atsauksmes. Tas nozīmē, ka viņi koncentrējas uz iterāciju, uz programmatūras agrīno versiju piegādi un atgriezeniskās saites iegūšanu, kā arī iespēju komandām sazināties utt.

Scrum ir viena veikla metodika, tā, iespējams, ir vispazīstamākā, taču ir arī citas. Scrum galvenokārt ir vērsts uz projekta, parasti programmatūras, piegādi, bet tas ir atkārtoti izmantots daudziem citiem projektu veidiem. Konkrētās funkcijas, kuras jūs meklējat, ir:
* Jūs varat noteikt, kad esat pabeidzis (vai kādā brīdī jums tiks darīts, un pārstāt darboties)
* Jums ir cilvēku komanda, kuriem jāsadarbojas projektā
* Jūs varat sadalīt paredzētos rezultātus pakāpēm vai mazās funkcionalitātes vienībās.

Tas nozīmē, ka scrum darbojas patiešām labi, ja jūsu projektam ir šie atribūti.

Tāpēc plāns sadalīt moduļus starp skolotājiem un mācīt viņus koncertā varētu labi darboties. Jūs varat sadalīt uzdevumus kā katru moduli vai vienību, katram uzdevumam varat piešķirt īpašnieku, un jūs zināt, kad tas ir izdarīts.

Kanban vai, kā es labprātāk to saucu, Lean, nāk no sākotnējās ražošanas. Toyota Ražošanas sistēma ir Lean priekštecis, un faktiski pāreja uz liesu ražošanu joprojām ir lieta, kas, kā jūs redzat, notiek rūpnīcās Lielbritānijā (pirms desmit gadiem es kādu laiku neesmu strādājis rūpnīcā!) .

Lean strādā pie sistēmas, kurai vajadzētu būt balstītai uz pull. Lielākā daļa ražošanas līniju tiek uzskatītas par balstītām. Vienā galā jūs satverat ķekars izejvielu, izbīdāt tos pa soļu virkni un otrā galā iegūstat gatavos produktus.
Gudrā lieta, ko izveic, ir apgriezt šo domāšanu un būtībā pateikt, ka rūpnīcai jāražo tikai tik daudz, cik klienti ir pasūtījuši. Viss vairāk kļūst par pārpalikumu, kas maksā naudu glabāšanai, un tam ir tendence vai nu samazināties, vai arī tā vērtība samazinās.
Katra ražošanas līnijas stacija vēlas no iepriekšējās stacijas izvilkt summu, kas nepieciešama viņu darba veikšanai, un caur sistēmu sistēmai vajadzētu atgriezties līdz izejvielām.

Liesās komandas izmanto Kanban plātni, lai signalizētu, kas viņiem ir uz viņu radara un uz ko viņi strādā, un tas palīdz komandām skatīties uz nākamo dēli utt.

Tāpēc Lean / Kanban patiešām ir piemērots problēmām, kas:
* Ir nepārtraukti, kur procesu var uzlabot, bet netiek mainīti, un jūs, iespējams, nekad netiksit “paveikts”
* Ja nepabeigta darba glabāšana vai, vēl sliktāk, darbs, kas glabājas starp procesa posmiem, ir dārgs vai savā ziņā nelietderīgs
* Kur varat viegli izmērīt un uzlabot vietas, kur varētu būt izmaiņas procesā

Jo īpaši Lean koncentrējas uz dažiem galvenajiem principiem:
* Cikla laiks, tas ir, laiks no sākuma līdz beigām ir slikts
* Nepabeigtais darbs ir jāierobežo, lai nodrošinātu, ka jūs virzāt darbu uz nākamo posmu ātrāk, nekā viņi to var patērēt
* Uzglabāt darbu starp apstrādes posmiem ir nelietderīgi vai grūti

Es izmantoju liesu procesiem, piemēram, marķēšanas un validācijas procesiem, vai jebkuram daudzpakāpju procesam. Katra persona vai komanda ir atkarīga no vienas vai vairāku komandu informācijas, un tā apkopo un koordinē darbu, lai turpinātu.

Patiešām interesanta Lean mācība ir tāda, ka vietējā optimizācija var būt pilnīgi bezjēdzīga. Tātad, ja jums ir piecu pakāpju process un viens posms var apstrādāt tikai 10 priekšmetus dienā, tad darbs pie tā, lai cits posms varētu apstrādāt 25 priekšmetus dienā, ir pilnīgi bezjēdzīgs, ja vien jūs nevarat arī paātrināt lēno posmu. Tas palīdz jums koncentrēties uz to, kur veikt uzlabojumus. Kanbanas termins tam ir Kaizen, kura mērķis ir veikt nelielus pakāpeniskus uzlabojumus lēnākajai, vājākajai un zemākās kvalitātes ķēdes daļai (izvēlieties metriku) un pēc tam atkārtot nākamnedēļ / iterāciju.

Runājot par skolotāju administratora darba organizēšanu, tas ir pilnībā atkarīgs no tā, vai cilvēki sadarbojas un cik viņi ir atkarīgi viens no otra. Es ļoti maz zinu par to, kā tiek veikts skolas darbs, bet domāju, ka mājasdarbi, kursu apzīmējumi un citas lietas parasti nesadarbojas. Citas lietas, kuras es uzskatu, ir vienreizēji projekti, tāpēc šāda veida lieta ir ceļojumu organizēšana vai jauni lieli projekti.

Man ir aizdomas, ka projektiem ar noteiktu mērogu, kad sadarbojas vairāki cilvēki, es, iespējams, eju pa Scrum stila ceļu. Salieciet cilvēkus, izprotiet, ko vēlaties piegādāt, un sekojiet tam līdzi, izmantojot lielu redzamu tāfeli ar pastkarti vai indeksa kartēm un pārvietojiet uzdevumus uz paveikto, kad viņi to dara. Jūs neizmantojat patiesu “skrubēšanu”, taču gūsit dažas no veiklības priekšrocībām, piemēram, redzamu atgriezenisko saiti, aplēsīsit nodedzināšanu (atlikušais laiks jāpabeidz ar aprēķiniem par to, kad pabeigsit) un tamlīdzīgas lietas.

Jūs darāt to pašu, bet kā lielu procesu, piemēram, dokumentu vai ziņojumu nodošanu daudziem cilvēkiem, katra ieguldījuma saņemšanu vai izmaiņas, un jūs darāt to pašu katru termiņu vai gadu, tad Lean / Kanban varētu būt piemērots Jūs labāk.

Visbeidzot, protams, ja tas, ko jūs darāt, ir projekts, kurā tas, kā jūs to darāt, ir labi saprotams un rezultāts ir zināms, tad visticamāk, ka veiklās metodes jums nepalīdzēs, un tā vietā jums vajadzētu izmantot tradicionālo projektu pārvaldības kopumu. tehnikas vietā.