Starban. Гнучка методологія розробки, гейміфікація і ще багато модних слів

Оскільки пост некороткий і навіть недоречні картинки не роблять його читання легше, то давайте насамперед позначимо цільову аудиторію.
  • Ви розробник, керівник групи розробки, менеджер проекту або його еквівалент.
  • Над проектом працює більше одного програміста, бажано — більше трьох.
  • Ви пробували всі ці скрамы і эджайлы, відчули їх принадність, але є певні нарікання до догматичного сприйняття методології. Можливо, у вас ніхто не займається постановкою процесів зовсім і завдання просто «накидаються».
  • Команда втомилася (від проекту, від стресу, ...) і незабаром всіх чекають батоги і пряники.


Добре, є методологія, яка вигадана командою програмістів «для себе», але яку, на нашу думку, буде цікаво спробувати й іншим. Всередині команди відтворюється невелика економічна модель ринкових відносин, а пріоритети регулюються за допомогою курсу внутрішньокомандній валюти. .

Преамбула

IT світ винайшов чимало підходів до побудови процесу розробки ПЗ, запозичуючи найкращі ідеї у своїх допостиндустриальных колег. На певному етапі свого професійного розвитку ми зіткнулися з проблемами мотивації, управління якістю і візуалізації робіт для команди і замовника. Взявши все найкраще з усього кращого, що взяли до нас, ми організували роботу над проектами середнього розміру у вигляді старбана (starban).

Історична довідка

Довгий подорож по всесвіту комерційної розробки програмного забезпечення зіштовхнув нас з безліччю підходів до ведення проекту. Ми бачили і водоспади, працювали RUP, пробували застосовувати базові концепції MSF, але найтепліші спогади залишили гнучкі методології. У рамках одного проекту, який тривав 2 роки, ми перейшли з scrum на kanban, ділили і об'єднували команди, згинали під свої потреби Голдратта і тойоту.
З скрама ми взяли способи комунікації команди і оцінку завдань в безрозмірних (умовних) одиницях. Ітеративності процесу так само важлива, але може регулюватися. Так само, в скраме відмінно деталізована візуалізація поточної роботи (тактичне планування). Канбан гарний застосуванням теорії обмежень, гнучкістю їх налаштування під зміни всередині команди і візуалізацією поточної роботи на стратегічній карті. Складно повністю розділити дві методології, оскільки в канонічному втіленні вони зустрічаються рідко. У багатьох програмістів, наприклад, є труднощі з оцінкою завдань story point, тому найчастіше створюються таблиці переведення людиногодин в сторі поінти або ж відразу оцінка проставляється в годинах. Замість цього ми вирішили оцінювати завдання щодо їх поточної цінності для проекту і назвали цю величину зірками. Так з'явилася назва starban.

image

Коли потрібен STARban

  1. Є проект з не завжди готовим або зрозумілим ТЗ, яке потрібно представити в відчутному і оціненого вигляді.
  2. Розмір проекту достатній для того, щоб команда не встигала стежити за змінами в проекті, що вносяться іншими учасниками і поточним статусом проекту.
  3. Проблеми колективної відповідальності (Чому це маю робити я? Закомичу так, може тестувальник не знайде? Знову хтось білд звалив, піду поки пообедаю. Не баг це.)
  4. Зниження мотивації з плином часу із-за переходу проекту в статус підтримки або через overqualified. (занадто гарний, щоб працювати, дуже потворний щоб займатися проституцією).


image

ДОБРЕ, у нас є проект, в якому беруть участь 5-15 осіб, з необхідністю підтягнути стратегічне планування і кількома втомленими програмістами, які сприймають будь-яку задачу як рутину. Інші сприймають будь-яку задачу як тягар і ставлять своєю метою формальне закриття завдань з мінімізацією на те зусиль. Потрібний, як кажуть, підкреслити.

