Чому б тобі не відправитись до рашки та спитати Мішу, що він тобі обіцяв? Далі можеш у Зюганова (нащадка комунистів) спитати?
Есть все таки разница между сирийскими и украинскими парнями.
Ні, тепер ні. Треба все відбудувати. Наступні
А ось тут вже давно все вигадано, коли використовувати Скрам: thecynefin.co/...about-cynefin-framework/2. Не треба нічого придумувати.
Ні, не є. Дуже різні підходи до планування, роботи, командної роботи. І, мабуть найголовніше — у проекта є дедлайн, який нам відомий вже на старті (так, рідко хто попадає в дедлайні, але вони є), у продукта немає ніякого попередньо сформованого дедлайну. Ось тут можна подивитись більше www.solutionsiq.com/...-a-project-and-a-product
Скрам для продуктовой разработки. Не для управления проектами. Точка!
Вот блин. Как же мне этого не хватало на старте моей карьеры!!!
20 лет в менеджменте и до сих пор учишься работать с людьми, а тут — раз, и за месяц научился управлять людьми! ( тут бы организаторам задуматься, что Скрам — не про управление людьми).
Но мы говорим два — и за месяц ты научился фасилитировать все ивенты ( обычно на это не один год уходит).
3 — и ты создаёшь проекты в Джире. Хотя Скрам не про проекты, и не про джиру.
Обходите, товарищи, стороной эти кемпы, как минимум, до тех пор, пока не пообещают сделать из вас Аджайл Коуча. Конечно же, за месяц!
Забыли сказать, что всем выдали серую форму и ходили строем.
2. Оцінюй правильно
Наприклад, у нас був спринт і розробники оцінювали завдання. Була реєстрація, зокрема через Facebook, і заповнення профілю користувача. Звичайна реєстрація і заповнення профілю користувача займали три Story Points, а на Facebook виділили їх п’ять. З цього бачимо, що реєстрація через Facebook — складніша задача, аніж звичайна реєстрація та оформлення профілю.
Потерялась причинно-следственная связь: мы сначла оцениваем размер задач, а потом присваиваем им сторипойнты. Но важно даже не это. Сторипойнты не используются для планирования спринта. Используются часы — потому что команда должна согдать план достижения цели спринта. С часами план создать проще и быстрее, со сторипойнтами... даже непонятно как это можно сделать. Сторипойнты используются для:
1. Оценки верхней части беклога продукта для того, чтобы ПО имел возможность им управлять (упорядочивать).
2. Как индикатор, для планирования спринта (паттерн «Yesterday weather» при условии стабильного процесса разработки)
5. Розбивай великі сторі на маленькі
Тут вообще непонятно — какое задание брать? Как разбивать большие стори пойнты на маленькие?
В Скраме (коль мы говорим о спринтах и остальном) мы заранее разбиваем большие пользователтские истории на маленькие, соответствующие INVEST, желательно занимающие до 1 дня разработки (именно так рекомендует scrumm guide).
6. Коригуй Story Points
Вся команда оценивает размер и сложность пользовательских историй. Важный принцип — оценивает работу тот — кто ее делает. И уж тем более мы не предлагаем брать задания — команда сама решает кто, что и как делает. В основе Скрама — самоорганизованная команда.
8. Вимірюй результати
Burndown chart — покахывает, как хорошо ваша команда сжигает часы или сторипойнты, но совсем не показывает, какую пользу или ценность вы принесли заказчику. Хотите мерять важное? Читаем EBM.
11. Ретроспектива після кожного спринту
Чтобы получить обратную свзяь клиента (пользователей, стейкхолдеров) — Спринт Ревью, на которм мы инспектируем иполученный инкремент и адаптируем беклог продукта для следующего спринта.
Ретроспектива — это внутренний ивент Скрам команды для инспекции себя и своих процессов.
1. В скраме нет «Проблемы оценки проекта»
Скрам для разработки продуктов в комплексном домене. Может пока оставить вопрос «комплексности», а сосредоточиться на продукте.
У продуктовых и проектных подходов очень большая разница.
И если в проекте у вас есть спецификации, wbs , опыт в разработке подобных или похожих вещей, то помним о конусе неопределённости и планируем проект.
В продукте же есть идея ( или вижн), есть мысли как это может выглядеть и как работать. И все.
Начинаем процесс Discovery: собираем и валидируем наши продуктовые идеи. Хорошо бы уже сейчас на этом моменте подключить команду.
В любом случае, за процессом Discovery или параллельно с ним начинается процесс Delivery.
Как уже сказано выше, Скрам используется в комплексных средах, в области Wicked или «злых» проблем, когда мы не знаем будет ли успешен продукт ( viability), можно ли его технически реализовать ( feasibility) и понравится ди он пользователям (desirability). Таким образом, каждый инкремент продукта в Спринте закрывает эти три риска, а Бэклог Продукта адаптируется в конце каждого Спринта.
И да, мы не можем сказать сроки заказчику продукта, потому что у продукта, в отличие от проекта, как правило нет дедлайна. Продукт развивается все время пока есть на рынке: собираются новые данные, новые хотелки пользователей, новые продуктовые идеи...
Но каждый инкремент, наш Заказяик будет получать самый ценный функционал, который позволит ему получить уже профит, как и обратную связь от рынка. И в любой момент, Заказчик может остановить разработку, посчитав, что своих целей он (Заказчик) достиг.
На подумать: сколько займёт разработка Facebook? Who knows, как говорится...
Концепция Velocity, часто ошибочно примеряющаяся как метрика производительности команды, говорит только лишь о способности команды трансформировать элементы беклога продукта в готовый инкремент. И может служить только как вводные данные на этапе планирования спринта ( при velocity driven способе планирования) или как вводные доя ретроспективы команды ( если наша велосити достаточно сильно нестабильна за последние спринты).
Велосити хорошо срабатывает если у нас стабильная команды, стабильный процесс разработки. А если же нет — в помощь другие способы.
Наличие же правильной велосити помогает строить прогнозы и например, планировать выпуск больших фич.
Очень бегло и вкратце о планировании в Скраме.
Смысл статьи верен, хотя и ряд толкований скрама несколько не точен. Скрам — не является серебряной пулей, хорошо работает в продуктовой (а не проектной) разработке, в комплексном домене, в области Wicked или «злых» проблем, когда мы не знаем будет ли успешен продукт ( viability), можно ли его технически реализовать ( feasibility) и понравится ди он пользователям (desirability). Таким образом, каждый инкремент продукта в Спринте закрывает эти три риска, а Бэклог Продукта адаптируется в конце каждого Спринта.
Planning poker — это НЕ техника планирования. Это инструментальное оценки. Иными словами, инструмент для синхронизации представления членов команды о сложности (размере) задачи.
Не важно. Между проектом и продуктом большая разница. Погуглите какая.
Его станет это интересовать как только от проектов они перейдут к продуктовый разработке.
1. Обратная связь необходима, но не достаточна. Но точно важна.
2. В скрам гайде так и сказано, что есть дополнительные инструменты и практики, которые можно и нужно использовать.
3. Метрики в EBM guide на сайте scrum.org
Крутезна штука! Дякую!