Comments 42
Думаю, из субтитров спокойно можно выкинуть все слова-паразиты, смотреть станет гораздо проще.
Мда… пересказ Scrum from trenches в не очень хорошем исполнении.
Как обычно упущены вопросы:
1) Как планировать багфикс и то что называется operations. Если учитывать в беклоге, то неясно как это оценить. Если не учитывать, то начинает velocity скакать, причем непредсказуемо. А ели будут две команды — dev и ops, то нужен уже ПМ, как координатор действий команд.
2) Как приоритезировать PBI. В 90% внедрений скрамов это очень сложная проблема. Если все отдать команде, то начнут делать то что понятнее и\или интереснее. Если отдать все бизнесу, то возникнет то возникает ступор, ибо разные стейкхолдеры считают свои фичи важнее всех других. Нужен опытный product owner, который сможет это разруливать, а его зачастую нет.
3) Как выработать правильный definition of done, который с одной стороны не снижает темп, а с другой не позволяет релизить откровенное говно. Часто внедрения скрама начинают буксовать именно из-за этого.
Как обычно упущены вопросы:
1) Как планировать багфикс и то что называется operations. Если учитывать в беклоге, то неясно как это оценить. Если не учитывать, то начинает velocity скакать, причем непредсказуемо. А ели будут две команды — dev и ops, то нужен уже ПМ, как координатор действий команд.
2) Как приоритезировать PBI. В 90% внедрений скрамов это очень сложная проблема. Если все отдать команде, то начнут делать то что понятнее и\или интереснее. Если отдать все бизнесу, то возникнет то возникает ступор, ибо разные стейкхолдеры считают свои фичи важнее всех других. Нужен опытный product owner, который сможет это разруливать, а его зачастую нет.
3) Как выработать правильный definition of done, который с одной стороны не снижает темп, а с другой не позволяет релизить откровенное говно. Часто внедрения скрама начинают буксовать именно из-за этого.
Спасибо за Ваш комментарий.
Сначала поместил отрывок в статью из видео лекции. Но после Вашего замечания решил дополнить. Спасибо.
1. Бакфиксинг рассматривали (теперь дополнено) — очень важный пункт
2. С приоритетами тоже добавился материал. Как их определять вместе с продукт оунером. И как важно ходить на первые спринты продукт оунеру, чтобы откоррелировать приоритеты.
3. Скрам ради скрама, это не есть хорошо. Надо этого избегать — Вы правы. Панацеи нет как таковой. Можно лишь использовать некоторые полезные инструменты.
Спасибо огромное за ценные замечания!
Сначала поместил отрывок в статью из видео лекции. Но после Вашего замечания решил дополнить. Спасибо.
1. Бакфиксинг рассматривали (теперь дополнено) — очень важный пункт
2. С приоритетами тоже добавился материал. Как их определять вместе с продукт оунером. И как важно ходить на первые спринты продукт оунеру, чтобы откоррелировать приоритеты.
3. Скрам ради скрама, это не есть хорошо. Надо этого избегать — Вы правы. Панацеи нет как таковой. Можно лишь использовать некоторые полезные инструменты.
Спасибо огромное за ценные замечания!
Используем Scrum.
Команда 5 человек, все senior-level, разрабатываем ХД и связанные ETL-процессы (Postgres, MS SQL, MySQL, AWS).
Мой опыт: небольшие задачи, бьющиеся на спринты (2 недели), выполняются «на ура». Проблема — с долгосрочным планированием и с задачами, которые на спринты бьются плохо. В первую очередь это касается системной архитектуры: несколько раз уже случалось так, что с таким трудом реализованный функционал приходилось спустя какое-то время полностью переделывать.
Команда 5 человек, все senior-level, разрабатываем ХД и связанные ETL-процессы (Postgres, MS SQL, MySQL, AWS).
Мой опыт: небольшие задачи, бьющиеся на спринты (2 недели), выполняются «на ура». Проблема — с долгосрочным планированием и с задачами, которые на спринты бьются плохо. В первую очередь это касается системной архитектуры: несколько раз уже случалось так, что с таким трудом реализованный функционал приходилось спустя какое-то время полностью переделывать.
Эх, говорит, что ретроспектива — самый важный из митингов, но совсем не уделяет ему внимания в рассказе :(
User Story не совсем о требованиях, а скорее о проблемах пользователей.
Story Points не имеют ничего общего с приотретизацией, потому как приоритезирует Product Owner, а Story Points — удел команды. Помимо всего прочего Story Points не стоит приравнивать к человеко-часам.
Scrum — о командной ответственности, так что задачи на Sprint Planning берёт на себя команда, а не отдельные личности.
У Скрам-мастера нет блин никакого права вето в принципе.
Много воды в лекции и неточностей в деталях, которые превратят скрам в организации в скрамнецо.
Story Points не имеют ничего общего с приотретизацией, потому как приоритезирует Product Owner, а Story Points — удел команды. Помимо всего прочего Story Points не стоит приравнивать к человеко-часам.
Scrum — о командной ответственности, так что задачи на Sprint Planning берёт на себя команда, а не отдельные личности.
У Скрам-мастера нет блин никакого права вето в принципе.
Много воды в лекции и неточностей в деталях, которые превратят скрам в организации в скрамнецо.
такой вопрос.
Если стоит задача реализовать фичу с применением технологии, которой раньше никто из команды не пользовался. Почему так — вопрос не рассматриваем. И возникает ситуация, когда изначально простая фича кажется реализуемой, скажем, за неделю. Но из-за не знания технологии может начаться этап «исследования» который может затянуться и на 3-4 недели.
Как поступать в скраме с такими задачами?
Если стоит задача реализовать фичу с применением технологии, которой раньше никто из команды не пользовался. Почему так — вопрос не рассматриваем. И возникает ситуация, когда изначально простая фича кажется реализуемой, скажем, за неделю. Но из-за не знания технологии может начаться этап «исследования» который может затянуться и на 3-4 недели.
Как поступать в скраме с такими задачами?
Нужно из исследования выделить задачу, которую можно сделать и показать менее чем за неделю. Не забывать про правило числа Пи — сложность изучения новой технологии обычно в Пи раз недооценивается.
я столкнулся с такой штукой.
Есть система, и мне надо с ней интегрироваться. В определенные моменты на мой взгляд, она ведет себя совершенно не штатно. Соответственно, можно ломать мозг самостоятельно, можно писать в техподдержку. Как показывает практика, ТП отвечает в среднем через 1-2 суток. Ну и решение проблемы может занимать 4-5 вопросов-ответов с ТП.
При этом, при планировании разработки этой фичи по интегрированию, мы даже не предполагали возможность наличия какой-то проблемы.
Это получается задача с просроченным временем выполнения. А как планировать в дальнейшем? Было и наоборот, когда фича, запланированная на неделю, пилилась за полдня…
Есть система, и мне надо с ней интегрироваться. В определенные моменты на мой взгляд, она ведет себя совершенно не штатно. Соответственно, можно ломать мозг самостоятельно, можно писать в техподдержку. Как показывает практика, ТП отвечает в среднем через 1-2 суток. Ну и решение проблемы может занимать 4-5 вопросов-ответов с ТП.
При этом, при планировании разработки этой фичи по интегрированию, мы даже не предполагали возможность наличия какой-то проблемы.
Это получается задача с просроченным временем выполнения. А как планировать в дальнейшем? Было и наоборот, когда фича, запланированная на неделю, пилилась за полдня…
Не удалось сделать в пределах итерации — записали фейл, посмотрели какое значение velocity получилось, посчитали даты завершения, поняли сколько еще итераций можно потратить на попытки.
Суть гибких методологий в том, что не надо заранее план фиксировать. План фиксируется только на одну итерацию, а дальше пересматривается по результатам.
Суть гибких методологий в том, что не надо заранее план фиксировать. План фиксируется только на одну итерацию, а дальше пересматривается по результатам.
хм…
А если при том заказчик требует календарный план проекта с момента подписания договора до старта пром. эксплуатации?
То agile, scrum и прочие слова — не для нас?
А если при том заказчик требует календарный план проекта с момента подписания договора до старта пром. эксплуатации?
То agile, scrum и прочие слова — не для нас?
И вы реально верите, что если заранее составить план, особенно детальный на длительный срок, то все очно по нему пройдет? «Нет, сынок, это фантастика» (с)
Или есть проблема передоговориться с заказчиком, о том что и когда он получит? Особенно если заказчик уже получает ценность, а не кормится «завтраками».
Или есть проблема передоговориться с заказчиком, о том что и когда он получит? Особенно если заказчик уже получает ценность, а не кормится «завтраками».
хм. я — нет, не верю.
и вроде умом понимаю, что вы правы, и что при составлении плана на длительный срок предусмотреть все — почти невозможно, но каждый раз при необходимости переноса срока, возникает чуйство что облажался по полной…
С другой стороны, этот план иногда является приложением к договору. И особо упорные заказчики, чисто теоретически, за просрочки могут начать взыскивать неустойку.
и вроде умом понимаю, что вы правы, и что при составлении плана на длительный срок предусмотреть все — почти невозможно, но каждый раз при необходимости переноса срока, возникает чуйство что облажался по полной…
С другой стороны, этот план иногда является приложением к договору. И особо упорные заказчики, чисто теоретически, за просрочки могут начать взыскивать неустойку.
А не делать план приложением к договору? Этого даже при госконтрактах не требуется. Если заказчик хочет детальный календарный план и штрафы за просрочки, то он пытается закрыть риски. Это значит вы не управляете рисками заказчика.
Очень редко бывают случаи когда вас хотят намеренно нагнуть, потому что все понимают, что исполнитель может сделать полное говно, которое даже формальную проверку пройдет, но пользоваться этим будет невозможно. Кроме того менеджер заказчика на таком проекте подпортит свою репутацию. Поэтому всем нужно не формальное закрытие проекта, а получение value.
С помощью гибких подходов вы поставляете value больше и раньше, чем при «водопадном» подходе. В итоге заказчик более доволен, с ним легче договориться. В том числе заключить допник, который снимит уже ваши риски.
Очень редко бывают случаи когда вас хотят намеренно нагнуть, потому что все понимают, что исполнитель может сделать полное говно, которое даже формальную проверку пройдет, но пользоваться этим будет невозможно. Кроме того менеджер заказчика на таком проекте подпортит свою репутацию. Поэтому всем нужно не формальное закрытие проекта, а получение value.
С помощью гибких подходов вы поставляете value больше и раньше, чем при «водопадном» подходе. В итоге заказчик более доволен, с ним легче договориться. В том числе заключить допник, который снимит уже ваши риски.
Идеологоия у скрама несколько иная.
На полгода-год планов никаких быть не может, разве что крупными мазками могут быть обозначены хотелки. Единственная более-менее осязаемая часть беклога — нарезанные User story на пару-тройку спринтов. Всё это выливается из-за одного из пунктов Agile манифеста: готовность к изменениям важнее следования первоначальному плану.
В том числе сам подход о найме команд в идеале должен строиться иначе. Стейкхолдер платит не за проект в целом, а платит команде её стоимость в спринт. Тут же и раскрывается смысл итераций — инкремент продукта, который по завершению спринта и релиза в продакшн повысит прибыль, например. И по факту, стейкхолдеры в праве в любой момент прекратить финансирование команды.
При «Водопаде», если на середине разработки стейкхолдеры прекратят финансирование, то у них на руках остаётся не работающее нечто и бесполезное ТЗ, которое даже не привносит понимания: зря или нет они потратили кучу денег на разработку. При скраме же у них есть продукт с конкретным набором фич, который уже давно работает или не работает (как одна из причин, почему они прекратили инвестирование). Они так же могут банально прекратить инвестирование, если посчитают, что стоимость спринта, например, не соизмерима с инкрементом продукта.
На полгода-год планов никаких быть не может, разве что крупными мазками могут быть обозначены хотелки. Единственная более-менее осязаемая часть беклога — нарезанные User story на пару-тройку спринтов. Всё это выливается из-за одного из пунктов Agile манифеста: готовность к изменениям важнее следования первоначальному плану.
В том числе сам подход о найме команд в идеале должен строиться иначе. Стейкхолдер платит не за проект в целом, а платит команде её стоимость в спринт. Тут же и раскрывается смысл итераций — инкремент продукта, который по завершению спринта и релиза в продакшн повысит прибыль, например. И по факту, стейкхолдеры в праве в любой момент прекратить финансирование команды.
При «Водопаде», если на середине разработки стейкхолдеры прекратят финансирование, то у них на руках остаётся не работающее нечто и бесполезное ТЗ, которое даже не привносит понимания: зря или нет они потратили кучу денег на разработку. При скраме же у них есть продукт с конкретным набором фич, который уже давно работает или не работает (как одна из причин, почему они прекратили инвестирование). Они так же могут банально прекратить инвестирование, если посчитают, что стоимость спринта, например, не соизмерима с инкрементом продукта.
Выбор продукта, с которым необходимо интегрироваться для решения конкретной User story, лежит на плечах команды. Соответственно, если аналогов продукту нет, которые более адекватны и с временем ответа, и стабильностью работы, то есть пара выходов, но все они сводятся к совету gandjustas.
Во-первых на планировании спринта (а лучше на груминге, задолго до планирования) рассказать Владельцу продукта, что у такой-то User story есть внешняя зависимость (аналогов которой нет, поэтому приходится нам с ней работать), которая может подпортить итог спринта. Он в свою очередь может изменит приоритет, может ему это будет ОК.
Во-вторых всё в ваших руках, и если вы закоммитились на какую-то User Story, то должны стараться сделать всё, чтобы не облажаться командой на демо: это может и чаще долбить суппорт «внешней зависимости» (всей командой по 100500 раз на день, чтобы чаще отвечали), быть может предложить им помощь, если они не способны решать проблемы быстро (в ваших же интересах, чтобы они шевелились быстрее, так как в первую очередь вы потеряете деньги от их неторопливости), возможно реализвовать самим то, что предлагает другая контора.
Это, конечно, рассуждения о сферическом коне, ибо по описанию не совсем понятен масштаб бедствия.
Во-первых на планировании спринта (а лучше на груминге, задолго до планирования) рассказать Владельцу продукта, что у такой-то User story есть внешняя зависимость (аналогов которой нет, поэтому приходится нам с ней работать), которая может подпортить итог спринта. Он в свою очередь может изменит приоритет, может ему это будет ОК.
Во-вторых всё в ваших руках, и если вы закоммитились на какую-то User Story, то должны стараться сделать всё, чтобы не облажаться командой на демо: это может и чаще долбить суппорт «внешней зависимости» (всей командой по 100500 раз на день, чтобы чаще отвечали), быть может предложить им помощь, если они не способны решать проблемы быстро (в ваших же интересах, чтобы они шевелились быстрее, так как в первую очередь вы потеряете деньги от их неторопливости), возможно реализвовать самим то, что предлагает другая контора.
Это, конечно, рассуждения о сферическом коне, ибо по описанию не совсем понятен масштаб бедствия.
да не, в принципе ваш комментарий вполне в тему и без конкретики. Примерно так и поступаем.
Спасибо
Спасибо
А что касается
Если вы завершаете спринт быстрее и у вас остаётся адекватное количество времени до демо, то вы вполне можете смело подойти в Владельцу продукта и взять из беклога ещё одну-другую User Story на текущий спринт. Это проще, конечно, если беклог «начёсан» на пару спринтов вперёд.
Было и наоборот, когда фича, запланированная на неделю, пилилась за полдня…
Если вы завершаете спринт быстрее и у вас остаётся адекватное количество времени до демо, то вы вполне можете смело подойти в Владельцу продукта и взять из беклога ещё одну-другую User Story на текущий спринт. Это проще, конечно, если беклог «начёсан» на пару спринтов вперёд.
собственно скрам это агайл то есть гибкая разработка, сделайте спринты поменьше и никто вам не мешает сделать переоценку и обсудить задачу.
Нашел недавно отличный инструмент, позволяющий синхронизировать лекцию на youtube с презентацией sldeshare
presentz.org
Возможно пригодится.
presentz.org
Возможно пригодится.
Спасибо.
Сама статья довольно поверхностная, но такой общий взгляд тоже важен — для понимания в целом.
За комментарии отдельное спасибо — много ценного почерпнул.
Сама статья довольно поверхностная, но такой общий взгляд тоже важен — для понимания в целом.
За комментарии отдельное спасибо — много ценного почерпнул.
Последние 3 года для большей часть проектов использую Scrum и могу сказать, что если первоначально применяли его как он описан в Scrum Guide, то со временем он деформировался прочими активностями и практиками PMBoK и ITIL. Поэтому когда читаю успех применения Scrum, появляется комплекс, что это только у моих заказчиков есть бюджет и он заранее хочет знать когда же проект завершится, а еще почему изменений он вроде как не так много и добавил, а проект расширился больше его/ее ожиданий=)
Возникают те же самые вопросы.
В свое время нативно наработали практически тот же scrum, но не хватало учета скорости + с ростом проекта возникало все больше задач по обслуживанию самого проекта (миграция данных, разнос по серверам, наработка инфраструктуры, оптимизация, исследования,..) и в результате нам казалось что мы делаем очень много, а заказчику — что очень мало.
Навскидку scrum гораздо выгоднее разработчикам, для заказчика плюсы в первую очередь в гибкости (поскольку если фиксируется бюджет и сроки, то уже и менять задачи разработчики не дадут) ну и в поточности — можно работать по проекту непрерывно.
Интересно было бы услышать мнение руководителей разработки и заказчиков (со стороны разработчиков процесс понятен).
В свое время нативно наработали практически тот же scrum, но не хватало учета скорости + с ростом проекта возникало все больше задач по обслуживанию самого проекта (миграция данных, разнос по серверам, наработка инфраструктуры, оптимизация, исследования,..) и в результате нам казалось что мы делаем очень много, а заказчику — что очень мало.
Навскидку scrum гораздо выгоднее разработчикам, для заказчика плюсы в первую очередь в гибкости (поскольку если фиксируется бюджет и сроки, то уже и менять задачи разработчики не дадут) ну и в поточности — можно работать по проекту непрерывно.
Интересно было бы услышать мнение руководителей разработки и заказчиков (со стороны разработчиков процесс понятен).
Со стороны Владельца продукта, радеющего за свой продукт, профит в том, что у него есть возможность грамотно расставлять приоритеты Историй под ожидания и желания end-user'ов, условий рынка, каких-то шагов конкурентов под каждый спринт, а не сидеть на жопе и ждать, когда проект, который пилиться 9 месяцев по ТЗ появится наконец-таки на свет, но, например, уже никому не нужный, потому что многие условия/требования изменились и проект в том виде, как он проектировался изначально уже на рынке ничего не стоит.
Вы готовы часть недоделанного функционала переносить в следующий апдейт, а текущий при этом оплачивать полностью?
Мне, как разработчику, подход нравится, а вот как к этому относится заказчик — интересно узнать.
Мне, как разработчику, подход нравится, а вот как к этому относится заказчик — интересно узнать.
Если это первый проваленный спринт, то да, почему нет? Если в каком-либо последующем спринте произойдёт такая же ситуация (такие же условия провала), то это уже повод подумать о новой команде, потому как они не оценили, почему они провалили спринт и ничего для этого не сделали, чтобы в будущем этого не повторялось. Для команды и существуют ретроспективы, чтобы оценивать, что понравилось за спринт и что можно улучшить, в том числе проанализировать, почему завалили спринт/конкретную историю (если конечно завалили) и что можно сделать в следующий раз, чтобы дойти до конца спринта «без потерь».
Но это всё разговоры о сферическом коне в вакууме и ситуации бывают разные. У меня есть примеры и где несколько спринтов подряд комадна разработки фейлила одну и ту же критически важную фичу для бизнеса и Владельцу продукта при этом было ОК, ибо в основном провалы были из-за внешних зависимостей, о которых и Команда разработки, и Владелец продукта знали заранее до начала спринта, ибо ещё на груминге они все вылезали.
У них со временем скрам превратился, конечно, в эдакое подобие его и им скорее всего лучше бы подошёл водопад, но они из скрама почерпнули часть полезных идей, как для команды, так и для бизнеса в целом: если вкратце, то это пожалуй умная работа в бэклогом и улучшенная/налаженная коммуникации как внутри команды, так и в целом со своими клиентами.
Но у меня складывается впечатление, что вы пытаетесь всё же совместить водопад со скрамом. Точнее вы как команда разработчиков пытаетесь работать по скраму, а заказчик привык работать с водопадом и вы ему не рассказали правил игры в которую подписались играть. В таком случае вы находитесь в заведомо проигрышной ситуации.
Но это всё разговоры о сферическом коне в вакууме и ситуации бывают разные. У меня есть примеры и где несколько спринтов подряд комадна разработки фейлила одну и ту же критически важную фичу для бизнеса и Владельцу продукта при этом было ОК, ибо в основном провалы были из-за внешних зависимостей, о которых и Команда разработки, и Владелец продукта знали заранее до начала спринта, ибо ещё на груминге они все вылезали.
У них со временем скрам превратился, конечно, в эдакое подобие его и им скорее всего лучше бы подошёл водопад, но они из скрама почерпнули часть полезных идей, как для команды, так и для бизнеса в целом: если вкратце, то это пожалуй умная работа в бэклогом и улучшенная/налаженная коммуникации как внутри команды, так и в целом со своими клиентами.
Но у меня складывается впечатление, что вы пытаетесь всё же совместить водопад со скрамом. Точнее вы как команда разработчиков пытаетесь работать по скраму, а заказчик привык работать с водопадом и вы ему не рассказали правил игры в которую подписались играть. В таком случае вы находитесь в заведомо проигрышной ситуации.
Я пока не совмещаю )
У нас чистый водопад, и я пытаюсь понять, что как будет, если перейти на scrum.
В скрам'е все нравится, и вроде бы скрам решает все вопросы, которые сейчас встают.
Но пока все теоретически. Думаю, как наиболее безболезненно «мигрировать», в основном, беспокоит вопрос готовности заказчиков.
У нас чистый водопад, и я пытаюсь понять, что как будет, если перейти на scrum.
В скрам'е все нравится, и вроде бы скрам решает все вопросы, которые сейчас встают.
Но пока все теоретически. Думаю, как наиболее безболезненно «мигрировать», в основном, беспокоит вопрос готовности заказчиков.
Хех, прошу прощения за поспешность в выводах. :)
С точки зрения разработки и доносимой ценности Заинтересованным лицам (к которым относится и заказчик) scrum несколько интереснее, да. В том числе демонстрации по окончании каждой итерации позволяют Заинтересованным лицам не находится в неведении, а на каждой демонстрации понимать на каком этапе вы находитесь и в какую сторону движетесь. Принимая от них же обратную связь можно в том числе будет корректировать путь к достижению цели.
В принципе, многие беды из-за отсутствия нормальной коммуникации между людьми, в том числе в командах разработки. То же непонимание Заказчика, как заинтересованного лица, при решении задач из категории «технического долга» корнем лежат в том, что эти проблемы скорее всего не были объяснены ему с близкой ему экономической точки зрения, чем бизнесу это грозит в будущем и так далее.
Думаю, что если вы способны будете объяснить сильные стороны нового для заказчика подхода для разработки с экономической точки зрения, то у него не будет причин наставивать на чём-то другом. Главное быть честным перед ним и рассказывать всё как есть и в этом случае он будет лучше вовлечён в проект и, возможно, сможет помочь в каких-то вопросах решение которое у него займёт меньше времени, чем у вас, что в итоге ему принесёт профита больше.
С точки зрения разработки и доносимой ценности Заинтересованным лицам (к которым относится и заказчик) scrum несколько интереснее, да. В том числе демонстрации по окончании каждой итерации позволяют Заинтересованным лицам не находится в неведении, а на каждой демонстрации понимать на каком этапе вы находитесь и в какую сторону движетесь. Принимая от них же обратную связь можно в том числе будет корректировать путь к достижению цели.
В принципе, многие беды из-за отсутствия нормальной коммуникации между людьми, в том числе в командах разработки. То же непонимание Заказчика, как заинтересованного лица, при решении задач из категории «технического долга» корнем лежат в том, что эти проблемы скорее всего не были объяснены ему с близкой ему экономической точки зрения, чем бизнесу это грозит в будущем и так далее.
Думаю, что если вы способны будете объяснить сильные стороны нового для заказчика подхода для разработки с экономической точки зрения, то у него не будет причин наставивать на чём-то другом. Главное быть честным перед ним и рассказывать всё как есть и в этом случае он будет лучше вовлечён в проект и, возможно, сможет помочь в каких-то вопросах решение которое у него займёт меньше времени, чем у вас, что в итоге ему принесёт профита больше.
У меня вопрос — как абстрактные Story Points в итоге трансформируются в часы? Получается, что все-таки 1 Story Points имеет фиксированную временную оценку?
Нет, не имеет. Это просто уровень сложности. Вот мы знаем, что такая-то задача была оценена в N SP. Не важно сколько. Когда появляется новая задача мы просто сравниваем её и понимаем, что скорее всего это тоже N или N + 3. Дальше, через несколько спринтов команда понимает, что в среднем она выполняет K SP. И когда планируется новый спринт можно примено понимать, сколько задач можно взять на следующий спринт.
Кроме того, оценка может поменяться, например, мы замечаем, что у нас все задачи хорошо разбиты и мы оцениваим их в 8, почти всегда. Ну, тогда можно перекалибровать оценки, и сказать, что простая user story может стать… ну, допустим 3 SP. Это если нам хочется более точной оценки. Т.е. нам часы на самом деле не важны. Оцениваем не часы, а сложность.
Если хочется трекать время, то можно просто логгировать его в задаче. Может быть полезно, для аутсорс-комманд, где оплата идёт за часы.
Кроме того, оценка может поменяться, например, мы замечаем, что у нас все задачи хорошо разбиты и мы оцениваим их в 8, почти всегда. Ну, тогда можно перекалибровать оценки, и сказать, что простая user story может стать… ну, допустим 3 SP. Это если нам хочется более точной оценки. Т.е. нам часы на самом деле не важны. Оцениваем не часы, а сложность.
Если хочется трекать время, то можно просто логгировать его в задаче. Может быть полезно, для аутсорс-комманд, где оплата идёт за часы.
Кроме того, задача в 1 SP может занять разное время у разных разработчиков. Зависит от опыта, продуктивности, да много от чего зависит. Но «сложность» задачи от этого не поменяется, правда?
Спасибо, большое за ответ.
Вроде все понимал, но традиционный подход заказчиков: «сколько денег и времени?» и частые делдлайны внесли свою лепту.
Правильно ли я понимаю, что время (а точнее выполненный объем в единицу времени) можно сказать только по прошествии нескольких спринтов и оно так же может меняться от раза к разу, а работа идет по принципу «от забора и до обеда» — время вышло, не успели — не важно, решится уже в следующем спринте за доп.оплату?
И еще вопрос — как заказчик в таком случае оценивает эффективность? Как мотивируется команда на увеличение скорости работы? Есть ли какие-то механизмы для этого в scrum или решается внутри каждой команды по своему?
Вроде все понимал, но традиционный подход заказчиков: «сколько денег и времени?» и частые делдлайны внесли свою лепту.
Правильно ли я понимаю, что время (а точнее выполненный объем в единицу времени) можно сказать только по прошествии нескольких спринтов и оно так же может меняться от раза к разу, а работа идет по принципу «от забора и до обеда» — время вышло, не успели — не важно, решится уже в следующем спринте за доп.оплату?
И еще вопрос — как заказчик в таком случае оценивает эффективность? Как мотивируется команда на увеличение скорости работы? Есть ли какие-то механизмы для этого в scrum или решается внутри каждой команды по своему?
Вы пытаетесь совместить обычный водопад со скрамом, поэтому у вас возникают такие проблемы.
В скраме фиксированная оплата за спринт, фактически — нет никаких стоимостей проектов или чего-то подобного. Заказчик по истечении некоторых спринтов (за каждый из которых вы привнесли ему какую-то Ценность на основе его ожиданий) либо доволен результатами и продолжает с вами колбасить проект, либо нет и ищет других. При этом заказчику очень просто сравнивать ценно ли то, что вы сделали за спринт с тем, сколько он за него отвалил денег.
В скраме фиксированная оплата за спринт, фактически — нет никаких стоимостей проектов или чего-то подобного. Заказчик по истечении некоторых спринтов (за каждый из которых вы привнесли ему какую-то Ценность на основе его ожиданий) либо доволен результатами и продолжает с вами колбасить проект, либо нет и ищет других. При этом заказчику очень просто сравнивать ценно ли то, что вы сделали за спринт с тем, сколько он за него отвалил денег.
Когда я работал в аутсорсе оплата за работу шла по такой схеме:
У нас был продакт оунер со стороны заказчика. Он приезжал в офис на планирование спринта. Он знал, что он от нас хочет на следующий релиз. Мы говорили, сколько из его «хотелок» готовы выполнить. Он выбирает те, которые ему нужны больше.
После спринта и демонстрации он подписывал «приёмку» и релиз уходил на тестирование на стороне заказчика.
Во время спринта мы так же логгировали время, потраченное на задачи. По ним и выставлялся счёт. Не очень удобно, но так было проще платящей стороне.
У нас был продакт оунер со стороны заказчика. Он приезжал в офис на планирование спринта. Он знал, что он от нас хочет на следующий релиз. Мы говорили, сколько из его «хотелок» готовы выполнить. Он выбирает те, которые ему нужны больше.
После спринта и демонстрации он подписывал «приёмку» и релиз уходил на тестирование на стороне заказчика.
Во время спринта мы так же логгировали время, потраченное на задачи. По ним и выставлялся счёт. Не очень удобно, но так было проще платящей стороне.
Sign up to leave a comment.
Scrum — как эффективно работать без project-менеджера