В этой заметке поговорим про практические советы для User Stories (US). Говорить о них можно много, поэтому в несколько подходов. Для старта такие:
1) Вначале важно определиться с тем, чем для вас и команды US являются концептуально: это элемент бэклога (полезный инкремент продукта, или задача на разработку, если упрощенно) или элемент базы знаний (какая-то постоянная единичка, на которые попилен скоуп решения). В первом случае US как артефакт полезна до тех пор, пока не разработана и не принята. Для такой US всегда найдется место в бэклоге (списке того, что надо сделать) и применимо понятие Definition of Done (т. е. критерий того, что она утратила свою актуальность). Во втором же случае — это кусок спецификации требований, который вы поддерживаете в актуальном состоянии на протяжении всего проекта. Такую историю, когда придет время ее изменить/доработать/удалить, не запихнешь в бэклог и не оценишь как работу, т. к. это описание целевого кирпича, а не того, какое изменение в кирпичную стену надо внести. У каждого подхода есть плюсы и минусы (скорость и простота работы, но сложность в раскапывании того, как система работает в любой момент времени и восприятии полной картины решения VS ровно наоборот). Это решение определит в принципе вашу парадигму работы с документацией, а потому, дабы не делать заметку громоздкой, просто оставлю здесь видео, которым не раз уже делился: https://www.youtube.com/watch?v=qpwcE1rsBNg. Но если лениво смотреть, сигнальте, если хотите разбор обоих подходов.
2) Определитесь с форматом критериев приемки (т. е. требований) для US, чтобы подход был однообразным для читателей. Есть много разных вариантов:
- утверждения от лица персонажа истории
- Gherkin (Given-When-Then)
- своровать формат из Use Cases
- детально и подробно описать UI
- пишем, как пишется (т. е. в произвольном формате), комбинируем форматы и пр.
Выберите то, что по душе, и, как и с любыми иными артефактами, отразите от читателей (в первую очередь, от команды разработки) удобство и ценность. Любой формат хорош тогда, когда от него кайфуют получатели.
3) Лучше помнить про INVEST, чем не помнить. И вот он простым языком (при этом имеем в виду, что это = “в сферически идеальном вакууме US должна быть такой"):
Independent: US не зависит от других US. Это не всегда реализуемо. Но есть плохая зависимость, а есть та, с которой можно жить. Приемлемая зависимость (порядок поставки): Просмотр деталей заявки и Просмотр списка заявок (см. также ниже про Valuable). Без списка сложно выйти на Детали заявки, а потому порядок разработки тут едва ли избегаем — главное учесть подобное внутри бэклога и отразить зависимости между US в явном виде внутри них. Плохая зависимость, которой можно избежать (пересечение): Просмотр заявок для покупателя и Просмотр заявок для админа, если критерии приемки обеих подразумевают разработку списка с нуля. Лучше сделать так, чтобы первая история содержала разработку базового списка, а вторая добавляла новые элементы для админа (например, новые колонки в таблице). Но это подразумевает, что US у вас — это элемент бэклога (т. е. подход номер раз из пункта 1 выше).
Negotiable: не высекайте требования в камне в процессе написания. Т. е. в идеале а) не пишем сразу талмуд максимальной детализации, а учитываем наличие будущего инпута от команды: если у вас есть рефайнменты или иные события, где команда может дать фидбэк на требования, подготовьте требования в черновом варианте, чтобы быть открытыми к доработке, а не противодействовать тому, что команда поставила под сомнение пять страниц написанного вами текста; б) не навязывайте решения в тех областях, где не шарите — простой пример: если в команде есть тот, кто отвечает за проектировку UI, ваши требования (критерии приемки) должны быть максимально независимы от UI и не иметь никаких “кнопок” и “всплывающих окон” в тексте. Плюс не иметь там же всякие “базы данных”, “фронтенды” и прочие архитектурные моменты — по той же причине, что команда сама решит, как технически реализовать требования.
1) Вначале важно определиться с тем, чем для вас и команды US являются концептуально: это элемент бэклога (полезный инкремент продукта, или задача на разработку, если упрощенно) или элемент базы знаний (какая-то постоянная единичка, на которые попилен скоуп решения). В первом случае US как артефакт полезна до тех пор, пока не разработана и не принята. Для такой US всегда найдется место в бэклоге (списке того, что надо сделать) и применимо понятие Definition of Done (т. е. критерий того, что она утратила свою актуальность). Во втором же случае — это кусок спецификации требований, который вы поддерживаете в актуальном состоянии на протяжении всего проекта. Такую историю, когда придет время ее изменить/доработать/удалить, не запихнешь в бэклог и не оценишь как работу, т. к. это описание целевого кирпича, а не того, какое изменение в кирпичную стену надо внести. У каждого подхода есть плюсы и минусы (скорость и простота работы, но сложность в раскапывании того, как система работает в любой момент времени и восприятии полной картины решения VS ровно наоборот). Это решение определит в принципе вашу парадигму работы с документацией, а потому, дабы не делать заметку громоздкой, просто оставлю здесь видео, которым не раз уже делился: https://www.youtube.com/watch?v=qpwcE1rsBNg. Но если лениво смотреть, сигнальте, если хотите разбор обоих подходов.
2) Определитесь с форматом критериев приемки (т. е. требований) для US, чтобы подход был однообразным для читателей. Есть много разных вариантов:
- утверждения от лица персонажа истории
- Gherkin (Given-When-Then)
- своровать формат из Use Cases
- детально и подробно описать UI
- пишем, как пишется (т. е. в произвольном формате), комбинируем форматы и пр.
Выберите то, что по душе, и, как и с любыми иными артефактами, отразите от читателей (в первую очередь, от команды разработки) удобство и ценность. Любой формат хорош тогда, когда от него кайфуют получатели.
3) Лучше помнить про INVEST, чем не помнить. И вот он простым языком (при этом имеем в виду, что это = “в сферически идеальном вакууме US должна быть такой"):
Independent: US не зависит от других US. Это не всегда реализуемо. Но есть плохая зависимость, а есть та, с которой можно жить. Приемлемая зависимость (порядок поставки): Просмотр деталей заявки и Просмотр списка заявок (см. также ниже про Valuable). Без списка сложно выйти на Детали заявки, а потому порядок разработки тут едва ли избегаем — главное учесть подобное внутри бэклога и отразить зависимости между US в явном виде внутри них. Плохая зависимость, которой можно избежать (пересечение): Просмотр заявок для покупателя и Просмотр заявок для админа, если критерии приемки обеих подразумевают разработку списка с нуля. Лучше сделать так, чтобы первая история содержала разработку базового списка, а вторая добавляла новые элементы для админа (например, новые колонки в таблице). Но это подразумевает, что US у вас — это элемент бэклога (т. е. подход номер раз из пункта 1 выше).
Negotiable: не высекайте требования в камне в процессе написания. Т. е. в идеале а) не пишем сразу талмуд максимальной детализации, а учитываем наличие будущего инпута от команды: если у вас есть рефайнменты или иные события, где команда может дать фидбэк на требования, подготовьте требования в черновом варианте, чтобы быть открытыми к доработке, а не противодействовать тому, что команда поставила под сомнение пять страниц написанного вами текста; б) не навязывайте решения в тех областях, где не шарите — простой пример: если в команде есть тот, кто отвечает за проектировку UI, ваши требования (критерии приемки) должны быть максимально независимы от UI и не иметь никаких “кнопок” и “всплывающих окон” в тексте. Плюс не иметь там же всякие “базы данных”, “фронтенды” и прочие архитектурные моменты — по той же причине, что команда сама решит, как технически реализовать требования.