среда, марта 26, 2008

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

Когда вы ведете разработку в стиле 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. Обнаруженные баги следует оформлять в виде новых историй, а не возвращать на переработку старые.

8 комментариев:

Анонимный комментирует...

> При выкладке новой версии в production о любом новом баге становится известно максимум на следующий день...

Это получается что пользователи системы выполняют работу тестеров. Им за это платят?

Sergey Rozovik комментирует...

> Это получается что пользователи системы выполняют работу тестеров.

Да, это так. Это плата за agility? за то что пользователь может получить нужную ему фичу уже через пару дней в работающем виде. Обычно пользователи согласны на это.
Я не знаю систем, в которых не обнаружилось ни одного бага после выхода в production. Поэтому пользователи всегда выполняют роль тестировщиков, и в последнее время все больше и больше. Microsoft, например, выпускает Community Technology Preview (CTP) версии своих продуктов, и энтузиасты с радостью набрасываются на них в поисках новых фич и новых багов :)

Livce комментирует...

Если требования не хранятся, то не поможет не Agile, не RUP, не СуперМегаПлюсПлюсТурбо методология. Просто напросто не о чем спорить с заказчиком, если ничего нет.

Sergey Rozovik комментирует...

to Livce
Если система работает и к ней нет претензий, то и поводов для споров с заказчиком не возникает, и про требования не вспоминают :)

Анонимный комментирует...

>Да, это так. Это плата за agility? за то что пользователь может получить нужную ему фичу уже через пару дней в работающем виде.

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

Sergey Rozovik комментирует...

> должен быть член группы, который отстаивает интересы заказчика. Который не позволит "ах, эта фича не получается, ну и фиг с ней"

У нас этот человек называется PM :)

Анонимный комментирует...

PM часто говорит "ладно, черт с ним, постораюсь убедить заказчика что ему эта фича не нужна" :)

sse комментирует...

Весьма желательно так же список требований оформлять в виде тренда от времени, т.е. регистрировать не только требования, но и прогресс по ним. Иначе "зоказчег" начинает волновацца :)