Ваше определение Толпы [закрытых] Сделанных
5 ответов
Я сказал бы, что это до Вашей команды для решения. Разговор с владельцем продукта. Идеально сделанный был бы, когда история работает и быть используемым. Однако существует разрыв времени между тем, когда история является завершенной разработкой и в Живом. Сложно отслеживать, сколько времени история взяла для разработки.
В моей команде, наше определение сделанных, когда разработчик завершает историю, и делает "шоу и говорит" остальной части команды (тестеры, владелец продукта), и если все рады, что это входит в соединительную линию подрывной деятельности.
Дальнейшее тестирование сделано от автоматизированной сборки от соединительной линии.
Мы в TargetProcess используем следующее определение Сделанных для пользовательской истории:
- Короткая Спецификация создала
- Реализованный/Модульные тесты созданный
- , Приемочные испытания создали
- , 100% Приемочных испытаний передали
- Владелец продукта, которого демонстрация передала
- , Известные ошибки зафиксировали
В идеальном мире продукт должен быть в shippable состоянии в конце каждого повторения.
Теперь это на самом деле зависит от Вашего продукта, Вашего рынка, Ваших клиентов и не могло бы быть возможно.
, Если Вы не можете достигнуть этого, тогда следующий горизонт планирования применяется: выпуск. Команда в целом должна решить то, что требуется, чтобы поставлять продукт и план соответственно.
то, Что помогает здесь, должно определить "сделанный" на уровне задачи. Определение, сделанное здесь, намного более просто: одна задача сделана, когда можно запустить другой: все тестируется, интегрируется. Команда может alo определять это состояние: зарегистрированный, рассмотренный, включенный в автоматическую сборку, никакую известную проблему, принят Локальным Клиентом...
Наличие всех Ваших задач, действительно "сделанных", Имея все туристические неудовлетворенные объекты (или Пользовательские истории, whateveryou называют их) действительно "сделанный", позволяют быть "сделанным" при каждом повторении, которое помогает сохранению продукта в shippable или развертываемом состоянии.
Существует три хороших статьи Mitch Lacey , Dhaval Panchal и Mayank Gupta на этом на веб-сайте ScrumAlliance.
<час>РЕДАКТИРОВАНИЕ: В основном самое главное - то, что сделанный определяется на основе проекта проектом командой . Главная потребность состоит в том, чтобы договориться об определении, не, каково определение.
Все, что сделает ваш "период стабилизации" (т.е. работу, необходимую между замораживанием кода и релизом клиенту) короче.