keepsimple
dark
en | ru

#2. Что такое артефакт проекта и зачем он нужен?

Артефакт – это искуственно созданный объект, который наделяется каким-то смыслом тем, кто его создал. Например: схема, документ, прототип – это все артефакты. По сути артефакт это сжатое, емкое понятие единственная цель которого – оптимизация. Оптимизация времени на объяснение того, что нужно, оптимизация текста, затрачиваемого на описание чего-то и так далее.

Для процесса разработки программного обеспечения был выведен следующий общий набор артефактов (картинки второстепенны – я люблю картинки):

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

EPIC (Эпик)

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

Эпики составляются Бизнес Аналитиками (Business Analyst), Менеджерами Продукта (Product Manager) или Владельцами Продукта (Product Owner).

Пример:

Проект: «Мобильное приложение UBER».

Эпики: «Система регистрации», «Интерактивная карта», «Платежная система», «Рейтинговая система» и так далее.

Обычное описание эпика (так делает большинство):

Система регистрации – необходимо имплементировать возможность регистрации посредством социальных сетей, с обязательной верификацией номера мобильного телефона.

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

Пример:

Система регистрации. Целевая аудитория состоит из мужчин и женщин в пропорции (65% / 35%). Возраст 18 – 45. Ввиду того, что в наших стратегических планах присутствует расширение и запуск в Китае, необходимо учесть, что Facebook там запрещен, но присутствуют локальные соц. Сети Webo и Wechat. Для аналитики нам потребуется любая информация которая помогла бы выявить специфику в группе пользователей, а также облегчить процесс регистрации для пользователей целевой аудитории.

И так далее.

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

О ужас – скажете вы – неужели программисту действительно нужна эта информация?

О ужас – скажет среднестатистический программист – зачем мне все это нужно? Отмените ланч, мне срочно нужно писать код!

Однако, если мы говорим о настоящем качестве, где команда действительно действует как команда, а компания является живым организмом в котором эта команда живет и на благо которого процветает – тогда альтернативы нет.

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

User Story (Пользовательская история)

Данный артефакт вмещает в себе требования к разрабатываемому компоненту.

Один Эпик может содержать в себе десятки пользовательских историй.

Пользовательская история составляется Владельцем Продукта (Product Owner), Менеджером Продукта (Product Manager)-ом или Менеджером Проекта(Project Manager) (Хотя в идеале, проект менеджер этим заниматься не должен, но мир не идеален).

В отличие от Эпика, в Историях находится именно та информация, которая напрямую необходима программисту для разработки компонента.

Обычно, пользовательские истории пишутся от первого лица, в формате «Как пользователь .... я бы хотел ....чтобы...» , однако, опять же, по обоюдной договоренности с командой разработчиков, может быть применен и другой формат.

Для эпика «Платежная Система» могут быть выведены следующие Истории:

«Страница платежных методов», «Прикрепление банковской карты», «Прикрепление PayPal аккаунта», «Страница оформления заказа» и далее.

Пример пользовательской истории «Страница платежных методов»:

«Как пользователь UBER, я бы хотел иметь возможность доступа к странице «Платежные Методы» из левого меню. На этой странице я бы хотел видеть следующие кнопки:
  • Добавить новую карту
  • Добавить PayPal аккаунт
Если у меня уже есть добавленные методы платежа, я бы хотел видеть их в списке, с указанной датой добавления.

Напротив добавленных методов я бы хотел видеть кнопку удаления платежного метода, которая, при нажатии, открывала бы окно подтверждения действия с вариантами «Да/Нет».»

Думаю для общего примера этого хватит. Структура пользовательской истории – это вопрос опыта, который приходит со временем, но необходимо понимать, что здесь важно совершенно все. Любая деталь, которая будет упущена – это минус несколько минут/часов/десятков часов для программистов работающих над историей. Так, если вышеуказанная история доберется до программистов, один из первых вопросов который у них возникнет будет «А могу ли я прикрепить несколько банковских карт и/или PayPal аккаунтов?», дальше пойдет «А в какой поочередности мы должны их расставить? По дате добавления? По названию? Если по дате добавления – то могут ли карты и PayPal аккаунты чередоваться, или сперва мы должны показывать карты, а затем – PayPal аккаунты?». Все это и еще десятки других вопросов совершенно справедливо возникнут у разработчиков, потому что ничего не было написано в истории. В свою очередь на выяснение каждого из этих вопросов может понадобиться разное кол-во времени и вовлеченных лиц, и так, история, которая была оценена в «5 часов работы» может затянуться на дни, недели а то и месяцы.

Таким образом, для написания идеальной пользовательской истории, менеджеру нужно понять:

  • Как этот компонент системы должен работать?
  • Какие вопросы могут возникнуть у программистов?
  • Какие вопросы могут возникнуть у дизайнеров?
  • Какие вопросы могут возникнуть у тестировщиков?
  • Какие вопросы могут возникнуть у конечных пользователей этого компонента?

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

Task (Задача)

Задачи – это то, на что раздробляется пользовательская история. Так, для разработки истории «Страница платежных методов» могут понадобиться десятки задач, в которых будут вовлечены дизайнеры, программисты и тестировщики.

Пример:

Задачи составляются в основном техническими специалистами, разработчиками при прямом или косвенном участии Project Manger-а, либо Product Owner-а (по необходимости). В идеале, если история написана так, что ни у кого не возникает никаких вопросов – все задачи могут быть написаны разработчиками.

Разработчиком ответственным за раздробление задач обычно является Ведущий Разработчик (Team Lead).

Sub-Task (Подзадача)

Подзадача – это результат дробления задачи на более мелкие составляющие. Используется по необходимости, на усмотрение Team Lead-а.

Bug (Баг)

Ошибка, возникшая в программе. Например мы нажимаем на «Прикрепить PayPal», но в открывшемся меню мы видим приглашение прикрепить банковскую карту. Грусть.

Поиском ошибок занимаются тестировщики, являющиеся одним из звеньев в разработке ПО.

Помимо тестировщиков, баги выявляются самими пользователями, которые в свою очередь обращаются в службу поддержки с вопросами а-ля «У меня открылось не то окно, что делать?».

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

Вот и все. Каждый год появляются какие-то новые «артефакты-обозначения», которые набирают группы фанатов свято верующих что Эпики устарели, и что единственно-верным подходом является использование «Goal/Experience/Initiative/Feature» (нужное подчеркнуть). На самом же деле совершенно не важно как ты назовешь то, что делаешь, если ты понимаешь что делаешь. Единственно правильное во всем этом – чтобы структура была простой и понятной настолько, насколько это возможно.

В следующей статье мы бегло пройдем по онлайн системам управления проектами, увидев, где и в каком формате используется все то, о чем мы с вами поговорили в этой статье.