Исправляем ошибки документирования

Всем привет!

Сложности документирования, с которыми мне приходилось сталкиваться при работе на разных проектах, описаны в посте "7 ошибок документирования".

А что вы как project manager можете сделать для  улучшения процессов связанных с документированием?

Советы и рекомендации - ниже.

Поехали!

1. Выберите правильный инструментарий

Найдите эффективную для вашего проекта связку task tracker  + content collaboration software.

От content collaboration software вам нужно:

• легкий в использовании функционал по работе с разметкой, таблицами, форматированием текста;
• поддержка версионности документов;
• возможности просмотра изменений между двумя версиями документа; 
• Спасибо, Кэп! возможности коллективной работы.

Три варианта, с которыми приходилось работать:

• Jira + Confluence
• Jira + Ms Word
• Redmine + MediaWiki

Mediawiki. “Дешево, но сердито”. Сложный функционал редактирования (особенно табличных данных) компенсирован низкой стоимостью решения.  Устанавливали различные  плагины, но все равно оказалось не очень удобно.

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

Confluence. Удобно управлять контентом,  есть интеграция с Jira, поддержка коллективной работы. Но стоит денег.

Самый удобный вариант  -  Jira+Confluence. Его и буду рассматривать в качестве примера в следующих пунктах.

2. Внедрите документирование в процесс разработки

• Как начать писать документацию и не забывать ее актуализировать? Сделайте написание документации обязательной частью процесса разработки! При чем не на уровне декларации “Нужно!”, а потому что процесс будет останавливаться-замедляться.

• Документация должна стать основой общения участников процесса разработки - аналитиков, разработчиков, тестировщиков и т.д.

• Документация должна быть единственным “источником правды”. Что не написано на странице в Confluence - не может рассматриваться как договоренность.

• Все ценное, что было обсуждено устно, написано в чатах, нарисовано в блокнотах должно быть обязательно зафиксировано в Confluence.

• Откажитесь от использования Jira для описания требований в тексте тикета. Вместо этого - используйте ccылку на описание требования в Confluence.

• Используйте задачи в Jira как отправную точку для grooming meeting. Выстраивайте задачи в порядке приоритета - упорядочите  обсуждения user story.

• Один из критериев готовности задачи к передаче в разработку - наличие описанного требования в Confluence.

• Следите за тем, чтобы вся значимая информация о требовании была отображена  в Confluence.

• Прививайте команде культуру бережного обращения с информацией в Confluence.

3. Использовать версионирование документов

• Описывайте только финальный вариант требования. Что, где и как должно поменяться покажет Confluence c помощью функции Compare selected versions. Это и время экономит, и количество ошибок уменьшает.

• В задаче в Jira - ссылайтесь на конкретную версию страницы в Confluence. Появится возможность работать над новой редакцией документа без влияния на тот вариант, который уже отдан в разработку.

• Альтернативный вариант - в Confluence указать ссылку на задачу Jira (используя магию Jira Issues Macro). Получаем двустороннюю трассировку “требование-задача”. Но теряем преимущество связанное с возможностью работать с разными версиями страницы.

4. Разработать стандарты

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

• Разработайте шаблон структуры требований. Это ускорит написание требований и позволит избежать потери важной информации. Иногда подходит простенькая структура user story, иногда на поиск и разработку подходящих шаблонов  может уйти несколько месяцев.

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

• В Confluence есть шаблон требований “из коробки”. Используйте его на старте процесса внедрения документирования.

• Когда появится понимание какой шаблон нужен конкретно в вашем проекте - создавайте пользовательские шаблоны. 

Заключение

Возвращаясь к вопросу “нужна ли документация или можно обойтись без нее?”.

Для меня ответ очевиден - да, нужна. И не только для требований.

А как же тезис Working software over comprehensive documentation из agile manifesto?
Соблюдается!  Вносите в документы только “необходимую и достаточную” информацию. Не превращайте ее в "избыточную".

Улучшайте процессы, внедряйте документирование! )

Daily standup meeting. И у вас получится!

