Кілька команд scrum, що рухаються до одного відставання

Наразі у нас є 5 команд scrum, які відпрацьовують власні відставання продуктів за останній рік. Кожна команда працює за власною спеціальною системою, але основна технологія - однакова.

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

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

Моє запитання: чи відчували ви перехід на єдине відставання для двох або більше різних систем. Які були ваші виклики? Що вам потрібно було зробити, щоб він працював?

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

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

Нам не довелося об’єднувати відставання разом, але це звучить як пряма задача з вашого боку.

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

• Управління є ключовим. Кожен, хто має адміністративний палець у пиріг, повинен спілкуватися з іншими, перш ніж вносити значні зміни. І / або ті, хто вносить зміни, повинні відповідати своїм повноваженням (і бути готовими прийняти тепло для поганих змін). Наші виробники змін мають потужну підтримку виконавчої влади, і лінії досить чітко промальовані навколо районів. Але коли є сумніви, ми запитуємо перед тим, як змінитись.

• Може бути більше накладних витрат, пов'язаних із затримкою відставання, визначенням пріоритетів та початковими стартами. Пріоритетність як ритуал страждає найбільше, тому що важко регулярно збирати всіх власників. Ми використовуємо ряд переможців для узгодження пріоритету та / або доставки поганих новин про неприйняття пріоритету.

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

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

  1. Ми передмовим заголовком PBI з назвою продукту або скороченою версією.
  2. У нас є окреме поле, яке вказує на загальний продукт, і воно також має бути заповнене.

• Ми повинні докласти усвідомлених зусиль для перехресних тренувань та переконання, що всі отримають руку в різних сферах. У нас дуже велика база коду стосовно нашої команди розробників. Деякі з кодів ми також дуже спеціалізовані. Наші команди в цьому плані приголомшливі, і він підштовхне наш рівень зобов'язань донизу, щоб ми могли дозволити собі неефективність, пов'язану з перехресним тренуванням. В цьому плані вирішальне значення має наявність сильної команди.

• Ми робимо все можливе, щоб підтримувати наші часові рамки спринту. Складні проекти з новими членами команди перекладаються на нечасті кровоточення з зобов'язаннями. Тут дійсно допоможе процес вашої розгалуження. Вся наша робота проводиться проти гілки, яка потім об'єднується назад до випуску ствола. У нас також є сервер збірки, який працює щоночі на додаток до спеціальних тригерів. Розробники, які порушують збірку, знають і вирішують проблему протягом 24 годин. Період. Нездатність вирішити протягом 24 годин означає, що ваше зобов’язання відкочується назад, а старші дияволи доставляють їм горе. А старшим дияволам найважче, коли йдеться про підтримку складання.

• Додаткові описи та огляди коду стають ще критичнішими. Це допомагає усім бути в курсі того, що змінюється в різних областях.

• Аналогічно, щоденний стендап залучає всіх розробників плюс наших користувачів інтерфейсу. Ми знаходимося на межі вигідного спільного спілкування та неефективності занадто багатьох людей. Але ми залишаємо менше, ніж 15 хвилин, і ми швидко переходимо від побічних дискусій. Зазвичай ми закінчуємо за 5 - 10 хвилин.

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

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

• Виділіть час для науково-дослідних проектів. Інакше їм занадто легко проскочити через щілини, і ви втратите можливість інвестувати в ці сфери.

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

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

• Продовжуйте проводити свої ретроспективи і тримайте їх як групу. Важливо отримати відгук кожного про те, що працює, що не працює, а що потрібно намагатися по-різному. Це допомагає стимулювати почуття товариства в колективі та дає відчуття власності навколо процесу розвитку.

Правильна відповідь Scrum - "Запитайте команду (и)". Це принцип самоорганізації, коли вони повинні мати можливість реструктуризуватися, щоб швидко виконати роботу. Ви бачите, що багато людей у ​​командах мають більше контекстних знань, ніж сторонні люди, і вони знають, що найкраще. Сюди також відноситься Власник продукту.

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

Власник продукту

