Recommended
Recommended
More Related Content
Similar to Lean Requirements с помощью Confluence product requirements blueprint
Similar to Lean Requirements с помощью Confluence product requirements blueprint (20)
Lean Requirements с помощью Confluence product requirements blueprint
- 1. Lean Requirements Как избавиться от спецификаций с помощью Confluence product requirements blueprint
- 2. Французский стартап с офисом разработки в Минске. Компания занимается разработкой технологии для анализа движений спортсменов, в основе которой лежит машинное обучение.
- 3. Стартапы Ограничены во времени Ограничены в ресурсах Имеют большой риск провала
- 4. Спецификации • Требуют много времени
- 5. Спецификации • Требуют много времени • Не обновляются
- 6. Спецификации • Требуют много времени • Не обновляются • Плохо читаются
- 7. Спецификации • Требуют много времени • Не обновляются • Плохо читаются • Неудобная навигация
- 8. Спецификации • Требуют много времени • Не обновляются • Плохо читаются • Неудобная навигация • Недостаточны
- 9. Спецификации • Требуют много времени • Не обновляются • Плохо читаются • Неудобная навигация • Недостаточны • Избыточны
- 10. Спецификации • Требуют много времени • Не обновляются • Плохо читаются • Неудобная навигация • Недостаточны • Избыточны • НеValue-Centric
- 11. Спецификации • Требуют много времени • Не обновляются • Плохо читаются • Неудобная навигация • Недостаточны • Избыточны • НеValue-Centric • Не способствуют написанию User Stories
- 12. Делаем требования Lean Определить необходимый минимум Найти или создать подходящий шаблон Научить PO и команду пользоваться шаблоном Наслаждаться «нормальными» требованиями
- 14. Определяем специфику проекта • Кто вовлечен? • Какой текущий статус? • Когда состоится релиз?
- 15. Цели и бэкграунд • Для чего мы это делаем? • Как это вписывается в общие цели компании?
- 16. Требования в виде User Stories Список User Stories с описанием, приоритетами и заметками.
- 18. Вопросы и «Что мы не делаем» • То, что нужно решить или исследовать • То, что не входит в цели
- 19. Требования в одну страницу
- 20. Преимущества и польза Одна страница – один источник Особая гибкость Необходимый минимум Синхронизация Коллективная работа Вложения
- 22. Александр Котляренко • Email: akotliarenko@octonion.com • LinkedIn: /in/akotliarenko • Skype: aleksandr.kotliarenko
Editor's Notes
- Оказывается, огромные, детальные спецификации не только не любят писать, но еще ими не любят пользоваться. Тема моего доклада Lean Requirements или Как избавиться от спецификаций с помощью Confluence product requirements blueprint. Несколько слов о Lean. Дословно переводится как бережливый. Концепция бережливого производства основана на постоянном стремлении к устранению всех видов потерь. Подробную информацию легко можно найти в интернете.
- Всем привет! Меня зовут Саша. Я работаю в компании PIQ scrum мастером. Немного о компании. PIQ – это французский стартап с офисом разработки в Минске. Компания занимается разработкой технологии для анализа движений спортсменов, в основе которой лежит машинное обучение. Мы выпустили на рынок спортивный трекер, поддерживающий несколько видов спорта и соответствующие мобильные приложения к нему. Сейчас мы занимаемся разработкой платформы, с помощью которой пользователи смогут обучить свои умные часы (Apple, Huawei, Samsung) анализировать любые движения для любого вида спорта. Мои контакты будут на последнем слайде. Также в конце доклада я буду рад ответить на ваши вопросы. Перейдем к самому докладу.
- Компании тратят до 60% дополнительного времени и бюджета, используя неверные подходы к написанию требований. И это недопустимо для стартапов, ограниченных во времени, ресурсах, и имеющих высокий риск провала. Поэтому для стартапов предпочтительно использовать Lean Requirements. Я хочу поделиться с вами опытом, как мы избавлялись от детальных спецификаций и делали требования бережливыми.
- Раньше мы использовали спецификации, которые писал наш PO, и сталкивались со следующими проблемами: Требуют много времени от PO. В результате спецификации не всегда была готова вовремя, или же PO приходилось писать ее заранее и без участия и помощи команды.
- Не всегда обновляются. Часто после обсуждения с командой, например, в Skype, требования менялись. Или дополнительные требования записывались в описание Story. Но эти изменения гне попадали в спецификацию.
- Плохо читаются. Команде неудобно работать с огромным текстом, информация плохо воспринимается. Иногда спецификация просто не читалась, что приводило к лишним обсуждениям в Skype или дополнительным вопросам и времени во время Grooming и Planning.
- Навигация. Со временем сложно найти нужную информацию, особенно если в задаче забыли указать ссылку на документ. Никак не приживалась какая-то общепринятая структура спецификаций.
- В спецификациях всегда недостаточно информации. PO не может покрыть все кейсы. Как бы подробна не была она написана, всегда остаются вопросы.
- В спецификациях всегда есть избыточная информация. Например, каким образом показывать ошибки в приложении, как попасть на какой-нибудь экран и т.д. Это связывает руки разработчикам и дизайнерам.
- Не Value-Centric. Тут имеется в виду, что наши спецификации как правило отвечали на вопрос «Как делать?», но не на вопросы «Для кого?» И «Зачем?» мы это делаем. Это ставило под сомнение User или Business Value этой задачи. Разработчики часто сомневались, что функционал будет полезен пользователю и сделает наше приложение лучше.
- Фокусируя все внимание на спецификации, PO перестал писал User Stories. Backlog наполнился задачами с непонятным описанием, неясным Business Value и ссылкой на спецификацию, которую сложно читать.
- Что же делать? Нельзя же было просто сказать PO «Пишите пожалуйста нормальные требования». Поэтому было решено: Определить необходимый минимум содержания документа, достаточный для понимания требований и их влияние на пользователя Найти или создать подходящий шаблон, удобный для работы не только PO, но и для всей команды Научить PO и команду пользоваться этим шаблоном. Например, я взял старый документ, переписал его по шаблону и на готовом примере показал, как это работает и какие имеет плюсы После того, как процесс приживется и адаптируется, наслаждаться «нормальными» требованиями :) К счастью, шаблон придумывать самому не пришлось, и готовый нашелся довольно быстро.
- Этим шаблоном стал Confluence product requirements blueprint. Он входит в стандартный набор шаблонов в Confluence. Сейчас я покажу, что он из себя представляет и как им пользоваться. В Space нашего проекта создаем новую страницу из шаблона. Выбираем Product requirements шаблон из списка и нажимаем Create.
- Начинаем заполнять документ. В первой секции определяем специфику проекта: Когда состоится релиз? Заносим версию или дату релиза Какой текущий статус? Сюда мы заносим статус документа: черновик, в разработке или финальный. Но можно заносить, например, статус готовности задачи или соответствующего релиза Кто вовлечен? Заносим членов команды, PO, возможно стейкхолдеров. Во-первых, таким образом легко найти, к кому обращаться, если возникают вопросы. Во-вторых, указаные люди получают уведомления об изменениях в документе. Ячейка для соответствующего Jira Epic. В эту ячейку можно просто скопировать ссылку из Jira. В ней отображается статус задачи, а также можно быстро перейти на нее в Jira.
- Цели и бэкграунд (или предыстория) В этой секции описываем «Для чего мы это делаем?» и «Как это вписывается в общие цели компании?». Т.е. по сути описываем User и Business Value. Это помогает разработчикам понять, каким образом лучше функционал реализовать, при этом не дает избыточного описания. Также эта секция – это отлично подходит для ссылки на другие страницы Confluence с дополнительной информацией. Например, такие как интервью с клиентами или Roadmap.
- Требования Секция представляет список User Stories с описанием, приоритетами и заметками. Сюда мы записываем также Acceptance criteria. Таким образом, для каждой большой задачи мы заводим Epic в Jira. Для каждого Epic мы создаем Product requirement документ, в котором описываем к нему требования и разбиваем на User Stories. Требования для каждой User Story описывается с помощью User voice и Acceptance criteria. Кстати, очень легко заводить User Stories в Jira прямо из этой таблицы. Просто выделите название Story, и появится опция сделать это.
- Интерфейс и дизайн В эту секцию вставляем макеты, прототипы или уже готовый дизайн. Файлы можно просто перетянуть с помощью drag-and-drop. Как известно, одна картинка может заменить сотни слов Также в этой секции, как и во всех других, можно оставлять комментарии.
- Вопросы и «Что мы не делаем» Такой формат документа, в котором нет детально описания функционала, способствует тесному общению между командой, PO и стейкхолдерами. У команды обычно возникает много вопросов, когда она приступает к реализации. Поэтому в шаблоне документа предусмотрена секция для этих вопросов и возможных решений. По этой таблице легко отслеживать, почему определенные решения были приняты. Также для команды важно держать фокус на актуальной работе, определив, что не входит в scope, что может быть отложено на потом.
- На этом документ заканчивается. В итоге мы получаем требования, содержащие весь необходимый минимум информации, ссылки на другие страницы или Jira для дополнительной информации и вмещающиеся на одну страницу. Это всего лишь пример, чтобы продемонстрировать, какие элементы должны быть включены в документ. Документ легко адаптируется для ваших конкретных нужд.
- Итак, какими преимуществами обладает такой формат требований и какие наши проблемы он решил. Одна страница – один источник. Создавать документ в одну страницу по шаблону быстрее и легче, чем писать спецификацию с чистого листа. Такой документ, из-за своего скромного объема, легко читается и обновляется. Особая гибкость. Единый, но гибкий формат создания документации. Документ достаточно гибкий, чтобы адаптироваться под нужды каждой команды. При этом имеет единый формат для удобной навигации и работы с ним. Также документ может дополняться уже в ходе разработки. Необходимый минимум. Документ фокусируется на User и Business Value. Он дает достаточно информации, чтобы помочь разработчикам понять, что именно нужно пользователю и каким образом лучше реализовать функционал. В результате разработчики сами принимают решения, вместо того чтобы руководствоваться избыточными требованиями. Синхронизация. Требования состоят из User Stories, которые создаются прямо из документа. Мы видим статус каждой задачи в документе, а также ссылку на документ в каждой задаче. Это помогает держать в порядке и Backlog, и документацию. Коллективная работа. Формат позволяет людям легко вносить свой вклад в документацию. Обсуждение из Skype переносится на саму страницу в виде комментариев, вопросов и ответов, ссылок и т.д. Таким образом, документ всегда up-to-date. Вложения. Дополнительный текст заменяется макетами, прототипами, диаграммами. Это сокращает объём документа и облегчает его чтение.
- Сотрудничество. Этой, пожалуй, самый главный плюс. Теперь, вместо того чтобы жаловаться на PO и его спецификации, мы вместе пишем требования так, как нам нравится.
- На этом все. Спасибо! Мои контакты для связи на экране. Теперь я буду рад ответить на ваши вопросы.