Agile-Стоматолог

Автор: Александр Якима (www.enter-agile.com)

В 2007 году один из разработчиков на моем проекте посоветовал стоматолога. С тех пор я стоматолога не менял. И не собираюсь. Почему? Потому что этот стоматолог 100% ориентирован на качественное удовлетворение потребности "пользователя". Расскажу подробнее и мы увидим явные параллели с гибкой разработкой.


Обязательность приемки. Каждый раз, что бы ни делалось (фиксается скол пломбы или производится чистка ультразвуком и т. д.), работа заканчивается фразой "принимаем работу", после чего мне дают обычное зеркало и с помощью стоматологического зеркальца и зонда показывают, где только что все было проделано. Мой стоматолог успокоится только тогда, когда я кивну: "ОК".

Комментарий. Это мечта любого продакт-оунера. Команда исправно доставляет инкременты итераций, действительно работающие, и каждый раз ожидает от него простого "ДА" (принято) или "НЕТ" (не принято). Квинтэссенция всего - приемка релиза. Однако типичная расхлябаность и отсутствие элементарной дисциплины оставляют от гибкой команды одно название (см. У Вас Agile? Проверим?..). Очень часто ситуация усугубляется тем, что на проекте нет выделеной роли "продакт-оунер". Тогда следует кому-то в команде это бремя на себя принять, а именно - роль прокси продакт-оунера. Тема проксирования заслуживает целой книги, мы к ней обязательно вернемся в последующих постах. Однако важно помнить следуюющее простое правило: без продакт-оунера, делающего систематическую приемку выхлопа каждой итерации, это не Agile.

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

Комментарий. Команда должна не просто выкатывать комок софта на демо и на этом все. Нет. Так команда получит только поверхностный фидбэк от продакт-оунера. Чтобы основательно понять, в каком состоянии предлагаемый билд итерации, команда должна предоставить продакт-оунеру следующие две вещи:
1) "Алгоритм" полноценной приемки. Обяснить как "локализовать нервные окончания".
2) Время, достаточное для выполнения офф-лафн приемки.
Последнее означает в оптимальном случае (и это действительно хороший стиль работы), что до следующего демо у продакт-оунера будет свободный доступ к текущему билду; иными словами - держать инкремент предыдущей итерации доступным всю текущюю итерацию, пока не появится новый инкремент.

Сразу же хочу прояснить важный момент по поводу двойственности приемки итерации. С одной стороны на самом демо в реальном времени продакт-оунер должен сказать команде, принимает он билд или нет. Это - ключевой индикатор для команды. Офф-лайн приемка, с другой стороны, влияет скорее на план следующей (или следующих) итераций.

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

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

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

Берегите зубы!

No comments:

Post a Comment

 
Powered by Blogger