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

Agile club, 14 августа, как всё было

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

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


Встреча прошла в расслабленной, весёлой обстановке, за что спасибо GlobalLogic за отличное располагающее к этому помещение, ну и всем, кто пришёл.

Было просмотрено 30 минут часового видео Agile Transition от Майка Кона.

После чего мы переключились на обсуждения тем:



В частности:

  • Работа с требованиями
  • ScrumMaster vs. Project Manager
    Совмещение ролей.
    Кто и как в своих компаниях решает эти проблемы
  • У кого были какие проблемы при переходе на Agile и как вы их решали-решили
  • Архитектура приложений при Agile разработке
  • Кто с помощью чего пишет Acceptance Tests
  • Как правильно "продать" такой процесс спонсору-команде
  • Agile и размер компании
    Где и почему проще внедрять Agile











В ходе ретроспективы были выделены следующие комментарии и пожелания, которые стоит учесть на следующей встрече.

Хорошее:
  • просто хорошо
  • хорошая инициатива! считаю, что ведущий должен быть более инициативным, не спрашивать "что делать?" более одного раза и предлагать своё мнение
  • нашлось 3 чел, которых интересно послушатьхорошо проводить такие встречи регулярно
  • интересные обсуждения
  • обсуждение тем прошло классно
  • хорошее место
Отрицательные моменты:
  • кто есть кто непонятно
  • пицца быстро закончилась
  • нету кваса
  • нет чёткого пониманя "аутсорсинга" и "спонсора"
  • нет чёткого понимания scrum
  • нет понимания психологической подготовки PM и SM
  • не чётко определены темы, дискуссии часто заходят в тупик, и не делается никаких выводов
Пожелания:
  • находить несколько видео на выбор и все же его смотреть
  • 10 мин на представление народа и знакомствонужны беджики с именами, компаниями
  • подготовить case study, разобрать scrum проект
  • нужно более чёткое определение ведущего и его активность
  • нужен ведущий, который постоянно подводит итог и ведёт мысль, идею, дискуссии
  • более лёгкая еда, что больше говорили, а не ели
  • больше напитков (вода и пиво на выбор)
  • более активно обсуждать темы в googlegroups до встречи, как результат будет выше посещяемость и люди смогут лучше подготовить и решить свои реальные проблемы, а не просто потрындеть
До встречи 28 августа! Там же, тогда же.

ПОПУЛЯРНОЕ

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

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


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

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

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


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

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

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

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