SCRUM з нуля, без встановленої базової основи?

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

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

Отже, загалом, як ви використовуєте scrum, коли ви починаєте проект з нуля, не маючи фреймворків та базової бібліотеки?

Я не думаю, що багато спритних методів добре справляються з тими діями, які зазвичай є частиною проекту. Багато поширених фреймворків (XP, Scrum, Kanban) не вирішують цю проблему, але деякі масштабовані рамки (Discip дисциплінованість Agile Delivery, SAFe) до певної міри.

Деякі люди виступають за концепцію початкового приросту (в Scrum, спринт), яка призначена для налаштування вашого проекту. Це часто називається збільшенням нуля (або, в Scrum, Sprint 0). Однак це не формальна частина Scrum, і пуристи кажуть, що перший Приріст повинен бути звільненим.

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

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

Різні команди справляються зі спринтом 0 по-різному. Деякі можуть встановити його в ту саму тривалість, що і будь-який інший спринт. Інші можуть зробити це трохи довше або трохи коротше, залежно від потреб команди. Оскільки це ваша перша спроба Scrum, я можу зробити її довшою, особливо якщо у вас є більш короткі ітерації як частина вашого циклу розвитку. Якщо ви плануєте двотижневі ітерації, зробіть це 3 тижні.

Щодо формулювання завдань, я не обов'язково формулювати їх як історії користувачів. Ви можете, з точки зору членів команди та різних ролей (Власник продукту, ScrumMaster, розробник, тестер, дизайнер, технічний автор тощо). Однак Sprint 0 призначений для команди, а не для замовника чи користувача. Простий перелік завдань і заходів був би достатнім.

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

1. Члени команди мають високу або середньокваліфіковану кваліфікацію.
2. Команда щільно в’язана.
3. Обмін інформацією між членами команди - це швидкий, послідовний та вільний потік.
4. Команда розташована спільно.
5. Бізнес сильно залучений до команди.
6. Архітектура (бізнес, інформація, а також технічна) чітко визначена.
7. Інфраструктура працює і працює - середовище розробки, тестування та UAT.
8. Автоматизована збірка та випуск.
9. Високий рівень автоматизації випробувань.
10. Залежність команди від зовнішнього світу мінімальна (в ідеалі - нульова).
11. Кількість систем, що беруть участь, мінімальна.
12. Вимоги стабільні на більш високих рівнях, тому відставання товару має мінімальні зміни.
13. Учасники команди самостійно приймають рішення щодо того, яка історія користувача повинна бути частиною спринту / scrum, а також загальної кількості scrums / sprint, необхідних для досягнення поставленої мети.

Інші дві важливі частини:

1. Виберіть людей для ролей (Scrum master, Власник продукту та команда)
2. Приготуйте свою білу дошку, наклейки.