Комментарии 15
Теперь-то я знаю как называется извращённый скрам, спасибо за хороший термин
«scrumgile»
Я, кстати, такой термин вижу впервые. Но на первый взгляд он не так страшен, все-таки agile-мышление необходимо для внедрения Скрама. Знак равенства между scrum и agile ставить не корректно, а сочетать ценности и принципы agile-манифеста и самого скрама — это дело правильное.
Но хорошо бы понимать, что вкладывают в понятие «scrumgile» те, кто его использует)
А кто в модели без ПМ отвечает за бюджет, найм, мотивацию (вроде по скраму команда должна быть мотивированной, но самомотивация не обязательна)?
1. За бюджет отвечает PO, так как именно он владеет бэклогом, а значит определяет приоритеты и решает, как сделать максимально ценный продукт в рамках бюджета. Вообще, правильный PO — это человек «бизнесовый», в команде именно он отвечает за вектор развития, за вИдение и за деньги тоже.
В идеале при Скрам подходе использовать подход T&M, когда бюджет завязан на времени работы исполнителя, при этом обеспечивая высокую прозрачность рабочего процесса для стейкхоледров. Но это тема для отдельного разговора.
2. С наймом похожая история — инициаровать подбор нового участника команды может команда разработки, но финальное решение будет за PO, так как за деньги в скрам-команде отвечает он.
3. По поводу мотивации — зависит от того, что вы вкладываете в это понятие. Если речь идет про материальную мотивацию (зарплата, бонусы и тд), может быть несколько вариантов. Решение может принимать PO единолично (см. прошлые пункты), но в самых зрелых командах оно может быть принято всей командой. Это уже ближе к бирюзовым организациям, но опять же эта тема отдельного разговора.
Если речь про нематериальную мотивацию, тут важна роль каждого участника команды. Но, пожалуй, наибольшее влияние на мотивацию должен оказывать скрам-мастер. При должном уровне зрелости он помогает решать конфликты, поддерживать команду, умеет подобрать правильные слова и подбодрить остальных.
Неоднократно встречал ситуации, когда ПО с бюджетом не связан никак. ПО человек "бизнесовый", да, но бюджет разработки идёт мимо него, ему выделяют команду как данность, когда условно бессрочно, когда называют сроки типа "у тебя год". В плане бюджетирования, найма и т. п., он лишь заинтересованное лицо, которое может проявить инициативу по каким-то изменениям, но лишь инициативу. А так его основная задача сделать максимально ценный продукт в рамках имеющихся ресурсов (грубо говоря, разработчико-часов), а основной "материальный" инструмент — бэклог.
Есть обходные пути, например, задача считается неготовой даже для грубой оценки пока нет дизайна. Или в скоуп задачи спринта не включается завязка на внешние системы, например:
- спринт 1, задача на проектирование интерфейса взаимодействия на две команды
- спринт 2, задача на имплементацию этого интерфейса со стороны, например, фронта
- спринт N (по готовности бэка во второй команды), задача на интеграцию
Откуда ватерфол? И чем рисунок дизайнера отличается от невозможной текстовой задачи?
Так и в текстовой задаче нужно знать какие поля должны быть на форме, чтобы оценить.
Можно практиковать двухэтапную оценку: первичная оценка сложности реализации по текстовому описанию и, опционально, моков макета (иногда даже исключительно в устной форме, вообще без фиксации каких-то требований, типа услышал ПО, что его хотелка займёт грубо пару лет, независимо от дизайна и дизайнера не просит даже подумать), а потом переоценка после появления полноценных дизайн-макетов в порядке приоритетов ПО с учётом первичной оценки.
В любом случае в таких ситуациях скрам достаточно гибок, по-моему, чтобы переварить отступления от идеального (для кого-то) флоу без поломки принципов и духа, просто, например, изменениями формулировок definition of ready и definition of done, чтобы команда оставалась кроссфункциональной, чтобы могла выполнить за спринт любую готовую к разработке задачу от ready к done.
В Scrum оцениваются, как правило, только Stories путем коллективной оценки. В этом смысле Exreme Programming лучше справляется с задачей максимально раннего выявления отклонения от плана, поскольку использует двухуровневую оценку, сперва Stories оцениваются коллективно (тут есть отличия между 1-ой и 2-ой версией), а затем, при планировании итерации, уже оцениваются Tasks индивидуально.
При этом нужно не забывать, что оценка — это вероятностная распределенность, и, если делать оценивание правильно, то выражать оценку нужно не только вероятностной оценкой, но и ее среднеквадратическим отклонением распределения времени, которое, как раз, и выражает неопределенность оценки и служит бизнесу для грамотного управления бизнес-рисками. Чаще всего для этого используется методика оценки PERT.
Ну, и, кроме того, нужно не забывать, что оценка имеет свою стоимость, которая растет, как правило, экспоненциально в зависимости от точности, и бизнес-выгоды, которые растут линейно. Поэтому точность оценки должна находиться в балансе между затратами на оценку и ее бизнес-выгодами. Как правило, на оценку выделяется не больше 5% итерации.
Scrum вам не поможет. Разбираемся, почему