Как я управляю спецификациями в Толпе? [закрытый]
5 ответов
Короткий ответ: нет.
Важный вопрос, который следует задать себе при написании этих спецификаций: зачем мы их делаем? Какова ценность спецификации?
Ценность спецификации обычно заключается в передаче идей бизнеса команде разработчиков. Scrum предназначен для того, чтобы довести бизнес (в форме Владельца продукта) до команды разработчиков.Часто взаимодействуя с командой (помните, что отдельные люди и взаимодействие важнее процессов и инструментов) и часто наблюдая за работающим программным обеспечением, бизнес может работать рука об руку с разработчиками над созданием программного обеспечения, которое решает бизнес-задачи лучше, чем попытки описать все в целом. вещь, прежде чем вы попробуете это.
Таким образом Agile-проекты лучше справляются с поставкой продукта, который нужен бизнесу, а не продукта, который они запрашивали.
Тем не менее, существуют определенные базовые критерии, которым необходимо соответствовать. Мы можем проверить это, и, как и любые хорошие тесты, мы можем автоматизировать это.
Посмотрите на BDD и Cucumber . В дополнение к вашей пользовательской истории хорошо иметь базовый набор условий удовлетворения, желательно в формате «Дать / Когда / Тогда». Эти условия представляют собой минимальный набор критериев для того, чтобы история была принята как законченная.
Например, «Если я вошел в систему, при выходе из системы я возвращаюсь на главную страницу».
Если у вас есть критерии приемки, вы захотите их автоматизировать. Хуже всего то, что большинство спецификаций часто устаревают и собирают пыль после завершения проекта.
Кроме того, вы не должны назначать задачи команде. Скрам-команды являются самоорганизующимися, и каждый должен иметь возможность браться за любую задачу, над которой, по его мнению, он может работать, при этом соблюдая приоритет историй. Swarming - большая часть преимуществ Scrum в плане производительности.
Возможно, вам стоит подумать о привлечении внешнего тренера, который поможет вам в переходе.
Я думаю, что самый простой способ - сделать спецификации частью пользовательских историй внутри самих задач. Четко перечислите критерии приемки в каждом из них (или, если ваше программное обеспечение для отслеживания проблем позволяет, создайте их как первоклассные типы рабочих элементов). Пусть проблема в том, что вы используете для отслеживания рабочего элемента, станет живым документом.
Есть недостатки, такие как обнаружение связанных проблем, поскольку спецификации меняются с течением времени, но обычно этим можно управлять с помощью инструментов отслеживания рабочих элементов, если вы можете связать проблемы друг с другом.
То, как мы это делаем, заключается в том, что мы (на самом деле BA, а не разработчики) создаем «колоду подтверждения», которую владелец продукта может просмотреть, и на ее основе совместно создаем задачи. Если мы не можем создать задачу или есть открытые вопросы, мы вернемся к владельцу продукта с этими вопросами и обновим колоду. Все наши колоды организованы (в SharePoint), чтобы мы могли легко найти их в будущем.
Для меня спецификации находятся в пользовательских историях. Мы определяем спецификации и задачи на первом совещании вместе с владельцем продукта. Спецификации и задачи предназначены только для срока службы итерации схватки, так как все может измениться в следующей итерации (в худшем случае, но обязательно будут изменения).
Обычно мы отслеживаем спецификации и задачи в электронной таблице, чтобы все знали, над чем они работают. Я также пробовал несколько программ для этого, и одно из самых интересных, с которыми я столкнулся, - от [VersionOne] [1], а также от [Rally] [2].
Но я по-прежнему считаю, что использование простой электронной таблицы - самое быстрое и простое решение.
Существует реальное противоречие между Scrum и другими методологиями гибкой разработки и написанием спецификаций. Я думаю, есть два серьезных момента, вызывающих напряжение:
Потому что Agile говорит, что все должно быть на учётной карточке, это означает, что вы нужно что-то спланировать Достаточно, чтобы поместилось на учётной карточке. (Например, вы должны знать, как это все собирается работать.)
Некоторые вещи не имеют смысла в изоляция (какая польза от страница загрузки файла без управления Страница загруженных файлов, например.)
Вам не нужно разрабатывать все приложение сразу, но вы должны иметь видение всего приложения. Затем, особенно если у вас есть разделение на дизайнеров и программистов, вы выполняете функциональный дизайн для фрагментов размером со спринт. Затем эти проекты нужно разбить на куски размером с историю.
Это предварительный функциональный дизайн, и я думаю, что это упускается из виду в разговорах о гибких методологиях. Возможно, в некоторых магазинах разработчики больше занимаются дизайном. Кроме того, я думаю, что гораздо проще использовать scrum / agile для внесения изменений / исправлений ошибок в существующие приложения, а не для создания новых.
Самое полезное, что я нашел, - это дать отпор размеру сюжета. Многие организации сошли с ума, заявив, что рассказы должны длиться всего несколько часов. В оригинальной книге схваток сказано, что 16 часов, я думаю, часто бывает достаточно, чтобы уместить весь экран веб-приложения.Таким образом, «реализовать управление моей учетной записью» может быть рассказом (в отличие от подхода, состоящего из сотен крошечных историй «реализовать имя пользователя», «ввести пароль» и т. Д.). Затем обратитесь к своему проектному документу для «Управление моей учетной записью» и сделайте обязательно иметь точные скриншоты / прототипы / макеты, чтобы разработчик мог посмотреть на них и скопировать / вставить текст прямо в код, который они пишут, и они точно знают, какие поля должны быть там (или какие ссылки, или какие картинки или что-то еще).
Насколько я понимаю, SCRUM не заботится об управлении спецификациями. Вы должны сломать / сопоставить свои спецификации или изменения спецификаций с историями и задачами отдельно. Но на это можно поставить задачу :).