Як змусити Scrum працювати над командою з визначеними ролями?

Довідкова інформація

Я є частиною внутрішньої команди розробників програмного забезпечення. Він складається з

• 5 розробників (зі стажем від 2 до 5 років, я один з них)
• 3 співробітники з впровадження (вони займаються розгортанням та навчанням програмного забезпечення)
• та 1 керівник проекту.

Ми розробляємо безліч малих та середніх проектів, і їх терміни зазвичай збігаються. Розвиток йде так:

1. "Клієнт" дає нам набір початкових вимог
2. Ми розробляємо систему за вказаною специфікацією
3. Подаруйте зазначену систему "клієнту"
4. "Клієнт" надає нам додаткові вимоги на основі зазначеної презентації
5. Повторіть 2-4, поки у "клієнта" не закінчаться нові вимоги або дата закінчення розгортання не закінчиться
6. Налаштування та розгортання системи

Це разом з тим, що саме "клієнт" обробляє терміни більшість часу (це червоний прапор, що я бачу тут у програмістах та PM.SE), і ми не дотримуємося певної методології розробки для кодування ковбоя, майже неможливого коду та помилок, які потрапляють через виробництво, серед іншого. Тому ми вирішили застосувати методологію на основі Agile на зразок Scrum.

Чому Scrum?

Це була ініціатива нашого менеджера, і, схоже, всі згодні з цим, враховуючи сучасну ситуацію.

Проблема з Scrum

Деякі елементи Scrum конфліктують з нашою нинішньою програмою, яку ми не можемо легко вирішити, особливо характер "Ack-of-all-trades" розробників Agile. Команда з розгортання не вміє програмувати, а розробники мають комунікаційні та навчальні навички нижче середнього рівня. І цей склад насправді незабаром не зміниться.

Питання

Чи вплине це на ефективність роботи Scrum як методології? Чи потрібно вносити інші зміни для компенсації? Або краще було б взагалі відмовитися від думки і подумати над іншою методологією?

Насправді ваш теперішній спосіб роботи не так далеко від Scrum, як ви могли подумати.

У Scrum ви також отримуєте початковий набір вимог, впроваджуєте їх та демонструєте результат, і на основі демонстрації ви можете поставити нові вимоги або зацікавлені сторони можуть вирішити, що продукт достатньо хороший, що подальший розвиток не потребує.
У вашій ситуації "клієнтові", про якого ви говорили, може бути відведена роль власника продукту в Scrum (вони, здається, вже заповнюють цю роль, встановлюючи пріоритети в проекті та вирішуючи, коли він буде готовий до виконання).
Однією з великих змін може бути тривалість ітерації. У Scrum ітерація повинна тривати десь від 1 до 4 тижнів.

Що стосується складу команди та помилковості джек-оф-трейду: Scrum не вимагає, щоб усі були джек-оф-трейд. Scrum просто вимагає, щоб команда в цілому мала всі необхідні компетенції для отримання продукту зі списку вимог до того, що було / може бути розгорнуте.
У вашій ситуації я міг легко бачити команду за проектом, що складається з одного або декількох розробників (які в основному виконують роботи з впровадження та тестування) та члена "персоналу з впровадження", який зосереджується в основному на створенні посібників та навчальних матеріалів для функцій, які розробники зараз реалізують.

Після того, як клієнт / Власник продукту дав зелене світло для розгортання, робота для команди scrum здебільшого буде виконана, тому розробники можуть перейти до іншого проекту (і бути доступним лише на вимогу для вирішення проблем після розгортання) та впровадження Персонал може перейти на навчання та підтримку розгортання.

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

Ви запитаєте альтернативи, тож я скажу програмування eXtreme (XP). Зокрема, я думаю, що парне програмування може вам тут допомогти.

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

Але якщо чесно, то це здається, що SCRUM - це так далеко для вас. Частина SCRUM полягає в гнучкості та пошуку найкращого для вашої команди. Частина XP поважає вашу команду та адаптується. Можливо, за 100 років ми можемо мати більш всебічно розвинену професію з жорсткими та швидкими правилами (хоча я сумніваюся в цьому), але поки що все, що ми робимо для вас, - це все, що ми маємо. Важливо - мати петлі зворотного зв'язку. Якщо щось не працює, то команді потрібно обговорити це і спробувати нові речі, поки вони не знайдуть щось, що працює.

Як змусити Scrum працювати над командою з визначеними ролями?

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

Деякі речі, які ви хочете вирішити:

Спринти

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

Фіксовані терміни

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

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

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

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

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

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

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

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

Отже, є трохи Scrum, який допоможе вам, але спробуйте схилитися від Scrum замість того, щоб використовувати Scrum.