Життєвий цикл розробки ПЗ

Як і описаний раніше Scrum, Kanban є одним із можливих способів реалізації гнучкої (Agile) методології розробки. Спочатку Kanban був розроблений на основі Тойоти виробничої системи і спроектований таким чином, щоб найкращим чином відповідати концепції ощадливого виробництва. У загальних рисах її можна описати як прагнення мінімізувати витрати за рахунок зниження кількості виконуваної в даний момент роботи (Work In Progress, далі -WIP ). Принципи ощадливого виробництва широко застосовуються на виробничих підприємствах та їх застосування дозволяє уникнути надлишку вироблених матеріалів, а також виявити можливі вузькі місця у життєвому циклі виробництва.

Але це не означає, що Kanban може бути використаний лише у сфері промислового виробництва. Він може бути застосований для керування практично будь-яким процесом. Наприклад, для оптимізації життєвого циклу ПЗ. Щоб зрозуміти, як можна використовувати Kanban для цієї мети, давайте розглянемо його основні принципи.

Три принципи Kanban

Існують три основні принципи, які допоможуть вам застосувати Kanban у вашому проекті:

  1. Візуалізація процесу розробки. Візуальне представлення процесу розробки допомагає вам швидко визначити, яке завдання, на якій стадії виконання знаходиться. Це може бути дуже корисно у разі великого проекту, що складається з багатьох завдань.
  2. Мінімізація WIP. Обмеження кількості завдань, виконуваних кожної стадії розробки, допомагає ефективно розподіляти наявні ресурси не викликати простоїв у роботі.
  3. Вимірювання та оптимізація життєвого циклу розробки. Можливість вносити зміни до процесуРозробка є одним з важливих компонентів Agile методології.

Щоб краще зрозуміти, як ці принципи працюють, розглянемо, як на практиці виглядає використання Kanban.

Як використовувати Kanban

Оскільки Kanban може бути використаний у різних галузях, реальні приклади використання можуть різнитися залежно від конкретної ситуації. Але загалом процес виглядає приблизно однаково.

1. Поділ процесу розробки на етапи

Залежно від специфіки поставленої задачі можуть бути виділені різні етапи розробки. Головна вимога у тому, щоб вони відповідали трьом основним стадіям: “Що має бути зроблено”, “Що робиться” і “Що зроблено”. Ось приклад того, як може бути розбитий на етапи розробки ПЗ:

  1. Беклог проекту
  2. Вимоги
  3. Дизайн
  4. Розробка
  5. Тестування
  6. Деплоймент
  7. Закінчено

Після того, як ви розбили процес виробництва на етапи, слід визначити, скільки завдань може виконуватися кожному з них. Це те, що ми говорили раніше: мінімізація WIP. Чіткого та однозначного посібника щодо вибору кількості завдань для кожного кроку не існує. Все залежить від конкретної ситуації і від початку ви можете вибрати це число довільно. Наприклад, ви хочете, щоб кожен програміст був зайнятий вирішенням одного конкретного завдання. Або ви вважаєте, що над кожним завданням повинні одночасно працювати два розробники, взаємодіючи один з одним і генеруючи нові ідеї. Кількість завдань може змінитися пізніше, коли з'являться перші результати роботи. Головне на цьому етапі – не вибирати велику кількість завдань для кожної стадії.

Після того, як ви розбили процес виробництва наЕтапи, ви можете створити Kanban-дошку.

2. Візуалізація за допомогою Kanban-дошки

Цей етап є найважливішим у всій Kanban-методології. Саме слово Kanban має японське походження і складається з двох слів: Кан - видимий, візуальний, і Банк - дошка.

Kanban-дошка служить для того, щоб у зрозумілій візуальній формі уявити стан кожного із завдань, з яких складається проект. На цьому етапі кожному із завдань надається певний пріоритет. Створити Kanban-дошку можна, наприклад, за допомогою веб-програми Trello.

Ось приклад такої дошки, яка використовувалася в XB Software для роботи над проектом Workforce and Facility Management Suite (додаток для бізнес-адміністрування проектів):

життєвий

