и создать качественную дорожную карту (Roadmap). (См. раздел «Дорожные карты» главы 10.)
Как добиться успеха, используя водопадную модель
Agile подходит далеко не для каждой компании. И это нормально! Можно добиться успеха, используя водопадную модель. Если вы в компании, которой нужны предварительные планы или культура которой – «командуй и контролируй», то водопадная модель может быть более уместной.
Наиболее безопасно использовать итеративный водопад. Вместо того чтобы реализовывать один большой водопадный проект, что довольно рискованно, начните серию небольших водопадных проектов. Каждый должен длиться не больше 3–6 месяцев и завершаться работающим программным обеспечением, действительно пригодным для выхода на рынок. Каждый проект должен содержать стандартные фазы водопада: анализ требований, архитектура и дизайн, реализация, тестирование – или тот вариант фаз, который предпочитает ваша компания.
Водопадная модель работает наилучшим образом в хорошо изученных предметных областях при наличии небольшой неопределенности. Постарайтесь взять на работу людей, весьма опытных в создании именно того типа программного обеспечения, который вы собираетесь реализовывать.
Другую предварительную документацию, такую как анализ требований или проектная документция, также можно подготовить с помощью действующих подходов до начала выполнения Agile-части вашей работы. Оставшуюся часть работы, которую необходимо выполнять для того, чтобы ваш рабочий процесс соответствовал водопадному подходу, можно распределить параллельно Agile-работе вместе с пользовательскими историями (см. раздел «Истории» главы 8), как и любые другие запросы.
Водопадный стиль управления несовместим со свободным владением навыками на уровне оптимизации, который основан на адаптивном планировании. Если от вас требуется соответствие водопадным политикам управления, ограничьтесь уровнями фокусировки и поставки.
Измените вредные HR-политики
Agile – это командный спорт, и несмотря на то, что на словах командная работа поддерживается, многие компании имеют политики, непреднамеренно сдерживающие ее. Любая политика, поощряющая людей конкурировать друг с другом, затруднит работу по Agile. Особенно деструктивный пример – таблицы ранжирования, где члены команды оцениваются методом сравнения друг с другом. Люди, оказывающиеся на верхушке таблицы, получают повышение, а тех, кто «на дне», увольняют независимо от их реальной производительности.
Похожий случай – руководители, которые ценят только материальный результат. В Agile-команде есть много способов внести свой вклад в успех. Примером может служить человек, который непосредственно не пишет код, но проводит много времени, воспроизводя баги, или человек, который работает «за сценой» над улучшением коммуникации.
Во многих организациях также развита культура вины, при которой на ошибки реагируют путем наказания виновных. В мировоззрении Agile,
