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

open space

Автор: Алексей Кривицкий.

На встрече-конференции Agile Gathering 5 помимо докладов мы планируем провести сессию в формате "open space".

Ниже приведено описание базовых концепций open space, с которыми мне довелось познакомиться и опробовать на практике.


Цель open space:

  • Обсудить в открытом формате (когда каждый может высказаться) интересующие аудиторию темы, которые формируются по ходу проведения общения.
Условия для проведения open space:
  • Помещение разбивается на условные зоны - места проведения дискуссий. Каждая зона представляет собой набор стульев, выстроенных кругом, флипчарт и маркер с номером зоны.
  • В зале организован специальный стенд, где формируется агенда (расписание) дискуссий. Агенда доступна в течение всего времени проведения open space и является основой для проведения дискуссий.
  • В зале присутствует фасилитатор - человек, задачей которого является оказание помощи аудитории для максимизации получения пользы от мероприятия. Он организовывает помещение и зоны, помогает следить за временем и агендой, объясняет правила и т.д. Важно понимать, что мероприятием "владеют" участники, фасилитатор же просто помогает им достичь их целей - эффективного общения.
Правила такие:
  1. Когда бы это ни началось - это правильное время.
  2. Кто бы ни пришёл - это те, кто нужны.
  3. Что бы ни произошло - это единственное, что могло произойти.
  4. Когда закончилось - тогда закончилось.



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

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

Шаги проведения:
  1. Участники (все присутствующие на мероприятии) формирует агенду - что, где и когда будет обсуждаться.

    Для этого желающие наклеивают на заготовленную стену стикеры с названием темы, временем и номером зоны, где предполагается провести эту дискуссию.


  2. После того, как начальная агенда готова (нет больше тем для обсуждения или заняты все тайм слоты и зоны), участникам даётся время на ознакомление с агендой и реструктуризацией (группировкой) тем, если это необходимо.


  3. Когда агенда готова, начинается время дискуссий.

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

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

Приходите, подискутируем! :)

ПОПУЛЯРНОЕ

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

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


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

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

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


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

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

Календарь тренингов по Agile

Наши партнёры по тренингам: