Must have артефакты для разработки ПО
Привет! Меня зовут Сергей Алексеев, в IТ я уже
Я хочу, чтобы статья помогла разным командам увеличить свою производительность и профессионализм. Надеюсь, что этот материал прочтут сотрудники, которые отвечают за IТ в госслужбах и других непрофильных компаниях. Возможно, люди начнут внедрять у себя лучшие практики, что позволит компаниям стать более эффективными. Я не хочу обидеть никого, но для всех нас не секрет, что профессиональный уровень специалистов в этих структурах на порядок ниже, чем в лидирующих IТ-компаниях страны, но всегда есть исключения. Такими компаниями я бы назвал МХП, НП, «Розетка», ДТЭК. Возможно, их больше. Напишите в комментариях об этих организациях.
В последние годы я побывал в разных компаниях, работал с командами разной структуры, количества сотрудников и опыта, был вовлечен во множество бизнес-доменов. Благодаря накопленным знаниям я смог составить перечень минимального набора необходимых артефактов, без которых команды разработки не работают эффективно, особенно на fixed price проектах. Эффективность работы команды для меня подтверждают следующие показатели: скорость разработки, количество созданных багов, технического долга, изменений и переделок за свой счет. На все эти показатели очень влияет сплоченность команды. Только что сформированная команда сеньоров будет менее продуктивна, чем работающая уже год команда мидлов, но, конечно же, это только поначалу. Дальше сеньоры победят в этой схватке метрик.
На картинке ниже я специально выделил область в процессе «бэклог менеджмент», в которой происходит декомпозиция требований и создание большинства артефактов. Лично я использую rolling waves подход во всех проектах, чтобы сбор и описание требований прошли более спокойно.
Процесс декомпозиции feature
Чем же является feature (далее фича) в мире ПО? Фича — это часть функциональности в программном обеспечении, которую необходимо реализовать в определенном объеме и последовательности. Например, «Find friends» в Facebook, «Stories» в Instagram, «New incognito tab» в Chrome.
Вот так вот выглядит процесс декомпозиции feature на практике:
Важно: список задач не отсортирован по приоритетности выполнения во время процесса. Список фич появляется только после того, как были выявлены основные сценарии, которые необходимо автоматизировать, изменить, оптимизировать.
| Этап | Задача | Комментарий |
| Анализ | Получить видение, объем и границы фичи | Оформляйте это в виде простых требований типа:
|
| Анализ | Определить и описать роли | Понимание ролей необходимо как минимум для того, чтобы построить модель доступа к интерфейсам и данным ПО. Роли также понадобятся в момент описания use cases. Я выделяю два типа ролей (бизнес и системные):
Пример колл-центра: есть 2 бизнес-роли (супервайзер и оператор), у каждой из этих ролей есть свои обязанности и метрики, за которые они несут ответственность. В программном обеспечении вы можете создать 2 системные роли и каждому из пользователей будет назначена своя роль. Тем самым вы делаете границу между UI & Data по ролям. Но в случае, когда оператору нужно расширить возможности в ПО, ему могут назначить дополнительную роль «Супервайзер» для расширения полномочий в самом ПО, а не в реальном мире (один из возможных вариантов реализации). |
| Анализ | Понять основные кейсы использования фичи | Любая фича реализовывается для того, чтобы поддерживать минимум один сценарий взаимодействия пользователя/системы с ПО и приносить пользу. Вам необходимо выявить как можно раньше и больше сценариев, которые имеют отношение к определенной фиче. Это даст возможность понять объем работ, рамки реализации и спланировать разработку. Тут вам помогут «use case» диаграммы. Пример колл-центра: основные сценарии для оператора — принять звонок, зафиксировать обращение, осуществить звонок и так далее. |
| Анализ | Понять основные сущности фичи | Понимание основных сущностей и их взаимосвязей необходимо для правильного проектирования ПО. Это важно не только с точки зрения технической архитектуры, но и для проектирования интерфейсов. Пример колл-центра: клиент, который звонит в колл-центр; пользователь, который принимает звонок; звонок, заявка и так далее. Эту задачу помогут решить ERM диаграммы. |
| Дизайн | Определить основной сценарий | На этапе дизайна я всегда рекомендую показывать «happy path», чтобы команда и клиенты понимали сценарий, как это будет выглядеть от начала и до конца (end2end). Пример колл-центра: успешное формирование заявки по входящему звонку — интерфейс карточки звонка, интерфейс карточки клиента, интерфейс заявки. |
| Дизайн | Создать дизайн | Необходимо показать выбранный сценарий или несколько на самих мокапах. Желательно делать интерактивный мокап. |
| Дизайн | Создать артефакты | Пока создаются дизайны и выясняются требования, вы создаете артефакты (перечислены ниже по тексту) для всех участников процесса разработки ПО. |
| Утвердить | Презентовать клиенту/сотрудникам | Для того, чтобы утвердить требования и сделать решение окончательным на этой итерации, вам необходимо его презентовать клиенту или же коллегам, если это продуктовая компания. |
| Утвердить | Закрыть открытые вопросы | Собрать всю необходимую информацию для закрытия/решения вопросов после проведенной одной или или нескольких встреч. Утверждение требований как отдельный процесс стоит рассмотреть подробнее позже. |
| Утвердить | Подтвердить дизайн и требования | После презентации у вас либо будет утверждено решение, либо будут открытые вопросы, которые необходимо закрыть. |
В основе декомпозиции любой фичи лежит принцип итеративности. Он позволяет вам с каждым разом понимать клиента все больше и четче. Так что не бойтесь практиковаться и делать ошибки.
Практика
Я решил взять за основу общий сценарий, чтобы было более понятно. Если у вас будут конкретные вопросы по вашим кейсам, пишите их в комментариях или мне лично.
Epic: Account management
Features: log in / log out / password recovery
Во время выяснения требований и разработки документации я всегда придерживаюсь одного и того же паттерна и перечня документов, который должен быть предоставлен команде до момента разработки.
В это перечень входят:
- Meeting Notes;
- Use cases;
- Flows;
- ERM;
- State Machine;
- Design;
- User Stories;
- Mock Data.
По каждому из артефактов я буду отвечать на такие вопросы: зачем, как, когда, личное мнение.
Meeting Notes
Зачем. После проведенной встречи хорошим тоном считается зафиксировать договоренности и план дальнейших действий. Я рекомендую использовать этот артефакт только как инструмент самоконтроля, а не документ строгой отчетности. Структура документа достаточно проста. В нем должно быть все, о чем договорились, утвердили и какие запланировали дальнейшие шаги. Это необходимо не только для перестраховки самого себя, но и для того, чтобы быть на одной волне с заказчиком. Согласовывать требования намного легче в письменном виде, чем в устном. Meeting notes мне нужны на короткий промежуток времени, чтобы зафиксировать информацию, затем агрегировать, поместить в юзер стори, дописать требования, переделать мокапы, назначить встречи, и на этом, пожалуй, все. Основную роль этот документ выполнил.
Как. Если встреча была не запланированной и быстрой, тогда ручка и бумага — мои лучшие друзья. Если я контролирую ситуацию, тогда, конечно же, OneNote. Неважно, каким способом я зафиксировал информацию, я всегда ее оцифровываю. Дальше в электронном виде я могу ее расшарить кому и когда это необходимо. Если на вашем проекте много людей, которым важны ваши договоренности с заказчиком, тогда вы можете использовать, например, Confluence.
Когда. Я пишу заметки во время встречи и после нее. На каждую встречу я обязательно готовлю тему и список вопросов, на которые мне нужно получить ответы, чтобы работа по проекту двигалась вперед по плану. Конечно же, я уведомляю клиента о своих намерениях, чтобы мы не тратили время впустую. После каждой встречи у меня целый ряд новых требований, изменений, уточнений. Всю эту информацию я напрямую транслирую в юзер стори (создается новая или редактируется старая).
Личное мнение. Некоторые проектные менеджеры/лиды в надежде перестраховать себя и спасти проект от изменений пытаются заставлять аналитиков вести эту документацию официально в виде строгой отчетности. Лично я считаю, что это гиблое дело. Нужно не заниматься глупостями, а решать проблемы изменения скоупа другими методами. Кто не знает какими — приходите ко мне, я расскажу.
Use Cases
Зачем. Использование use cases позволяет осознать и показать максимальную картину того, что будет входить в разрабатываемую фичу или целый продукт. Используя эту технику, вы легко можете отображать и прослеживать зависимости взаимодействия между пользователем и системой. Хорошо видны границы функциональности или продукта. Use case диаграмма также очень удобна при декомпозиции требований. Почитать детально.
Как. Эта диаграмма создается итеративно, по мере поступления новой информации. Большая часть изменений в диаграмме приходится на начало выяснения требований. Именно вначале вы пытаетесь понять, какие кейсы использования ПО будут именно у вас.
Когда. Поскольку информация по кейсам меняется достаточно редко, я ее рисую в самом начале разбора продукта/фичи. Это не занимает много времени —
Личное мнение. Использование use cases очень помогает в структурировании информации. Я практически всегда использую этот тип диаграмм в проектах, где много ролей и сценариев.
Process flow diagram
Зачем. Чтобы упростить согласование бизнес-логики между всеми участниками процесса разработки ПО. В своей практике я использую «Activity Diagrams» или «Cross functional flow charts» для решения 99% задач. Мне не нужны сложные и комплексные нотации типа BPMN / IDF0 и прочие. Бесспорно, некоторые клиенты, особенно на постсоветском пространстве, любят эти нотации, но в большинстве случаев мне не приходилось их задействовать и работа шла успешно. Почитать детально.
Как. Прежде всего, вам необходимо понять, как работают процессы в данный момент, если это уже существующий бизнес. Если же это что-то новое, тогда вам необходимо подумать, как будет выглядеть тот или иной процесс. Используя паттерн AS IS / TO BE, я всегда делаю зарисовки процессов AS IS на бумаге в виде схем / слов / кракозябликов, а вот процессы TO BE я уже отрисовываю в программном комплексе, используя определенную нотацию и тип диаграммы.
Когда. Итеративно, по мере поступления новой информации. Процессы могут зависеть друг от друга.
Личное мнение. Ваша задача — не рисовать красивые диаграммы по всем канонам определенной нотации, а делать классный работающий продукт быстро, в сроки и качественно. Пытайтесь декомпозировать процессы на более мелкие. Это позволит улучшить читабельность диаграмм.
Entity Relationship Model
Зачем. ERM позволяет показать взаимоотношения бизнес-сущностей между собой. Если вы сможете это сделать в самом начале разработки своего продукта, тогда это упросит техническим специалистам понимание того, как правильно строить архитектуру самого приложения и базы данных. Используя такие диаграммы в процессе разработки ПО, вы снижаете риск того, что нужно будет переделать приложение.
P. S. Даже если разработчики говорят: «Мы используем NoSQL базы данных и мы можем меняться на ходу», — не верьте им :) Этот трюк работает только вначале, пока продукт молодой и зеленый, и нет ни нагрузок, ни сложной бизнес-логики... Так что пускай не ленятся и задумываются над архитектурой.
Как. Чтобы понять, как использовать эти диаграммы, я рекомендую почитать о реляционных базах данных. На каких принципах они построены, какие связи есть и зачем все это необходимо.
Когда. Обновляйте каждый раз, когда вам приходит новая информация или понимание о том, какие сущности появились. В принципе так необходимо делать только поначалу разработки, пока команда не совсем хорошо ориентируется в сущностях и их связях. Далее не нужно будет обновлять схему, ведь она уже будет осуществлена в вашем приложении.
Личное мнение. Я использую этот подход при разработке новой фичи или модуля, все зависит от знаний домена и сложности связей. Если простые связи и мало сущностей, тогда можно обойтись без ERM. В противном случае я рекомендую рисовать и доносить разработчикам. Она необходима в начале проекта, пока все участники процесса не будут знать сущности и взаимосвязи между ними.
State Machine
Зачем. Чтобы понять, какие существуют состояния/статусы и какие триггеры на это влияют. У каждой сущности есть свой life cycle. У некоторых из них он достаточно короткий и состоит из
Как. Я использую диаграмму «state machine» в нотации UML. Вам необходимо понять, в какой момент сущность создается, какие сущности влияют на состояние текущей сущности. Это все вам поможет более детально продумать ваше приложение.
Когда. Обновляйте каждый раз, когда вам приходит новая информация или понимание о том, какие сущности/состояния/триггеры появились.
Личное мнение. Используйте этот артефакт в случае, когда вы понимаете, что у определенной сущности много состояний, статусов, и команде будет сложно понять без визуализации, что и когда должно произойти.
Design
Зачем. Если вы делаете программное обеспечение, которое предназначено для использования человеком посредством визуальных интерфейсов, тогда вам не обойтись без дизайна вашего ПО. Дополнительное объяснение, зачем необходим дизайн на проекте, считаю лишним.
Как. Развернутый ответ о том, как может быть построена коммуникация с дизайнером, вы можете посмотреть в этом видео.
Когда. Обновляйте каждый раз, когда вам приходит новая информация или понимание того, как пользователь будет взаимодействовать с системой. Старайтесь держать мокапы обновленными.
Личное мнение. Все дизайны должны отображать основные сценарии работы с приложением. Должны быть отображены реальные примеры данных, имен, фотографий и так далее. Всегда делайте интерактивные прототипы. Это сократит вам время на согласование требований и даст команде понимание того, как это все должно работать, с первого раза.
User Story
Зачем. Для того, чтобы строить программное обеспечение кусочек за кусочком. Это как собирать пазл. Вначале есть только идея в головах заказчиков, эту идею необходимо описать, придать ей красок, затем разбить на небольшие кусочки и собрать в единое целое силами команды.
Очень важный момент: user story не является todo-листом. Не пишите туда, что должен сделать разработчик (создать сервис, получить что-то при помощи webhook, залить данные и так далее).
Как. Работая бизнес-аналитиком, основную часть времени я тратил на описание user stories. Я не только описывал поведение, но и делал перегруппировку требований, прослеживал зависимости и выставлял приоритеты. Это то, чем должен заниматься аналитик на проектах в текущих реалиях бизнеса.
Итеративная работа над user stories — это must have навык аналитика! Обсудили требования с клиентом => написали user story => обсудили с командой => внесли изменения => обсудили с клиентом => изменили юзер стори => обсудили с командой => внесли изменения. И так до тех пор, пока клиент не будет доволен требованиями, а команда не сможет дать оценку этой пользовательской истории.
Когда. После встреч с клиентом/командой.
Личное мнение. Пользовательские истории должны быть независимыми, тестируемым и должны нести ценность клиенту.
Mock Data (тестовые данные)
Зачем. Это тщательно подготовленные данные, которые должны использоваться разработчиками во время проектирования/разработки системы. QA специалисты должны использовать их как эталонные данные при тестировании.
Как. Я предоставляю данные команде в Excel-файле. Если в разработку user story входит использование нескольких зависимых сущностей (например, товар, склад, производитель и т. д), тогда я в файле добавляю несколько вкладок, на которых находится информация по каждой из сущностей. В таких задачах очень помогает функция (ВПР или VLOOKUP) — рекомендую почитать кейсы ее использования.
Когда. Данные по определенной user story должны быть предоставлены команде до начала разработки этой user story. Иначе есть риск задержать разработку и тестирование.
Если ваша система зависит от другой, побеспокойтесь о том, чтобы ваша команда понимала, какая структура и тип данных будет в будущем.
Личное мнение. Я считаю, что данные должен готовить бизнес-аналитик, а не разработчик или тестировщик. Если аналитик не может предоставить данные команде, значит он не до конца понимает ту задачу, которую необходимо сделать. Это ведет к тому, что команда может сделать не то, что хотел конечный заказчик по вине аналитика.
Выводы
Некоторые из вас сразу скажут, что подход к работе на ваших проектах совершенно другой: заказчик хочет видеть что-то другое или привык к ТЗ (техническому заданию) на 100 500 страниц в формате *.docx. Мой ответ прост: если вы хотите меняться и расти, вам придется найти способы изменить подходы к работе с клиентами и дать им четкое понимание плюсов и минусов разных подходов. Вам придется выстроить прозрачные и доверительные отношения, если вы хотите расти вместе со своим клиентом. Вам нужно помнить, что это вы специалисты по разработке ПО, а не ваш клиент! Вы должны его учить и помогать ему, а не он вам! Вы всему голова в данном контексте, а клиент всего лишь должен быть счастливым потребителем ваших сервисов!
Если вы считаете, что я что-то упустили или неправильно описал, буду благодарен за комментарии. Также вы можете поделиться своим опытом или задать вопросы другим специалистам в профильном чате.
