Agile-сообщество Беларуси

• Это паровоз. Здесь у него котел. Пар толкает поршень. Он двигает шатун. Шатун вращает колесо. За счет этого система и работает. Вопросы есть?
  
• Есть! И все-таки я не пойму – вот скажем у меня лошадь, куда ж мне ее запрягать?
  

Вот как-то так исторически сложилось, что последний год вокруг один сплошной agile – и проекты лезут agile, и среди Заказчиков один сплошной agile, семинары по agile заказывают иной раз по две штуки в неделю, плюс мы еще agile-сообщество сделали. В общем, насмотрелся на то, и как нормальные люди делают agile, и что иной раз мега-специалисты вытворяют под маркой «agile». Особенно кровавыми выдались некоторые драмы, произошедшие с людьми, которые пытались делать agile в (территориально-)распределенной среде. То есть в абсолютно распределенной – Заказчик в городе Х, разработчик в городе Y, другой разработчик в Z, тестер живет через океан в противофазе (то есть когда у нас день – у него ночь). В связи с этим я задумал было написать статью «8 «никогда» распределенного Agile». Но передумал. Потому что это будет запретительная статья – мол, дети, вот так делать не надо! Дети, понятное дело, сделают именно так – из принципа. Поэтому вместо этой статьи я написал другую – «8 “must have” распределенного Agile». Потому что чужим чеклистом на халяву – ктож не воспользуется? Итак, поехали.

• Постарайтесь избежать распределенного agile!
  

Помните, в чем основное преимущество agile? Правильно, экономим на документации за счет того, что Заказчик под боком, и мы в любой момент можем задавать ему вопросы, и он, честно глядя нам в глаза, отвечает прямо и разъясняет подробно. То есть мы работаем бок о бок, совместно – и за счет этого уменьшается потребность в документации и выстраивается доверие. Когда мы работаем посредством коммуникаторов, видео- и телеконференций – это ощущение пропадает. Даже лог чата с его собственными словами не является для Заказчика доказательством: «Да, это я писал! Но вы все не так поняли!». Тогда мы начинаем писать подробные user stories и заставлять Заказчика присылать письмо «approved»… Появляется первый документ… Ну дальше думаю знакомо, да? Распределенный agile лишается своей основной опорной точки – общения с Заказчиком глаза в глаза. Отсюда теряются и прочие преимущества – возможность экономить на документации, короткая обратная связь и т.д. Распределенный agile безболезненно работает только когда и команда, и Заказчик чувствуют себя в мире электронных коммуникаций как дома.

• Надо иметь отточенное умение делать agile обычным способом.
  

То есть надо отлично уметь делать agile «по старинке» - всей командой в одной комнате, с Заказчиком под боком, с прямым доступом в среду разработки и на сервера с приложением. Пока вы этому не научились на «отлично» – не пытайтесь запустить распределенную agile-разработку. Это так же фатально, как пытаться научиться пилотировать самолет «вслепую», не научившись предварительно пилотировать вообще. Никогда не начинайте распределенный agile-проект не умея на «отлично» делать обычный agile.

• Надо иметь Заказчика, умеющего работать agile.
  

Заказчик – это отправная точка agile-процесса. Научить Заказчика написанию «хотелок», подготовке тестовых примеров и «торговле» вокруг них – невероятно сложно. Представьте себе кондовую тетку-бухгалтера, сидящую на «Инфе» последние десять лет. А ну как вы ее будете учить писать юзерсториз? Содрогнулись? А теперь представьте себе – это надо сделать удаленно. Как перспектива? Но даже при абсолютно благостно настроенных и старательных кастомерах будьте готовы к тому, что обсуждения, которые раньше занимали 3 минуты – теперь будут занимать 15. Никогда не предполагайте, что Заказчик по умолчанию умеет и согласен работать по agile. Тем более удаленно, когда сил на коммуникации требуется тратить в 3> раза больше времени и сил.

• Убедитесь, что agile в данном случае не инструмент для провала проекта!
  

