Жизнен цикъл на разработка на софтуер

Подобно на Scrum, описан по-рано, Kanban е един от възможните начини за прилагане на гъвкава методология за разработка. Kanban първоначално е разработен от производствената система на Toyota и е проектиран да отговаря най-добре на концепцията за икономично производство. Най-общо може да се опише като желание за минимизиране на разходите чрез намаляване на количеството работа, която се извършва в момента (Work In Progress, по-нататък -WIP ). Принципите на щадящото производство се използват широко в производствените предприятия и тяхното прилагане помага да се избегне излишъкът от произведени материали, както и да се идентифицират възможните пречки в производствения жизнен цикъл.

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

Трите принципа на Канбан

Има три основни принципа, които ще ви помогнат да приложите Kanban към вашия проект:

Визуализация на процеса на разработка. Визуалното представяне на процеса на разработка ви помага бързо да идентифицирате коя задача е на кой етап на изпълнение. Това може да бъде изключително полезно в случай на голям проект, състоящ се от много задачи.
Минимизиране на WIP. Ограничаването на броя на задачите, изпълнявани на всеки етап от разработката, помага за ефективното разпределяне на наличните ресурси и не причинява прекъсване.
Измерване и оптимизиране на жизнения цикъл на разработката. Възможност за извършване на промени в процесаразработката е един от важните компоненти на Agile методологията.

За да разберем по-добре как работят тези принципи, нека да разгледаме как изглежда Канбан на практика.

Как да използвате Kanban

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

1. Разделяне на процеса на разработка на етапи

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

Закъснение на проекта
Изисквания
Дизайн
развитие
Тестване
Разгръщане
Готово

След като разделите производствения процес на етапи, трябва да определите колко работни места могат да бъдат изпълнени на всеки от тях. Това е, за което говорихме по-рано: минимизиране на WIP. Няма ясна и недвусмислена насока за избор на брой задачи за всяка стъпка. Всичко зависи от конкретната ситуация и в самото начало можете да изберете този номер произволно. Например, искате всеки програмист да е зает с решаването на една конкретна задача. Или смятате, че двама разработчици трябва да работят по всяка задача едновременно, взаимодействайки помежду си и генерирайки нови идеи? Броят на задачите може да бъде променен по-късно, когато се появят първите резултати от работата. Основното на този етап е да не избирате голям брой задачи за всеки етап.

След като сте разбили производствения процес настъпки, можете да създадете Канбан дъска.

2. Визуализация с Канбан дъска

Тази стъпка е най-важната в цялата Канбан методология. Самата дума "Канбан" е от японски произход и се състои от две думи: "Кан" - видим, визуален и "Бан" - дъска.

Kanban board служи за представяне на състоянието на всяка от задачите, съставляващи проекта, в разбираема визуална форма. На този етап на всяка от задачите се определя определен приоритет. Можете да създадете дъска Kanban, например, като използвате уеб приложението Trello.

Ето пример за такава платка, която е използвана в XB Software за работа по проекта „Workforce and Facility Management Suite“ (приложение за администриране на бизнес проекти):

Всяка задача има своя собствена карта. В този случай дъската беше разделена на четири части:

ToDo съдържа задачи, получени от клиента. Всяка задача е маркирана с цвят, който отговаря на нейната степен на важност.
След като получените от клиента задачи са анализирани и е планиран срокът за изпълнението им, те се преместват в областОчаквани.
Когато програмист започне да работи по конкретна задача, той я премества в областтаВ процес на изпълнение. На тази стъпка разработчикът маркира задачата с персонален етикет, от който става ясно кой точно отговаря за изпълнението на конкретна задача.
След като задачата е решена, тя се премества в областтаГотово.

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

Kanban принадлежи към категорията на така наречените Pull системи. На практика това означава, че член на екипа за разработка "влачи" задача от предишен етап, сигнализирайки на разработчиците, отговорни за предишния етап, че могат да започнат работа по следващата задача. Този подход намалява и WIP, за разлика от Push (от англ. "push" - тласък) системи, при които на всеки етап се извършва максимално възможното количество работа, което се прехвърля на следващия етап, независимо колко работа се извършва в момента.

3. Откриване на слабости

Визуализацията на всички фази на процеса на разработка помага бързо да се разбере на какъв етап възникват проблемите и да се определи къде се намира „тясното място“. Ако екипът, отговорен за определен аспект на разработката, като дизайн, разработка или тестване, не си върши работата, тогава той бързо ще попълни съответната област на дъската Kanban. И тъй като броят на задачите за всеки етап е ограничен, това ще доведе до прекъсване на работата. Визуализацията на процеса на разработка помага бързо да се идентифицират такива слабости, без да се прибягва до задълбочен анализ. Ранното идентифициране на този тип проблеми ви позволява бързо да намерите решение, което няма да позволи натрупването на голям брой незавършени задачи.

4. Оптимизиране на процеса на разработка

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

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

Заключение

Kanban е създаден, за да ви помогне да използвате ресурсите си по най-ефективния начин, бързо да намерите проблеми и да ги разрешите за кратко време. Централно за Kanban е визуализацията на процеса на разработка, която ви помага да проследявате състоянието на текущите задачи и да идентифицирате възникналите проблеми, без да прибягвате до сложни техники. Тази методология е лесна за използване на практика, тъй като се състои само от три основни принципа. Струва си да обърнете внимание на Kanban, ако докато работите по проект, за вас е важно да имате представа за етапа, на който се изпълнява определена задача, кой върху коя задача работи и колко време ще отнеме изпълнението на задачата. И, най-доброто от всичко, не е необходимо да променяте драстично процеса на разработка на съществуващ проект, защото Kanban включва постепенни промени. промени нещо-или в обичайния процес на разработка не е необходимо, докато не разберете какви точно промени са необходими за най-добрата оптимизация.