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

Есть такая популярная тема для обсуждения - вопрос применимости гибких методологий для разных типов проектов. «Ну да, Agile - это, конечно, очень интересно», - сказал мне недавно мой начальник. - «Но все это теория, а в жизни, увы, так не получается. У нас большой проект, удаленный заказчик и вообще…». Еще один коллега высказался немного конкретнее: «Существует куча проектов, в которых ты никак не применишь гибкие методы. Например, при работе с государственными организациями. Или если у тебя команда из одних новичков…». Существует даже несколько книг на тему того, когда стоит применять гибкие методологии, а когда - нет. Ни в коем случае не претендуя на истину в последней инстанции, хотелось бы поделиться своим взглядом на этот вопрос. Ниже в нескольких абзацах я постараюсь объяснить, почему, по моему мнению, Agile подходит для всех (ну, или для абсолютного большинства) проектов, и что я под этим понимаю.

Continue reading →

Пусть agile-процесс изначально и рассчитан под небольшие проекты и локальные команды — его вполне можно масштабировать. Главное для этого — открытость и смелость проектных команд и, в первую очередь, руководства.
Откажитесь от ложных целей вроде бюрократичной отчетности и стратегии прикрытия задницы, сконцентрируйтесь на получении необходимого вам продукта. Экспериментируйте с длительностью итераций, составом команд, способами взаимодействия и тестирования… Да, вы будете совершать ошибки, но суть гибкого адаптивного процесса в том, чтобы признавать свои ошибки, учиться на них и постоянно улучшать процесс, а не пытаясь скрыть ошибки и искать козлов отпущения. Технологии и процессы несовершенны, люди несовершенны, мир несовершенен… но это не означает, что не мы не должны учиться и улучшать качество своей работы.

http://mourk.com/blog/2008/05/05/scaling-agile/

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

Вот есть классная штука - грузовик Caterpillar. Грузоподъемность - караул. Места в кузове - можно дом разместить. Проходимость - хоть вообще без дорог езди. По всем параметрам - чудо-агрегат.

Внимание вопрос - есть в аудитории автомобилисты? Почему вы, уважаемые автомобилисты, на нем не ездите? Тут же следуют ответы: слишком много жрет топлива, фиг на ней запаркуешься, нам такие объемы груза перевозить не надо, да и вообще - слишком дорого стоит железяка.

Если перефразировать это для софта: слишком дорогая лицензия, требует саппорта, половина его фич нам не нужна.

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

С машиной вполне все понятно. А вот с софтом автоматизации\поддержки процессов получается почему-то совершенно не очевидно.

Уважаемые коллеги! Аналогия полная! Не покупайте никаких тулов, пока со всей очевидностью не увидите какие конкретно задачи они для вас решают! Иначе может оказаться, что для поездки в супермаркет вы купили грузовик Caterpillar! Зачастую вам вполне хватит PostIT! и Excel.

Как выбирать себе тул? Запустите процесс на PostIT! или Excel. Поработайте месяц-другой. Когда сможете написать “нас больше не устраивает Excel, так как нам еще нужны фичи А, Б и Ц, причем желательно чтобы А была …, а Б и Ц были…”, вот тогда переходите к выбору нужного тула, в котором А, Б и Ц реализованы наилучшим способом. Это дает еще один положительный момент - выбранный тул принимается всей командой, так как его необходимость осознанна и принята. Прикол в том, что через два месяца вы можете решить, что вам не нужен никакой другой тул! Потому что имеющийся делает все что надо, а лучшее - враг хорошего.

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

Думаю, имеет смысл написать спец. статью про бэклог в Excel + SharePoint? Прошу высказываться - писать ли такую статью или нет.

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

Вот как-то так исторически сложилось, что последний год вокруг один сплошной 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-проекты. Но даже если нет – пройдите по чеклисту, добейтесь его выполнения с самого начала проекта.

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

Хороша сформулированная проблема как минимум наполовину состоит из решения. Проект с хорошо сформулированными user stories обречён на успех.

Приглашаем желающих послушать и принять участие в обсуждении темы “User Stories - Написание, отбор, оценка” (ведущий - Павел Габриель) на третьей встрече сообщества, которая состоится 17 июля в офисе ScienceSoft (ул. Л. Беды, 2, третий этаж), начало в 18:30

Желающие принять участие - сообщите, пожалуйста, о своём желании письмом.

Большое спасибо всем, кто сказал, что бы он хотел услышать! Однако вопрос был “кто на какую тему готов выступить?” Пока есть четыре темы и два желающих, так что приглашаю всех голосовать:

 Loading …

Agile, как Scrum или XP, уже не просто понятия технические, процессные или идеологические. Это понятия маркетинговые. Заказчики задают вопросы: “А ваша команда работает по Scrum?” А сами уже пишут строгое ТЗ на пол года вперед. Им кто-то когда-то рассказал, что Scrum позволяет делать проекты лучше. И они в это поверили, но что это такое не узнали.
Каждый находит в Agile что-то свое, что ему хорошо и удобно.

Заказчик:
– О! Agile позволяет всегда видеть что делается в разработке. Теперь-то они не отвертятся, что мол релиз будет готов через месяц! Я смогу лучше контролировать их работу. Только не на этой неделе… все дни расписаны, а на следующей неделе конференция 3 дня. Пусть работают, а там через месяц время найдется. Continue reading →

ОК, я освоил технологию публикации слайдов :)  Презентация со встречи про экономику проекта:

Вчера 13 мая, в офисе компании Epam прошла очередная встреча Agile-сообщества.
На ней Денис Петелин читал доклад “Экономика agile-проекта“. Презентацию ждем от него. Видео записывалось, и его планируется выложить. После доклада с интересом пообщались на тему: как сами заказчики любят Agile и чем же экономика для них.
Меня попросили добавить на сайт сообщества средства для голосования. Поэтому собственно и первый вопрос…

 Loading …

Как вы думаете, зачем мы делаем проекты? Думаете, чтоб сделать Систему? Ответ неверный – те, кто поциничней, уже подсказывают – «чтобы заработать деньги». Тема нашей встречи – как зарабатываются деньги в agile-проектах. Для начала задумывается один докладчик:

Денис Петелин, «Экономика agile-проекта». В докладе:

1. Действительная цель проекта – заработать деньги. Два случая – заработка процессом выпуска (например, оффшорная разработка) или заработка продуктом (например, выпуск утилиты).
2. Случай первый: зарабатываем собственно на выпуске.
   1. Почему прибыль (profit) на проектах с большой выручкой (revenue) зачастую минимальна?
   2. Рассматриваем механизм минимизации прибыли на больших проектах. Выделяем составляющие (неопределенность, риск, расползание границ, изменчивость требований) и думаем, как с ними бороться.
   3. Смотрим, как посредством agile мы минимизируем влияние этих составляющих – короткие итерации, usability first, игра в планирование.
3. Случай второй: зарабатываем уже на продукте.
   1. Идеи недостаточно. Что кроме идеи?
   2. Соотносим выгоду и «хотелки».
   3. Печальный вывод – в топку бесплатные версии.
   4. Опасности типа «этого хочет мега-клиент Х!».
   5. Проактивный, а не реактивный баг хантинг.
4. Выводы и дискуссия.

Если есть еще желающие высказаться по теме «Экономика agile-проекта», обязательно предлагайте идеи в комментах к этому посту! J Мы вас обязательно пригласим.

Всех желающих присутствовать прошу регистрироваться здесь.

Встреча пройдет 13 мая в 18-30 по адресу Хоружей 29, 5 этаж, офис 54-1. Ожидаются кофе и булки.