- PVSM.RU - https://www.pvsm.ru -

Зачем и как мы делаем аудиты

Представьте, что у вас что-то заболело (не дай бог, конечно). Вы идете к врачу и тут есть две возможности:

  • «Резать к чертовой матери!»
  • Вы идете сдавать анализы и после этого узнаете, что просто съели что-то не то

Лично мне и мы мои коллегам нравится второй вариант, именно поэтому, когда нас просят внедрить «эти ваши аджайлы», мы проводим аудит. Но мы не такие, как PricewaterhouseCoopers — мы лучше, мы неформальные и мы даем ценные результаты. Как именно — читайте под катом!

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

В начале мы общаемся с заказчиком аудита. чтобы четко определить цель аудита, причины аудита, ожидания от аудита и готовность к изменениям. От этого зависит то, какие вопросы мы будем задавать и какие рекомендации давать. Затем вместе с лидами проектом (технические, менеджеры, лидеры аналитиков) мы рисуем value stream map (VSM). Что это такое? Это описание того, как бизнес идея через разработку в конечном итоге попадает к конечному пользователю. Выглядит это примерно так
image
VSM позволяет понять области для улучшенияиНенужные шаги, не добавляющие стоимость, являются источником потерь и, как таковые, они могут быть устранены.

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

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

С точки зрения технологий, нам важно знать следующие вещи:

  • технологии (язык программирования, фреймворки, базы данных, IDE, VCS)
  • архитектуру
  • процесс работы над фичей
  • процесс работы с VCS (feature branch, branch by abstraction, …)
  • состояние Continuous Integration
  • состояние unit-тестирования на проекте (пишутся ли тесты, кто пишет, какой опыт, …)
  • наличие практик совместного владения кодом (парное программирование, code review, …)

С продуктовой же точки зрения нам важны следующие аспекты:

  • кто и как исследует рынок и пользователей
  • как происходит разработка видения продукта
  • есть ли понятие MVP — minimal viable product
  • как определяется, какой функционал действительно необходим
  • кто и как прорабатывает требования
  • есть ли метрики, удачен тот или иной функционал

Обычно на этом первый день заканчивается и мы берем таймаут.

Следующую половину дня мы продолжаем общаться с командой.

Для разработчиков, тестировщиков и системных администраторов мы по очереди проводим два следующих упражнения.

Во-первых — Speed Boat. Суть в том, что мы рисуем на большом листе корабль. Данным кораблем является процесс разработки, а проблемы, которые есть – рифы, за которые цепляется якорь корабля. Задача – написать около якоря, за что тот цепляется. Степень важности проблемы можно отразить глубиной расположения якоря, чем глубже – тем серьезнее проблема. Как ни странно, эти проблемы почти не пересекаются с тем, что до этого люди говорили на VSM. Но помимо проблем, мы так же фиксируем и то, что есть положительно или хотелось бы, чтобы оно было. В случае корабля — это ветер, который дует в парус.
image
После того, как с кораблем мы закончили, вместе выполняем вторую задачу — строим инфраструктуру проекта: сервера, хранилища, сервисы и так далее. Что самое интересное в данном случае, каждая следующая группа, говорит «И почем они не нарисовали … » или «Да они все неверно отобразили!»
image
Так же, в формате Speed Boat, мы общаемся и с рекрутерами компании. Это нужно для понимания настроения в компании, мотивации людей и так далее. Один раз, именно общение с рекрутерами помогло детально понять проблему.

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

Во-первых, все проблемы мы разбираем по следующим группам:

  • Атмосфера и культура в компании
  • Работа с продуктов
  • Процессы
  • Люди

Это разбиение позволяет нам понять текущий уровень зрелости компании согласно нашей внутренней модели:

  • Управление требованиями
  • Качество
  • Коммуникации
  • Управление разработкой
  • Мотивация
  • Инженерная культура
  • Управление персоналом

image
После всего этого мы готовим предложение и слайды. Тут тоже стоит отметить, что презентацию мы готовим на больших листах флипчартах, используя инфографику и технику Visual Notetaking. Особенность листов — клейкий край, что превращает их в гигантские стикеры, которые после презентации остаются у клиента. Сама презентация продолжается около 3-4 часов. Во время нее мы рассказываем, что увидели за два дня, что ощутили и какие проблемы зафиксировали. В 99% вся аудитория соглашается, что такие проблемы есть и их надо решать. Таким образом достигается дополнительная цель аудита — открыть глаза людям на то, что у кого-то помимо них есть проблема, которую можно совместными усилиями взять и решить.

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

Автор: mythmaker

Источник [1]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/agile/34797

Ссылки в тексте:

[1] Источник: http://habrahabr.ru/post/180417/