Фирма

«Инрэко ЛАН»

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

Когда я подписывался на участие в конференции Agile Days, я испытывал опасения нарваться на очередное рекламное мероприятие. К счастью, опасения оказались напрасны.

Мероприятие проходило 17 сентября в Санкт-Петербурге в гостинице Азимут, что на берегу реки Фонтанки. Надо отдать должное организаторам – московской компании ScrumTrek – для проведения конференции были выбраны залы, расположенные на 18-м этаже гостиницы. Не удивительно, что на кофе-брейках можно было заметить участников конференции, увлеченно фотографирующих Питер через огромные панорамные стекла. Вообще, уровень организации оказался очень неплохим, и это при том, что конференцию посетили более пятисот человек, а график докладов был весьма плотным.

Программа конференции включала в себя 3 параллельных потока: keynote, вторая сцена и мастер-классы. Пришлось делать трудный выбор – какому потоку и когда отдать предпочтение. Ну а порой хотелось раздвоиться.

Уровень и стиль докладов заметно отличались. Интересными были примерно треть докладов. Остальные или ориентировались на неподготовленных слушателей и были, поэтому сугубо поверхностными, или были откровенно скучными.

Секция keynote была посвящена в основном теоретическим вопросам Agile, новым методам и подходам. Доклады на второй сцене более тяготели к практике – представители разных компаний рассказывали о своем опыте работы по гибким методологиям. Как это часто бывает, на конференции прозвучали не все заявленные доклады – некоторые докладчики просто не смогли приехать.

Ниже – заметки по наиболее любопытным докладам.

Дмитрий Лайер, Softline: Rugby, Scrum и командная работа.

Первый доклад на Второй сцене,  призванный расшевелить пока еще сонную аудиторию и задать тон всему мероприятию. Докладчик появился на сцене с регбийным мячом под мышкой и без долгих предисловий начал рассказывать о методологии Scrum и ее связи с регби. Собственно, термин "scrum" и пришел из регби, где он означает толкотню, схватку вокруг мяча.

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

Асхат Уразбаев, ScrumTrek: как продавать Agile заказчику

Отличный доклад по одной из самых актуальных проблем применения гибких методологий. На нем хотелось бы остановиться подробнее. Вообще говоря, круг вопросов, поставленных в докладе, был шире:

  • какие проблемы могут быть решены с помощью Agile,
  • когда Agile будет работать, а когда он противопоказан,
  • как убедить заказчика, руководство и коллег, что Agile – это хорошо,
  • как адекватно оценивать Agile-проект,
  • как "бороться" с желанием заказчика раздувать функциональность и менять требования по ходу проекта, и, наконец,
  • что делать, если проект уже идет, а заказчик начинает вести себя все менее адекватно?

В своем выступлении Асхат обозначил общий подход к "продаже" Agile, а конкретно – методологии Scrum:

  • выявление проблем и их последствий,
  • предложение решений и обсуждение их выгод,
  • рассмотрение опасений,
  • создание безопасного окружения для пилотных задач,
  • общий commitment – наличие соглашения по всем вопросам.

При этом акцент следует делать на то, что требования в любом случае будут меняться на разных этапах проекта, а Scrum – это методология управления этими изменениями. Кроме этого, один из основных принципов Scrum – короткие итерации, по окончании которых заказчику демонстрируется новая функциональность. Значимость этого принципа также нужно всячески подчеркивать при "продаже" методологии заказчику.

Общие правила взаимоотношений с заказчиком таковы:

  • обязательное наличие backlog'a (портфеля задач, фич) – списка функциональности, которая должна быть реализована;
  • заказчик может поменять любую нереализованную фичу на эквивалентную по трудозатратам;
  • задачи оценивает исполнитель (не заказчик!),
  • заказчик может добавить или удалить фичу из бэклога,
  • заказчик может менять порядок нереализованных задач,
  • заказчик формально принимает реализованные задачи,
  • в любой момент заказчик вправе остановить разработку.

Далее Асхатом был озвучен ряд вопросов из серии "а что если". Скажу сразу – все они заслуживают внимания, поскольку за ними маячат хорошо знакомые подводные грабли.

Вопрос: а что если заказчик будет напихивать новые фичи и упираться при разговоре об изменении срока (и стоимости)?

Ответ:

  • все разговоры вести вокруг бэклога;
  • демонстрировать незыблемость позиции относительно согласованных правил (тот самый commitment!);
  • переводить разговор в конструктивное русло – обсуждать, что можно убрать из бэклога, что урезать, но дополнительную работу бесплатно на себя не взваливать;
  • уметь говорить НЕТ.

Вопрос: а что если заказчик будет раздувать функциональность фич: "Такое поведение тут подразумевалось! Вы должны это сделать!"?

Ответ: следует действовать в духе партнерства с заказчиком, а именно:

  • подчеркивать с самого начала, что заказчик и исполнитель являются партнерами;
  • постоянно объяснять, что раздувание функциональности затягивает сроки;
  • с самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения;
  • в конце концов, учиться на собственных ошибках при реализации новых фич.

Вопрос: а что если заказчик будет менять фичи, находящиеся в работе в текущей итерации?

Ответ:

  • создавать приемочные тесты или четко формулировать критерии приемки фич;
  • согласовывать тесты и критерии приемки до начала итерации.

Вопрос: а что если заказчик при наличии проблем будет сваливать вину на нас?

Ответ:

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

Вопрос: А что если мой заказчик (в данном случае – его представитель) очень занятой человек и не может уделить мне достаточно времени?

Ответ:

  • создать ритм (расписание) взаимодействия, настаивать на соблюдении ритма;
  • тщательно готовиться к встрече – чтобы она была максимально содержательной;
  • ловить заказчика везде, где возможно: за пуговицу в коридоре, on-line;
  • опять - культивировать хорошие отношения;
  • настаивать на общении - в рамках расписания, а также при возникновении любых вопросов и проблем, требующих его вмешательства.

Вопрос: а что если мой заказчик технический человек и постоянно вмешивается в работу команды?

Ответ:

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

Вопрос: а что если мой заказчик все-таки неадекватен?

Ответ:

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

Тезисы этого доклада достаточно просты и вполне согласуются со здравым смыслом. Однако, собранные воедино, они представляют собой прекрасную памятку всем, кто начинает новый проект или переводит уже существующий на рельсы Agile/Scrum.

Еще перед докладом Асхат принес два уже знакомых мяча для регби и устроил небольшой конкурс – предложил любому желающему "продать" ему, Асхату, Agile, а также устроил небольшой опрос на знание методологии Scrum. Agile продавался не очень бойко, а вот после опроса оживились и приготовились слушать даже самые сонные. :-)

Продолжение следует.

Метки: agile | Agile Days 2010 | конференция | Санкт-Петербург

Комментарии  

#1 liv 08.11.2010 15:45
И "как адекватно оценивать Agile-проект"?
Заказчик, особенно неподготовленный (в первый раз, заказывающий разработку ПО), хочет знать сколько будет стоить готовый продукт, ну или хотя бы первая рабочая версия. При этом даже общее описание расходится с тем, что действительно хочет заказчик.
Цитировать
#2 Сергей Чебыкин 08.11.2010 16:13
Об этом - в продолжении. Там было как минимум два доклада, касающихся способов оценки Agile-проектов. Обязательно напишу.
Цитировать

Добавить комментарий