Існує лише один власник продукту на відставання, і це має бути ділова особа чи особа, яка представляє бізнес. Це не повинно бути управління ІТ. Великий відставання містить багато предметів, і для кількох команд це може бути занадто багато, щоб мати справу з одним PO. З цієї причини ви можете залишити відставання окремими.

Якщо існує декілька PO, то вам обов'язково потрібно декілька відстань, оскільки команди повинні бути сприйняті в спринті до одного PO та відставання. Причина - команді не потрібно керувати конфліктами між пріоритетами власників продукції.

Розробка продукту та технічне обслуговування

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

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

Контекстна комутація

Робота над кількома продуктами або різними функціями спричиняє зміну контексту, що сповільнює продуктивність команд. Офіційний сайт повинен враховувати це, коли розробляє, що буде далі, і яка команда повинна працювати над тим, який твір працює. Кількість комутацій не незначна і не просто теоретична, це реально, і я був свідком того, що команда знизила продуктивність до цього на 80%.

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

Ризик

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

Приклади

• Погоджуючись на смішний час. Швидше скажіть, які зусилля потрібно взяти, щоб виконати роботу належним чином і змусити бізнес управляти проблемою в часі

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

• Технічний борг. Команди повинні оцінити виконання високоякісного коду, який повністю перевірений, і оцінити його, тобто припинити дефекти писати через тиск. Якщо бізнес хоче нижчої якості, то це ризикувати, і коли все піде не так, це їх проблема.

Професіоналізм

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

Оглянути та адаптувати

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

Нижня лінія

Зрештою, управління відставанням - це вибір PO. Як він / вона хоче керувати чергою роботи, залежить від них. Думаю лише, що вони ОБОВ'ЯЗКОВО підтримувати роботу ВСІХ команд здоровими та в хорошому стані. Таким чином, рішення про те, що вирішується, залежить від PO.

Контракт

Під час сеансів планування спринтів команді слід очікувати переліку продуктів, які є доглянутими, які є чіткими, однозначними та упорядкованими. За короткою дискусією із спеціалістами, команда повинна точно знати, чого бажає спеціаліст; ЩО . Потім команда зосереджується на тому, як вони збираються будувати.

Якщо ПП приходить на засідання з планування добре підготовленим, кого турбує, як управляється відставання. Якщо PO прийшов непідготовлений до зустрічі планування спринту, це повинно вирішити СМ і зробити його дуже видимим, оскільки це абсолютно неприйнятно і не є проблемою команди.

Ми нещодавно поглинули відставання іншої команди. У команді був лише один член (я не знаю, що команда, я знаю), але фактична робота над їх відставанням. Ми не дуже знайомі з їх роботою, і вони не дуже знайомі з нашою.

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

Натомість почніть, щоб обидві команди працювали саме над тим, над чим працювали раніше; Єдина відмінність - все в тому ж відставанні.

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

Якщо ви виконаєте все навчання заздалегідь, значні штрафи за продуктивність. Хтось із вищого керівництва напевно помітить, і ви змушені будете скористатися відставанням іншої команди, сподіваючись, що нова команда зможе компенсувати низьку ефективність ... :) Жарти вбік, однак, це буде моєю рекомендацією.

Я припускаю, що причина, по якій ви (або керівництво) бажаєте створити об'єднані відсталі для двох команд, полягає в тому, що ви хочете мати можливість вибирати лише елементи відставання для однієї системи та мати, щоб обидві команди працювали над ними.

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

Отже, єдиний спосіб досягти цього успіху - це розбити дві команди та сформувати їх у дві змішані команди. Тільки тоді є ймовірність, що ви швидко накажете всіх розробників на (важливій) системі.

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

Перемикання між проектами також коштує зусиль, і якщо є нова людина, щоб почати розробляти накладні витрати - це справді велике. Потрібно отримати права доступу до розробленої системи, різних сховищ тощо.

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

Навіть якщо вони простоюють у своєму проекті, вони набагато продуктивніші у тому, що їм знайоме, ніж стрибати з проекту на проект.