Результаты первой встречи Agile Club’a.

Итак, что же успели обсудить:

• Работа с требованиями
• Проведение stand-up митингов
• Что делать, если нет product owner’а
• Project management systems

Попутно обсудили еще много мелких вопросов

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

Мне лично было очень интересно сравнить подходы “продуктовых” и “заказных” проектов

Весенний Agile Club будет в немного другом формате - изначально будет определенна одна (возможно, несколько) тем для обсуждения. И будет несколько человек, которые выступят в роли “экспертов” по данной теме. Возможно, будут очень небольшие (20-30 минут) доклады “для затравки”. Но дискуссия все-таки будет общая.

Детальная информация по весеннему Agile Club’у должна появиться до конца марта.

Пора оживляться, весна скоро

В Беларуси начинает свою работу Agile club. Agile club - это ежемесячные встречи с обсуждениями актуальных вопросов в формате open space, небольшие доклады и воркшопы. Количество участников встреч намеренно ограниченно - 20 человек. Люди, которым есть что рассказать.

Первая встреча - 25 февраля, 17:00 - 20:00.
ул. Кальварийская, 25 (рядом с метро Молодежная), к. 424 (спасибо Exigen Services за предоставленное помещение).

Участие бесплатное.
Предварительная регистрация обязательна.

1. Если кто-то команду собрал, то она не самоорганизующаяся. Ну типа самоорганизующаяся команда – это когда какие-то парни сами взяли и организовались в команду. Это часто так, но это не всегда обязательно. Например толковый продукт менеджер создает самоорганизующуюся команду, чтобы пожать преимущества ее использования. Толковый лидер может подбирать себе единомышленников для создания продукта. Когда они собрались и запустились – появилась самоорганизация. От того, что у истоков  создания команды стоит кто-то – она не перестанет быть самоорганизующейся.
2. Самоорганизующаяся команда предполагает отсутствие контроля и может привести к недостижению бизнес-целей. Вот эта штука меня насмерть убила. Из чего следует – вообще не понял. Команда создается именно под достижение этих самых бизнес-целей, они постоянно обновляются и их достижение измеряется. Вот способ достижения бизнес-целей – остается на усмотрение команды. Команда придумывает наилучший способ исходя из своего понимания своих сильных и слабых сторон, и именно в этом прелесть самоорганизации. Если “команда” “самоорганизуется” для того, чтобы делать исключительно то что ей нравится так как она считает правильным тогда когда ей этого не хочется – это не команда, это клика, одна из ошибочно называемых командой сущностей.
3. В самоорганизующейся команде нет лидера. Как правило самоорганизующася команда выстраивается вокруг лидера, у которого есть понимание целей и способов их достижения, которые остальные разделяют. Таким образом у них возникает дискуссии только о том, как лучше воплотить в жизнь это самое общее видение. Да, иногда собирается подборка товарищей, которые бесконечными терками выводят общее видение – но это не есть непременное условие, при наличии страстного компетентного лидера создание команды происходит гораздо бодрее.

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

Лавра

Мое посещение конференции началось с неожиданной прогулки по Киевско-Печерской Лавре. Хорошая утренняя прогулка по памятнику зодчества охраняемого Юнеско. Да, это прекрасно.

«Лавра» на Яндекс.Фотках

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

Agile Base Camp

«Твиттер-фид на конференции» на Яндекс.Фотках

К большому сожалению на конференцию не смог прибыть мой коллега Денис Петелин с докладом про выбор инструментов для Agile проекта. Оказалось, что данная тема крайне возбуждает умы проджект-менеджеров и разработчиков ближнего зарубежья. Вместо выбора тул-сета  я зачитал аудитории семинар о том, как управлять рисками в проекте. Это мой внутрениий тренинг в EPAM.

На мой взгляд риск-менеджмент относится к общей практике управления проектами и прекрасно ложится на agile-проекты. Безусловно там есть свои ньюансы. Риски waterfall проектов — это одна из приичин самого появления agile как методологии.

Этот семинар вызвал массу интереса со стороны… епамовских менеджеров. Уже поступили запросы на проведение внутренних вебинаров для agile-команд.

Coach Camp

«Coach Camp» на Яндекс.Фотках
Второй день. У меня сложилось такое ощущение, что не все из тех кто были на этом собрании являются (или планируют являться) agile-сенсеями. К сожалению, опоздал на знакомство. Но тем не менее в ходе наших обсуждений и разговоров я записал для себя много интересных моментов, которые надо прорабатывать вглубь.

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

Для меня agile состоит из следующих составляющих:

• Философия.
  Как, зачем, почему в agile придумали работать именно так.
• Процессы.
  Конкретные процессы, которые надо ставить в компании + инстументы, позволяющие работать по agile.
• Знания + навыки.
  Набор знаний, которые надо донести до команды, которая думает использовать agile, а также навыки, которые надо помочь им развить.

По этим трем направлениям мне видится внедрение agile в компании от 30 человек. В более маленьких компаниях процессы никто не описывает, а выбор иструментов уже сейчас довольно широк (BaseCamp, AcuNote, JIRA…, не говоря уже про task-board и Excel).

