Но не все идеально в команде проекта «Электронная книга» – она еще далека от совершенства. Разработчики используют итерации для поставки рабочего программного обеспечения, но они завалены документацией. Все действительно счастливы, что не застряли над созданием ПО, которое не будет продаваться. Но каждый раз, когда команда находит хорошие изменения, которые нужно внести в проект, половина ее участников застревает, возвращаясь к спецификации, и обновляет ее, чтобы их планы стали актуальными и соответствовали выбранному курсу. Кажется, что они тратят столько же усилий на обновление документации, сколько и на написание кода.
Рис. 3.2. В начале каждой итерации команда выбирает функции для реализации из списка невыполненных работ
В команде уже обсуждались способы сокращения объема работ, необходимых для сохранения этих документов. Состоялись обстоятельные дискуссии об «уровне детализации» документации. Но всякий раз при попытке что-либо убрать кто-нибудь приводит «вескую» причину, почему это не стоит делать. Ведь если не создать описание этой конкретной функции, требования, дизайна или примера, то кто-нибудь неправильно поймет документ. А если он будет неправильно реализован, то появится повод предъявить претензии. Со стороны кажется, будто каждый фрагмент документации необходим, потому что в противном случае над командой нависнет опасность создать плохое программное обеспечение.
Есть ли способ избежать этой опасности без вреда для проекта? Существует ли «правильный» уровень степени документированности проекта?
12 принципов гибкой разработки, которые сопровождают Agile-манифест, укажут agile-практикам направление, в котором надо работать, и дадут понимание методов и методологий.
Agile-команды удовлетворяют своих клиентов, получая обратную связь на ранних этапах проекта, и непрерывно поставляют программное обеспечение, чтобы сохранить эту связь актуальной (принцип № 1).
Agile-команды одобряют изменения, рассматривая их как положительные и полезные события для проекта (принцип № 2).
Используя ограниченную продолжительность итераций при частой поставке работающего программного обеспечения, agile-команды постоянно корректируют проект, поэтому он обеспечивает наибольшую ценность для потребителя (принцип № 3).
Общение и совместная работа
Команды-разработчики задавали вопрос, сколько документации необходимо на протяжении всего времени разработки программного обеспечения. Многие команды годами искали методологию «серебряной пули» для улучшения процессов, программирования и решения проблем с поставкой и подобный волшебный шаблон для создания документации, позволяющий записывать все необходимое для создания программного обеспечения сегодня и сохранения его в будущем.
Традиционное представление о программной документации выглядит примерно так: нужна система документооборота, в которой каждый может разместить имеющиеся у него сведения, а она должна связать эти сведения с остальной информацией. Если у нас появится возможность ее отслеживать, то мы сможем установить связи между всеми данными, что даст почти идеальный обзор того, что мы создаем, как будем тестировать, разворачивать и поддерживать ПО. Идея заключается в том, что разработчики могут отследить каждый элемент дизайна по сравнению с изначальными требованиями, а тестировщики – результаты каждого теста относительно первоначальных элементов конструкции, требований и области применения. Всякий раз, когда команда должна изменить, скажем, часть конструкции, она имеет возможность точно видеть, какой код, требования, область и тестовые примеры будут затронуты, поэтому не нужно тратить массу времени на выполнение анализа. Программисты называют это импакт-анализом (анализом воздействия) и часто стараются поддерживать в актуальном состоянии подробную таблицу всех обнаруженных неисправностей в каждой области, требованиях, дизайне и тестах.
Итак, вернемся к вопросу о том, сколько документов должны создавать команды. Ответ для agile-команды – ровно столько, сколько нужно, чтобы создать проект. Конкретное количество зависит от команды, налаженности коммуникации и того, какие проблемы она решает. Что представляет собой необходимая программистам документация? Это фиксация всех решений, принятых на собраниях с учетом большого количества примечаний, создание перекрестных ссылок на документы, описывающих каждый аспект каждого источника данных или хранилища, сложная матрица подробных функций, обязанностей и правил, которыми каждый должен руководствоваться. Образец должен быть сделан для всех видов документации. Если все это не помогает создавать программное обеспечение или не требуется по другим причинам (например, для регламентирующего органа, инвестора, менеджера высшего звена или других стейкхолдеров), то agile-команда может не создавать такую документацию. Но та команда, которая считает, что функциональная документация действительно поможет, может сделать ее и при этом остаться гибкой.
Все зависит от того, что больше подходит данной команде, и это одна из свобод, которую предоставляет Agile. Развернутая документация, матрица трассировок, импакт-анализ – вся эта дополнительная работа нужна в основном для того, чтобы полностью проанализировать влияние каких-либо изменений. Agile-методологии имеют другой (часто гораздо более эффективный) подход к управлению изменениями в проекте. Agile-практики признают, что традиционный подход к документации соответствует их целям. В традиционном водопадном проекте весь смысл исчерпывающей документации заключается в том, чтобы внести в проект наиболее удачные изменения.
Как ни странно, именно исчерпывающая документация чаще всего становится преградой на пути управления изменениями. Мечтать о совершенной документации и отслеживании изменений в ней – значит иметь такую систему, в которой команда может автоматически фиксировать все производимые в продукте изменения, поэтому команда может точно определить, что должно быть исправлено.
Для большинства команд, к сожалению, реальность управления изменениями при помощи исчерпывающей документации не столь привлекательна. Им придется потратить огромное количество времени в начале проекта, пытаясь предсказать будущее и безупречно записать его. В ходе проекта они должны сохранять документы, которые написали, и отслеживать любые новые события. Если есть изменения в понимании сути продукта, который они создают, то им придется вернуться и внести изменения во все документы, имеющие к этому отношение. Со временем это может привести к беспорядку в устаревших документах, а также потребует значительных усилий для их создания и поддержания.
Из-за того, что исчерпывающая документация неидеальна, это приводит к ненужным изменениям и затраченным впустую усилиям. Любой фрагмент документации написан с точки зрения человека, имеющего определенную роль: бизнес-аналитики делают это с одних позиций, архитекторы, создающие дизайн, – с других, а тестировщики (QA-инженеры), строящие планы тестирования, – с третьих. Когда нужно связать это воедино с матрицей отслеживания, они обнаруживают точно такие же несоответствия, которые вы ожидаете от внедрения раздробленного видения. Создание документации становится самоцелью и требует все нарастающих предварительных усилий. И наконец, когда понадобится изменение, всю работу по согласованию их точек зрения и объединению документов в обширный комплекс придется переделывать. Это ведет к переписыванию командой документации, формированию заново матрицы трассируемости и улаживанию конфликтов. Хотя на самом деле требуется написать код, протестировать ПО и внедрить изменения.
Должен быть более эффективный способ разработки программного обеспечения.
Agile-практики признают, что документация – это просто одна из форм общения[21]. Когда я пишу документ и передаю его вам, цель не в написании документации. Моя задача состоит в том, чтобы убедиться: мои мысли почти полностью соответствуют вашим. Во многих случаях документирование – отличное средство для достижения этой цели, но не единственное из имеющихся у нас.
Рис. 3.3. Когда члены команды не общаются, они могут о чем-то договариваться, но все-таки цели их работы разные. Исчерпывающая документация может ухудшить ситуацию и легко привести к ее неоднозначному пониманию
Непосредственное общение – это почти всегда более предпочтительное средство для обмена идеями внутри команды разработчиков, чем документация. Известно, что совместное обсуждение проблемы – самый эффективный способ понять новую идею. У нас гораздо больше шансов запомнить идеи, высказанные во время разговора, чем почерпнутые из книги или электронного носителя. Вот почему практики agile-общения в основном сосредоточены на людях, непосредственно общающихся друг с другом и использующих документацию только в тех случаях, когда позднее необходимо детализировать сложную информацию.
К счастью, это несложно для команд, которые используют исчерпывающую документацию для более эффективной личной коммуникации своих членов. Потому что большинство из них не стремятся достичь «идеала» в детализации информации и трассируемости. Разработчики программного обеспечения, как известно, практичны. Когда они видят весь объем работ, необходимых для создания исчерпывающей информации, они идут по пути разговоров друг с другом. Это единственный надежный способ эффективного построения ПО. Признав, что исчерпывающая документация не всегда уместна, они перестанут чувствовать вину за то, что не совершили невозможного – не создали идеальной, подробной документации. Ведь если бы они это сделали, польза для их проектов была бы невелика!