Agile and Lean, каква е разликата?

Наскоро един приятел на учител попита дали знам нещо за Agile и дали някой от тези пъргави или мършави методи ще помогне за организирането на проекти и хора в образователна среда.

Знаех какво има предвид приятелят ми, но липсата на яснота относно разликата между мършаво и пъргаво ме накара да вляза в пълния си режим на обяснение и по този начин исках да напиша нещо за него. Това, което написах, беше по същество това и ми беше препоръчано да го споделя по-широко.

Agile / Scrum / Kanban изобщо не са едно и също нещо, но те представят с подобни инструменти и видими маркировки, така че често се объркват.

Agile е просто обща работа на колекцията от предимно методологии за разработка на софтуер, които се фокусират върху това да не правят планиране на проекти отпред, това, което сега наричаме стил водопад, или за съвременните практикуващи V-модел на развитие. Agile методите споделят няколко общи принципа, които по същество се свеждат до това, че няма да знаете дали софтуерът, който изграждате, е полезен, докато някой не го види, опита и ви даде обратна връзка. Това означава, че те се фокусират върху итерация, предоставяне на ранни версии на софтуера и получаване на обратна връзка и позволяване на екипите да комуникират и т.н.

Scrum е една пъргава методология, случва се да е най-известната, но има и други. Scrum е фокусиран предимно за предоставяне на проект, обикновено софтуер, но той е използван повторно за много други типове проекти. Конкретните функции, които търсите са:
* Можете да идентифицирате кога сте готови (или ще бъдете готови в един момент и да спрете да работите)
* Имате екип от хора, които трябва да си сътрудничат по проекта
* Можете да разбиете планираните резултати на стъпки или малки единици функционалност.

Това означава, че scrum работи наистина добре, когато проектът ви има тези атрибути.

Така че планът за разделяне на модули между учители и преподаването им в концерт може да се окаже добре. Можете да разделите задачите като всеки модул или единица, можете да зададете собственик на всяка задача и ще знаете кога е направено.

Kanban, или както предпочитам да го наричам, Lean, идва от производството първоначално. Производствената система на Toyota е поклонник на Lean и всъщност мигрирането към постно производство все още е нещо, което виждате да се случва във фабриките днес във Великобритания (добре преди десетилетие, от известно време не съм работил във фабрика!) ,

Lean работи върху това, което трябва да бъде система, базирана на издърпване. Повечето производствени линии се разглеждат като изтласкани. Хванете един куп суровини в единия край, избутвате ги през серия от стъпки и в другия край получавате готови продукти.
Интелигентното нещо, което опира, е да обърне това мислене и по същество да каже, че фабрика трябва да произвежда само толкова, колкото е поръчано от клиенти. Всичко повече се превръща в излишък, което струва пари за съхраняване и има тенденция или да се разпадне или да се обезценява.
Всяка станция на производствената линия иска да изтегли от предишната станция количеството, необходимо за извършване на своята работа, и тегленето трябва да се върне обратно през системата към суровите съставки.

Lean екипи използват Kanban дъска, за да сигнализират какво имат на радара си и какво работят, и това помага на екипите, които гледат на следващия борд и т.н.

Следователно Lean / Kanban е наистина добър за проблеми, които:
* Непрекъснати са, където процесът може да се подобри, но да не се промени и никога няма да бъдете готови
* Когато съхраняването на незавършена работа или още по-лошо, работата, съхранявана между етапите на процеса, е скъпа или разточителна под някаква форма
* Където можете лесно да измерите и подобрите къде могат да бъдат промени в процеса

По-специално Lean се фокусира върху няколко основни принципа:
* Времето за цикъл, това е времето от началото до края е лошо
* Незавършената работа трябва да бъде ограничена, за да се гарантира, че натискате работата до следващия етап по-бързо, отколкото те могат да я консумират
* Съхраняването на работата между етапите на обработка е разточително или трудно

Бих използвал постно за процеси като маркиране и валидиране или всеки многоетапен процес. Всеки човек или екип разчита на информация от един или много други екипи и събира и координира работата, за да продължи напред.

Наистина интересното обучение от Lean е, че локалната оптимизация може да бъде напълно безполезна. Така че, ако имате процес на 5 етапа и един етап може да обработва само 10 елемента на ден, тогава работата по създаването на друг етап да може да обработва 25 елемента на ден е напълно безсмислена, освен ако не можете да ускорите бавния етап. Това ви помага да се съсредоточите къде да направите подобрения. Терминът Kanban за това е Kaizen, който е да направите малки постепенни подобрения на най-бавната, най-слабата, най-нискокачествената (изберете вашия показател) част от веригата и след това да повторите следващата седмица / итерация.

По отношение на това как да организирам работата на администратора за учители, зависи изцяло дали хората си сътрудничат и доколко те зависят един от друг. Знам много малко за това как се работи в училище, но предполагам, че домашните, маркирането на курсове и други неща обикновено не са съвместни. Други неща, които смятам, са еднократни проекти, така че организиране на пътувания или нови големи проекти, такива неща.

Подозирам, че при проекти с фиксиран обхват, при които много хора си сътрудничат, вероятно бих тръгнал по маршрута на стил Scrum. Съберете хората, разберете обхвата на това, което искате да доставите и го следете, като използвате голяма видима дъска, с пост-нейни или индексни карти и преместете задачите, докато свършат. Няма да използвате истински „скрем“, но ще получите някои от предимствата на пъргавия, като видима обратна връзка, оценка на изгарянето (остава време за завършване с прогнози за това, когато приключите) и подобни неща.

Вие правите същото, но като голям процес, като например предаване на документи или доклади на много хора, получаване на принос или промяна от всеки, и правите същото всеки срок или година, тогава Lean / Kanban може да се побере Вие по-добре.

И накрая, разбира се, ако това, което правите, е проект, където това, как го правите, е добре разбрано и резултатът е известен, тогава гъвкавите техники едва ли ще ви помогнат изобщо и вместо това трябва да използвате традиционен набор от проекти за управление на техники вместо това.