Кожному завданню відповідає своя картка. У цьому випадку дошку було розділено на чотири частини:

  • ToDo містить завдання, отримані від замовника. Кожне завдання відзначено кольором, який відповідає ступеню її важливості.
  • Після того, як завдання, що надійшли від замовника, були проаналізовані і був запланований термін їх реалізації, вони переміщаються в областьEstimated.
  • Коли розробник починає роботу над певним завданням, він переміщає її в областьIn Progress. На цьому кроці розробник наголошує на задачі персональною міткою, яка дає зрозуміти, хто саме відповідальний за реалізацію конкретного завдання.
  • Після того, як завдання вирішено, воно переміщається в областьDone.

На цьому етапі також реалізується принцип мінімізації WIP. До кожного етапу, у тому числі складається процес розробки, встановлюється максимально можливе кількість завдань, з яких ведеться робота. Отже, можна встановити максимальну кількість карток,яке одночасно може бути на дошці в тій чи іншій області. Зниження кількості завдань, над якими ведеться робота, дозволяє зменшити кількість часу, необхідне завершення кожної їх і підвищує якість виконаної роботи з допомогою те, що команда може сфокусуватися на обмеженому обсязі завдань. Це також дозволяє знизити кількість помилок та мінімізувати час, необхідний для їх виправлення.

Kanban належить до розряду про Pull (від англ. “pull” — тягнути) систем. Насправді це означає, що член команди розробників “перетягує” завдання з попереднього етапу, даючи зрозуміти розробникам, відповідальним за попередній етап, що вони можуть розпочати роботу над наступним завданням. Такий підхід також знижує WIP, на відміну Push (від англ. “push” – штовхати) систем, у яких кожному етапі виконується максимально можливий обсяг роботи, який передається наступного етапу незалежно від цього, який обсяг роботи нині виконується.

3. Пошук слабких місць

Візуалізація всіх фаз процесу розробки допомагає швидко зрозуміти, на якому етапі виникають проблеми та виявити, де знаходиться “пляшка”. Якщо команда, відповідальна за певний аспект розробки, наприклад, за дизайн, розробку чи тестування, не справляється зі своєю роботою, вона швидко заповнить відповідну область Kanban-дошки. І оскільки кількість завдань для кожного етапу обмежена, це призведе до простою в роботі. Візуалізація процесу розробки допомагає швидко виявити такі слабкі місця, не вдаючись до глибокого аналізу. Раннє виявлення таких проблем дозволяє швидше знайти рішення, що не дасть накопичитися великому числу незавершених завдань.

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

Конкретне рішеннявиниклих проблем залежить від ситуації. Можна зменшити кількість завдань кожної стадії чи, наприклад, частково залучити програмістів у процес тестування.

Для подальшої оптимізації процесу розробки необхідно враховувати два часові параметри: скільки часу займає завершення конкретного завдання від моменту отримання завдання від замовника до моменту реалізації функціоналу; скільки часу знадобиться розробнику для реалізації конкретного завдання. Систематизувати таку інформацію вам допоможе спеціалізоване ПЗ. Як результат, ви чітко уявлятимете, наскільки швидко ви зможете задовольнити вимоги замовника і скільки часу вам знадобиться на завершення завдань, які розробляються в даний момент. На підставі цих даних команда може приймати рішення щодо подальшої оптимізації процесу розробки.

Висновок

Kanban був спроектований таким чином, щоб допомогти вам використовувати наявні у вас ресурси найбільш ефективним способом, швидко знаходити проблеми, що з'явилися, і вирішувати їх у стислі терміни. Центральне місце в Kanban займає візуалізація процесу розробки, яка допомагає відстежити стан завдань, що виконуються на даний момент, і виявляти проблеми, що не виникають, не вдаючись до складних методик. Цю методологію легко використовувати практично, оскільки вона складається з трьох базових принципів. Звернути увагу на Kanban варто у тому випадку, якщо під час роботи над проектом вам важливо мати уявлення про те, на якій стадії знаходиться виконання того чи іншого завдання, хто над яким завданням працює і скільки часу завершення завдання займе. І, найголовніше, вам не потрібно кардинально змінювати процес розробки вже наявного проекту, оскільки Kanban передбачає послідовні зміни. Міняти що-або у звичному процесі розробки не потрібно доти, доки ви не з'ясуйте, які саме зміни необхідні найкращої оптимізації.