Насамперед потрібно зазначити, що starban це не закінчена методологія розробки ПЗ, а набір розширень, що дозволяє підвищити продуктивність і не дати проекту зануритися в кризу. Втомлений розробник може піти з проекту і забрати з собою унікальні незадокументированные знання. Менеджер може злитися на оффер краще, і тоді зрозуміти поточний статус проекту може бути досить проблематично. Відділ тестування закриє завдання і побудує приймальне тестування таким чином, ніби всі користувачі продукту повністю прочитали інструкцію і поклялися могилою свого кота ніколи її не порушувати. Відділ розробки лається з відділом з відділом тестування, перекладаючи відповідальність на аналітиків і збираючи масштабні мітинги, на яких можна 2 години слухати, 1 годину складати meeting minutes і за підсумками призначити наступне збори стейкхолдером, щоб переказати йому все ще раз.

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

Принци розробки STARban


Розподіл на команди
Навіть якщо в команді всього 4-5 розробників, є резон розділити їх на 2 команди, оскільки більше 3 чоловік навряд чи зможуть паралельно займатися розробкою однієї фічі (користувальницької історії). Найчастіше фичей зайняті 1-2 людини, третій може в цей час займатися підготовкою до розробки наступного функціоналу.
Якщо усереднювати, то наш досвід, чомусь, завжди показував, що ідеальні команди завжди складалися з трьох чоловік. Можливо, це суб'єктивне значення, але наші колеги теж часто приходили до такого ж висновку. Бути універсальною автономною одиницею складно і погано внаслідок відсутності зовнішнього контролю прийнятих рішень, а колектив більшого складу може блокувати сам себе. До того ж, кожен член команди повинен знати, чим зайняті інші.

image

Використання дошки для візуалізації прогресу проекту і команд
Дошка повинна виконувати наступні функції:
  1. Показувати найбільш повний RoadMap проекту. Команда буде бачити, до чого рухається продукт і використовувати це при розробці для застосування найбільш оптимальних зі стратегічної точки зору рішень. Власник продукту може на цій же схемі корегувати пріоритети і при цьому розуміти, що додаткові термінові завдання вплинуть на deadline інших.
  2. Ілюструвати стек найближчих завдань до розробки. Це дає стимул до завершення поточних завдань. Завдання до розробки повинні бути оцінені в SP.
  3. Відображати статус поточного виконання завдань командами. Це дозволить членам команд скоординувати свої дії, інформувати інших членів команди про проблему, побачити моментальний статус. Менеджер на основі динаміки цих даних може побачити проблему і втрутитися в її рішення.
  4. Готові завдання можуть поділятися на версії при випуску чергового релізу, що дозволить орієнтуватися в функціональності того чи іншого випуску продукту.


image

Дошка є важливою частиною в оптимізації процесу і повинна бути максимально інформативною.
Самою лівою колонкою є Roadmap проекту, відсортований за пріоритетністю завдань. Тут же повинні міститися глобальні технічні завдання обслуговування і модернізації інфраструктури розробки. Тут же може міститися терміновий запит на виправлення функціоналу, але він повинен дотримуватися ті ж правила, що й інші картки. Для себе ми взяли два правила — картки в цій колонці поділяються за кольорами і для кожної картки представлений її числовий пріоритет, який допоможе при сортуванні в системі ведення проекту. Ця колонка повинна бути по можливості максимально заповнена щоб всі учасники могли бачити очікуваний результат розробки і враховувати майбутні потреби при виконанні поточних завдань. Змінювати пріоритет виконання завдання може одноосібно стейкхолдер (замовник, його представник, власник розроблюваного ПЗ). При зміні пріоритету він відразу може оцінити втрати — випуск яких фіч зрушиться внаслідок його змін.

Наступна колонка — product backlog — містить формалізовані у вигляді користувальницьких історій завдання щодо зміни функціоналу, баги і технічні завдання. Деталізація тут може бути різною, як і типи завдань. Наприклад, злиття гілок в системі контролю версій може ставитися до конкретної user story, але може бути й окремою оцінюваної карткою в залежності від контексту. Пріоритет у цій колонці перестає грати роль, а порядок вилучення завдань повинен налаштовуватися менеджером за допомогою «зоряної оцінки». Про зірок поговоримо пізніше, поки тільки варто знати, що командам вигідніше брати до себе в розробку більш зоряні картки. На цю колонку можна ввести обмеження по кількості одночасно знаходяться в ній карток щоб уникнути спекуляцій. Ми пробували правило котячого лотка, коли число карток має на 1 перевищувати число міні-команд, що займаються розробкою (кількість лотків, якщо ви утримуєте будинку кілька кішок, має так само перевищувати їх кількість на одиницю).

