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

Первая конференция: 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). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.
Читать далее »

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив
Читать далее »

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...
Читать далее »

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.
Читать далее »