Difference between revisions of "Блог:Стас Фомин/SECR-2011: сводки с полей/Open-Space по Agile"

From Wiki4Intranet
Jump to: navigation, search
Line 13: Line 13:
  
 
Хотя на самом деле, Сазерленд всегда говорил о максимальной '''автономности команды''', а не о унификации юнитов.
 
Хотя на самом деле, Сазерленд всегда говорил о максимальной '''автономности команды''', а не о унификации юнитов.
Т.е. в команде да, должны быть все самые необходимые специальности, и чтобы не было никаких блокирующих зависимостей от «отделов».
+
Т.е. в команде да, должны быть все самые необходимые специальности, и чтобы не было никаких блокирующих зависимостей от «отделов» (блокирующий «ад отделов тестирования и документирования»).
  
 
Я изложил свое понимание разумной кроссфункциональности, которой имеет смысл добиваться:
 
Я изложил свое понимание разумной кроссфункциональности, которой имеет смысл добиваться:

Revision as of 17:36, 6 November 2011

Open-Space по Agile на SECR2011.jpg

После доклада Асхата и панельной Agile-дискуссии, несколько десятков совсем упертых, кому было еще мало аджайла, собрались в первой резервной аудитории, для самого простого Agile-формата:

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

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

Я ненадолго присоединился к теме «Кроссфункциональность в Agile». Мнения там были разные, от защитников узкой специализации, до только что прослушавших самого Сазерленда («Чувак! Я только что слушал Сазерленда, если ты не в курсах — это он придумал SCRUM, и он сказал…» → бггг, спс), и жестко стоящих на позиции абсолютной кроссфункциональности и взаимозаменяемости членов команды.

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

Я изложил свое понимание разумной кроссфункциональности, которой имеет смысл добиваться:

  • Кроссфункциональность по коду и предметной области — если задачи у команды более-менее однородные:
    • какой-то фреймворк работы с данными
    • серверная энтерпрайз логика
    • лес каких-то бизнес-форм

→ то да, надо добиваться совместного владения кодом и взаимозаменяемости, чтобы никто не сидел на «своих» классах-пакетах-формах.


Разумная кроссфункциональность (версия Стаса Фомина).svg



(«санитары-стрелки»)