Розуміння ролі Продуктного менеджера в Скрам

Відповідальність

Повинен мати спільне бачення
Розробляє Winning продукт

Власник продукту управляє зусиллями по розробці програмного забезпечення в цілях створення якісного продукту

Інші функції

A) Створення бачення продукту
B) Підтримка розробки продукту
C) План випуску
D) Залучення клієнтів, учасників проекту і зацікавлених сторін в розробці продукту
E) Управління бюджетом
F) Управління запуском продукту
G) Відвідання Scrum і спілкуватися з командою розробників
H) Управління продуктом
Як ScrumTeam член – тісно спілкуватися з командою розробки

А) Переконатися що завдання виконуються
Б) Вимагати оцінку продукту від команди розробників

Інтеграційна команда в Multi-Scrum

Якщо однієї команди в Scrum не вистачає, можна використати декілька команд (Multi Team). Але тут виникає проблема – як управляти більш ніж однією командою. Відповідь: використовуйте інтеграційну команду. З Multi Team ваш Scrum буде виглядати трохи по-іншому.

Multi-team Sprint Planning

Всі команди або, принаймні представники від кожної команди збираються разом
Власник продукту дає бачення Sprintа
Представники з’ясовують залежності
Представники з’ясовують, як звести до мінімуму ці залежності
Потім кожна команда проводить свої звичайні Спринт планування

Integration Team’s Daily Scrum

Не те ж саме, що і звичайний Daily Scrum – не “3” питання
Ця зустріч може тривати менше 15 хвилин
Мета визначити: Чи є проблеми в інтеграціі роботи команд?
– “Чи були які-небудь проблеми інтеграції вчора?”
– “Чи проблеми інтеграції сьогодні?”

Multi-team Sprint Review

Мета:

Показати готове, працююче, інтегроване програмне забезпечення
Отримати зворотній зв’язок

Multi-team Sprint Retrospectives

Представники команд збираються разом
Обговорюють та визначають проблеми Multi Team
Представники проводять регулярні Sprint Retrospectives в своїх командах

Scrum з багатьма командами

Відповідно до Scrum команда повинна мати від 3 до 9 осіб. Але іноді ви хочете або повинні додати більше команд. Цей процес називається Multi-team Scrum.

Проблеми Multi-Scrum команди

Тепер ви повинні координувати не тільки одну команду
Scrum Master необхідно звернути увагу на залежності в доставці продукту
Управління залежностями у спринті
Нова відповідальність – об’єднати роботу з декількома командами

Done в одній команді проти кількох команд

В одній команді
– Мета: готове, працюче програмне забезпечення.
-Якщо це не відповідає DoD, воно не готове.

У декількох командах
– Мета: готове, працююче, інтегроване програмне забезпечення.
– Якщо воно не відповідає DoD, і якщо воно не інтегроване, воно не готове.

Мульти-команди – PBI Рекомендації

PBIs повинні бути зроблені однією командою в одному Sprint
Управління залежностями між PBIs
Створити нову команду інтеграції: Робота, щоб переконатися, що робота інтегрована
Один власник продукту для всіх команд
– Один продукт – один Product Owner

Як робити Scrum під Waterfall?

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

Чим одинаковий і чим відрізняється Scrum під Waterfall?

Одинаковий

Фокус на ‘Definition of Done’
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective

Відрізняється

Backlog = Project Plan
Менше часу для Backlog refinement
Менше часу для Sprint planning
Менше спілкування протягом Sprint

Але будьте обережні протягом використання Waterfall:

Waterfall має погану комунікацію / непорозуміння
Відсутня прозорість
Відрив від реальності
Повільний зворотній зв’язок / Немає зворотного зв’язку
Відсутній результат

Так що вам потрібно зробити наступні речі:

1: Робота в спринті

Waterfall може бути заплановано наприклад на 12 місяців. Якщо Sprint триває 30 днів, ви будете мати 12 спринтів.

2: Уникайте «освоєного обсягу»

Завдання не може бути зроблено для 85,6 або 98%. Завдання може бути готовим або не готовим Definiton of Done!

3: Фокус на Done

Створити критерій готовності (DoD), робота з DoD

4: Тестування, тестування, тестування

Тест протягом спринтів, створення тестів на початку проекту.

5: Отримати Зворотній зв’язок

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

Waterfall vs. Scrum

Що таке “Waterfall”?

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

Waterfall vs. Scrum

Waterfall

Розроблені вимоги
Стійкість до змін
– зміна є багом
Слабка участь клієнта
Визначений початок і кінець проекту
Великий розмір команди
Кілька фаз
Визначений набір функцій

Scrum

Вимоги Just-In-час
Безперервна зміна
– зміна – Особливість
Постійна участь клієнта
План для Sprint. Product Backlog
Невеликі команди (від 3 до 9 осіб)
Реліз в коженому спринті
Не фіксований набір функцій

Definition of DONE в розробці програмного забезпечення

Давайте уявимо, що в кінці кожної ітерації в SCRUM або будь-якому іншому способі Agile розробки програмного забезпечення, розробник приходить до вас і каже: “I’m done with this functionality! або функція зроблена” Але ви, звичайно, запитаєте: “Що ти маєш на увазі під словом зроблена? Вона зроблена чи повністю зроблена”

Що я хочу тут сказати: Розробники ПЗ думають, що розробка програмного забезпечення починається і закінчується з ними. Це насправді не дуже хибним твердженням, але …
Розробка програмного забезпечення набагато є більшим, ніж просто писати код. Код сам по собі не так вже й корисний. При розробці команда повинна визначити критерій, коли продукт можна назвати готовим (DoD), але тоді це буде набагато більше, ніж “просто кодування”.

Приклад визначення готовності фунціоналу (Definition of Done)

Розробка / Кодування

Код написаний з модульними тестами
Код був об’єднаний в Main
Код розглянув хтось інший, ніж автор

Тестування / Розгортання (Deployment)

Написані QA тести
Функція підтверджена QC
Функція протестована QA
Написані і проведені UI тести
Прийняті Product Owner

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

Визначення Definition of Done (DoD)

Зберіть команду перед або на початку старту проекту
Почніть дискусію, коли фунціонал може вважатися DONE
Намагайтеся уникати двозначності і відмінності у визначенні
Запишіть визначення!
Всі члени команди повинні слідувати DoD

Таким чином, наступного разу, коли розробник прийде і скаже: “Я зробив!”, всі будуть точно знати, що це означає.

9 основних методологій розробки програмного забезпечення Agile

Agile Modeling

Набір концепцій, принципів і методів (практик), який дозволяє швидко і легко виконувати проектування та документацію для проектів з розробки програмного забезпечення. Не включає в себе докладні інструкції з проектування, містить описи, як побудувати діаграми UML. Основна мета – ефективне моделювання та документація, але не включає в себе програмування і тестування, управління проектом, розгортання та обслуговування системи.

Детальніше

Хто такий насправді Скрам Мастер?

Скрам Мастер допомагає команді бути продуктивною і використовувати її творчий потенціал для отримання готового, працюючого програмного забезпечення.

Основне є те, що Скрам Мастер очолює команду, але не командує нею

Скрам Мастер є тренером. Він не бос. Члени команди не повинні звітувати Скрам Мастеру.
Скрам Мастер не є менеджером і не наказує команді. Він є лідером і йому потрібно з’ясувати, як вести команду.

Детальніше