image

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

Наступні чотири колонки розділені по горизонталі. Кожна команда володіє своїм шматочком дошки і веде облік на ньому. Коли у команди виникає потреба взяти в розробку чергову картку з product backlog, вона проводить планування — декомпозирует завдання на таски, з'ясовує подробиці реалізації, оцінює строки реалізації. Завдання береться «в роботу» — і сюди ж поміщаються всі картки. Декомпозиція повинна бути досить детальною для того, щоб дотримувалося правило: один чоловік на одну задачу. Ще добре йде ієрархічна нумерація <номер фічі>.<номер таски> або колірне поділ за фічами.

Як утримати команду від захоплення зайвих завдань, на які немає вільних рук? Чи потрібно це робити? Вводити обмеження на число карток? Скоріше це потрібно регулювати зоряно-ринковим методом, про який ще буде розказано, але при виникненні проблем можна без проблем вводити Голдраттовские обмеження. Для завдань з колонки «в роботі» можна використовувати значки — це додаткові прикметні здалеку позначки для карток. Стікери з жирними символами — підходять. Приклади: "!" — завдання знаходиться в роботі довше, ніж за початковою оцінкою; "?" — по завданню є питання, який вимагає проведення зборів з іншими командами. Слід актуалізувати цю частину дошки як можна частіше і стежити за бейджами на завданнях.

Коли активності по завданню завершені, вона переміщується у колонку «перевірка». Команда тестування бачить, що всі одноколірні фичевые завдання перейшли на перевірку і починає тестування. Баги на дошці можна відображати стікерами до карток або просто додати піктограму.

При завершенні тестування і відсутність багів завдання переносяться в колонку «готово». Тут їх назад можна згрупувати в фічу, зазвичай просто склеюючи картки драбинкою. Деякі значки, наприклад, про прострочений термін, тут можуть ще стати в нагоді. Періодично в рамках процедури приймання команда влаштовує демонстрацію завдань, що дійшли до цієї колонки, для власника продукту або відповідального аналітика. Прийняті завдання деталізації колонки «product backlog» переміщаються в колонку «прийнято».

image

Колонка «прийнято». Якщо в системі багато багів (а ми говоримо про довгострокові проекти, тому багів в трекері буде пристойно) і оцінювати кожен немає сенсу, у цій колонці записано поточний курс оцінки багів в зірках, загальний для всіх команд. Наприклад, чверть зірки за один баг або зірка за кожен баг. Бажано не міняти це число в рамках одного релізу, тому постарайтеся заздалегідь вибрати баланс між новим функціоналом і стабілізацією продукту. Варто згадати, що в цій колонці згадуються тільки баги, які прийшли з беклога, але не ті, які були створені в процесі тестування реалізованих командою фіч. Але скрізь є свої винятки.

При релізі чергового випуску продукту, всі картки з «прийнято» переносяться в загальну для всіх команд колонку «прийнято» і позначаються номером чергової версії. Найпростіше візуалізувати це сортуванням за номером версії, колірним кодуванням за номером версії або угрупованням всередині колонки.

Ще дещо наостанок. Буває конвеєр з майданчиками очікування і без них. Ви можете зіткнутися з тим, що тестування переводити нові завдання не можна з-за обмежень, але вони вже готові. Ця ситуація може виникнути з різних причин. Якщо команда не хоче фиксить баги за своєю фиче на тестуванні, то це проблеми команди, і не можна давати їм можливість перевести нові завдання на тестування до закриття старих. Якщо відділ тестування не справляється з потоком завдань або погано розподілив пріоритети, то можна призначити додаткову ціну в зірках за тестування фічі — і тоді одна з команд може взяти цю фічу на тестування. Такий підхід допоможе ще і поділитися знаннями між командами.

Експоненціальна тимчасова шкала дошки
Це так само можна переформулювати як «одна дошка для всього». Буває так, що дошку з Roadmap продукту розділяють зі скрам-дошкою, а розподіл функцій за релізами і зовсім не візуалізують. Це має свої переваги, наприклад, дорожню карту можна проілюструвати у вигляді справжньої картки, показавши залежність елементів замість не завжди очевидних числових пріоритетів або плоского списку. ОК, ніхто не обмежує вас в просторі (якщо бути більш точним — ніхто не обмежує вас в просторі-часі)!

