Мені здається, зараз відбувається якесь "нове відродження" адептів Agile (з великої літери) - людей, що не розуміють дух agile manifesto, а лише намагаються слідувати книжковим правилам без огляду на дійсність та результати своїх дій. (Це може бути пов’язано із черговою великою хвилею "нових айтішників".)
І от як раз нагодився текст Єгора Бугаєнка: 12 помилок Agile маніфеста (12 Mistakes in Agile Manifesto).
В житті цих помилок, звісно ж, не 12, бо кожен із постулатів Agile Маніфеста може мати безліч неправильних інтерпретацій :-)
Набільше мене зацікавило пояснення Принципів №9 та №11:
Principle #9: Continuous attention to technical excellence and good design enhances agility.
Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Я погоджуюсь, що Єгор пояснює "технічну досконалість" наявністю "політик та правил", що мають визначати крітерії "досконалості" та покарання за нехтування ними.
Від себе ще додам, що, як і при будь-якому вихованні, покарання має бути невідворотнім. Бо лише ясність правил в поєднанні з обов’язковим покаранням порушників веде до максимального дотримання правил.
Разом з тим, задля ясності, правила мають бути обґрунтовані. Щоб коли в кого-небудь з’являються сумніви щодо доцільності правила, можна було легко пояснити його мету. Також якщо через зовнішні обставини мета та саме формулювання правила вже не відповідають одне одному, можна було змінити правило без враження, що настала анархія.
Щодо регулярного поліпшення ефективності, Єгор висловлює сумніви, що "ретроспективи" є реальним інструментом. Я зі свого досвіду дійсно пригадую дуже мало прикладів команд, де "ретроспективні зустрічі" бодай якось поліпшували роботу команди. Зазвичай це просто перетворюється на "годинку самоїдства" у ліпшому випадку, і "взаємних звинувачень" - у гіршому. Про якісь тривалі результати та стратегічні рішення у такому форматі зустрічі мова йти не може. Єдина корисна інформація з ретроспективи - це узагальнення по невирішених проблемах. Ну і "просто пожалітися" декому часто хочеться.
Тобто "ретроспектива" потрібна для збору тактичної інформації. Звичайно, якщо ви збираєтеся в подальшому її аналізувати. Якщо скрам-майстер чи ПМ знаходиться в безпосередній гущині подій із командою, і немає проблем із перетоком знань, то всю інфу можна збирати безпосередньо "у полі", і без мітингу.
Для стратегічних змін потрібен окремий інструмент, що збиратиме інформацію на більш тривалих дистанціях, ніж спринт. І саме завдяки йому можливо впливати на роботу команди.
До того ж, тут я б не розділяв "технічну досконалість" та "ефективність команди", бо вони обидві реалізуються в один і той самий спосіб: в "політиках і правилах".
І от як раз нагодився текст Єгора Бугаєнка: 12 помилок Agile маніфеста (12 Mistakes in Agile Manifesto).
В житті цих помилок, звісно ж, не 12, бо кожен із постулатів Agile Маніфеста може мати безліч неправильних інтерпретацій :-)
Набільше мене зацікавило пояснення Принципів №9 та №11:
Principle #9: Continuous attention to technical excellence and good design enhances agility.
Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Я погоджуюсь, що Єгор пояснює "технічну досконалість" наявністю "політик та правил", що мають визначати крітерії "досконалості" та покарання за нехтування ними.
Від себе ще додам, що, як і при будь-якому вихованні, покарання має бути невідворотнім. Бо лише ясність правил в поєднанні з обов’язковим покаранням порушників веде до максимального дотримання правил.
Разом з тим, задля ясності, правила мають бути обґрунтовані. Щоб коли в кого-небудь з’являються сумніви щодо доцільності правила, можна було легко пояснити його мету. Також якщо через зовнішні обставини мета та саме формулювання правила вже не відповідають одне одному, можна було змінити правило без враження, що настала анархія.
Щодо регулярного поліпшення ефективності, Єгор висловлює сумніви, що "ретроспективи" є реальним інструментом. Я зі свого досвіду дійсно пригадую дуже мало прикладів команд, де "ретроспективні зустрічі" бодай якось поліпшували роботу команди. Зазвичай це просто перетворюється на "годинку самоїдства" у ліпшому випадку, і "взаємних звинувачень" - у гіршому. Про якісь тривалі результати та стратегічні рішення у такому форматі зустрічі мова йти не може. Єдина корисна інформація з ретроспективи - це узагальнення по невирішених проблемах. Ну і "просто пожалітися" декому часто хочеться.
Тобто "ретроспектива" потрібна для збору тактичної інформації. Звичайно, якщо ви збираєтеся в подальшому її аналізувати. Якщо скрам-майстер чи ПМ знаходиться в безпосередній гущині подій із командою, і немає проблем із перетоком знань, то всю інфу можна збирати безпосередньо "у полі", і без мітингу.
Для стратегічних змін потрібен окремий інструмент, що збиратиме інформацію на більш тривалих дистанціях, ніж спринт. І саме завдяки йому можливо впливати на роботу команди.
До того ж, тут я б не розділяв "технічну досконалість" та "ефективність команди", бо вони обидві реалізуються в один і той самий спосіб: в "політиках і правилах".
Немає коментарів:
Дописати коментар