Agile больше ценит работающий софт, а не обширную документацию - это четвёртая часть первичного манифеста. Это не означает "не пишите документацию"! Это ознначает "не пишите больше, чем необходимо для документирования". У документации есть ценность, но сама практика документирования стала излишней - вот почему реакция на плохие примеры привлекла к себе внимание как один из краеугольных камней Agile. Как же избежать чрезмерного сокращения документации при изменении культуры излишнего документирования?
Необходимость документирования
Документация нужна нам, чтобы помочь нам общаться. Можно определить команду Agile как "люди, создающие продукт". Можно понимать под "создающие" людей, о которых мы обычно думаем как о предпринимающих действия по достижению цели, а можно расширить понятие и включить в команду и людей, имеющих цель.
С философской точки зрения Agile уделяет особое внимание сотрудничеству. Обычно оно происходит через (1) людей, которые предпринимают действия и работают сообща для принятия наилучших решений и (2) людей, являющихся частью команды, которые сотрудничают с людьми, для которых они создают продукт. Обычно проекты, в разработке которых принимают участие заказчики, успешны, а те, в которых не принимают, - нет, поэтому лучше считать заказчиков частью команды.
Вне зависимости от определения сотрудничество требует коммуникаций, а коммуникации улучшаются при наличии документации.
Коммуникация во времени
Коммуникация между группами людей происходит во времени.
Некоторое сотрудничество мгновенно - коммуникация происходит прямо сейчас и важна прямо сейчас. Другие коммуникации более длительны - сотрудничество происходит прямо сейчас, но нам нужно будет помнить позже, о чём и почему мы договорились. Существуют вариации "прямо сейчас" и различные степени "позже", но если упростить
- есть коммуникации для сейчас
- есть коммуникации для потом.
Оба вида важны.
Документация, как она видится в кошмарах, - огромные кипы документов с описаниями требований, анализов архитектуры и детальных психографических профилей - очень неэффективна для коммуникаций сейчас.
Эти массивные документы, мешая разговору, всё-таки дают возможность запомнить (в будущем), почему мы приняли те решения, которые приняли (сегодня).
Документация, как её понимают в большинстве дискуссий agile, - случаи пользователей и критерии принятия или карточки, прикреплённые к стене, - не являются хорошим решением для коммуникаций, которые случаются потом.
Этот практически безбумажный подход к фиксированию сегодняшних идей на самом деле побуждает и улучшает сегодняшнюю дискуссию - но не даёт нам записей, которые мы сможем использовать в будущем, чтобы узнать, почему мы приняли такое решение.
Как у команды agile, у нас всегда есть способы, как применить и мгновенную и длительную тактику документирования, чтобы сделать их более ценными. Мы можем приспособить наши мгновенные записки и сделать их более полезными для будущего использования. мы можем применить подход agile к развитию длительных документов, чтобы нам пришлось записывать только необходимый минимум, жертвуя минимальным количеством краткосрочной эффективности, чтобы избежать долгосрочных проблем.
Мгновенные документы для будущего
Картинка сверху со встречи по определению недоработок в продукте и начального толчка дляя нового проекта. Команда определила наиболее важные стороны (истории) для первого этапа, критерий их принятия и размер, в баллах, каждой истории. Как часть scrum, истории написаны в пользовательском формате, а критерий принятия каждой истории определён и записан на дополнительных карточках (прикреплённых к карточкам соответствующих историй). Замечательный быстрый способ зафиксировать истории "должны сделать" и "улучшит", о которых думает владелец продукта.
Как команда мы сделали пару небольших изменений, чтобы сделать эти карточки с историями более полезными. Во-первых, все истории были разожены по темам, которые помогут установить контекст (для команды), и объединили истории в "значимые области фокуса" для общения с заказчиками.
Каждая история получила свою цветовую кляксу в верхнем левом углу, которая определяла какая из пяти тем поддерживалась. На изображении сверху вы можете видеть обведёнными некоторые из них.
Мы также разработали набор из 8 прото-персон (прототипов, первый черновой вариант, очень грубое приближение персон - почти стереотипы), которых весь продукт / проект должен был поддерживать. У каждой персоны была звёздочка своего цвета.
У каждой пользовательской истории была своя наклейка в виде звёздочки соответствующего цвета, которая показывала, для какой персоны была написана история. В частности, когда несколько персон могли использовать историю, мы определяли, для какой персоны мы применяли историю на этом этапе.
В мире "прямо сейчас" эти ухищрения помогли нам понять, поставить задачу и подтвердить темы и персоны, которые поддерживались в первой истории. Эти разговоры помогли нам достичь прагматичных компромиссов относительно того, какие заказчики будут в выигрыше и когда. Они также позволили нам написать исходящее сообщение, что является первым этапом в менеджменте ожиданий заказчиков.
Список тем менялся в процессе - мы перешли с 4 до 5 тем, поскольку поняли, что нам лучше разделить одну тему на две. Группа прото-персон выросла из первоначальных 3 до 8, поскольку мы быстро поняли, что команда пыталась "построить что-то для каждого", а мы хотели избежать проблемы эластичного пользователя и вместо этого разработать возможности, которые бы удовлетворяли ценные группы пользователей с похожими целями и перспективами.
Изменение культуры для заказчиков
Как и следовало ожидать, наличие кучи карточек, прилепленных к стене, даёт команде замечательные, быстрые, "сейчас" коммуникации - как во внедрении, так и при общении. Однако, карточки на стене - явление краткосрочное. Также это не лучший способ общения с заказчиками старой школы (представьте себе руководителя, который заставляет своих админов распечатывать е-мейлы, чтобы их читать и аннотировать - такие люди до сих пор существуют!).
Это может создать проблемы при сотрудничестве и коммуникациях с той частью команды, которая "не часть разработки".
В книге "Применение пользовательских историй" Майк Кон делает ударение на том, что краткость пользовательских историй специально призвана побуждать (и я бы добавил "зависеть от") разговор. Я считаю это как сильной, так и слабой стороной пользовательских историй. Сильной, потому что можно быстро охватить широкий круг тем (широта) и высветить несколько историй, как приведённый выше список. Слабой, потому что документация требований не существует сама по себе - она требует разговора для заполнения деталей. Иногда помогает использование тестов принятия "Проверь, что ..." в качестве метода документирования этих деталей (глубина) в сочетании с краткими, легко усваиваемыми историями.
Эти разговоры проходили как часть процесса определения историй, записи их на доске в правильном порядке и определении критерия принятия. У заказчиков часто короткая память, особенно когда именно они шли на компромисс. Необходим какой-то способ удержать контекст разговора, который привёл к определённой организации и контенту историй на стене.
Постоянные документы в настоящем
Последователи agile жалуются на большое количество мешающих документов, которые замедляют старт проектов, не дают командам адаптироваться к меняющимся условиям рынка и вообще осложняют создание хороших продуктов. Я согласен. Последователи agile также недовольны процессом создания софта типа водопада "сначала построй полностью, затем выпускай" - и предлагают альтернативу - интерактивную разработку софта. Я снова согласен.
Почему бы не применить тот же принцип интерктивной разработки к постоянным документам?
Рассмотрим пример, приведённый выше, с использованием цветных наклеек в виде звёздочек, которые определяли людей, к которым применялась каждая история на каждом этапе. Большая часть времени, потораченная на этот анализ, пришлась на понимание того, какие люди важны (для успеха продукта) и для каких людей возможность осуществления этой пользовательской истории важна (для персоны). Комбинация этих двух важностей - начало приоритизации. Минимальное количество времени было потрачено на прилепление стикеров к карточкам и на создание нескольких карточек для одной и той же истории (каждая с разной наклейкой для разных персон и потенциально разных критериев принятия).
Добавьте немного наглядных пособий и создайте такую таблицу (или как вам удобнее).
Вышеприведённая картинка показывает соответствие примеров использования и действующих лиц. С такой же лёгкостью она могла показать соответствие пользовательских историй и персон. Переход от мыслей о действующих лицах до мыслей о персонах короткий. Эту таблицу я взял из более ранней статьи о распространении расписания с пользовательскими историями - она помогает заказчикам получить общую картину кто когда выигрывает - пользовательскоцентричная, но всё-таки вертикальная перспектива.
Примечание: ещё одним нюансом пошаговой доставки является то, что вы можете представить "голую" версию истории сейчас, и "более хорошую" её версию позже. Вы также можете показать, что истории со временем становятся лучше, для некоторых пользователей, с помощью той же таблицы.
Также очень просто составить таблицу, которая показывает, как каждая тема "представлена" на каждом этапе. Такой вид стимулирует хорошую дискуссию относительно того, стоит ли делать ударение сначала на одной теме, а затем на другой или нужно сначала сделать наиболее важные элементы в каждой теме - и постопенно добиваться прогресса в каждой теме. Создание такого вида и использование его для коммуникаций помогло мне разрешить проблему, когда "внешние" заказчики считали, что команда выглядит "хаотичной и случайной" при её подходе к приоритизации и внедрении.
Множество моделей
Существует большое количество типов документации - и большое количество моделей для выделения и обсуждения определённых аспектов сложной системы (вроде пользователи и цели и решения). Создание простой диаграммы вроде следующей схемы - практически обязательное условие для эффективных быстрых коммуникаций в некоторых проектах.
Когда большинство людей жалуются на документацию, они не жалуются на вышеприведённую схему. Они бы посчитали эту схему дополнением к разговору. Отлично. Вот что я сделал в своё время. Затем я её сфотографировал. И вдруг она стала частью документации. Позже подошёл заказчик, подтвердил, что системе следует работать таким образом, и подписался на доске - и мы обновили фото.
Каждый тяжёлый документ можно начать таким образом. И он может развиваться. Он должен развиваться. Если вы хотите добиться успеха, он должен развиваться по мере того, как ваша команда становится умнее, ваши конкуренты реагируют и ваш рынок меняется.
Весь фокус в том, что вам не нужно писать окончательную версию прежде чем начать. Зафиксируйте на высоком уровне, что вы знаете именно сейчас - как в дорожной карте. Зафиксируйте достаточно деталей того, что вам нужно именно сейчас - как в бэклоге истории. И меняйте её по ходу.
Заключение
Документация - это не зло. Документирование того, чем вы никогда не будете пользоваться, плохо. Документирование того, что вам долгое время не потребуется, рискованно, потому что оно может измениться до того, как вы обратитесь к своему документу.
Документирование того, почему вы приняли решения именно сейчас, как часть быстрого сотрудничества и коммуникации важно, потому что так весь коллектив запомнит. Такая документация сохранится, и ваша команда сможет приумножить знания - наподобие того, как ваша команда шаг за шагом достраивает развивающуюся базу кодов.
Источник:
Tyner Blain
Скотт Сельхорст написал замечательный пост у Тайнера Блейна о документации. Не технической документации, а информации, которую вы записываете, чтобы процесс разработки заработал. Под работой я не имею в виду только деятельность внутри команды разработчиков, но и остальной цепочки создания стоимости тоже.