Довольно часто я слышу про такие ситуации: люди попадают в какой-то странный процесс, рисование карточек, ежедневные отчеты, отсутствие какой-либо документации, а спустя пол года (опа!) узнают, что это был Скрам. Я могу допустить, что процессы в этом случае были поставлены верно и на уровне процесса там было нечто напоминающее Скрам, но без обучения сотрудников (знания + навыки) и без понимания почему это делается именно так (философия) такой процесс буксует самым страшным образом. Более того, сотрудники демотивируются попадая в такой проект.

Задумайтесь об этом, когда будете внедрять agile.

Оригинал: http://yuri.shilyaev.com/archives/2010/01/29/473/kiev-agile-base-camp.html

Выкладываем презентации участников и видео из того, что уже есть.

Юрий Шиляев. Экономика Agile-проекта.

Денис Петелин. НЕ-аджайл: введение в распознавание фальшивой монеты, или основы аджайла.

Доклад Дениса Петелина еще не залит на шароварный видео-хостинг. Но его можно посмотреть здесь.

Павел Габриель. Обязательные практики Agile-проекта и правило ППП.

Видео выступления Павла:

Обязательные практики agile-проекта и правило ППП from alovak on Vimeo.

По мере добавления материалов мы обновим этот пост.

Еще Лео Лознер говорил: “Ребята, осторожнее со словами - слова имеют значение”.

Презентация Владимира Габриеляна из Mail.ru на конференции HighLoad++. По сути он перечисляет методы работы и практики из agile (в частности XP), но при этом работа идет по ТЗ.

И вот что примечательно (к слову развернувшейся тут беседы): слова agile, scrum, XP в презентации вообще не фигурируют. Т.е. можно рассказывать про то, как надо работать, но при этом agile’ом это не называть. Да и вообще никак не называть.

В Scrum есть такое понятие, как sprint demo – новая версия показывается заказчику (product owner’у). Обычно проводится более-менее закрыто – команда, product owner и, возможно, кто-то из stakeholder’ов. «Открытое» sprint demo имеет некоторые плюсы:

• Знание о том, что demo будет открытым, и что там будут присутствовать коллеги, создает более сильный commitment
• Заставляет команду подумать о том, как продукт используется с точки зрения пользователя – нужно будет показывать это
• Продукт становится более стабильным – редко кто хочет показывать нестабильный продукт коллегам
• Это позволяет другим командам иметь какое-то представление о том, что происходит в компании
• Команда имеет возможность похвастаться своими достижениями
• Улучшает презентационные навыки команды
• Иногда можно получить ценные замечания от присутствующих
• Успешное публичное sprint demo дает команде сильное ощущение того, что они чего-то добились

Иногда невозможно (или бессмысленно) проводить публичное sprint demo. Например, когда:

• Контракт запрещает демонстрацию продукта даже другим сотрудникам компании
• Возможности продукта тяжело продемонстрировать, например, framework
  Хотя в случае framework’a можно построить демо-приложение (что будет полезно и пользователям framework’а)

Не все так просто

Если бы «открытое» sprint demo было легко проводить, его организовывали бы чаще. Есть много сложностей, одними из основных являются:

• Команда боится публичной демонстрации
  • Не привыкли работать с широкой аудиторией
  • Боятся критики – помощь со стороны менеджера проекта/Scrum master/кого-то из stakeholder’ов будет весьма кстати
  • Много ошибок в продукте – следующий раз продукт будет более стабильным
• Компания настолько разрозненна, что никто не интересуется работой других – это может быть серьезной проблемой и результаты публичной демонстрации являются хорошим индикатором
• После неудачного спринта – в этом случае особенно полезно делать sprint demo открытым. Это заставит команду проанализировать допущенные ошибки. Но нужно помочь команде понять, что иногда это случается, жизнь на этом не заканчивается – лучше подумать о том, как избежать таких проблем в будущем. Команда становится более стрессоустойчивой.

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

Результаты

История в начале статьи взята из реальной жизни. Помогла ли открытая демонстрация? Да.

В начале было сильное неприятие самой идеи. Но, после некоторого нажима со стороны менеджера проекта, команда согласилась провести открытое sprint demo. Одним из основных опасений команды было то, что никто не придет. Сюрприз – пришло так много людей, что пришлось перенести демонстрацию в большее помещение.

В итоге продукт стал более удобным и стабильным. Настроение в команде поднялось – проведение демонстрации и возможность похвастаться перед коллегами привнесло оживление.

Можно ли сказать, что эта практика должна быть обязательно применена каждой командой? Нет. Но в определенных ситуациях она принесет пользу. Пробуйте.

На сайте DI.by еще старая программа висит.

Предыдущее сообщение также обновлено.

Рассматриваются 4 методики разработки (не буду называть их методологиями или фреймворками):

• Водопадный процесс разработки (Waterfall Development);
• Итеративный водопад (Iterative Waterfall Development);
• Скрам (Scrum Development), как разновидность Agile;
• Лин — бережливое произвдство (Lean Development).

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

Еще одна сложность: Lean отталкиваясь еще от принципов Деминга должен быть использован не только непосредственно в команде разработке ПО, а должен быть наложен на весь процесс целиком, что еще больше усложняет его полноценное использование.