Цитаты из книги «Гибкое управление IT-проектами. Руководство для настоящих самураев»

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

Простая истина заключается в том, что точные заблаговременные оценки невозможны,

Пользовательские истории имеют смысл для бизнеса. Вот почему мы всегда пытаемся формулировать их просто, чтобы пользователь все понимал и не углублялся в технические дебри. Это не означает, что при создании наших систем мы не можем использовать объединенное подключение или образцы проектирования. Это означает, что такие детали нужно излагать словами, понятными клиенту. Вторая характеристика по-настоящему хорошей пользовательской истории заключается в том, что она описывает систему на всех уровнях, так сказать, «прорезает программу по всей толщине». Большинству сладкоежек не понравится, если от торта им достанется только бисквит, без крема. Так и клиенту не хочется получать всего половину или треть решения. Вот почему хорошая пользовательская история является комплексной, затрагивает все уровни архитектуры приложения и действительно имеет ценность. Кроме того, хорошие пользовательские истории имеют следующие характеристики: При реализации проектов обстановка меняется. То, что на прошлой неделе казалось очень важным, на этой неделе становится второстепенным. Если все пользовательские истории тесно взаимосвязаны и зависят друг от друга, компромиссы становятся довольно сложным делом. Такое разделение не всегда удается (прежде чем создавать отчеты, нужно написать программу), но послойное препарирование историй и собирание пожеланий по конкретной функции позволяет считать абсолютное большинство историй независимыми и при необходимости корректировать функционал приложения. Любую отдельно взятую историю всегда можно реализовать несколькими способами. Мы можем выполнить любую возможность в версиях, условно соответствующих «Форду-Фокус», «Хонде-Аккорд» и «Порше-911». Истории, которые клиент готов обсуждать, хороши потому, что предоставляют нам поле для маневра, которое иногда очень требуется, чтобы уложиться в бюджет. Иногда обязательно нужен «Порше». В других случаях можно обойтись более непритязательным «Фордом». Хорошо, если пользовательские истории поддаются тестированию (в противном случае их называют нетестируемыми (detestable)). Ведь мы должны знать, когда функция работает, а когда – нет. При написании тестов на основании пользовательских пожеланий мы даем ориентиры нашей команде разработчиков и помогаем понять, когда определенная функция готова. И, если говорить о готовых функциях, как гарантировать, что конкретную историю удастся реализовать за отведенное нам время? Чтобы сроки соблюдались, истории должны быть краткими (каждая – не более чем на пять дней работы). Так с ними будет легко работать в течение недельных или двухнедельных итераций, и наши оценки будут более уверенными.

Первый полезный элемент пользовательской истории – ее суть. Что считать полезным? То, за что клиент готов заплатить.

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

«Разработка ПО пошла в ложном направлении из-за слова “требование”. Требование – это нечто обязательное. Слово имеет коннотацию абсолютности и незыблемости, а это мешает учитывать изменения. И слово “требование” просто совершенно неверное». «Из тысяч страниц, на которых описываются требования, можно выбрать 5, 10 или 20 % полезной информации, которая позволит понять всю практическую пользу, которую должна обеспечивать система.

Так с ними будет легко работать в течение недельных или двухнедельных итераций, и наши оценки будут более уверенными. Билл Уэйк придумал удобную аббревиатуру INVEST (Independent, Negotiable, Valuable, Estimatable, Small and Testable – независимые, доступные для обсуждения, ценные, поддающиеся оценке, небольшие и удобные для тестирования).

если говорить о готовых функциях, как гарантировать, что конкретную историю удастся реализовать за отведенное нам время

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

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