Гибкость и отсутствие документации создают свободу интерпретации или явного искажения информации. Сообщаю новость – заказчик может быть вовсе не заинтересован в успехе проекта. Он может быть заинтересован в его провале с выставлением Исполнителя в максимально дурном свете. Другой вариант – на стороне заказчика может быть честный и старательный рохля, который ничего не может, ни за что не отвечает и который не в состоянии согласовать приоритеты. А может оказаться некомпетентный болван, которому отсустствие документации и особенно распределенные коммуникации позволяют сваливать на вас любую вину и безжалостно врать даже не глядя вам в глаза. Распределенный agile предоставляет всем категориям балбесов ничем не ограниченную свободу гадить вам на голову. Поэтому не давайте им использовать agile таким образом.
Никогда не начинайте делать распределенный agile с Заказчиком, который не вызывает у вас доверия – agile предоставляет слишком много свободы, в том числе желающим дурить вам голову. А распределенный agile не позволяет своевременно выявить паскуд.

• Готовьтесь к командировкам
  

В идеале – каждую первую и последнюю неделю релиза вы у Заказчика. Программа-минимум – несколько дней для совместного планирования спринта. В идеале вы – это вся команда. Программа-минимум – ключевые люди проекта. Иначе вы потратите несколько недель на обсуждение того, что поняли бы за несколько дней совместного размахивания руками возле доски, исчеркивания скриншотов и выдергивания новых листов из флипчарта. Никогда не думайте, что обойдетесь без регулярных командировок – позаботьтесь включить их в бюджет.

• Надо иметь быструю и надежную связь.
  

Быстрый интернет – это от мегабита и выше. Но в идеале – лучше иметь 10 мбит. Надежная – это когда в любой момент вы можете набрать номер Заказчика и быть уверенными что вас соединят и что качество связи будет хорошим. Иначе усложненная и затрудненная коммуникация не состоится – кому охота долбаться с нестандартной звонилкой провайдера IP-телефонии, которого вы выбрали из-за стоимости звонков $0,01. А нет коммуникации – нет agile. Я рекомендую выбрать единого провайдера для всей команды в каждой физической локации – это снижает риски на порядок. Никогда не экономьте на инструментах коммуникации. Лэптоп + 2 мбита интернета – обязательное условие.

• Стандартизируйте инструменты!
  

Вася пользуется SomeSCCClient 1.3 и без проблем коннектится к репозитарию. Федя поставил себе 1.4 Beta и не может соединится, а версию для Mac OS X, который стоит у Маши, еще и не планируется выпускать. В довершение праздника Коля не может участвовать в голосовых конференциях Skype, потому что он использует альтернативный скайп-клиент, а метафора, которую вы дописали этой ночью, не читается после пересохранения ее в формате docx. Я думаю, вы уже поняли о чем я. Никогда не разводите зоопарк на проекте – у всех стоят одни и те же инструменты, настроенные одинаковым образом. Даже если кто-то клянется, что «я все настрою сам!» - набор инструментов для проекта должен быть стандартизирован и по их использованию должны быть написаны гайдлайны.

• Надо иметь отличный VPN + доступность сервисов.
  

Все системы, необходимые для работы, должны быть доступны в режиме 24х7. Иначе нечего пенять девелоперу в Новосибе, что он не коммитнул код, когда ваш сервер лежал, а вы его не включали так как у вас видите ли ночь. С доступностью вопрос решается просто, даже если у вас небольшой бюджет – используйте системы, работающие через HTTP, и hosted services типа Beanstalk если не можете себе позволить свою серверную ферму. Другое дело – доступ к серверам в локальной сети, своей или Заказчика. В отсутствие личного присутствия единственный способ отладить криво вставший билд – влезть в него ручками. Отсутствие доступа терминалом в таком случае понятно чем чревато. Никогда не экономьте на инструментах, которые используются 10 раз на дню – раздражение встанет дороже.

Надеюсь, у меня получилось отсоветовать вам устраивать распределенные agile-проекты. Но даже если нет – пройдите по чеклисту, добейтесь его выполнения с самого начала проекта.

Я вам обещаю – вы скажете мне «спасибо» в течение первой же недели, причем не один раз.