Персональные инструменты
 

Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02) — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м (Подкасты)
м
 
(не показаны 2 промежуточные версии 2 участников)
Строка 54: Строка 54:
 
Обсуждался и стандартный, горячий вопрос, где должен быть аналитик в Agile?  
 
Обсуждался и стандартный, горячий вопрос, где должен быть аналитик в Agile?  
  
{{note}} Заметим, мы уже неоднократно обсуждали этот вопрос на семинарах и конференциях, см. например, [http://team.custis.ru/2009/03/c-agile.html] или [http://team.custis.ru/2008/12/agile.html].
+
{{note}} Заметим, мы уже неоднократно обсуждали этот вопрос на семинарах и конференциях, см. например, [[Блог:Team/2009-03-06_Cеминар_«Теория_и_практика_Agile»:_(видео)_отчет]] или [[Блог:Team/2008-12-30_Аналитик_в_Agile:_Архаизм_или_необходимость?]].
  
 
А также:
 
А также:
Строка 74: Строка 74:
 
Так что рекомендуем заранее распечатать майндмап, а затем смотреть видео, поглядывая на него…
 
Так что рекомендуем заранее распечатать майндмап, а затем смотреть видео, поглядывая на него…
 
Еще раз извините.
 
Еще раз извините.
 
Ну и скачать сами видеофайлы можно [[Видеотека#2009-12-02 Управление требованиями в Agile|здесь]].
 
  
 
{{vimeoembed|8473772|640|288}}
 
{{vimeoembed|8473772|640|288}}
 +
  
 
{{vimeoembed|8471264|640|288}}
 
{{vimeoembed|8471264|640|288}}
 +
  
 
{{vimeoembed|8474663|640|288}}
 
{{vimeoembed|8474663|640|288}}
 +
  
 
== Подкасты ==
 
== Подкасты ==

Текущая версия на 21:06, 15 июля 2011

Аннотация

Опять «про управление требованиями»? Ну сколько можно! Действительно, начало зимы вообще оказалось очень богато на IT-eventы для всех типов аналитиков, будь то системный, бизнес-аналитик, или просто растущий тестировщик:

Так вот, на это нытье мы скажем — «Надо Федя, надо!».

Ибо «управление требованиями» — штука несколько эфемерная, где сложно отделить правильные, эффективные подходы от неправильных и даже безумных.

Например, нельзя программировать совсем уж безумно — сразу будет видно, что ничего не работает (и даже не компилируется). Можно сравнить две программных реализации, выяснить, какая лучше по скорости, какая — по использованию памяти и диска.

А «Управление требованиями» — штука из «мира людей» — т.е. в любом случае, «команда вытянет», и очень трудно сравнить разные проекты, с разным управлением требованиями, это возможно только после многолетнего анализа, иначе всегда будет диалог: (…«все стало гораздо удобнее!» — «это аукнется вам через пять лет!»…)

Так вот, наблюдение за аудиторией (как докладчиками, так и участниками) ReqLabs показало огромный, практические не пересекающийся спектр, так сказать, представлений об управлении требованиями.

Считают, что управление требованиями это:

  • Cбор требований.
  • Сбор и документирование любой ценой. Причем, документирование это:
    • Документы в шаблонах ГОСТ 34 серии.
    • Бумажное согласование с заказчиком с росписью и мокрой печатью.
    • Обязательное заполнение Специальной Коммерческой Системы Управления Требованиями, с обязательным атрибутированием и классифицированием. Потом еженощное поддержание всего этого в актуальном состоянии.
  • Сбор не важен, а вот анализ — всегда обязателен, должен быть глубоким, все расжевывающим до уровня абсолютных быдлокодеров. Да, дело это не быстрое, ну да того стоит.
  • И да, traceability любой ценой, а там хоть трава не расти.
  • Управление требованиями заказчика — суть манипуляция заказчиком, хвост вертит собакой, рулит НЛП;
  • «Управление требованиями» — это то, что написано в книгах великих — Маркс-Энгельс-Ленин Леффингуэл-Коберн-Вигерс, все остальное — жалкий паллиатив для неучей.

Т.е. очень сильно доминирует технический консерватизм, ориентировка на исторически унаследованные (или усвоенные у Гуру Эльфов Запада) best practices. Т.е. best practices не моложе десяти лет.

Note.svg По моему (Стас Фомин) мнению, это даже не проявление карго-культа, а скорее ситуация, иллюстрируемая грустным историческим анекдотом:


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

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


Да, на самом деле — все эти best practices былы вполне эффективны и востребованы в свое время, но сейчас динамика софтверных проектов сильно изменилась, и старые догмы становятся страшным тормозом.

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

В результате, про управление требованиями в Agile пока мало что известно, и природа, которая не терпит пустоты, заполняет ее безумными слухами — «В идеальном Agile нет документации» (из выступления докладчика на ReqLabs).

Соответственно, наше собрание пыталось закрыть эти лакуны.

Note.svg Ведущими встречи были Никита Филиппов и Максим Гапонов, активно делился своими бизнес-кейсами Павел Афанасенко.

Например, мы пришли к выводу, что составление концепта проекта (Vision), по сути является «внепроектной», специализированной исследовательской деятельностью, в не зависимости от того, что будет практиковаться дальше — «Водопад» или Agile (так что для Agile-команд вполне применимо то, что обсуждалось на семинаре «Разработка концепции ПО» (семинар UML2.ru)).

Обсуждался и стандартный, горячий вопрос, где должен быть аналитик в Agile?

Note.svg Заметим, мы уже неоднократно обсуждали этот вопрос на семинарах и конференциях, см. например, Блог:Team/2009-03-06_Cеминар_«Теория_и_практика_Agile»:_(видео)_отчет или Блог:Team/2008-12-30_Аналитик_в_Agile:_Архаизм_или_необходимость?.

А также:

  • связанные вопросы сбора и приоритезации требований (включая методы оценки трудоемкости, и разрешения конфликтов у стейкхолдеров);
  • трансляции требований на уровень задач и реализации разработчиками;
  • что, как, когда и чем эффективно документировать.
  • ну и отдельная песня — usability.


Итак, смотрите видео или слушайте аудио, распечатайте конспект-майндмап.

Майндмап-конспект

Видео

Caution.svg Мы вынуждены извиниться — на этой встрече произошел технический сбой (мы ищем причины и виновных), и в отличие от предыдущих встреч не удалось записать скринкаст построения майндмапа! Не повезло, извините еще раз. Поэтому выкладываем только записи из жанра ток-шоу («говорящие головы»), подкасты-аудиозаписи (ниже) и окончательный конспект-майндмап (см. выше). Так что рекомендуем заранее распечатать майндмап, а затем смотреть видео, поглядывая на него… Еще раз извините.




Подкасты


Dilbert (2006-01-29).jpg



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02)»