Пирамида требований

Записал несколько подкастов на тему управления требованиями и оценки.

http://agile.rpod.ru/112496.html - здесь я ввёл понятие пирамиды требований
http://agile.rpod.ru/112634.html - тут введено понятие условных единиц измерения для каждого уровня. И показано как условная единица уровня User Story превращается в Story Points.
http://agile.rpod.ru/112772.html - ну а здесь краткое объяснение супер техники коллективной оценки трудоёмкости Planning Poker

Подключайтесь и задавайте вопросы. Будем искать ответы :)

«Agile по-крупному!» — ВИДЕО

Во вторник, 21 апреля, прошла аннонсированная ранее встреча сообщества AgileRussia.ru, озаглавленная «Agile по-крупному!». Изначально тема заявлялась, как разбор сложностей Agile в крупных командах и проектах, обсуждение тонкостей масштабирования, ведь все, что выходит за максимальный размер стандартной Agile-команды в 9 человек, уже требует специальных подходов.

«Waterfall2Agile — Agile для Большой Waterfall компании: нужен? как и что внедрять?» — это пришли ребята из широкоизвестной компании «C», они детально описали свой цикл разработки и структуру проектного управления своего Большого Продукта (достаточно заметить, что цикл тестирования релиза занимал у них 18 месяцев), пояснили возникающие проблемы, и запросили у сообщества предложений по улучшению процесса — включая как Agile-практики, так и технические/инструментальные решения.





«AgilePostmortem» — это была посмертная ретроспектива распределенного Agile-проекта, интересного высокотехнологичного стартапа, к сожалению, «не дожившего до весны».



Оригинал: http://team.custis.ru/2009/04/agile-agilerussiaru.html

Обязанность Agile-коучера: фасилитация

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

Было бы здорово получить список тех практик, которые должен выучить коучер, а потом предложить команде. Вот давеча нашёл сайт, на котором собраны практики фасилитации :)

Facilitation comes from the latin facile, which mean easy. In fact, the role of a facilitator in a group setting is to “make things easy”. It involves planning, organizing, and setting or supporting rules and goals within such groups. It is my goal here to collect and share many of the tricks, techniques and practices that facilitators use in their work.

Более подробнее читайте на сайте: http://facilitationpatterns.org

А inquisitor_rus подсказал суперскую статью - http://ru.wikipedia.org/wiki/Consensus_decision-making

Сопротивляемость изменениям или про тюрьму опыта

Просто приведу цитату, которая просто вызывает благоговенный лепет в моей душе:

Идея о тюрьме впервые была исследована Платоном в «Республике» в знаменитой аллегории пещеры, где Сократ рассуждает о связи видимости, реальности и знания. Перед входом в подземную пещеру пылает костер. В пещере находятся люди, закованные цепями и лишенные возможности двигаться. Они видят только ту стену пещеры, что прямо перед ними. Она освещена пламенем, и тени людей и предметов видны на ней. Обитатели пещеры думают, что тени - реальность, дают им имена, говорят о них и даже связывают звуки, доносящиеся снаружи, с движением теней на стене. Истина и реальность для пленников заключаются в этом мире теней, поскольку они не знают другого.
Однако, считает Сократ, если бы одному из жителей пещеры позволили покинуть пещеру, он понял бы, что тени - всего лишь отражение более сложной реальности, а знания и восприятия его товарищей неверны и искажены. Если бы он вернулся потом в пещеру, он никогда уже не смог бы жить по-старому, поскольку для него мир был бы уже другим. Несомненно, ему трудно было бы смириться со своим затворничеством и стало бы жалко других пленников. Однако если бы он попытался поделиться с ними своим новым знанием, его, вероятно, осмеяли бы. Для пленников знакомые образы пещеры имели бы гораздо большую значимость, чем тот мир, который они никогда не видели. Более того, поскольку человек, получивший новое знание, больше уже не сможет функционировать с прежней убежденностью относительно теней на стене, его сотоварищи, скорее всего, посчитают внешний мир опасным. Это происшествие приведет к тому, что они станут жестче придерживаться знакомого образа мыслей.
Герет Морган. Образы Организации. с.235

И в продолжение к сравнению не-Agile подхода и Agile подхода: многие пытаются устранить неопределённость и защититься от неё через предварительное проектирвоание, детальное изучение требований и анализ. Agile же состоит в том, чтобы учиться на неопределнности и лавировать в её условиях. Аналогичную метафору можно проследить в западном подходе производства (предотвращения через накопление и буфферизацию на складах) и японской модели (от куда, кстати пошли многие Agile практики) производства.

Теперь я полностью понимаю своих не-Agile оппонентов, видать им в пещере уютней :)

Квота идей

Интересная практика для адаптации существующего процесса, да и просто интересная практика развития команды и проекта обнаружена у Джона Паттерсона, президента компании "Нэшнл кэш реджистер". Он всё время записывал :)

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

