Рецензия: User Stories Applied

Написано ещё в октябре 2021 года

У меня есть ощущение, что Agile исподволь превратился в свою противоположность: Agile/Scrum Industrial Complex со строгими, сложными, негибкими процессами, карго-культ.

Отчасти потому, что серьёзное изменение — это всегда сложно, и проще притвориться, что Мы, Компания, Делаем Аджайл, чем попытаться сделать его по-настоящему.

Отчасти же потому, что люди получают знания про методологии в пересказах пересказов, получается глухой телефон. На динамику компаний повлиять сложно, а вот с индивидуальной частью можно работать — поэтому мне интересно ознакомиться с ранними материалами, и поэтому я начал читать User Stories Applied.

До этой книги я подсознательно относился с опаской к user stories, потому что считал их просто недописанными задачами. В книге рассказывается, что они действительно не описывают важных нюансов, но это не баг, а фича — user story это напоминание поговорить с пользователями в процессе разработки. Нельзя взять карточку и пилить её в одиночестве, она намеренно underspecified.

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

С другой стороны, особенно если речь о новом продукте, где сложно получить доступ к живым пользователям, автор предлагает проводить Story Workshop — вся команда и менеджеры садятся брейнштормить Типы Пользователей и Истории, затем происходит объединение похожих Типов Пользователей. Отсюда возникает избитый формат As a User, I want to X, обыгрываемый в Твиттере: вместо User может стоять более точное определение.

Эти stories — не задачи в джире. Когда история попадает в итерацию, из неё выделяются задачи для разработчиков. Но при этом у самой истории есть критерии приёмки — acceptance tests, которые может провести заказчик.

Чтобы спрогнозировать, что мы успеем включить в релиз, нужно спланировать итерации (здесь автор проводит разницу между итеративной разработкой и инкрементальной разработкой: в итеративной мы можем вернуться и переделать кусок, в инкрементальной подразумевается, что законченный кусок закончен. На русском языке это известно как «метод прогрессивного джипега»). Для планирования нам понадобятся оценки, и тут рекомендуются сторипоинты. Сторипоинты автор для себя определяет как «день идеальной работы»: таких дней не бывает на практике, но это позволяют сравнивать истории между собой с целью расставить их по важности/ценности. Пользователь присутствует при оценке, но не оспаривает их, автор запрещает заметно удивляться, когда звучат высокие оценки. Зато он может просигнализировать, что конкретная фича не настолько необходима, если придется потратить месяц, но зато её можно переформулировать вот так, чтобы получить 80% выхлопа при 20% усилий, ну или отказаться вовсе.

И даже такие сугубо технические вещи как «настроить пул соединений к базе данных» предлагается формулировать в терминах пользы для клиентов внутри историй для планирования, возможно, как история-ограничение (например, «системой может пользоваться 50 человек одновременно»). Такая история получает оценку в 0 сторипоинтов, и она висит, чтобы все её видели и не забыли.

Отдельно отмечу, что автор зачастую описывает очень аналоговый процесс: команда и клиент пишут истории просто на карточках, не стесняясь порвать бумажку, если её заменяют другой, в особенности, когда история закончена; задачи он выписывает на маркерную доску; клиент сидит где-то рядом с командой и постоянно доступен для общения.

Когда же обстоятельства вынуждают команду работать удалённо (от заказчика; варианта распределенной работы всех не прослеживается в тексте), то тогда можно и компьютеризировать. Но тогда особенно важно не подменить невзначай необходимые разговоры джирой.

Чтобы такая конструкция хорошо работала, необходимы одновременно high-trust environment (мы не описываем полностью что нужно сделать, доверяя, что разработчики и пользователи будут общаться и сделают правильно) и вовлечённые разработчики. Иными словами, хорошие люди могут работать хорошо при любых процессах, плохим людям процессы не помогут; так зачем перегружать хороших людей тяжелыми процессами.