Практически во всех резюме, которые довелось читать последнее время, есть информация о
agile/scrum. Что первым делом вспоминает кандидат, когда спрашиваешь об этом опыте? Практически всегда -  daily standup meetings!  А иногда - это единственное, что он может внятно рассказать о гибких методологиях.

При внедрении мной daily standup meeting в разное время и с участием разных людей возникали однотипные вопросы либо озвучивались типичные "проблемы".
Где-то  эти вопросы были продиктованы зачаточным состоянием внедрения scrum'a, а где-то - каргокультовостью оного.

Мой ТОП5
1. "Зачем собираться? Одни митинги - работать некогда."
Страх перед выступлениями, нежелание брать на себя ответственность либо показывать свое безделье "отчитываться", негативный опыт с затратными по времени митингами... Причины  у каждого могут быть разные, но митинги таки вводились, участники втягивались в процесс и такого рода вопросы отпадали сами-собой, т.к. и польза и ненапряжность митингов становится быстро очевидной.

2. "...Вчера - кодил/тестировал, сегодня - аналогично..." 
Другой вариант  этого же - слишком детализированное описание ( "..Пришел, включил, почитал, ответил, встретил, поговорил и...")
Ориентация на результат, а не на процесс - это важно :) Собственно, это и объясняется в ответ. Люди, в большинстве своем, быстро приходят к нужному формату выступления, но нет-нет да и вылазит у кого-нибудь "работу работал".

3. "А зачем стоять? Так тяжело, давайте сидя!"

Только стоя! И это работает.  На практике случалось, что члены команды сами предлагали оптимизировать дейли стендап "потому что надоело и невозможно стоять по 30-40 минут". А командная самоорганизация - это ведь тоже важно :)

4. "...А давайте соберемся на 6 минут позже, а то я чай не успеваю приготовить."
Я люблю теорию "разбитых окон", которая говорит о том, что небольшие нарушения правил, тянут за собой чуть большие нарушения, а те в свою очередь еще большие, и в конце-концов игнорирование правил полностью..
А ведь выполнение командных договоренностей - это важно :)
Потому я борюсь с  переносами, опозданиями на митинги  всеми доступными средствами.

5. "...А вот здесь я расскажу по-подробнее.." или "Я только спросить!"
Боль и печаль стендап митингов - это растягивание времени проведения за счет дискуссий и выдачи излишне детализированной информации, которая неинтересна всей части команды.
Тут палка о двух концах: с одной стороны есть четкая структура выступления "вчера-сегодня-проблемы", с другой - порой стендап это единственное удачное время-место для того что бы рассказать нечто полезное-интересное либо здесь и сейчас по-быстрому порешать. И иногда бывает эффективнее потратить небольшое время на стендапе, чем собирать отдельно этих же людей для обсуждения в другое время и в другом месте. В любом случае модератор митинга должен контролировать развитие таких ситуаций.
Я в таких случаях даю, как правило, не более 5 минут и выношу обсуждение на afterstandup meeting.

И еще с чем приходится сталкиваться на начальном этапе - выбор времени проведения митинга. Я предпочитаю утро. И этому есть несколько причин:
- при митингах вечером фокус смещается с миниконтракта на день("буду делать") на отчет ("делал"). Т.к. события прошедшего дня более близки, нежели то, что будет происходить завтра. Встречаясь же утром, команда получает некий заряд на достижение дневных целей.
В командах с которыми я работаю есть крайнее время прихода на работу, но нет такого рода ограничений по уходу. В моем случае наиболее удобно проводить митинги где-то через 30 минут после начала рабочего дня команды. Этого времени обычно достаточно, что бы подготовиться к митингу, вспомнить что было вчера и составить план на сегодня, а опаздывающим таки успеть доехать на работу :)

Понятно, что это не единственное с чем приходится столкнуться в процессе "приобщения" к правильным  standup'ам, но эффективность правильно построенных митингов высока независимо от того у вас scrum или "типа scrum". Потому - дерзайте! :)