ОСОБЕННОСТИ РАБОТЫ С ПРОЕКТНОЙ ДОКУМЕНТАЦИЕЙ В РАМКАХ МЕТОДОЛОГИЙ СЕМЕЙСТВА AGILE

В данной статье будут рассмотрены особенности ведения проектной документации при работе над проектом и при управлении деятельности проектного типа согласно методологиям семейства Agile.

Введение

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

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

Проекты и документирование

Всё вышесказанное подводит к тому, что процесс создания и ведения проектной документации по факту решает те же самые задачи, что и передача знаний об умении строить пирамиды или способ лепки горшков. Вне зависимости от вида проекта, используемой методологии, будь то Waterfall, SCRUM или какая-либо другая, в 99 процентах случаев люди, работающие над совместным проектом, сталкиваются с необходимостью фиксации некой информации. Разумеется, документация может отличаться более чем полностью в зависимости от того, какой цели она служит и как будет использоваться в дальнейшем.

Разумеется, возможны случаи, когда на создание и работу с документацией не стоит тратить время, отведенное на реализацию проекта, например, если проект представляет собой работу трех людей по созданию статуи.  Само собой, ниже будут рассматриваться проекты, где ведение документации и документирование знаний жизненно необходимо для завершения проекта в срок и обусловлено различными факторами: объемом информации в проектном домене, сложностью и нетривиальной структурой знаний для работы над ним.

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

Согласно одному из определений, проект - это последовательность взаимосвязанных событий, которые происходят в течение установленного ограниченного периода времени и направлены на достижение неповторимого, но в то же время определенного результата [1]. Проект характеризуется следующими чертами:

• Наличие конкретной цели
• Уникальность
• Разовый характер
• Ограниченность в ресурсах
• Последовательная разработка

Наличие цели у проекта необходимо для определения момента, когда проект будет считаться завершенным. Уникальность означает, что нет двух абсолютно одинаковых проектов: при одинаковой цели может быть сколько угодно вариантов её достижения. Разовый характер говорит о том, что никакая повторяющаяся деятельность не считается проектной: стоит достичь цели – проект сразу же завершается и впредь его жизненный цикл подошел к концу. Ограниченность ресурсов зачастую подразумевает ограниченность во времени, бюджете и прочих подобных ресурсах, обладая которыми в неограниченном количестве, сразу отпадает необходимость решения задачи управления проектом. Последовательная разработка означает то, что любой проект развивается во времени, проходя через определенные ранее этапы и шаги [2].

Для чего вообще возникает необходимость создавать и поддерживать проектную документацию и, в частности, документацию для проектов из сферы информационных технологий? Одной из важнейших задач проектного менеджмента является управление рисками, и проектная документация позволяет снижать данные риски. Фактически, при наличии грамотной документации в любой момент времени становится возможным отслеживать статус проектных работ и контролировать его будущее. Иными словами, документация позволяет установить связь и доверительные отношения между заказчиком и исполнителем, позволяет исполнителю владеть всей информацией о проекте в текущий (в идеальном случае – в любой) момент времени, а заказчику – оценивать прогресс и качество выполняемых работ.

Waterfall и Agile

С момента зарождения первых методологий и попыток формализовать работу над деятельностью, имеющей проектные черты, прошло значительно времени. В 1970 году У.У. Ройсом была опубликована статья, в которой он описал концепцию каскадной модели процесса разработки программного обеспечения, так называемую Waterfall модель, в которой описал процесс разработки как последовательность фаз, таких как определение требований, проектирование, реализация, тестирование, эксплуатация и поддержка. При этом подразумевалось, что каждая фаза может начаться только тогда, когда полностью завершена предыдущая [3].

Что подразумевала работа с проектной документацией в рамках каскадной модели? Поскольку фазы следовали друг за другом и начинались только в момент завершения предыдущей, требовалась максимальная прозрачность на каждом из этапов: необходимо было в точности понимать, что нужно делать дальше. Нельзя вернуться назад и обновить требования – формальное описание каскадной модели этого не подразумевает. Разумеется, подобная формализация позволяла снижать риски и повышать прозрачность проекта в целом, но при этом страдали и сроки, и стоимость, и качество. Таким образом, определение требований играло невероятно важную роль с точки зрения всего проекта.

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

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

Agile же, в силу своих особенностей, гласит в том числе:

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

В рамках рассматриваемых особенностей интерес представляет второй пункт этого списка. Многие разработчики, работающие по каким-либо из методик класса Agile-методологий, к примеру, по SCRUM, полагают, что Agile позволяет не работать с документацией или даже против ведения документации. Разумеется, это не так. Одинаково вредными могут оказаться как привычка документировать ненужные детали (приходящая из мира каскадной модели разработки), так и полное игнорирование поддержки базы знаний по проекту и удаление описания всех пользовательских историй сразу по их завершению.

Как и во многих областях, важно находить компромисс и решать, что именно нужно документировать в рамках проекта. Как создание документации повлияет на продуктивность? Что нужно документировать, а что не нужно? В какой момент необходимо документировать новые знания о проекте и в каком объеме? Нет четкого ответа на данные вопросы. Можно лишь сформулировать некоторые рекомендации по ведению документации в Agile.

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

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

Вне зависимости от специфики работы над спринтами и пользовательскими историями в каждой конкретной команде, в той или иной форме возникает задача создания документации как для команды, так и для заинтересованных лиц. Теоретически, команда может обходиться общением с заинтересованными лицами,  трекингом пользовательских историй или в Jira, или в Excel, или даже в виде стикеров на доске с привычными колонками, такими как «В планах», «В процессе», «Готово» [4]. На практике подобный минимализм, как правило, невозможен и даже опасен. Как минимум, желательно наличие документов, описывающие проект и знакомство с ним для новых членов команды, всевозможные заметки и руководства для различных ролей и обязанностей. Не стоит забывать о том, что код также является частью технической документации, и при грамотном подходе позволит избежать множества необязательной документации со стороны разработчиков.

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

Заключение

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

Список литературы:

1. Бэгьюли Ф. Управление проектом: пер. с англ. / Ф. Бэгьюли – М.: Гранд ФАИР-ПРЕСС, 2002. – 202 с.
2. Перерва А., Еранов С., Иванова В., Сергеев С. Путь IT-менеджера. Управление проектной средой и IT-проектами. – СПб.: Питер, 2016. – 320с
3. Каскадная модель [Электронный ресурс] – Режим доступа. – URL: https://ru.wikipedia.org/Каскадная_модель
4. Книберг Х. Scrum и XP: заметки с передовой: пер. с англ. / Х. Книберг – InfoQ Enterprise Software Development Series, 2007. – 94 c.