К основному контенту

Первая конференция: Agile Gathering



Благодарности

Итак, первая встреча украинского agile сообщества состоялась. Спасибо всем, кто посвятил свой выходной беседам об agile.



Благодаря компании Ciklum у нас было светлое и просторное помещение, которое создало комфортную обстановку для четерыхчасового общения. Спасибо, ребята, за поддержку.

Просим прощение у всех тех, кто подал заявки после закрытия регистрации, и не попал на встречу. Надеемся увидеть вас всех в следующий раз.

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

Спасибо Лене Терёшиной и Тиму Евграшину за содействие в организации.



Участники

На встрече было порядка 25 человек из таких украинских IT компаний как: Ciklum, Miratech, Luxoft UA, KCK Software, GlobalLogic, Sotware MacKiev (SMK), Yukon-Software Ltd., Novades, Kyivstar GSM, Infopulse, IMX Ltd., SoftServe Inc.

Формат

Формат встречи был экспериментальным, что, возможно, было немного непривычно и неожиданно для некоторых. Мы использовали практику just-in-time планирования, с тем, чтобы продемонстрировать гибкость и адаптивность agile.

Разбив встречу на три короткие часовые итерации, мы тратили 5-10 минут в начале каждого часа на сбор и выбор тем. Таким образом мы обсуждали наиболее важные вопросы, интересующих большинство участников.

У всего есть как и положительные стороны, так и недостатки. Недостатком в таком подходе была трата времени на планирование встречи в обмен на список горячих тем.

Благодаря вашим комментариям, мы сделаем все, чтобы следующая встреча была более эффективной.



Результаты ретроспективы

Основываясь на опросе, мы делаем такие выводы:
  • делать немного больше планирования в подготовке ко встречи с тем, чтобы сэкономить время для собственно представления материалов и дискуссий; сбор тем и голосование можно проводить online;
  • необходимо более чётко сформулировать и ограничить тему встречи с тем, чтобы во-перых чтобы более чётко определить целевую аудиторию, а во-вторых сфокусировать выступающих и аудиторию на проблемной области;
  • увеличить время, отведенное на встречу, чтобы глубже раскрыть темы;
  • проводить более четкое модерирование дискуссий и вопросов;
  • не забыть начать с фазы знакомства участников друг с другом
  • выделить больше свободного общения: как вариант за счет проведения встречи в формате open space



Обсужденные Темы
  • Presentation: Review of agile approaches
    (Sergey Yevtushenko)
  • Presentation: Agile principles and values
    (Sergey Yevtushenko)
  • Presentation: Case of implementing Scrum in Pluron, Acunote tool
    (Sergey Smetana)
  • Presentation: Intro to User Stories (дискуссия)
    (Alexey Krivitsky)
  • Presentation: Estimation and planning: agile release, iteration planning
    (Alexey Krivitsky)
  • Discussion: Scrum certifications (дискуссия)
  • Discussion: Tools for Scrum (дискуссия)


Отложенные Темы
  • Presentation: Introduction to Scrum
  • Discussion: How to "sell" Scrum to your customers
  • Discussion: "100% done" as a key concept of Scrum and Agile (дискуссия)
  • Discussion: Choosing iteration length
  • Discussion: Retrospectives as a heart of agile
  • Discussion: How to introduce Scrum to project
  • Discussion: What Scrum gives to the team
  • Discussion: Project Manager in Scrum (дискуссия)
  • Simulation game: Drawing a map
Давайте обсуждать темы в оффлайне.



Будущее

Начало положено. Следите за анонсами встреч на сайте группы в разделе события. Предлагайте даты и темы в дискуссиях.
И вообще, давайте общаться!

Материалы


ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


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

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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