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