Что вы тут понаделали?

Когда вы ведете разработку в стиле Agile или XP, это означает, что через пару итераций (3-4 недели), систему которую вы продолжаете разрабатывать, уже вовсю используют. К сожалению так бывает далеко не всегда. Владельца системы обычно пугает тот факт, что еще недоделанная система будет использоваться его сотрудниками в реальных условиях. А если это финансовая система? А если это business critical приложение? Часто разработчиков даже близко не подпускают к их системе в production. На одном из моих проектов только выкладка в production занимала две недели. И тем не менее заказчик хочет Agile и разработчики готовы его изобразить.
Обычно все сводится к тому, что раз в две недели владелец системы приходит к разработчикам (на Scrum или еще как), и те демонстрируют ему свои достижения. Кусок работы считается сделанным после того, как его показали заказчику. Далее составляется план на следующие две недели (в виде набора user story или еще как) и работа кипит дальше.
Вот все это называется нехорошим словом "суррогат", а вовсе не agile. В конце концов, когда дело подходит к сдаче проекта, выясняется, что система сырая и буквально разваливается на глазах, баги сыпятся из всех щелей, а часть задекларированного функционала не сделана вовсе. Сроки проекта съезжают на пару месяцев. Если проект выполнялся по фиксированному бюджету, то матерятся разработчики, потому как работают за даром. А если оплата идет по времени, то уже заказчик проклинает весь этот agile, потому как мало того что ему сроки прослайдили, так и платить за это безобразие должен он сам.
Отстутствие работающей системы разрушает систему agile процесса не хуже чем отсутствие нормальных коммуникаций с заказчиком. При выкладке новой версии в production о любом новом баге становится известно максимум на следующий день, и способы, которыми пользователи системы доносят эти не благие вести до разработчиков очень хорошо дисциплинируют последних. В отсутствии работающей системы демонстрация результатов итерации заказчику превращается в необременительное шоу, - "показываем то, что работает, что не работает - про то рассказываем (ничего, в понедельник доделаем)".
Что же делать в таких случаях? Вспомнить о гибкости agile. Вот несколько советов:

• Обязательно ведите и храните требования. В виде user story, use case, карточек. В backlog-е или на бумаге - не важно. Важно чтобы они были. Обычно работающая система и есть воплощение требований, но у вас нет работающей системы.


• Введите практику формальной приемки user story заказчиком или владельцем системы. Это подразумевается и в XP и в других agile методиках, но об этом часто забывают. Без приемки карточка не может считаться выполненной. Это можно организовать либо настройкой workflow в backlog-е системы, при котором работы закрывает только заказчик, либо отметками на карточках, если они ведутся на бумаге.


• Никогда не изменяйте уже оформленные требования. Они могут быть реализованы или не реализованы. Если они не реализованы они могут быть вообще выброшены, если от них откажется заказчик. Часто бывает что требование уже реализовано и только тут заказчик понимает, что надо что то доделать или сделать по другому. Прекрасно, никаких проблем, но это должно быть оформлено в виде нового требования.


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