Що таке модель Канбан у програмній інженерії?
Томас Гамільтон
⚡ Розумний підсумок
Модель Канбан у програмній інженерії візуалізує кожне завдання на дошці, обмежує незавершену роботу та додає нові елементи лише тоді, коли звільняються можливості, завдяки чому команди забезпечують стабільний та передбачуваний потік виконаної роботи.
Що таке Канбан?
Kanban є дуже популярним фреймворком для гнучкої методології розробки програмного забезпечення. Він забезпечує прозорий спосіб візуалізації завдань і працездатності команди. Він переважно використовує фізичні та цифрові дошки, щоб дозволити членам команди візуалізувати поточний стан проекту, над яким вони працюють.
Канбан виник у Toyota в 1940-х роках. Канбан японською мовою означає «рекламні щити». На дошці Канбан є стовпці та картки з історіями. Стовпці — це ніщо, але стани робочого процесу та картки — це не що інше, як демонстрація фактичного завдання, яке виконує член команди.
Ці картки несли сигнал «точно вчасно»: станція запитувала деталі лише тоді, коли вони їй дійсно були потрібні, тому нічого не виготовлялося заздалегідь. Канбан зберігає цю ідею. Це метод, що накладається на ваш існуючий процес, а не його заміна, тому він підходить для будь-якого... Життєвий цикл розробки програмного забезпечення модель, яку ви вже використовуєте.
Коли використовувати Канбан?
Канбан підходить командам, чия робота надходить непередбачувано і яким потрібно випускати її, щойно елемент готовий. Ось основні причини використання методу Канбан:
- Kanban можна використовувати в будь-якому домені, і його можна дуже ефективно використовувати в розробці програмного забезпечення. Управління проектами Kanban допомагає підвищити ефективність команди.
- Це система на основі витягування. Завдання знімаються, як тільки особа звільняється.
- Kanban слід використовувати, коли ви хочете опублікувати свою роботу в будь-який час. Для цього потрібне розгалуження git, але це можливо.
- Канбан слід використовувати, коли ви хочете змінити пріоритети на льоту. Для цього все, що вам потрібно зробити, це поставити цю історію на вершину черги справ.
- Його слід використовувати, коли ви хочете візуалізувати свою роботу та бажаєте візуально бачити хід виконання своїх завдань.
Відповідність – це одна половина рішення; результат, наведений нижче, – це інша.
Переваги методології Канбан
Найвагомішим аргументом на користь Канбану є те, що він покращує виконання, не змушуючи до реорганізації. Ніхто не змінює посаду і не нав'язується календар спринту, проте дошка робить черги, блокування та перевантажених людей видимими з першого дня. Вузьке місце, яке бачать усі, як правило, усувається.
Команди, які використовують Канбан, постійно повідомляють про такі переваги:
- Коротші терміни доставки: Ліміти незавершеного виробництва скорочують час очікування картки, а саме в цьому і криється більшість затримок.
- Більша гнучкість: Терміновий пункт може будь-коли переміститися на початок стовпця справ, без необхідності чекати на повторення.
- Краща співпраця: Коли стовпець досягає своєї межі, вільні учасники допомагають очистити його, замість того, щоб починати щось нове.
- Розширення можливостей працівників: Фізичні особи обирають свою наступну картку та володіють її станом, що усуває труднощі з її схваленням.
- Передбачуване прогнозування: Історичний час циклу дає оцінку доставки на основі доказів, а не припущення.
- Less відходи: Ніщо не починається, поки система не має можливості це завершити.
Ці результати випливають з чотирьох принципів, якими керується кожне впровадження Канбану.
Чотири принципи канбану
Нижче наведено чотири основні принципи Канбану:
- Почніть з того, що маєте зараз: система Kanban пропонує працювати поступово та починати з того, що у вас є на даний момент. Оскільки однією з його практик є безперервне вдосконалення, ви повинні вдосконалювати систему поступово.
- Погодьтеся на поступові еволюційні зміни: Kanban рекомендує поетапні зміни в процесі, і ви не повинні вносити великі зміни в процес за один раз.
- Поважайте поточний процес, ролі та обов’язки: Ще раз почніть з того, що у вас є зараз, і поступово змінюйте процес, роль і обов’язки.
- Заохочуйте акти лідерства на всіх рівнях: кожна людина може діяти як лідер і надавати ідеї для підвищення ефективності загальної системи Канбан. Не варто думати, що це діяльність управлінського рівня, і в ролі лідера може виступити навіть наймолодший член колективу.
Принципи описують спосіб мислення. Шість практик, наведених нижче, описують щоденну поведінку, яка їх втілює в життя.
Шість основних практик канбану
Нижче наведено шість основних практик Канбану:
- Візуалізуйте робочий процесЦей принцип пропонує використання дошки Канбан (фізичної або цифрової) для візуалізації робочого процесу. Кожен член команди повинен бачити свою картку та картки інших членів команди. Ви можете переміщувати свої картки в різних колонках відповідно до макета дошки. Це забезпечує значну прозорість у команді, а також полегшує вирішення перешкод.
- Обмежте незавершену роботу: Kanban — це система на основі витягування, яка покращує ефективність команди, обмежуючи незавершену роботу та створюючи завдання, які команда може виконати в заданий проміжок часу. Цей ліміт WIP застосовується від початку до кінця робочого процесу. Ви можете застосувати обмеження у верхній частині стовпця, використовуючи додатне ціле число.
- Зосередьтеся на потоці: Цей принцип спрямований на потік і будь-які переривання. Якщо є переривання або блокувальники, їх необхідно виправити назавжди.
- Явні правила: у команді можна встановити політику, щоб зменшити переробку та зосередитися на областях, які потребують уваги, або де це більш ефективно.
- Петля зворотного зв'язку: цикли зворотного зв’язку дуже важливі в канбані. Це відбувається не лише всередині команди, але й між кількома командами, тренерами тощо. Це допомагає покращити загальний стан системи Канбан.
- Постійне вдосконалення: Це основний принцип системи Канбан. У ньому зазначено, що ви завжди можете вдосконалити процес, і це призведе до кращої ефективності.
Практикам потрібні власники, і Канбан вирішує їх інакше, ніж інші методи. гнучкі методології.
Ролі та обов'язки Канбану
Канбан не передбачає нових назв посад, і це навмисно — третій принцип вимагає від вас поважати ролі, які у вас вже є. Розробник залишається розробником. Однак на практиці, у міру дорослішання ради директорів виникають дві обов'язки, і зрілі реалізації чітко їх називають.
Команда Менеджер з надання послуг відповідає за потік робіт на дошці. Ця людина стежить за картками, які перестали рухатися, збільшує кількість блокуючих, утримує колонки в межах їхніх лімітів незавершеного виконання та проводить огляд, під час якого команда перевіряє власні дані про час циклу. Менеджер запитів на обслуговування володіє тим, що потрапляє на дошку, представляє клієнтів, які роблять запити, упорядковує стовпець справ таким чином, щоб найцінніший елемент був зверху, та чітко визначає політику вибору.
Обидва є обов'язками, а не додатковим штатом; одна людина часто виконує обидва завдання. Важливо те, що хтось відповідає за потік, а хтось за надходження. Далі йдуть справи з артефактами, якими вони керують.
Карти Канбан
Метод Канбан рекомендує візуалізацію роботи. Він пропонує використання фізичної та цифрової дошки, а дошка нижче показує ці колонки з розподіленими по них картками.
Картки Kanban є важливими частинами дошки Kanban, оскільки вони представляють роботу, над якою працює команда. Ці картки матимуть
- Пріоритет
- власник
- тип
- Термін сплати
Стовпець на дошці Kanban представляє етап роботи, і ви можете встановити обмеження WIP (Work in Progress) для стовпця. Ліміт WIP означає максимальну кількість карток, які можуть залишатися в цьому стовпці.
Оскільки метод Канбан використовує систему на основі витягування (pull-based system), коли розробник вільний, він/вона може витягнути картку зі стовпця справ до стовпця розробника. Дошка, на якій знаходяться ці картки, заслуговує на детальніший розгляд.
Рада Канбан
Рада Канбан це гнучкий інструмент управління проектами, який допомагає реалізувати Kanban для управління проектами для особистих і бізнес-цілей. Це фізична або цифрова (JIRA) дошка, розроблена, щоб допомогти командам візуалізувати свою роботу на різних етапах і процесах. Це також допомагає представити етапи роботи з колонками за допомогою карток.
У ньому є стовпці, які відображають статус роботи, наприклад
- Зробити,
- DEV
- Тестування
- Пожертвувати.
Кожен із цих стовпців може містити картки <=ліміту WIP. Картки представляють фактичну роботу.
Ви можете використовувати додатні числа для обмеження незавершеної роботи, і це лімітуюче число можна розмістити у верхній частині стовпців як на фізичних, так і на цифрових дошках Канбан. Будь-який член команди може керувати станом своєї картки, а вся команда може візуалізувати робочий процес. Digiтакі дошки, як ДЖИРА додайте ті ж обмеження з автоматичним часом циклу tracкороль. Далі ми дізнаємося про робочий процес Канбан, який представляють ці стовпці.
Канбан робочий процес
Канбан робочий процес це набір кроків, який допомагає командам визначати чіткі політики та принципи в Kanban. Він представляє правила та процедури під час роботи на різних етапах розробки та циклів доставки. Робочий процес Kanban складається з покрокових процесів між запуском і виконанням певного завдання.
Основний принцип Канбану такий: «перестань починати, почни закінчувати». За допомогою обмежень WIP він виконує більше роботи. У будь-якому сучасному інструменті, як-от JIRA, доступні настроювані робочі процеси та стани Kanban.
Нижче наведено основні стани, яких дотримуються багато програмних команд для керування робочим процесом.
| Штати | Розуміння завдань |
|---|---|
| Зробити | Завдання надходять сюди вперше в такому стані. |
| Готовий до аналізу | Проаналізуйте завдання і повністю додайте вимоги. |
| Готовий до розвитку | Аналіз завершено, можна починати розробку. |
| У розробці | Завдання розробляються. |
| Готовий до тестування | Розробка завершена, і тепер можна почати тестування. |
| У тестуванні | Завдання перевіряються. |
| Готовий до випуску | Тестування завершено; звільнення може статися. |
| Випущено/Готово | Звільнений. |
Зверніть увагу, що стани «готові до» – це черги, а не робота. Карта може залишатися в одній необмежений час, тому правило переміщення карток має більше значення, ніж стани.
Система на основі витягування
Канбан — це метод, заснований на витягуванні, коли завдання витягуються, а не штовхаються. Щойно ви заповните свою поточну картку, ви зможете отримати нову картку з попереднього стовпця дошки Канбан.
Завдяки ліміту WIP Kanban допомагає покращити час виконання замовлення та тривалість циклу. Між цими двома моментами має бути якомога менший розрив. Наприклад, у нас 5 розробників і лише 1 тестувальник; що буде в цьому випадку? Завжди буде багато карт, які вимагають тестування, і вони будуть простоювати і чекати.
Щоб подолати проблеми, згадані вище, і підвищити ефективність, Канбан використовує підхід на основі витягування з лімітами WIP, коли буде обмежена кількість карток для вилучення.
Отже, тестувальник витягне завдання зі стадії «готове до тестування», коли він завершить своє поточне завдання. З лімітом WIP у стовпцях Kanban (етапи розробки) ви не матимете багато неконтрольованих карток у робочому процесі Kanban.
Система, що базується на методі «pull», також допомагає знайти правильну швидкість для команди. З правильною швидкістю команда працюватиме краще. Тут усе залежить від одного числа: ліміту незавершеного виконання.
Обмеження WIP (виконується робота)
У методі Канбан незавершене виконання обмежує кількість завдань/карток, над якими може працювати член команди або вся команда одночасно.
Обмеження WIP гарантують, що команда стабілізує свою роботу та підвищує передбачуваний характер, який є важливим у системі на основі вилучення. Зазвичай рішення про ліміт WIP приймає сама команда.
Причина встановлення лімітів WIP
Ось причини встановлення лімітів WIP:
- Це зміщує фокус на виконання завдань, оскільки людина зосереджується на одному завданні за раз.
- Це допомагає командам зрозуміти свої можливості.
- Це покращує продуктивність і час циклу.
- Це допомагає уникнути нагромадження завдань (у режимі очікування).
- Це покращує рух робочого процесу, щоб завдання продовжували рухатися.
- Це також допомагає усунути блокатори, оскільки людина не перемикається між різними завданнями.
⚠️ Попередження: Занадто високий ліміт — це те саме, що й відсутність ліміту — черга карток та час циклу розтягуються. Занадто низький ліміт залишає людей бездіяльними. Змінюйте ліміт для одного стовпця за раз і спостерігайте за часом циклу протягом двох тижнів.
Це останній фрагмент теорії; у розділі нижче вона перетворюється на дії.
Як впровадити Канбан крок за кроком
Почати з Канбану легко: перший крок описує те, що ви вже робите. Опрацюйте цю послідовність у присутності всієї команди.
- Зобразіть поточний робочий процес. Проведіть один готовий елемент у зворотному порядку через кожну передачу, яку він пройшов. Кожна передача стає колонкою, включаючи стани очікування, які офіційно нікому не належать.
- Намалюйте дошку. Один стовпець на штат, зліва направо, що закінчується словом «Готово». Протягом першого місяця достатньо білої дошки з стікерами.
- Напишіть картки. Надайте кожному предмету, що знаходиться в польоті, картку із зазначенням пріоритету, власника, типу та терміну виконання, а потім помістіть його в колонку, що відповідає його фактичному стану.
- Визначте «виконано» для кожного стовпця. Напишіть критерії виходу на дошці. Ця практика чітких правил запобігає тому, щоб картки відскакували назад.
- Встановіть початкові ліміти незавершеного виробництва. Виберіть початковий номер для кожного стовпця, окрім «Справ» та «Виконано», використовуючи наведений нижче метод, а потім напишіть його над заголовком.
- Погодьтеся з правилом витягування. Ніхто не починає нову карту, поки його колонка досягла своєї межі; натомість вони допомагають очистити колонку праворуч від себе.
- Щодня ходіть по дошці. Рухайтеся справа наліво, починаючи з найстарішої картки, і запитуйте, що блокує цю картку та хто може розблокувати її сьогодні.
- Виміряйте, а потім затягніть. Через два тижні дані про час циклу показують, у якому стовпці картки зберігаються найдовше. Зменште це обмеження або збільште місткість, а потім повторіть.
Крок п'ятий – це те, на чому більшість команд зупиняються, тому ось три методи визначення розміру, які використовують фахівці:
| Метод визначення розміру незавершеного продукту | Як ми можемо допомогти |
|---|---|
| Розмір команди плюс один | Ліміт дорівнює кількості людей, які працюють у цьому стовпці, плюс один слот SLAck для заблокованого елемента. Найкраще підходить для нової дошки без даних. |
| Два-три предмети на людину | Помножте кількість людей у колонці на два або три; три розробники з двома пунктами кожен дають шість. |
| Пропускна здатність x час циклу | Застосуйте НЗП = пропускна здатність x час циклу до власної історії, а потім встановіть ліміт трохи нижче результату. |
Розглядайте перше число як гіпотезу. Поєднання дошки з формальними гнучке тестування запобігає перетворенню тестової колонки на вузьке місце, а два наведені нижче таймінги показують, чи працює це.
Час виконання та час циклу
У методі Канбан широко використовуються час виконання замовлення та час циклу, між ними є різниця, і важливо розуміти це, щоб уникнути плутанини.
| час виконання | Час циклу |
|---|---|
| Час виконання вимірюється як час між надходженням завдання у ваш робочий процес і його виходом із робочого процесу, тобто його було звільнено. | Час циклу вимірюється як час між надходженням завдання в стан «виконується» та надходженням завдання в стан «готовий до випуску». |
Тут також важливо розуміти, що не включати час між готовністю до випуску та фактичним випуском.
Cycle Time = Work in Progress/Throughput
💡 Порада: Час виконання замовлення – це те, що відчуває клієнт; час циклу контролює команда. Великий проміжок часу означає, що робота чекає в черзі, перш ніж хтось її почне, тому вирішіть проблему з надходженням, перш ніж пришвидшувати роботу команди.
В ідеальному сценарії розрив між часом виконання замовлень та часом циклу має бути мінімальним, і Канбан використовує кумулятивну блок-схему (CFD) для вимірювання історичних даних часу виконання замовлень та циклу. Ця діаграма є темою наступного розділу.
Кумулятивна діаграма (CFD)
CFD - це графік, який доступний у всіх провідних засоби управління документообігом як JIRA. Ця діаграма вимірює загальну кількість робочих карток/завдань, які увійшли в робочий процес і накопичили виконані картки/завдання протягом певного часу.
Це допоможе вам отримати оцінку середнього часу виконання та тривалості циклу для попередньо визначеного часу.
Діаграма CFD надасть вам індикатори або проблемні області, які потрібно виправити. Вона надасть вам чітку картину, і на основі цієї діаграми ви зможете скоригувати час виконання та час циклу вашої команди. На діаграмі сукупних потоків нижче кожен стан зображено кольоровою смугою; смуга, яка постійно розширюється, є вузьким місцем.
Діаграма зчитується через чотири величини:
- час виконання: це тривалість між надходженням нової картки у ваш робочий процес і її остаточним виходом із робочого процесу.
- Час циклу: Це тривалість між надходженням картки в робочий стан і моментом, коли картка готова до випуску.
- WIP: незавершена робота (WIP) обмежує максимальну кількість робочих елементів на різних етапах робочого процесу.
- Пропускна здатність: це фактична продуктивність, і вона говорить про фактичну кількість карток, доставлених за певний період часу.
Throughput = WIP/Cycle Time
Це охоплює артефакти, механіку та метрики. Залишається питання, як Канбан порівнюється зі Scrum.
Scrum Vs. Канбан
Ось важливі відмінності між Scrum Vs. Канбан. Для ширшої картини див. Agile проти Scrum.
| Бійка | Kanban |
|---|---|
| Бійка акценти на плануванні. Він починається з планування спринту та закінчується ретроспективою спринту. Проводиться багато зустрічей, які допомагають переконатися, що команда узгоджується з наступними кроками, пріоритетами та знаннями, отриманими з попередніх спринтів. | Канбан відкритий для внесення змін на ходу. Це означає, що є менша жорсткість і речі можуть часто змінюватися. |
| Він рекомендує колекцію вимірювання часу зроблені під час спринтів | Kanban рекомендує графіки щоб отримати огляд прогресу команди з часом. |
| Бійка більше не вимагає зобов'язань від команд. Натомість йдеться про спринтерські цілі та прогнози. | Канбан спирається на часові рамки та прогнози. |
| Це наголошує на плануванні тощо оцінка відіграє дуже важливу роль у Scrum | Канбан має немає обов'язкових вимог для оцінки. |
| Кожен індивід має свою роль та відповідальності. | Немає встановлюйте ролі так гнучко в частині індивідуальних обов'язків. |
| Ітерації/Sprints фіксовані за тривалістю. Ця тривалість коливається від 2 тижнів до 1 місяця. | Канбан є не на основі тривалості. Ця річ вимірюється відносно часу циклу. |
| Команди є необхідно здійснити конкретний обсяг роботи. | Зобов'язання не потрібні це необов'язково для команд. |
| У цьому методі міжфункціональні команди важливі, оскільки вони можуть впоратися з будь-якими збоями, які можуть спричинити вузьке місце в розробці програмного забезпечення. | Хто має спеціалізована команда це важливо. |
| Це неможливо додати елементи до поточних ітерацій. | Нові елементів можна легко додати якщо є додаткова потужність. |
| Відставання в спринті належить лише a єдина команда. | Кілька командs може ділитися дошкою Kanban. |
| Результати роботи є визначається спринтами, який комплекс робіт повинен бути виконаний і готовий до перегляду. | Продукти та процеси є доставляється безперервно на необхідній основі. Тому процес тестування та перевірки відбувається одночасно. |
| Метод розробки програмного забезпечення Scrum фокусується на відставанні. | Повністю метод Канбан фокусується на інформаційній панелі процесу. |
| Кожен член команди має певну роль у Scrum майстер визначає часові рамки, власник продукту ставить цілі та завдання, а члени команди проводять роботу з розробки. | Для команди немає заздалегідь визначених ролей. Тим не менш, може бути ще керівник проекту; команда заохочується до співпраці та спільної роботи. |
| Найкраще для проектів з зміна пріоритетів. | Ідеально підходить для команд з стабільні пріоритети що навряд чи зміниться з часом. |
| Вимірює виробництво використовуючи швидкість через спринт. | Вимірює виробництво за допомогою час циклу або точний час, необхідний для завершення однієї повної частини проекту. |
| Scrum вимагає a повний відхід від традиційної моделі до моделі Agile Scrum, яка буде реалізована в проекті. | Kanban не допускає кардинальних змін у проекті. |
| У Scrum весь team зосереджується на співпраці та виконанні завдання забезпечити якісну розробку. | Команди працюють для досягнення цілей і скоротити час для завершення всього процесу. Таким чином, скорочення часового циклу є найбільшим показником успіху тут. |
| Бійка акцент на його розкладах; нові елементи не можна додавати до поточних ітерацій. | Канбан є більш ітеративним за своєю природою не має конкретних часових рамок. Таким чином, нові елементи можна постійно додавати, коли є додаткова ємність. |
| Вся робота виконана в партії/Sprints. | Весь проект виконується на русі однопотоковий робочий елемент потоки. |
| Майстер Scrum діє як розв'язувач проблем. | Канбан заохочує кожен член команди є лідером і розподіл відповідальності між ними всіма. |
| Scrum призначає обмежені за часом ітерації. | Канбан фокусується на планування іншої тривалості для індивідуальної ітерації. |
| Scrum допомагає фірмам заощаджуйте час і гроші. | Метод Канбан орієнтація на постійне вдосконалення, продуктивність і ефективність. |
| Achieve стабільне та послідовне спілкування продуктивності на всіх рівнях. | Члени команди мають більшу ймовірність досягати своїх цілей набагато легше через візуальну природу дощок Kanban. |
| Це легше адаптуватися до постійних змін завдяки коротким спринтам і регулярному зворотному зв’язку. | Це призначений для регулярного стабільного виходузначні зміни в попиті клієнтів можуть призвести до невдачі Kanban. |
| Загальна вартість проекту мінімальна, що може призвести до більш швидкий і дешевий результат. | Якщо завдання не правильно оцінено, то загальна вартість проекту ніколи не буде точною. У таких випадках завдання можна розподілити на кілька спринтів. |
| Ця методологія потрібні досвідчені члени команди тільки. Отже, якщо команда складається з людей, які не є експертами, проект не може бути завершений вчасно. | Немає конкретні часові рамки розподіляються для кожної фази, тому члени команди ніколи не уявляють, скільки часу вони можуть витратити на кожну фазу. |
| У цьому методі Agile Scrum це так легше доставити якісний продукт в запланований час. | Він призначений для a регулярний, стабільний вихід, Значні зміни в попиті клієнтів можуть призвести до провалу Канбану. |
| Команда план проекту ніколи не завадить навіть якщо член команди залишає команду. | Якщо хтось із членів команди вийде під час розробки, він може зашкодити розвитку проекту. |
| Іноді щоденні зустрічі розчарувати члени команди. | Застаріла дошка Kanban може призвести до проблем у процесі розробки. |
| Великі проекти можна легко розділити легко керованих спринтів. | Великі проекти обробляються як безперервний потік окремих елементів, а не розділених на партії. |