image

Магнітно-маркерної дошки з площею 2-3 квадратних метра цілком вистачить щоб зробити двомірну модель великого проекту зі всіма необхідними колонками і ще залишиться місце для художнього оформлення. Якщо використовувати електронну версію з масштабуванням, то нічого не заважає деталізувати завдання до будь-якого необхідного межі. Дошка з точки зору часової шкали буде виглядати як «місяці -> тижні -> дні -> місяці».

Оцінка завдань в зірках
У чому оцінювати завдання — годинах або в story point? Існує багато спроб визначення сторі пойнт і методики оцінки в безрозмірних величинах (слонах, папуг). Більшість приводять до поняття складності і в підсумку до внутрішнього (а іноді і офіційно затвердженим записаному) побудови таблиці відповідності SP -> годинники. Погулявши між проектами, можна зустріти спочатку оцінку з розрахунку 1 SP == 8 годин команди, а потім, у сусідньому кабінеті, побачити 20 SP == 8 годин роботи 1 людини. Іноді залежність нелінійна. І ніколи немає розуміння з першого разу, що ж таке цей story point. Все, як кажуть книги, в порівнянні. Було б із чим порівнювати.

«Point Star» або просто «зірка» — безрозмірна величина оцінки завдань в проекті на основі їх поточної значущості для проекту. Можна провести аналогію з грошима. Є команда розробників, які безперервно працюють за договірною ставкою в зірках. Менеджер пропонує нове завдання — необхідно додати в продукт версіонування і зробити присвоєння версій напівавтоматичним при збірці на білд-сервері. Пропонує ціну в 10 зірок. Програмісти оцінюють завдання і розуміють, що простіше поправити 10 багів, які зараз оцінюються в 1 зірку за кожен. Оскільки вказівку версії терміново потребує служба підтримки для потреб фіксації помилок, цей функціонал є більш пріоритетним, ніж стабілізація продукту, тому менеджер призначає ціну в 20 зірок і перший же звільнився розробник квапливо забирає цю задачу для себе або своєї команди, щоб заробити відразу 20 зірок.

Через якийсь час менеджер проекту розуміє, що розробники накинулися на великі завдання, а в службу підтримки стало надходити багато скарг на дрібні помилки при роботі з додатком. Це можуть бути помилки, відсутність сортування списочних формах і безліч подібних незначних, але неприємних недоліків. Так як торгуватися за окремі помилки занадто дорого, керівник приймає рішення і оголошує команді — з вівторка до кінця тижня будь закритий баг оцінюється в потрійному коефіцієнті. Прямих вказівок при цьому можна не давати, а команда розробників сама змінить вектор розробки щоб не упустити шансу заробити зайві зірки.

image
Може здатися, що у програмістів немає мотивації вистачати важливі або складні завдання, але це не так.

Ринок
Коли чергову картку приймає керівник, її вартість в зірках перераховується на рахунок розробника або команди, які займалися реалізацією. Принадність зірок полягає в тому, що їх можна не тільки збирати, але й витрачати. Тут є певна проблема, звана економікою, з неї випливає кілька інших проблем — інфляція, ринок, спекуляції.
Це і добре і погано одноврем
військово. І, на жаль чи на щастя, найбільший друг людини криється саме в цьому пункті. Керівник проекту повинен запустити ринкові відносини серед працівників, зайнятих не проекті, і регулювати систему не через авторитарні вказівки, а невидимою рукою.

