Пользовательские истории. Искусство гибкой разработки ПО

Это снова мой друг Шериф из Atlassian. На этой фотографии он объясняет мне, что члены команды разработки продукта постоянно собирают и обрабатывают множество мелких улучшений. Они очень волнуются за своих пользователей. Они знают, что стаи мелких багов и неполадок бесят пользователей, и этот факт бесит саму команду. По их словам, это примерно как умереть, «тысячу раз поранившись бумажным листом». Поэтому на стене, рядом с которой команда работает над продуктом Green Hopper, много сгруппированных пометок. Каждый раз, когда какой-нибудь член команды исправляет какой-то мелкий недостаток, он или она делает пометку на стене. Похоже, что в следующем релизе будут исправлены 47 мелких неполадок. Если вы пользуетесь JIRA или Confluence, чуть позже вы можете сказать ребятам спасибо.

Глава 18. Извлекайте уроки из всех своих разработок

Если вы приверженец традиционного подхода к разработке программного обеспечения, то, наверное, думаете, что работа закончена, когда приложение готово. Но разработка Agile и истории предназначены для обучения. Перед тем как приступить к написанию кода, мы тратим много времени на то, чтобы убедиться, стоит ли вообще что-то разрабатывать, и если да, то что именно. А после того, как работа закончена, мы оцениваем полученный результат и спрашиваем себя, стоило ли это создавать и насколько хорошо у нас вышло.

Давайте поговорим о возможностях для обучения, которые предоставляются нам после окончания разработки.

Оцените свою командную работу

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

После того как вы все поздравили друг друга, всем вместе нужно сесть и честно оценить то, чего удалось достичь. Если вы честны с самими собой, то, скорее всего, найдете кое-что, что стоило бы сделать иначе. Нужно для каждой такой шероховатости написать отдельную историю и добавить ее в релизный бэклог. Затем надо решить, нужно ли вносить эти изменения немедленно или можно отложить их на какое-то время и обработать в порядке очередности.

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

Команде, которая тесно сотрудничала, проводила самые детальные обсуждения, приходила к соглашениям о сути создаваемого продукта и работала над его реализацией, необходимо время и спокойное место, чтобы открыто обсудить свою работу. Мнение людей, не входящих в команду, включая руководство организации, очень важно, и, конечно, команда должна его услышать. Но все-таки эти люди не присутствовали на обсуждениях, где было выработано одинаковое понимание деталей создаваемого продукта. Они не участвовали в обсуждениях, во время которых составлялся детальный план разработки. И наконец, они не работали вместе с командой над воплощением всех этих соглашений и дискуссий в работающее программное приложение. Итак, сначала мы должны оценить, удалось ли нам построить то, что мы себе представляли, с тем уровнем качества, на который мы надеялись. Для этого и нужны такие мероприятия, как командное осмысление и оценка продукта.

Рецепт командного осмысления и оценки продукта

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