|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02)Материал из CustisWiki(перенаправлено с «Agilerussia-2009-12-02»)
Короткая ссылка: Agilerussia-2009-12-02 СодержаниеАннотацияОпять «про управление требованиями»? Ну сколько можно! Действительно, начало зимы вообще оказалось очень богато на IT-eventы для всех типов аналитиков, будь то системный, бизнес-аналитик, или просто растущий тестировщик:
Так вот, на это нытье мы скажем — «Надо Федя, надо!». Ибо «управление требованиями» — штука несколько эфемерная, где сложно отделить правильные, эффективные подходы от неправильных и даже безумных. Например, нельзя программировать совсем уж безумно — сразу будет видно, что ничего не работает (и даже не компилируется). Можно сравнить две программных реализации, выяснить, какая лучше по скорости, какая — по использованию памяти и диска. А «Управление требованиями» — штука из «мира людей» — т.е. в любом случае, «команда вытянет», и очень трудно сравнить разные проекты, с разным управлением требованиями, это возможно только после многолетнего анализа, иначе всегда будет диалог: (…«все стало гораздо удобнее!» — «это аукнется вам через пять лет!»…) Так вот, наблюдение за аудиторией (как докладчиками, так и участниками) ReqLabs показало огромный, практические не пересекающийся спектр, так сказать, представлений об управлении требованиями. Считают, что управление требованиями это:
Т.е. очень сильно доминирует технический консерватизм, ориентировка на исторически унаследованные (или усвоенные у Гуру Эльфов Запада) best practices. Т.е. best practices не моложе десяти лет.
В Сибири было много колоний старообрядцев, не признающих царскую власть, не служивших в армии и т.п. На случай появления царских войск и чиновников у них был заготовлен не раз срабатывающий лайфхак — выходили навстречу с крестным ходом, портретами императора и патриарха, имперской символикой. К сожалению, ситуация изменилась, и когда до старообрядцев добрались красноармейцы, получилось, скажем так, нехорошо. Да, на самом деле — все эти best practices былы вполне эффективны и востребованы в свое время, но сейчас динамика софтверных проектов сильно изменилась, и старые догмы становятся страшным тормозом. При этом, в отличие от конференций разработчиков, которые уже давно в теме Agile (не важно согласны ли они с этими подходами, или нет), часто попытки рассказать об Agile-подходах и инструментах, встречали глубокое неприятие, основанное на незнании («Что такое вики-системы? А где там ставить подписи и печати?»). В результате, про управление требованиями в Agile пока мало что известно, и природа, которая не терпит пустоты, заполняет ее безумными слухами — «В идеальном Agile нет документации» (из выступления докладчика на ReqLabs). Соответственно, наше собрание пыталось закрыть эти лакуны.
Например, мы пришли к выводу, что составление концепта проекта (Vision), по сути является «внепроектной», специализированной исследовательской деятельностью, в не зависимости от того, что будет практиковаться дальше — «Водопад» или Agile (так что для Agile-команд вполне применимо то, что обсуждалось на семинаре «Разработка концепции ПО» (семинар UML2.ru)). Обсуждался и стандартный, горячий вопрос, где должен быть аналитик в Agile?
А также:
Майндмап-конспектВидео
Подкасты
Репликация: База Знаний «Заказных Информ Систем» → «Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02)» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
![]() |
![]() |