На що можна витрачати зірки? Все залежить від проекту і компанії, нематеріальна мотивація буває різною. Можна не брати до розгляду відгули, xbox one, спортзал і прогулянки на яхті за кожні півтисячі зірок — адже це ваша компанія надає своїм співробітникам без всяких умов. Всередині проекту є багато іншої рутини, яка може бути товаром. Не всі завдання цікаві, а цікаві можуть бути не так актуальні, і від цього в низький пріоритет. Дві команди можуть придивлятися до однієї задачі. Можна влаштувати торги за цю задачу і той, хто дасть більше зірок — має право взяти її на виконання. У команди завал по фичевым багам, а хочеться взяти якусь задачу, не влезающую в обмеження колонки? Нехай продасть баги за фиче іншій команді! А вже про ціну домовляться. Або нехай купують додатковий слот у колонці на тиждень. Але якщо запізняться за термінами — оштрафувати в зоряному еквіваленті так, щоб найближчий місяць їм діставалися тільки самі неприємні завдання (інші команди відкупляться від них). Комусь не подобається мержить, а комусь писати тести. За відсутність тестів на новий функціонал покладений штраф, але можна за половину вартості штрафу знайти кого-небудь, хто ці тести напише. Приклад з завантаженістю команди тестування і самопроверкой завдань — теж підходить.

Завдання керівника тут утримувати баланс зірок, не знецінюючи їх і прозоро вказуючи пріоритети, маніпулюючи ринком. Потрібно встановити певні правила, такі, як курс обміну багів на зірки, але в той же час виявляти постійну гнучкість і підтримувати ініціативи команди. Якщо хтось вирішить продати свою чергу мити кофемашину — чому б і ні! Комісія за операції з зірками? Можна. Але бажано зберігати бажання до отримання більшої кількості зірок, оскільки інакше нічого працювати не буде.

Якщо цей пункт все-таки буде викликати складності, то настільна гра від Мосигры і Хабрахабра "Стартап" може дати добрий грунт для роздумів і зайвий раз порадувати ваших колег, втомлених від xbox one і прогулянок на яхтах.

image

Технічні завдання важливі
Так. Потрібно просто пам'ятати. Оновлення версій використовуваних бібліотек, ревізії, налагодження CI CDналаштування СКВ, підтримка team-wiki, модифікація трекера завдань. Ці завдання повинні бути враховані у загальному обсязі роботи, вони повинні мати свій пріоритет і вартість в зірках. Команда придбає навички DevOps, а проект трохи заощадить.

Постамбула

А ми пробували скрам, але нам не сподобалося
А у нас і так все працює
А тимлид не хоче нічого міняти
Менеджер сказав, щоб закінчували в іграшки грати і писали код
У нас занадто мало програмістів, навіщо це взагалі потрібно?


image

А тут не написано, що робити, якщо ...
… програмісти не захочуть заробляти зірки
… у нас постійно вклинюється терміновий багфикс на продакшені
… ми неправильно оцінюємо завдання, варто на це взагалі витрачати час?
… все горить, а обмеження не дають нічого виправити
… у нас немає дошки
… Мігалкін хомячит всі зірки і не хоче їх віддавати


image

Ох, да. Розробка ЗА це така область, де скепсис є необхідною якістю для виживання як фахівця, так і проекту. Що ж, starban призначений скоріше для тих, хто встиг пізнати гіркоту розчарування в канонічному Agile, але й знає про існування спеціального місця в пеклі, де ви продовжуєте працювати програмістом, один на проекті, з менеджером, у якого ще 4 таких же проекту. І у вас, можливо, ще один. Або на одному проекті у вас одна команда, а на іншому зовсім інша, частково укомплектована замовником. Словом, краще б вам вести себе пристойно в цьому житті.

Гнучкі методології розробки були створені, щоб вирішити певні завдання — захист розробників від замовника, забезпечення конвеєрної обробки завдань, адаптивність до зміни вимог. Є корисні практики, які завжди вигідно використовувати незалежно від конкретної методології. Старбан спробував зібрати їх воєдино щоб зробити розробку проекту комфортної і цікавою для всіх учасників процесу. При цьому він залишається адаптивним до різних умов. Буває так, що на проекті всього пара розробників, але і їм можна організувати зоряну конкуренцію, замінивши командний залік особистим. Дошка може підлаштовуватися під реалії постановки завдань і можливості формалізації у проекті. Ніхто не заважає навіть не прив'язувати starban до конкретного проекту — якщо можна уявити завдання в рамках єдиного беклога (що часто буває в IT-відділі виробничих компаній) і вмістити на одну дошку, то проект є тільки умовним дільником.

А в підсумку кожен отримає той процес розробки ПЗ, якого заслуговує.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.