Scrum - чим займаються члени команди під час спринту

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

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

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

1) Нехай члени команди вирішують, що робити, коли вони не виконуються.

Мінуси:

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

2) Створіть місце в спринті лише для розвитку, і почніть тестування після закінчення спринту (коли розробники почнуть працювати над функціями з наступного спринту)

Мінуси:

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

Отже, моє запитання: як правильно розподілити роботу під час спринту між розробниками та тестерами, щоб ніхто не перевантажувався роботою або в будь-який момент не закінчувався без завдань? Чи є шляхи вдосконалення описаних вище підходів? Або є кращі підходи?

На початку спринту ще немає чого перевірити

Дійсно? У вас немає вимог до перевірки? Немає обговорень із клієнтом? Немає каркасів для оцінювання? Ніяких тестових планів не варто думати?

наприкінці спринту зазвичай не залишається нічого або дуже мало для розвитку / виправлення

Я ніколи не був на тому місці в проекті. Немає більше роботи? Завжди є щось. Чи всі ваші тести повністю автоматизовані? Як виглядає ваш КІ? Чи можна змінити рівень доступу до бази даних простішим? І я ніколи не працював над чим-небудь із порожнім списком помилок та відставанням. Що раніше використовували ваші розробники на етапі тестування водоспаду?

Я знаю, що деякі люди дуже релігійні щодо того, що є, а що не "СКРУМ". Мені це було менше цікаво. Але я думаю, у вас тут два питання:

1. Традиційний «QA-відділ», який тестує код після того, як його «закінчили» розробники, а не працювали з клієнтами та розробниками, щоб переконатися, що ви будуєте правильну річ, а також будуєте її правильно. Погляньте на спритні квадрати тестування Лізи Кріспін. Найкращі тестери беруть участь у кожному етапі життєвого циклу розробки програмного забезпечення, а найкращі розробники пишуть власні тести.

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

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

Ще один додатковий момент, який підкреслив @Cort Ammon у коментарях. Швидкий маніфест говорить про співпрацю з клієнтами щодо укладання договорів. Ви кажете, що:

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

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

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

Підводячи підсумок, я б не переймався над тим, щоб намагатися зробити людей ефективнішими на початку та в кінці спринту, а скоріше сприймати це як симптом ширшої проблеми в команді. Ви чули про програмування eXtreme (XP) . Я б сказав, що тут застосовуються принципи роботи із XP, це спілкування та повага:

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

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

Однак над кожною командою, в якій я був, завжди багато роботи. Дозвольте мені вирішити кілька ваших конкретних проблем:

На початку спринту ще немає чого перевірити,

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

наприкінці спринту зазвичай не залишається нічого або дуже мало для розвитку / виправлення

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

Я бачив 2 підходи для вирішення цього питання ... 1) Нехай члени команди вирішують, що робити, коли вони не мають завдань.

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

Зробіть місце в спринті лише для розвитку,

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

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

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

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

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

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

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

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

Спосіб SCRUM б , щоб дозволити вашій команді бути крос функціональні. Ваші тестери в будь-якому разі повинні володіти навичками автоматизації тестів, це короткий крок до кодування деяких менш складних речей.