Зворотна сторона Agile — розбираючи чужі помилки

"Дурний вчиться на своїх помилках, розумний на чужих".
Всім доброго дня.
У цій статті я маю намір розібрати помилки відбулися і досконально описані в топіку Зворотний бік Agile
Це жодною мірою не holywar, ні тим більше який-небудь blame. Мені лише цікаво препарувати ці питання з боку дослідження і частково відновити добре ім'я SCRUM'a.
Запитання і відповіді. Все коротенько.
Перш ніж ми перейдемо до розбору ситуацій та спроб знайти правильні рішення, а я вірю, що практично в будь-якій ситуації можна знайти і тим більше застосувати (іноді через дуже боляче), я б хотів відповісти на кілька питань, які можуть виникнути у читача.
  1. Хто ти такий щоб міркувати про SCRUM'е і розбирати помилки? — Я сертифікований SCRUM master по програмі SCRUM.org'а. Зараз PSM level I. Так, я отримав сертифікат недавно, але практикую і готую дану методологію (framework ;) ) вже протягом останніх років 5, якщо не більше, як з нуля, так і змінюючи існуючі.
  2. Ти тут забув? — У мене свої корисливі цілі: я зараз готуюся до сертифікації PSM level II, а для підтвердження другого рівня необхідно розбирати кейси, а не бездумно натискати на правильні відповіді, звіряючись зі SCRUM Guide. Тому подібні випадки для мене — золотий криниця (та і якщо комусь буде цікаво, надсилайте мені Ваші випадки, постараюся їх препарувати, ну або возопию про допомогу і піду її шукати).
Отже, якщо з усіма запитаннями розібралися, приступимо.
Вносите пацієнта.
В один прекрасний момент керівництво компанії вирішило спробувати новомодну для Росії методологію розробки. Був обраний Agile (Scrum), в компанію найнятий скрам-майстер, всі розробки були переведені в TargetProcess. З точки зору менеджменту це було зроблено для того, щоб поліпшити швидкість і якість розробки, а також отримати розуміння, на що витрачають час розробники.
  • Найм SCRUM master'а (скрізь далі SM) — це хороший і логічний крок, тому що іноді зустрічаються спроби приготувати SCRUM на своєму часто специфічному розумінні. Сподіваюся досвід у людини в цій області був, т. к. робити SCRUM з нуля, заняття далеко не просте, хоча, судячи з подальшого змісту вихідної статті, я в цьому сильно сумніваюся. Але поки що залишимо його компетенції під питанням.
  • Торкнемося хотілок менеджменту: поліпшення швидкості і якість — добре, на що витрачають час розробники — це повз і не до SCRUM'у. Це звичайний time-tracking, ніяк не описаний в SCRUM Guide і його можна застосовувати для будь-якої методології, будь то КопьВап, Waterfall або інші RUP'и.
Я, звичайно, прекрасно розумію, що часи змінюються, і раніше, можливо, розробка проекту була чимось на зразок творчості. Тепер це налагоджений бізнес-процес, метою якого є заробляння грошей. Але доведений до апофеозу цей процес може придушити в розробниках тягу до креативу і зацікавленості в розвитку проекту.
  • завдання SCRUM'а — підтримка креативності, зацікавленості і хорошої атмосфери. Основний нюанс — навчитися правильно його застосовувати і не змінювати основні правила, оскільки якщо в добре налагодженому механізмі замінити одну деталь зовсім інший, невідповідною ні за розміром, ні за функціями, то вийде одна велика нічого з усього механізму.
Спочатку, після впровадження новомодного Скрама, всі раділи його логічності і зовнішній простоті. Все зрозуміло, ділимо процес розробки на спринти, отримуємо від менеджерів user story (завдання що робити), включаємо їх у ті чи інші спринти, в кінці спринту робимо ретроспективу (дивимося що зробили, і що пішло не так) і зацикливаем цей процес.
  • Тут і перша серйозна помилка — отримання user-story від менеджерів. З усього тексту, прочитаного мною в первісному топіку, я не зустрів згадки ролі Product Owner (скрізь далі РВ). Хто ж такий РО — людина відповідальна за кінцеве бачення, розвиток проекту та управління бэклогом проекту, у нього є ще ряд обов'язків, але поки що обмежимося цими. Тобто PO — перший стримуючий бар'єр від череди менеджерья мешкає на теренах вашого офісу. Так це повинно виглядати і працювати.
image
У команди є РО, який агрегує всі забаганки\бачення\фідбек від усіх зацікавлених осіб, обробляє цей список і доносить його до команди і РО повинен бути один і лише один(!) для SCRUM команди, а не купа менеджерів, бо вийде, як у тій байці Крилова:
Коли в товаришах згоди немає,
На лад їх справа не піде,
І вийде з нього не справа, тільки борошно.
  • Наступний нюанс — відсутність факту оцінки. Може бути автор статті забув вказати, а може її просто не було, але команда повинна давати свою оцінку на ту чи іншу User Story. Якщо оцінка дана кимось іншим, не Development Team'ом (скрізь далі DT), то це буде біль\печаль і взагалі так робити не можна. Повинен дотримуватися постулат, хто виконує завдання, той і дає оцінку. Не менеджер Вася, а весь DT.
