Принципы быстрой разработки ПО - Пользовательские истории

E-mail Печать PDF
Рейтинг пользователей: / 0
ХудшийЛучший 
Индекс материала
Принципы быстрой разработки ПО
Экстремальное программирование
Игра в планирование (Planning Game)
Пользовательские истории
«Билль о правах» заказчика
«Билль о правах» программиста
Притча
xUnit
Приемочные тесты
План рабочего цикла
План выпуска версий
Все страницы

Пользовательские истории

Для того чтобы приступить к планированию проекта, необходимо иметь общее представление о требованиях, предъявляемых к конечному результату работы, но совсем не обязательно заранее вдаваться в детали. Достаточно четко представлять себе все необходимые условия. Об отдельных деталях на данном этапе можно знать только то, что они существуют.

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

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

Таким образом, связь с пользователями осуществляется путем проведения бесед, посвященных различным аспектам разработки программного продукта.

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

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

Команда разработчиков:

·                    формирует оценку времени, которое предположительно потребуется для того, чтобы реализовать каждое из пожеланий;

·                    оценивает затраты, связанные с выбором той или иной технологии, на основе которой будет выполняться реализация;

·                    распределяет задачи между членами команды;

·                    оценивает риск, связанный с реализацией каждого из пожеланий;

·                    определяет порядок, в котором будут реализованы пожелания, являющиеся частью текущей итерации (если рискованные пожелания реализовать в первую очередь, можно снизить общий риск).

Заказчик:

·                    определяет объем работ (Scope), то есть набор пожеланий для выпуска (release) и набор пожеланий для итерации (iteration);

·                    определяет дату завершения работы над выпуском (release);

·                    назначает приоритеты (priorities), то есть, исходя из полезности различных функций с точки зрения бизнеса, определяет, какие из функций продукта должны быть реализованы в первую очередь.

Планирование должно выполняться достаточно часто. Благодаря этому и заказчик, и разработчики могут своевременно изменить план в случае, если в силу вступают новые непредвиденные обстоятельства.

Чтобы проект увенчался успехом, процесс разработки должен гарантировать заказчикам и программистам определенные неотчуждаемые права.



 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры