Требования, спецификации и управление в гибкой среде
Моя компания пыталась принять методологию скрама с переменным успехом. Тезисы - это области, в которых у нас были проблемы. Как вы справляетесь с этим?
- Отслеживание требований от маркетинга до продукта. Мы пытаемся JIRA отследить все требования индивидуально и назначить релиз для каждого, как он выбран для реализации.
- Кто создает истории? Менеджер по продукту, который не знает достаточно, чтобы эффективно создавать небольшие истории, разработчики, которые могут не иметь знаний в предметной области, аналитик между ними?
- Функциональные характеристики
- Вы пишете их или просто пытаетесь включить их в определение истории?
- Вы пишете функциональные спецификации для каждой истории? По функции?
- Как вы видите связь между функциональными характеристиками и историями?
- отвечая на вопрос от людей с VP в их названии "что мы собираемся получить [через 8 месяцев]?"
5 ответов
Давайте посмотрим, добавляет ли мой дубль что-либо (не совсем точно...)
Я не уверен насчет "назначения релиза каждому". Я думал, что идея заключалась в том, чтобы установить "цену" на каждую историю / функциональную точку / единицу разработки и выбрать то, что входит в текущий спринт. Все остальное - отставание - вы можете предложить некоторое указание на оставшиеся усилия (см. Планирование на основе фактических данных в FogBugz), но я не думаю, что вам следует выделять определенные спринты - вы не знаете, что будет в отставании к тому времени Вы получите там, с одной стороны. Все, что вы знаете, это то, что это изменится, так зачем тратить на это время?
Должен быть назначенный представитель пользователя. Или более одного, если знание предметной области не может быть сконцентрировано в одном человеке. Но кто-то из бизнес-сферы должен нести ответственность за принятие решения о спринте, конечно, при условии, что он приложит все усилия. Может быть место для типа бизнес-аналитика, но они должны быть экспертами в предметной области. Если ваши пользователи не могут писать истории, даже с вашей помощью (это совместная работа или должна быть), вам всем нужна помощь. Подумайте о привлечении тренера для спринта или двух.
Вы не будете писать функциональные спецификации в Agile-среде. Вы будете писать код. Ваш пользователь будет всегда под рукой (или вы уже подвержены значительному риску), и это ваша спецификация. История рассказывает вам "что", и это будет достаточно маленькая единица работы, чтобы вы могли довольно быстро определиться с "как". И рефакторинг. Всегда рефакторинг. Это не накладные расходы, это часть процесса, и ваш дизайн не будет развиваться удовлетворительно без него.
Если у вас есть вице-президенты (эй, я вице-президент, мы не все плохие!), Которые задают такой вопрос, то часть вашей компании еще не получила его. Выберите кого-то (человек, который лучше всего может иметь дело с нетехниками, возможно, или, возможно, человек, который менее всего способен, так как им явно нужна практика), чтобы объяснить им это. Если то, что построено, важно для них, возможно, их вопросы являются показателем того, что кто-то не так вовлечен, как следовало бы.
Немного информации о том, как Atlassian (создатели JIRA) используют свои продукты для гибкой разработки:
Что касается функциональных спецификаций - у сайта Скотта Амблера "Agile Modeling" есть несколько хороших образцов. Там также много кратких, прагматичных советов по гибким требованиям в целом.
Стоит посмотреть!
Вы должны перевести свои требования в Журнал ожидания продукта. Этот журнал используется для определения того, какие элементы журнала Sprint будут выбраны для каждой итерации Sprint. Руководство решает, что входит в Журнал ожидания продукта, но команда должна согласиться с тем, что они могут произвести в Спринте (это согласование, которое происходит на каждом спринте).
Ваш владелец продукта (обычно менеджер по продукту) руководит созданием историй. Истории просты (как системный администратор, я должен иметь возможность добавить пользователя). Если ваш продукт не понимает ваш продукт, у вас проблемы.
Agile - это проектирование по мере необходимости. Дизайн никогда не в истории. Спецификация может быть за историю или за функцию. Вы можете создать все свои CRUD внутри одной спецификации, которая охватывает несколько историй.
Владелец продукта получает демонстрацию продукта в конце каждого спринта. Таким образом, ценность демонстрируется на каждом цикле. Таким образом, ваш вице-президент будет получать отчеты ежемесячно (обычно 3 недели разработки + 1 неделя для подготовки к демонстрации Sprint).
Если вы собираетесь что-то делать в отношении написания или разработки кода, одна из вещей, которые вы всегда должны делать, - это написать спецификацию, независимо от используемой вами методологии, будь то Scrum, XP, Agile или SDLC. Многие люди, которые говорят, что написание спецификаций является настолько неуклюжим и памятником расточительной бюрократической бумажной работы. Простой факт заключается в том, что они вводят в заблуждение, когда говорят, что код - это спецификация.
Очевидный факт заключается в том, что спецификация позволяет заранее сформулировать свои идеи и проекты, и изменить спецификацию гораздо проще, чем изменить программу, особенно если вы работаете за пределами простого LOB-приложения. Спецификации гарантируют, что у вас есть более четкое понимание того, что требуется, когда вы начинаете кодировать.
Снова и снова было показано, что команды, использующие спецификации, разрабатывают лучшее программное обеспечение. По моему мнению, если вы слышите, что кто-то говорит, что код - это спецификация, то есть догма, простая и понятная, и она накапливает огромные проблемы с поддержкой в будущем.
Кроме того, я не имею ничего против Agile Manifesto или методов, ориентированных на легкий процесс управления, таких как Scrum. Я использовал это в последние несколько лет несколько раз, и это доставляет. Я также видел хорошее программное обеспечение, где бы ловкий фокус спас его. Но это не панацея или серебряная пуля.