Днешните софтуерни екипи са, поне в своите процеси, по-пъргави! Те са готови да мислят извън зададените параметри, за да следват какво работи за тях. Те са нетърпеливи да научат и приемат нови техники за управление на проекти и проектни процеси.
Метод за управление на проекти, наречен Kanban, прави кръговете в софтуерната индустрия от доста години, а през последните пет години печели валута. Заедно с методите Agile, възприемането на метода на Kanban даде на компаниите много да празнуват.
Но има и критиката, че Канбан не е нищо друго освен прославен списък със задачи. И така, за какво става въпрос? Нека разберем.
Какво е Kanban?
Ако вашата компания е готова да премине отвъд традиционния подход за управление на софтуерни проекти, днес няма недостиг на техники за управление на проекти.
От една страна съществува системата Agile Project Management, която се фокусира върху нелинейните, итеративни методи за разработване на софтуер. Използването на Agile методи е очевидно в Scrum, който се фокусира върху по-гъвкавия подход за управление на проекти.
Agile също има връзки към други рамки за управление на проекти като Kanban и Extreme Programming. От тях Канбан постигна голяма популярност. В крайна сметка, кой не иска процес, развит от японците?
Kanban е концепция, която се развива в производствения завод на Toyota, за да постигне навременното производство (JIT), което намалява разходите и позволява по-малко използване на ресурсите. В основата си той следва принципа на „дърпане“ на работа, което означава, че задачите или продуктите трябва да бъдат „дърпани“ според изискванията и търсенето, а не да бъдат „изтласквани“ отгоре надолу. Той е разработен, за да осигури по-добро складиране на автомобилните компоненти в заводите на Toyota, въз основа на търсенето. Това означаваше, че с увеличаването на търсенето заявките ще бъдат попълнени.
Концепцията беше адаптирана към софтуерната индустрия с няколко промени от Дейвид Андерсън, в книгата му от 2010 г., Kanban . Оттогава той се използва за различни проекти с голям успех. Това може да бъде от огромна помощ при сложни проекти, които могат да страдат от претоварване от едната страна на цикъла на развитие.
По принцип системата Kanban третира процеса на проектиране на софтуер като тръбопровод. Да речем, че един софтуерен процес има три вида задачи: анализ, разработка, тестване и накрая, внедряване. Да речем, че има двадесет задачи, които трябва да бъдат изпълнени.
В случай на традиционна система за управление на проекти, ако например
- Общо има 25 истории
- Анализаторите са в състояние да се справят с пет истории седмично
- Разработчиците са в състояние да се справят с пет истории седмично
- Тестерите са ограничени до три истории седмично
В тази ситуация работата просто се трупа в края на тестерите. В края на седмица 1 ситуацията ще бъде следната:
- Само три истории са преминали към внедряване.
- Разработчиците и анализаторите работят върху три истории, тъй като тестерите не са в състояние да вземат резултатите от разработчиците и да тестват същото.
- Работата се натрупва, оставяйки разработчици и анализатори и ръководителя на проекта, да се поправят.
Сега анализаторите и разработчиците могат просто да развеят палците си! Или техният мениджър може да осъзнае, че е празен и да ги пренасочи към друг проект, където може да възникне подобна ситуация. Така че има два проекта, които сега са останали във фазата на тестване!
Проблемите в такава ситуация не се виждат трудно. Какъв е смисълът от разработването на десет истории (или бита софтуер), когато те няма да бъдат тествани скоро?
Сега, към метода на Kanban.
Методът на Канбан е изключително проста концепция. Следва проста логика на използването на „метод на издърпване“, за да се премахне първо местата в тесните места и да се ограничи Работата в ход (WIP) за по-добри работни процеси.
В най-простата си форма, Kanban, буквално, "визуална дъска" помага, като "дърпа" елементи от списък със задачи, вместо да работи с времеви срокове. Методът на Kanban помага при идентифицирането на тесните места, за да се управлява по-добре потока на процеса.
Основен съвет на Kanban има списък на задачите, които трябва да бъдат изпълнени, задачите в ход и изпълнените задачи.
В управлението на софтуера обаче задачите могат да бъдат малко по-сложни. Повечето проекти на Agile също имат подобен борд. В борда на Kanban етапите на разполагането са ясно маркирани, заедно с число за всяка колона. Това число представлява максималния брой задачи или истории, с които може да се справи определена стъпка.
Примерът ни в борда на Kanban би изглеждал така в началото на втората седмица. Това означава, че разработчиците и анализаторите няма да работят върху оптималния брой истории през тази седмица. Би било очевидно, че работата се трупа в края на тестера. И организациите могат да гарантират, че екипите работят заедно, за да завършат тестването. Освен това, те могат да разгледат други модели на протичане на процесите, така че това да не се случи.
Когато проектите се обработват чрез системата на Kanban, има по-малко възможности за трупане. Историите се приемат според максималната налична честотна лента.
При типична настройка за Kanban работата ще се приема според наличната ширина на честотната лента и работата ще бъде изтеглена от екипи, така че те да са винаги на максимален капацитет. Системата дава възможност и за бързо проследяване на неотложни задачи, така че да се движат през дъската с минимални усилия.
Разгледайте тази дъска на Kanban.
Ясно е, че всички стъпки работят с максимална ефективност. И задачата, която е на „Бързата писта“, също се отчита.
Kanban в никакъв случай не е единственият метод, използван за повишаване на ефективността чрез ограничаване на WIP. Има и други системи, които постигат същия резултат - например CONWIP (постоянни работи в ход) и DBR (барабан-буфер-въже), които са предназначени предимно за производствената индустрия.
Kanban обаче е системата, която е най-добре модифицирана, за да отговаря на софтуерната индустрия.
По какво се различава Kanban от Agile методологиите?
В основата си Kanban е методология, която използва някои елементи на Agile Project Management. Много проекти в рамките на Agile имат корени в подходите на Lean. Разликата между методологията на Kanban и управлението на Agile Project не е толкова черно-бяла, колкото привържениците на двата метода биха ни накарали да вярваме. Те имат повече общо, отколкото разлики.
Agile рамката не е абсолютна. Въпросът не е дали отборите са пъргави или не. Екипите често проявяват пъргавина в различна степен. Един от методите за по-голяма гъвкавост в процеса на разработка на вашия софтуер е да използвате Kanban.
Има няколко разлики между методологиите на Kanban и Agile. Някои от характеристиките на развитието на Kanban, които са малко по-различни от Agile, са:
- Времевите линии не са важен фактор . Това е трудна концепция за увиване на главата си, тъй като изглежда много неинтуитивна. „Как работите без крайни срокове?“ Хората често питат. Но ако всеки член на екипа се ангажира с неговата максимална ефективност, времето престава да бъде фактор.
- Историите (задачите) са по-големи, отколкото в типичните Agile системи. Обикновено продължителността и сложността на историите са по-дълги, отколкото при типичен проект Scrum. Тъй като акцентът не е върху оценката на времето, а просто върху придвижването на процеса, Канбан може да си позволи да работи върху по-големи истории.
- Няма съществена промяна в съществуващите процеси. Принципите на Kanban за разработка на софтуер, както е изложено от неговия основател Дейвид Андерсън в своя блог, включват следните основни принципи:
-
- Започнете с това, което правите сега
- Съгласете се да преследвате постепенна, еволюционна промяна
- Уважавайте текущия процес, роли, отговорности и заглавия
- Всяка история се измерва във времето на цикъла . Проектът се оценява не от традиционното изчисление на скоростта на Agile (броя на завършените истории през дадено време), а от времето на цикъла. Това означава, че Канбан поставя акцент върху колко време е отнело да се изпълни задача. Често можете да видите отметка на много табла на Kanban, които споменават колко дни отборът отнема, за да завърши история. Тази оценка преминава в следващия цикъл.
Канбан: Борд, но какво друго?
Така че, Kanban е съвет, който ни показва как са подредени историите - е, че дори толкова голяма работа, мнозина питат. Всъщност има голяма дискусия за това какво е и може да прави Канбан.
Kanban само метод за управление на работния процес? Или е нещо, което човек може да използва заедно с методите Agile за максимална ефективност? Или може да е напълно нов начин на управление на работния процес?
Всеки отбор използва Канбан, както сметне за необходимо, за конкретната си ситуация. Независимо от това, Kanban има потенциал да работи като начин на живот за разработка на софтуер, ако бъде използван на оптималното си ниво.
Независимо дали се използва за управление на работния процес или като нова парадигма в разработката на софтуер, не може да се отрече, че помага за управление на WIP.
За да накарате Kanban да работи най-добре, важно е да мислите за него не само като управление на WIP, а като рамка за управление на проекти. Някои основни насоки ще помогнат за процеса.
- Оптимизирайте екипите, така че нито един отбор да не започне нещо, което не може да завърши. Това помага на процеса.
- Не устоявайте на промените от оригиналната система Kanban. Ако вашият проект ще се справи добре със срокове и срокове, включете същите, както бихте направили. Това създава по-здравословна и по-здрава среда за развитие.
- Не отбягвайте работата в екип. Канбан може да изглежда, но не е модел, базиран на хора, работещи в изолация. Работата в екип трябва да бъде неразделна част от разработката на софтуер на Kanban.
- Мислете извън кутията. Помислете за промените в работния процес. Много отбори сега избират тестово задвижване, с Приемане на тестово развитие, при което тестовете за приемане се извършват първо със случаи на използване, които след това задействат необходимите функции и естеството на развитие.
хибриди
Тъй като все повече компании използват инструментите за управление на проекти, които са най-подходящи за конкретната им ситуация, не е изненадващо, че две от най-добрите методологии за управление на проекти: Scrum и Kanban, бяха интегрирани с голям успех.
Хибридът, наречен Scrumban, навлиза в много проекти.
Ако дадена организация вече използва Scrum, но затруднява задържането на проекта, независимо дали спринтовете не работят добре, за да тестват, че не са херметични, може да е време да помислим за Scrumban.
За да го обясня просто, Scrumban се включи с лупа към спринтовете. Не става въпрос само за спринтовете като част от проекта, а за това какво се случва в спринтовете. Scrumban помага да се проучи как историята се обработва в спринта и това може да доведе до всичко.
Scrumban, или който и да е от неговите варианти, е минимална промяна от съществуващите практики. Красотата на използването на Kanban е, че може да се използва с практически всякакъв модел на управление на проекти: водопад, Agile или каквото и да е между тях.
Първи стъпки с Kanban
Лесно е да започнете със системата Kanban. Възможно е също така да се приложи Kanban минимално като изпитание за определена част от проекта.
- Определете процеса на разработване на софтуер. Направете ясна карта на целия процес. Как проектът - от първоначалния дизайн, до разработването, тестването, до промените в характеристиките, работи в действителност?
- Избройте стъпките, в които ще се използва Kanban. Използвайте стъпките, които са изцяло под ваш контрол. Това обикновено включва фазите на анализ, разработка, преглед и тестване.
- Работете по важни точки като:
- Ограничения за незавършената работа за всяка стъпка.
- Процеси за ускорена / блокирана работа
- Прогнози за обратната част на плика с оглед на времето на цикъла
- Честота на прегледа на борда / процес / оценка на Kanban
- Купете бяла дъска и стек от бележки Post-It.
- Първи стъпки
- Прегледайте според изискванията.
- повторение
Така че, продължете напред и започнете с Kanban!
Не се плашете, ако не се окаже по начина, по който първоначално сте възнамерявали. Цялата идея зад Agile методологиите е да се съобразят с промените в хората и процесите! Кажете ни за вашите преживявания с метода на Kanban.
Препоръчителни статии
- 6 най-полезни офис за управление на проекти (PMO)
- 8 полезни стъпки за изграждане на сложни карти на историята за вашия проект
- 5-те важни ценности на екстремното програмиране (мощно)