Требования, спецификации и управление в гибкой среде [закрыто]

Моя компания пыталась применить методологию скрама с переменным успехом. Тезисы - это области, в которых у нас были проблемы. Как вы справляетесь с этим?

  1. Отслеживание требований от маркетинга до продукта. Мы пытаемся JIRA отследить все требования индивидуально и назначить релиз для каждого, как он выбран для реализации.
  2. Кто создает истории? Менеджер по продукту, который не знает достаточно, чтобы эффективно создавать небольшие истории, разработчики, которые могут не иметь знаний в предметной области, аналитик между ними?
  3. Функциональные характеристики
    1. Вы пишете их или просто пытаетесь включить их в определение истории?
    2. Вы пишете функциональные спецификации для истории? По функции?
    3. Как вы видите связь между функциональными характеристиками и историями?
  4. отвечая на вопрос от людей с VP в их названии "что мы собираемся получить [через 8 месяцев]?"
18.08.2008 23:17:09
Я сталкиваюсь с той же проблемой, как управлять спецификациями в SCRUM. Задачи SCRUM являются функциональными, как они могут нести спецификации? SCRUM не способен отслеживать спецификации?
this. __curious_geek 24.05.2010 10:23:53
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что он касается управления проектами и методологии, а не программирования.
EJoshuaS - Reinstate Monica 10.10.2017 14:45:57
5 ОТВЕТОВ
  1. Вы должны перевести свои требования в Журнал ожидания продукта. Этот журнал используется для определения того, какие элементы журнала Sprint выбираются для каждой итерации Sprint. Руководство решает, что входит в Журнал ожидания продукта, но команда должна согласиться с тем, что они могут произвести в Спринте (это согласование, которое происходит на каждом спринте).

  2. Ваш владелец продукта (обычно менеджер по продукту) руководит созданием историй. Истории просты (как системный администратор, я должен иметь возможность добавить пользователя). Если ваш продукт не понимает ваш продукт, у вас проблемы.

  3. Agile - это проектирование по мере необходимости. Дизайн никогда не в истории. Спецификация может быть за историю или за функцию. Вы можете создать весь свой CRUD внутри одной спецификации, которая охватывает несколько историй.

  4. Владелец продукта получает демонстрацию продукта в конце каждого спринта. Таким образом, ценность демонстрируется на каждом цикле. Таким образом, ваш вице-президент будет получать отчеты ежемесячно (обычно 3 недели разработки + 1 неделя для подготовки к демонстрации Sprint).

1
19.08.2008 02:44:26

Давайте посмотрим, добавляет ли мой дубль что-нибудь (не совсем точно ...)

  1. Я не уверен насчет «назначения релиза каждому». Я думал, что идея заключалась в том, чтобы установить «цену» на каждую историю / функциональную точку / единицу разработки и выбрать то, что входит в текущий спринт. Все остальное - отставание - вы можете предложить некоторое указание на оставшиеся усилия (см. Планирование на основе фактических данных в FogBugz), но я не думаю, что вам следует выделять определенные спринты - вы не знаете, что будет в отставании к тому времени Вы получите там, с одной стороны. Все, что вы знаете, это то, что это изменится, так зачем тратить на это время?

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

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

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

4
19.08.2008 09:26:44

Немного информации о том, как Atlassian (создатели JIRA) используют свои продукты для гибкой разработки:

4
26.01.2009 05:38:46

Если вы собираетесь что-то делать в отношении написания или разработки кода, одна из вещей, которые вы всегда должны делать, - это написать спецификацию, независимо от используемой вами методологии, будь то Scrum, XP, Agile или SDLC. Многие люди, которые говорят, что написание спецификаций является настолько неуклюжим и памятником расточительной бюрократической бумажной работы. Простой факт заключается в том, что они вводят в заблуждение, когда говорят, что код - это спецификация.

Очевидный факт заключается в том, что спецификация позволяет вам заранее сформулировать свои идеи и проекты, и изменить спецификацию гораздо проще, чем изменить программу, особенно если вы работаете за пределами простого LOB-приложения. Спецификации гарантируют, что у вас есть более четкое понимание того, что требуется, когда вы начинаете кодировать.

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

Кроме того, я не имею ничего против Agile Manifesto или методов, ориентированных на легкий процесс управления, таких как Scrum. Я использовал его в последние несколько лет несколько раз, и это доставляет. Я также видел хорошее программное обеспечение, где бы ловкий фокус спас его. Но это не панацея или серебряная пуля.

0
17.04.2009 12:10:18
Я утверждаю, что пользовательские истории XP являются «спецификацией».
Tom Bushell 23.09.2009 16:08:38
Пользовательские истории не являются спецификациями по определению и не имеют места для описания как спецификации. Пользовательская история более схожа с требованием, чтобы сказать, что одна или несколько отправлений, кратко соединенных как требование, могут каким-то образом описать сложные отношения между объектами в сложной распределенной системе, все равно что сказать, что движение цилиндров и кулачков в двигатель автомобиля, так или иначе, связан с тем, как он доставляет водителя от А до Б. Есть отношения, но они косвенные.
scope_creep 23.09.2009 20:14:45
«Планы - ничто, планирование - все», - генерал Эйзенхауэр. Термин «спецификация» означает много вещей в зависимости от контекста. Хорошая идея - подумать о том, как разные вещи будут сочетаться друг с другом. пытаться выяснить каждую деталь в спецификации, прежде чем руки нет.
James Kingsbery 4.06.2012 16:57:43

Что касается функциональных спецификаций - у сайта Скотта Амблера "Agile Modeling" есть несколько хороших примеров. Там также много кратких, прагматичных советов по гибким требованиям в целом.

Стоит посмотреть!

1
23.09.2009 16:04:23