Вие сте запознат с Scrum, нали? Предполагам, че да, като се има предвид, че The Scrum Alliance има над 400 000 членове и повечето от тях успешно го използват в своите организации.
Но това не е единственият начин за изграждане на софтуер по гъвкав начин - сериозно! Чували ли сте за Канбан?
За малко основна информация първоначално е приложена за постно производство като начин за визуализиране на входа и продукцията на работа, докато тече през фабрика. Тази визуализация беше представена на дъска, известна като - чакай го - Канбан. По-скоро и по-подходящ за вас, той е приет като метод за управление на разработката на софтуер.
Първо очертан от невролога Дейвид Дж. Андерсън, това е начин за организиране на разработка и планиране на софтуер, който ви позволява да разкриете проблеми в процеса и последователно да доставяте ценни подобрения на вашия продукт - което знам, звучи идеално. Просто казано, по всяко време можете да видите къде работата (представена с карти) е в процес на развитие.
Как работи
Основният съвет на Kanban използва шест колони, които показват къде е всяко произведение в цикъла на разработка на продукта. Груба извадка от това как изглежда е по-долу.
Вижте този пример на дъската Kanban в Trello.
Колона 1: Закъснение
Колоната „Блог“ трябва да съдържа списък с идеи, грешки или бизнес нужди с приоритет. Картата все още не трябва да има много подробности, но трябва да има достатъчно информация, за да могат членовете на вашия екип да разберат защо е важна.
Колона 2: Планиране
В тази колона продуктовият мениджър ще попълни спецификация за функцията, като се срещне с бизнес заинтересовани страни, инженери и дизайнери. Когато е готов, той или тя ще го премести в графата „Готов за инженерство“.
Колона 3: Готов за инженерство
На този етап всички карти трябва да имат подробни спецификации. Въпреки че все още имате въпроси относно техническите подробности, бизнес изискванията трябва да са ясни.
Колона 4: В ход
По всяко време можете да преместите карта на „В ход“. Тази самоуправлявана система за „дърпане“ изгражда култура на лична отчетност и любопитство.
Колона 5: Тестване
Когато приключите работата по картата, преместете я в „Тестване“, където друг инженер (или някой от QA екипа) ще я вземе.
Колона 6: Разгърнати
Друга определяща характеристика е, че работата трябва да се доставя непрекъснато в етапна или производствена среда. Тази колона позволява на всеки от екипа да види каква работа е пусната наскоро.
Предимства и компромиси
Когато решавате между Kanban и по-разпространена методология като Scrum или водопад, имайте предвид тези предимства и предизвикателства:
Полза: Подобрява сътрудничеството
В някои екипи за разработка, с които съм работил, инженерите бяха специалисти. Всеки екип ще има по няколко фронтови инженери и резервни инженери. Това означаваше, че работата често е блокирана, защото един инженер е зает с нещо друго.
Kanban, от друга страна, ограничава незавършената работа и възпира блокажите. Всеки член на екипа може да работи само върху един елемент по едно и всеки, който не е зает, може да изтегли работата от върха на колоната „Готов за инженерство“. Това насърчава инженерните специалисти и сътрудничеството между членовете на екипа.
Увеличете ползата: Не позволявайте нещата да преминат, преди да са готови
Kanban работи само когато чакате да преместите картите до следващата колона, докато не бъдат напълно завършени. (Бонус: Това значително минимизира дефектите.)
Предизвикателство: Окуражава времето за размисъл
По подразбиране няма спринтове с полета с ясни цели, цели за дата и цикли на освобождаване. Вместо това, мислете за всяка карта като самостоятелна работа, която може да бъде завършена и издадена по всяко време.
При този непрекъснат поток от работа няма опция „изчакване до следващия спринт“. Необходимо е непрекъснато да проверявате дъската, да дърпате следващия елемент и да премествате завършени елементи надолу по течението. Освен ако не изградите навреме за ретроспективи и промени, може да е трудно за членовете на екипа да бъдат в крак с това как се справят.
Отидете около: Наемете какво работи от Scrum
Използвах ежедневни редукции и ретроспективи с Kanban и установих, че те добавят стойност. Ако има редовни срещи или модели, които работят за вашия екип, не ги променяйте, за да се придържат догматично към Kanban. Бюджетно време, за да поговорим за приоритетите и как са се променили, така че всички да знаят какво се случва в цикъла на разработка на продукта.
Полза: Увеличава прозрачността
Всеки предприемач трябва да поеме инициативата за преместване на карта в графата „В ход“. Значение, във всеки даден момент мениджърът на екипа може да разгледа кой е зает, кой не е зает и колко дълго се работи.
Когато производството се забави или спре, Kanban ви позволява да видите точно защо. Независимо дали това е, защото бизнес екипът не е дал приоритет на елементите в изоставането, екипът на продуктите не е завършил спецификацията, екипът на разработчиците се движи по-бавно от очакваното или QA екипът не е в състояние да тества нещо; тесните места са очевидни.
Увеличете ползата: Позволете на напредъка да бъде публичен
Едно от предимствата е, че Kanban е много визуален. Дори нетехническите членове на екипа могат да разгледат борда на Kanban и да кажат къде се намират работата. Използвайте това в своя полза и оставете постиженията на екипа да блестят, като поставите дъската си на обществено място.
Предизвикателство: не позволява дългосрочно планиране
Притесненията за крайните срокове и прогнози не са най-продуктивната употреба на вашето време, така че може би ще оцените, че Kanban е повече за ежедневната продукция. Това каза, че само по себе си не предоставя система за изграждане на дългосрочен план. Това може да ви накара да работите по проекти спорадично, вместо да се съсредоточите върху едно нещо дълго време. Трудно е да прекарате един ден в Проект А, а след това един ден в Проект Б, а след това да преминете обратно към Проект А.
Отидете около него: Използвайте го, когато приоритетите ви вероятно ще се променят
Всяка колона във вашия съвет е независима от останалите, така че членовете на екипа могат да движат нещата по всяко време. Това може да дразни разработчиците в настройка на Scrum (където оценките за спринта се правят предварително), но Kanban процъфтява в този вид бързо променяща се среда.
Всеки иска да бъде по-продуктов, но може да е трудно да опитате нещо ново, ако дори не сте сигурни откъде да започнете. Намерих Kanban за полезен и се надявам, че ще го намерите и полезен за личния ви работен процес (или дори за целия ви екип!).
Щракнете ми, ако решите да го снимате!
