Оценки времени и эпики как релизы

Инвесторам требуются даты оценок высокого уровня для определенных вех.

Это не совсем в духе Scrum... больше Waterfall. Тем не менее, вы не можете просто сказать: «Извините, инвесторы, у вас нет первоначальной оценки», поэтому часто вы делаете первоначальную оценку всех известных историй, необходимых для минимально жизнеспособного продукта (MVP), а затем используете свой установленной скорости (которой у вас, вероятно, нет, если вы только начинаете работать со Scrum), вы рассчитываете время, необходимое для завершения всей работы. и он будет скорректирован, когда станет доступна дополнительная информация. Также, если возможно, укажите диапазон значений .

Мне сказали, что в идеале мы НЕ должны использовать EPICS для представления релиза.

В Руководстве по Scrum нет ничего об эпиках или их отсутствии, поэтому просто делайте то, что имеет смысл для вашей команды. Не позволяйте инструменту или соглашению ограничивать вас или вашу команду.

Наконец, я получил противоречивые мнения о том, следует ли включать в TFS операционные аспекты разработки продукта.

Если CodeGnome простит мне кражу его Закона...

"Никакой невидимой работы, никогда!" - Закон прозрачности CodeGnome

Вы должны отслеживать эти задачи разработчика. Однако, если возможно, вы должны как-то различать эти задачи разработчика и обычные, связанные с бизнесом истории. Так как, в конце концов, люди вне Команды Разработки должны иметь возможность видеть Scrum Board, но не заботятся об этих задачах.

• Инвесторам требуются даты высокого уровня оценки для определенных этапов. Например, когда следует ожидать готовности MVP (минимально жизнеспособного продукта).

Может быть, еще слишком рано говорить... вы скрам-мастер? Это действительно вопрос к ОП. Но, в конце концов, пока у вас за плечами не будет нескольких спринтов, вы не сможете дать никаких реалистичных оценок. Смотрите твиттер-аккаунт @WoodyZuill, чтобы узнать подробности о движении #NoEstimates.

• В идеале мы должны использовать EPICS для представления релиза. Но поскольку я не вижу другого жизнеспособного способа добиться этого в TFS, я создал Epic под названием «Минимально жизнеспособный продукт» и добавил туда функции, которые нам нужны. Мысли?

Релиз может включать в себя множество эпиков или фрагментов многих эпиков... так что вы пытаетесь сбалансировать MVP с непрерывной доставкой. Лучшим вариантом для ваших инвесторов будет... как нам увеличить то, что у нас есть, чтобы стать чем-то более ценным? И, таким образом, получить более короткий взгляд на проект. это водопад, думая сказать, что вы будете жить со своим MVP через 6 месяцев. С точки зрения гибкости можно сказать, что через 6 месяцев ваш продукт станет лучше с (надеюсь) множеством небольших приращений функциональности.

• Наконец, я получил противоречивые мнения о том, следует ли включать в TFS операционные аспекты разработки продукта. Такие вещи, как «выбрать фреймворк», «настроить среду разработки» и т. д. Один скрам-мастер сказал мне, что мы НЕ должны этого делать, потому что скрам должен только перечислять поставляемый продукт, в то время как другой сказал мне, что очевидно, что эти вещи должны быть там, поскольку мы должны учитывать их в разработке продукта.

Поскольку они не будут доставлены в живую, правильным ответом будет «Нет». в некоторых названиях задач есть подсказка, например, «Обсудить» и «Оценить».

Мне нравится ответ @sarov, и я просто хотел добавить немного удара, связанного с TFS, в отношении к удару по Scrum, возможно, с небольшим дополнительным ударом по Scrum.

Инвесторам требуются даты оценок высокого уровня для определенных вех. Например, когда следует ожидать готовности MVP (минимально жизнеспособного продукта). Однако только задачи можно измерять в часах. Как я могу предоставить инвесторам хороший набор предполагаемых дат вех в этом случае?

(теория схватки) Это то, что полностью находится в компетенции владельца продукта и не относится к TFS. TFS — это система отслеживания усилий, а не система отслеживания времени.