Менеджмент почав конвертувати завдання під час їх виконання і природно у вартість. Тут, як водиться, одразу виникло непорозуміння між менеджментом і розробниками. Як перенесення проекту з Symfony 2.6 на Symfony 3.0 може зайняти майже тиждень часу розробника, адже це просто оновлення з однієї версії на іншу? Можливо, відділ розробки з точки зору бізнесу завжди виглядає як ледачі співробітники, які добре, якщо б змогли працювати втричі, а краще в п'ять разів швидше, щоб знизити витрати на розробку і збільшити її швидкість.
  • Ось у цей момент повинен був вступити в гру SM послати всіх менеджерів в пішу еротичну подорож захистити розробників(DT) від менеджерського свавілля. Бажання менеджменту зрозуміло і застосовно: оцінити, виміряти, заощадити бабла (ну не всі менеджери цим займаються, від цього нікуди не дітися). Але в даному випадку в справу повинен був втрутитися SM, приймаючи весь удар на себе, пояснюючи всім, що робить команда, чим займається і чому їх не можна чіпати. Ну а якщо в кімнату до DT прокрадеться який-небудь особливо старанний менеджер, то гнати його ссаными ганчірками. Так, я передбачаю заперечення: "Осіб, етож менеджери, хто їм слово-то проти скаже, не кажучи про ганчірки?", але тут все досить просто, SM заздалегідь повинен домовитись з ТОП\МегаТОП та іншими великими менеджерами, що команду не чіпають і працюють через нього. Власне, це один з обов'язків SM'а — впроваджувати SCRUM організації та впроваджувати його правильно, а не тяп ляп. Тут же судячи по всьому SM усунувся від проблеми і сидів гамал в танчики?
Але, з точки зору розробників, з'явилася дещо інша картина, розробники так і не були обділені роботою, працюючи паралельно над трьома-п'ятьма проектами кожен, як тут з'явилося тиск з боку менеджменту звіт за кожну годину робочого часу. Стали виникати питання в дусі «чому ви витратили цілий день на розробку або тестування того-то»?
  • Один DT — один PO і бажано один проект (або обов'язково один Product Backlog), або необхідно міняти серйозно процес, змінювати методологію з чистого SCRUM'а на Kanban (а ще краще помісь зробити SCRUMBan, і так, тут немає нічого страшного, якщо буде цікаво, розповім, як це робити і впроваджувати плюс різної чорнухи). Тобто коли багато реквестов з багатьох проектів, то це вже пахне support'ом і тут краще йти від SCRUM'а. Плюс де був SM (аааууу?), чому не захищав DT? Він точно SCRUM знав? Був готовий його впроваджувати? Мав досвід? До цього абзацу я вже сумніваюся в позитивних відповідях на ці питання трохи більше ніж повністю.
Стали виконуватися тільки завдання (User Story), що надходять від менеджерів, на якусь непомітну, але корисну діяльності часу у розробників залишатися не стало.
  • Не було PO, невірно впроваджено SCRUM — звідси і люта біль. Якби був один(!) PO, який відповідав за управління Project\Product Backlog'ом, а не стадо оскаженілих менеджерів, то все було б простіше (Та йому б довелося лаятися з менеджерами і бути ними нелюбом, ну а що робити? Доля в нього така в деяких реаліях. Це потім вже всі звикли і змирилися.)
Доходило до того, що при знаходженні де бага-то на продакшне розробники не могли його лагодити, т.к. на це завдання потрібно, щоб списувати туди час. Та й самі розробники були завалені своїми завданнями. Завданням стали присвоювати пріоритети. Менеджери почали конфліктувати між собою, намагаючись присвоїти своїй userStory вищий пріоритет, оскільки у них зобов'язання перед замовниками і нікого не хвилює зайнятість розробників.
  • Я повторюся якщо скажу, що PO немає і SM мудак і це основна проблема? Насправді Backlog item (в нашому випадку User Story) — це необхідний артефакт, хтось скаже, що це данину формалізму, але тут я посмію заперечити — ні. Це опис, розуміння і бачення кінцевих результатів того, що повинно бути зроблено. І це повинно бути оформлено таким чином, що Вася\Петя\Ктулху з DT — всі розуміли, що потрібно зробити і могли це пояснити PO і SM'у. Навіщо пояснювати, якщо вони і так знають? Потім, щоб побачити, що члени DT правильно розуміють і немає різночитань. За рекомендаціями — все просто, виставити PO і SM'a на передню лінію оборони DT, щоб всі какашки летіли в них, а DT відсікти від світу і підігнати їм чай\кава\печенюшки\куртизанок.
Методологія Скрам, перетворює процес розробки у конвеєр, не враховує насамперед людських взаємин у команді, не враховує того, що деякі речі в компанії можуть робитися тільки за ентузіазму співробітників, і не можуть бути загорнуті в UserStory.
  • Framework, Bro. Не методологія, ні разу. Вона враховує людські стосунки це одна з основних цілей SCRUM'а і базується на цих відносинах. Чому я так вирішив, так ось чому (шматок виламаний з SCRUM Guide'а):
    When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient living in these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open all about the work and the challenges with the performing the work. Scrum Team members respect each other to be capable, independent people