Практика "Квота идей"
Установите квоту: в день столько-то новых идей, касающихся вашей работы или проекта, - например, по пять идей в день в течении одной недели.

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

Во время ретроспективы, или раньше, будет замечательный повод поговорить :)

Дополнительно:
1. Майкл Микалко. Игры для разума
2. Технологии шевеления мозгами
3. Советы по генерации идей

Agile English (как учить английский по Agile)

Мини-инструкция по изучению английского языка. Идея родилась вчера и уже мною заиспользована.

1. Слушаю текст, повторяя за диктором (лучше брать лингофонный курс, BBC News или др - там где есть тестовка)

2. Услышал новое слово - выписал на карточку (3x4 см)
- с одной стороны слово
- с другой стороны всё предложение, в котором это слово встретилось (вместо слова в предложении оставляю пробел)

3. Оцениваю в English Points сложность изучения этого слова (см. Story Points у Mike Cohn)

4. Переслушиваю абзац, в котором было обнаружено новое слово.

5. Повторяю над каждым незнакомым словом по тексту.

6. Повторно прослушиваю запись.

В результате на руках у меня будут карточки. В свободно время я их перебираю, вспоминаю слова, контекст рассказа. То что запомнилось откладываю. В конце дня подбиваю суммы выученных слов в English Points и радуюсь результатам рисуя диаграмму Velocity ;)

* Ничего не мешает по этому же принципу учить грамматику. Маркер правило на одной стороне карточки, пример правила на другой.

Проектирование по контракту

Интересный подход разработки - проектирование по контракту. Основы подхода заложил Бертрана Мейера. Чтобы быстро разобраться рекомендую классную статью:
http://habrahabr.ru/blogs/crazydev/38612/

Немного философии и сопряжения этой идеи с C#:
http://tagirovarthur.blogspot.com/2007/11/1.html
http://tagirovarthur.blogspot.com/2007/11/2.html

Ну и самого великого маэстро можно читать бесплатно здесь:
http://www.intuit.ru/department/se/oopbases/11/

User Group: Изучение качественного кодирования!

Приглашаю на еженедельные встречи желающих укрепить свои знания и навыки в областях: шаблонов проектирования, рефакторинга и других инженерных практик.

Цель встреч: изучение и углубление знаний в области design patterns. Мы практикуемся и обмениваемся опытом в сфере качественного кодирования, шаблонов, рефакторинга и т.п. (см. выше).

Study Group – помогает осилить сложные книги и идеи, может помочь там, где другие проваливаются, и он поможет тогда, когда в вашем окружении нету тех, кто хочет учиться и расти.



Место встречи:
Кафе в центре Москвы,
Каждую среду в 19 часов
Контакты: syspo_mail.ru
ICQ: 20079282
skype: denis_miller
+7 917 518 68 12 (Денис)

Как назначать задачи в Agile (Task Volunteering)

Вопрос по назначению задач не даёт спать. В ряде веток Agile задачи назначаются руководителем (см. FDD методологию). Но в основном принято задачи разбирать самими разработчиками. Остаётся вопрос - когда?

Вариант 1 (Tasks ownership). В начале итерации все расхватывают задачи, а потом уже помогают друг другу. Общий пул задач. Каждый, кто освободился, берет себе задачу с наивысшим приоритетом.
+ Ориентация на общее решение (приоритетность задач)
+ Выполняется максимально возможное количество самых приоритеных задач
+ Возрастает мотивация (я выбираю сам согласно приоритету, я являюсь вкладом в командный успех)
+ Командная ответственность
+ При появлении высокоприоритетных задач во время итеррации их легко отправить в разработку
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру), а потом поделиться размышлениями с коллегой, взявшим задачу
+ Общее владение кодом
+ Общий стиль программирования
+ Кросс-функционалность
+ Повышение коммуникации

Вариант 2 (Individual Commitments). Общий стэк задач на всю итерацию, и каждый отхватывает самую приоритетную.
+ Ориентация на личные предпочтения
+ Возрастает мотивация (я выбрал задачи сам)
+ Индивидуальная ответственность
+ Специализация разработчиков
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру)
- Разные стили программирования
- Незаменимость учатников
- Снижение коммуникации

Я работал в обоих вариантах. Есть свои плюсы и минусы в обоих. Предлагаю послушать эксперта в области оценки в Agile проектах:

Individual Commitments

When assessing the ability to commit to completing a set of new functionality,
some teams prefer to allocate each task to a specific person and
then assess whether each individual is able to commit to that amount of
work. This approach works well and I’ve recommended it in the past
(Cohn 2004). However, I’ve found that by not allocating tasks while planning
the iteration and not doing the personal math needed to make individual
commitments, the team benefits from the creation of a “we’re
all in this together” mindset.

If you do find a need to allocate tasks to individuals while planning an
iteration, the allocations should be considered temporary and subject to
complete change once the iteration is planned and underway.

src:
1. Mike Cohn Agile Extimating and planning
2. Беседа с Ильёй Сербисом :)