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

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

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

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

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

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

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

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

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

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