Згідно SCRUM'у люди — основа. Хоча, чого я тут його славлю — люди основа скрізь у будь-якого керівника і при будь-якому процесі\підході\методології. Якщо мозку немає, якщо ж менеджери думають сідницями, то тут все погано.
Шановний Keks650, я можу постаратися навіть доповнити вашу статтю, як мені здається ви забули згадати один серйозний фактор, який сильно вплинув на всю команду і на весь процес. Можливо я і помилюся, але як мені підказує інтуїція він мав місце бути — оцінка User Story розглядалася як commitment, і розробники сиділи в овертаймах по самі вуха. Вгадав?
  • Здавалося б, це як-то незначно commitment або прогноз. Яка в пень різниця? А відмінність насправді величезна. В SCRUM Guide немає такого поняття як commitment за термінами виконання. Якщо завдання було оцінено невірно\неправильно або не враховані всі фактори, то це предмет торгу між DT і PO, але ніяк не "помри, але зроби". Та й взагалі є поняття прогноз, якщо звернути увагу, то SCRUM Guide не описує способи эстимации і одиниці вимірювання. Всі ці годинники, покер та інші розміри трусів, з'явилися локальні розширення, які "прижилися". Але в первоскраме їх просто немає. Таким чином, якщо прогноз не вдався, то в рамках Retro, DT повинна розглянути\чому і як це виправити, щоб подібного не повторювалося. І якщо SCRUM впроваджено нормально, то проблем з цим не виникає.
Посмертний епікриз.
Я так вважаю що пацієнт врятований не був, тому підіб'ємо підсумки.
В принципі усі фікси для помилок описані в статті, але нижче я зберу коротке резюме:
  1. РВ і SM повинні бути і повинні бути залучені в процес відповідно до своїх обов'язків.
  2. РВ повинен працювати безпосередньо з stakeholder'ами. DT має лише виконувати бачення РВ згідно бэклогу проекту і не спілкуватися з менеджерами взагалі, крім як для уточнюючих запитань і отримання зворотного зв'язку в рамках рев'ю.
  3. SM повинен бути не для галочки, не тому що це модно\молодіжно, не для попила бабла, а для налаштування процесу, т. к. без грамотного SM'a весь процес піде прахом. Зокрема, в даній ситуації він повинен був ініціювати створення ролі РВ, потім навчити його як працювати з бэклогом, DT і зовнішніми менеджерами. Так само на перших парах дивитися щоб він не накосячілі і на нього не чинили зайве вплив менеджери.
    Потім працювати з командою, отримуючи від неї зворотний зв'язок і усуваючи то що заважає команді: будь то протяг в приміщенні або який-небудь особливо настирливий і запопадливий менеджер.
  4. РЗ повинен бути опрацьований і приоритезированный Project Backlog, з чітким визначенням пріоритетів, а не так що прийшов черговий парниша і ввів супер-пупер пріоритет тому що йому так треба.
Епілог
Чому я так відреагував на статтю, місцями втрачаючи нитку логічного оповідання і скочуючись у міркування -тому що у мене підгоріло мабуть тому що SCRUM хаят дуже часто не розібравшись. Як підсумок це призведе до того, що хтось скаже: "%username%, ти знаєш SCRUM — гавно, соковижималка і фашизм. Не будемо його впроваджувати." і як підсумок все що-небудь втратять.
У первісному топіку явно видно величезні проблеми в організації самого процесу, на які забили\поклали\подставить_на_свое_усмотрение. SCRUM якраз тут не причому. При правильному підході він просто бусечка і взагалі
image
Це я можу заявити з повною упевненістю людини, який робив SCRUM з нуля, змінював SCRUM, миксовавшего його з Kanban, що використовував його успішно з проектами Fixed Price(!).
Так, перехід на нього агресивний, нововведення завжди, мабуть, несподівана і хворі, але якщо його правильно подати, то він буде працювати дуже добре.
PS — я не закликаю що SCRUM — панацея від усього. Іноді буває, що він не застосуємо, які б асани йому не співали, але ця незастосовність полягає в різних факторах: бюджет, обмеження, необхідність застосовувати інший процес. Але, його незастосовність не можна відносити на рахунок кривих рук. Криві руки — це криві руки, ними можна изговнять все, не тільки SCRUM.
Майже всі мої міркування перетинаються SCRUM Guide. Дуже рекомендую уважно вивчити і працювати активно з цим документом, а не сліпо слідувати за чиїм кривим думкою.
Джерело: Хабрахабр

0 коментарів

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