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

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

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

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

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

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

Пример:

Проект: «Мобильное приложение UBER».  
Эпики: «Система регистрации», «Интерактивная карта», «Платежная система», «Рейтинговая система» и так далее. 
Обычное описание эпика (так делает большинство):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для примера этого хватит. Структура пользовательской истории – это вопрос опыта, который приходит со временем, но необходимо понимать, что здесь важно совершенно все. Любая деталь, которая будет упущена – это минус несколько минут/часов/десятков часов для программистов работающих над историей.

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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