Як координувати розробники часу між двома різними проектами в Scrum?

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

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

Я спробував виділити% часу розробника на роботу, але, мабуть, це не вирішує проблему. Мені цікаво почути майстрів scrum-майстрів, які раніше стикалися з цією ситуацією, як ти впорався з цим та які рекомендації?

Ця проблема така ж стара, як і scrum. Є рішення, але воно вам не сподобається.

• Покладіть нові завдання на відставання.
• Не перебивайте розробників.
• Зачекайте наступного спринту.

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

Якщо ви спробуєте подібний тип речей, ви в основному повертаєтесь до методів розвитку "хаосу" або "JFDI" з усіма супутніми проблемами, наприклад

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

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

Але це насправді не так.

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

Що ймовірніше, але це одне з наступних:

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

• Помилки - користувачі, які не розуміють, як система повинна працювати "Це сталося! Це помилка?". Отримайте службу підтримки та навчіть своїх користувачів, пишіть документацію.

• Страх відкату. Ви запустили нову функцію, і вона щось зламала, не намагайтеся поспішати з виправленням. Поверніться до попередньої версії та покладіть помилки на відставання.

Просто намагаюся думати нестандартно тут.

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

Чому б не спробувати передбачити це і використати його на свою користь?

Вам знадобиться команда 5+, щоб це було можливо реалістично.

Але чому б не взяти одного розробника з кожного спринту (обертаючись між розробниками, кожен отримує свою чергу).

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

• Проведення тестів для виявлення вузьких місць продуктивності або проблем масштабованості
• Підтримання системи побудови
• Зустрічі з клієнтами
• Дослідження нових рамок / бібліотек
• Вивчення мовних функцій, які ви хочете використовувати
• Читання з питань безпеки
• Обслуговування баз даних
• Обслуговування сервера

Швидкість команди може зрости, стрес може знизитися, конфлікти з керівництвом можуть знизитися, ви фактично отримаєте час для вдосконалення своїх знань.

Ефективне рішення для управління зусиллями розробників для справді важливих виробничих проблем, які я використав, - це "підхід Бетмена".

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

Скориставшись командою, створіть список членів команди та пройдіться по ній, щоб кожен день нова людина оголошувався "Бетменом" на засіданні зустрічі і відповідав на найважливіші виробничі проблеми в цей день. Залишок команди може залишатися зосередженим на розвитку, не потребуючи перемикання контексту, і кожен має неабияку частку болю підтримки. З 5-ма командою це один день на тиждень, коли розробник може бути перерваний і 4 дні безперебійного, передбачуваного часу розробки.

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