(практика scrum) Если вы планируете в Scrum, то хорошей практикой является то, что ваша команда разработчиков оценивает каждый из ваших элементов невыполненной работы в относительных размерах на основе числовых баллов. В то время как ваша Команда Разработки может использовать эти баллы, чтобы решить, какой объем работы прогнозировать для следующего Спринта, ваш Владелец Продукта может использовать их для прогнозирования нескольких Спринтов и того, когда некоторые из их этапов могут быть достигнуты.

(tfs/vsts) Я бы попытался научить вашего владельца продукта тому, как отслеживать ценность. Есть хорошие учебные курсы как от Scrum.org, так и от Scrum Alliance. Если вы используете VSTS (облачная TFS), вы получаете расширение плана доставки ( https://marketplace.visualstudio.com/items?itemName=ms.vss-plans ), которое позволит вам легко и наглядно планировать будущие спринты, но дело еще не в часах.

(теория схватки) В конечном счете, если кто-то дает гарантии вашим инвесторам, значит, вы их не уважаете. Принципиально невозможно заранее определить, сколько времени потребуется для доставки элемента невыполненной работы и когда он будет доступен. Убедитесь, что вы фокусируетесь на прогнозах, а не на оценках.

Мне сказали, что в идеале мы НЕ должны использовать EPICS для представления релиза. Но поскольку я не вижу другого жизнеспособного способа добиться этого в TFS, я создал Epic под названием «Минимально жизнеспособный продукт» и добавил туда функции, которые нам нужны. Мысли?

(теория схватки) В руководстве по скраму не говорится об эпиках или фичах, потому что все они просто элементы невыполненной работы...

(практика схватки) Есть много способов организовать вашу работу, и вам решать, как именно. Однако общепринятой практикой является то, что эпики, функции и элементы невыполненной работы представляют одно и то же, только с разной степенью детализации. Поскольку все они находятся в потоке выполнения, все они должны представлять ценность, доставляемую клиенту.

(tfs/vsts) Здесь нет жестких правил, однако в TFS есть готовый метод управления прогнозами на основе времени. У вас уже есть Спринты в Пути Области, и, поскольку он иерархичен, вы можете добавить много уровней. Распространенный метод:

\Release 1\
\Release 1\Sprint 1
\Release 1\Sprint 2
\Release 1\Sprint 3
\Release 1\Sprint 4 
\Release 2\
\Release 2\Sprint 5
\Release 2\Sprint 6
\Release 2\Sprint 7

Поскольку вы можете указать «Команды» на определенный набор путей, вы можете создать дополнительную команду и указать ее на Релизы, предоставив вашему Владельцу Продукта возможность планирования высокого уровня. Я создал довольно подробный пост о том, как его настроить: https://nkdagility.com/creating-nested-teams-visual-studio-alm/

Наконец, я получил противоречивые мнения о том, следует ли включать в TFS операционные аспекты разработки продукта. Такие вещи, как «выбрать фреймворк», «настроить среду разработки» и т. д. Один скрам-мастер сказал мне, что мы НЕ должны этого делать, потому что скрам должен только перечислять поставляемый продукт, в то время как другой сказал мне, что очевидно, что эти вещи должны быть там, поскольку мы должны учитывать их в разработке продукта.

(теория схватки) Ваш Владелец Продукта несет ответственность за Бэклог Продукта, его содержание и понимание его всеми. Имея это в виду, может иметь или не иметь смысла иметь эти элементы в бэклоге в зависимости от вашей команды, вашего продукта или вашей компании.

(практика Scrum) Многие Scrum-команды помещают четко обозначенные «архитектурные» или «инфраструктурные» элементы в Бэклог Продукта, чтобы убедиться, что они не забыты. [эта практика взята из SAFe]

(tfs/vsts) Начиная с TFS 2015, в каждом рабочем элементе выполнения (Epic, Feature и Backlog Item) есть дополнительное поле, которое представляет собой раскрывающийся список со значениями «Бизнес» и «Архитектурный».

(практика схватки) Противоречивая передовая практика заключается в том, чтобы никогда не помещать в Бэклог Продукта то, что заинтересованные стороны не могут понять.

(предупреждение) Что бы вы ни выбрали, убедитесь, что вы можете прозрачно представлять технический долг.