ConversationalStories
Перевод статьи Мартина Фаулера ConversationalStories
Существует общее неправильное представление о гибкой методологии разработки ПО (agile method). Она основывается на user stories (набор требований), которые появляются в течение разработки. Неправильное представление заключается в том, что владелец ПО создает user stories и затем ставит их перед разработчиками. Идея в том, что поток задач от владельца ПО на разработку указывает на связь между владельцем ПО, ответственного за определение того, ЧТО должно быть сделано и разработчиков, которые отвечают за то, КАК это выполнить.
Оправдание этого подхода – это разделение ответственности в зависимости от компетентности. Владелец знает для чего нужно ПО, соответственно и ЧТО необходимо сделать. Разработчики знают технологии и КАК сделать, таким образом, они представляют, как реализовать требования владельца.
Эта идея пришла от DecreedStories и является глубоким и неправильным пониманием способа гибкой разработки. Когда подбирали имена на Snowbird, я помню, Кент предлагал «диалоговый (разговорный)». Это подчеркивало, что центром наших размышлений было общение между клиентами и разработчиками о том, как должна протекать разработка ПО.
Что касается user stories, то они постоянно изменяются в течение разработки и разработчики должны принимать активное участие в помощи их определения.
- Определять несоответствия и расхождения между stories;
- Используя технические знания, придумывать новые stories, соответствующие видению о проекте владельца ПО;
- Рассматривать альтернативные stories, которые дешевле сделать;
- Разделять stories, чтобы сделать их проще для проектирования или выполнения.
Любой член команды, занимающейся гибкой разработкой может создавать stories и предлагать изменения. Может так получиться, что только немногие члены команды стремятся написать большинство stories. Это указывает на самоорганизацию команды. Но каждый должен быть заинтересован в появлении и улучшении stories (это условие – дополнительная обязанность разработчикам к оценке stories).
Владелец ПО не имеет особенных обязательств. В конечном счете, владелец задает приоритеты stories. Это отражает тот факт, что владелец должен быть главной персоной, который может сопоставить этот скользкий атрибут (приоритет) с бизнес значимостью. Но имея конечное решение, владелец не должен останавливать других в соучастии и давать заблуждаться в понимании stories.
P.S. От автора. Из-за боязни, что в дальнейшем, в ру-сообществе приживутся неправильные толкования слов, некоторые выражения и слова остались без перевода (в скобках для таких слов указано значение по мнению автора).
Recent Comments