Как японското производство повлия на пъргавината: Кратко обяснение на Scrum vs Kanban

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

Двете велики идеи: пъргаво и стройно

Agile разработката на софтуер влезе в известност в края на 90-те години с разработването на софтуер, използващ Rapid Application Development (1991), Scrum (1994) и Extreme Programming (1996). Въпреки това, група от видни разработчици през 2001 г. поставиха на пазара гъвкавата методология, като публикуваха Manifesto for Agile Software Development, който можете да видите в Agile Manifesto. Философията е насочена към предоставянето на работещ софтуер на клиентите в близки итерации, които подобряват сътрудничеството между разработчиците и клиентите. В момента най-използваната философия за разработка на софтуер зад водопада, Agile е оглавена от Scrum, методология, която се фокусира върху „спринтове“, които ще обсъдим по-нататък.

Lean производство влезе в известност в края на 20-ти век, въз основа на науките от Just-in-Time, японска философия, която бе въведена от японския автомобилен гигант Toyota.

Тази философия, подчертана около премахването на „муда“ (отпадъци), бе въведена от Toyota Production System, която даде огромно конкурентно предимство на японските производители, които надминаха американското производство чрез „kaizen“ (непрекъснато подобряване). Toyota разглежда отпадъците като всичко, което не осигурява стойност на клиента, така че производствената верига е съсредоточена около елиминирането на дейности без добавяне на стойност. "Kanban" (табела) е използван за планиране на производствените процеси в тази система.

Agile Софтуерна разработка

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

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

Agile методологиите са предпочитани в случаите на използване на софтуерни разработки, когато има по-висока толерантност към грешки и грешки и области, в които не се изисква софтуерът да бъде правилен за първи път.

Можете да видите принципите зад Agile Manifesto тук.

спорна топка

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

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

Доста подобно на ръгби скрут, където действието се основава на повторени движения.

В началото на спринта има среща за планиране, ръководена от „Scrum Master“, докато „Собственикът на продукта“ избира функциите, които трябва да бъдат разработени и да го планират за спринта. Този избор обикновено се основава на предварително определени критерии като спешност или критичност и собственикът на продукта с екипа за разработка трябва да прецени колко време ще е необходимо да бъде разработено и тествано. Процесът използва Scrum Board за планиране на спринта и всяка функция, която трябва да бъде разработена, се обработва с помощта на билет.

Всеки ден се провежда ежедневна готовност, където разработчиците и Scrum Master се събират, за да обсъдят какво трябва да се направи и какви билети трябва да се управляват. В края на спринта се прави „ретроспектива“, където се преглежда извършената работа и се учат уроците. Това е ключовият момент, в който се преглежда точността на оценката на работата и след това се подобрява, за да се използва за планиране на следващия спринт.

Пример за Scrum Board, направен с помощта на Trello

Основната характеристика на методологията Scrum е освобождаването на функциите в края на спринта. Има ясен фокус върху планирането на спринта, тъй като успехът на спринта зависи изцяло от това колко точно е оценката на работата в началото на спринта. Ако в края на спринта са останали билети, ефективността се преоценява на ретроспектива, за да се избегне прекаляване с ангажимента за следващата оценка.

Kanban

За да разберете Agile Kanban, трябва да разберете оригиналната метода за производство Just-in-Time. Японците наблегнаха на освобождаването от незавършено производство, незавършеното инвентаризиране, което изграждаше нивата на запасите във веригата на доставки. Тъй като парите бяха обвързани в този инвентар, това премахване намалява разходите, както и подчертава грешките, скрити чрез тези незавършени дейности. Ако двама работници извършват последователни работи в производствения процес, първият работник не изпраща парче, преди вторият работник да го поиска. Това доведе до пълно разчитане на производствения процес, основан на търсенето, което доведе до ниска незавършена работа.

Традиционен борд на Kanban.

В среда на Agile Kanban горната философия е приложена, но с обрат.

Идеята е да се освободи колкото е възможно повече, без да се чака до края на спринт като в Scrum.

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

„Agile Coach“ замества Scrum Master в методологията на Kanban, докато собственикът на продукта прави избор на билети от задния дневник. И така, как те заместват оценката, която се прави в Scrum? По ирония на съдбата те поддържат ниво на незавършена работа, така че да няма прекомерно обвързване. Ако нивото на WIP се поддържа на 3 билета, билет се изтегля само от колоната To-Do, само ако в колоната In-Progress има по-малко от 3 билета.

Пример за дъска на Kanban; подобно на Scrum Board, но забележете нивото на WIP, обозначено с червено!

заключение

И така, какво е по-добре?

Няма такова нещо. Scrum vs Kanban е решение, което трябва да бъде взето от компания, след като се вземе предвид културата, която искат да имат и личностите в екипите за развитие. За мен, човек, дошъл от произход на производството, Kanban се чувства у дома, въпреки че му липсва модерното усещане, подобно на проект, което предлага спринт в Scrum.

В крайна сметка, който не иска да отиде за щастлив час след успешен спринт.