Scrum - розробники, що працюють поза спринтом

Колектив Scrum

• 3 x розробники
• 2 х Тестери
• 1 х Аналітик тесту автоматики

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

Зараз ми робимо двотижневі спринти.

На початку спринту всі зайняті, розробники починають роботу над розробкою, а тестери проводять підготовку до випробувань (написання тестових випадків тощо)

Після того, як тестувальники закінчили свою підготовку, вони тепер чекають завершення роботи з розробки АБО робота з розробки завершена, а розробники чекають зворотного зв'язку / помилок.

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

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

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

Я хотів би дізнатися досвід інших людей з цим, якщо можливо :)

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

По-перше, я хотів би відзначити кілька речей, які я вважаю важливими:

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

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

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

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

Що дуже добре працювало для мене, це два інструменти:

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

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

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

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

ми завжди розробляємо наступну роботу спринтів у поточному спринті

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

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

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

Якщо у розробників не вистачає завдань з розробки, вони абсолютно повинні поставити перед собою і допомогти тестерам, технічним письменникам або дизайнерам - будь-кому в команді. Їм не обов’язково писати фактичні тести (хоча вони повинні ), але вони все одно можуть брати участь у процесі тестування. Вони можуть писати сценарії, які допомагають тестувальникам бути більш ефективними, або вони можуть просто обговорити з тестувальниками, які їх проблеми, і допомогти їм подолати ці завдання (наприклад, додавання атрибутів id до елементів веб-сторінки, надання гачків або API, які тестувачі може використовуватись у своїх тестах тощо).

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

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

Я думаю, що ключова проблема тут полягає в наступному:

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

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

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

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

Так чи інакше, робити щось, що не було заплановано на початку спринту - це велика ні-ні. Краще нічого не робити, ніж робити щось, що не планувалося. Функціональність, яку вони пишуть у цих випадках, швидше за все, не відповідає критеріям DoD (Definition of Done), оскільки, ймовірно, не перевірена добре, оскільки тестери були зайняті тестуванням того, що спочатку планувалося. Це надійний спосіб ввести помилки та погіршити якість продукту, який потім направляє команду в низхідну спіраль проблем регресії та перемикання контексту, в результаті чого виникає стрес, знижена швидкість і, нарешті, відмовляється від команди через це.

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

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

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

На мій досвід, ви можете зробити кілька речей:

• Не робіть команду занадто малою. Якщо у вас, наприклад, є 4 розробники та 4 тестери, набагато простіше перенести завдання іншому розробнику чи тестеру, тоді як у цьому прикладі є лише 3/2.
• Спробуйте розділити великі завдання. Якщо у вас більше дрібних завдань, ви будете більш гнучкими.
• Визначте кілька додаткових завдань, які можна було б виконати, якщо залишиться час.

Ці пропозиції можуть бути не 100% -ними теоріями СКРУМ, але спочатку потрібно продовжувати роботу. SCRUM - це лише набір інструментів.

Здається, вам потрібно дезіхронізувати свою команду. Таким чином:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

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

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