Требования, спецификации и управление в среде Agile

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

1. Я не уверен насчет "assigning a release to each one" вещи. Я думал, что идея заключалась в том, чтобы поставить "price" на каждую историю / функциональную точку / единицу развития и выбрать то, что входит в текущий спринт. Все остальное-отставание-вы можете предложить некоторые указания на оставшиеся усилия (см. планирование на основе доказательств в FogBugz), но я не думаю, что вы должны выделять на конкретные спринты - вы не знаете, что будет в отставании к тому времени, когда вы туда доберетесь. Все, что вы знаете, это то, что это изменится, так зачем тратить на это время?

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

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

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

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

• Как мы используем JIRA и слияние
• Atlassian Agile процесс Часть 1
• Atlassian Agile процесс часть 2
• Atlassian Agile процесс Часть 3
• Atlassian Agile процесс Часть 4

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

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

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

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

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

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

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

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

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

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