Comments 9
Встретить Григория можно и здесь, на Хабре. :)
Это отлично.
Вспомнился MindManager — карты памяти. По сути это разноуровневые списки. Можно сворачивать-разворачивать топики на карте, таскать их мышкой в разные другие уровни. А можно выдать весь текст одним большим текстовым списком. Или импортировать список — разные уровни автоматом подхватываются и отображаются.
Проблема с большими картами — там можно завязнуть…
Вспомнился MindManager — карты памяти. По сути это разноуровневые списки. Можно сворачивать-разворачивать топики на карте, таскать их мышкой в разные другие уровни. А можно выдать весь текст одним большим текстовым списком. Или импортировать список — разные уровни автоматом подхватываются и отображаются.
Проблема с большими картами — там можно завязнуть…
Вспомнил свои изыскания давно забытых лет.
www.klerk.ru/soft/articles/2034/
www.klerk.ru/soft/articles/1880/
Кстати, искал эти ссылки и узнал, что одну из статей использовали в диссертации :) Ну, приятно, что сказать.
За эти годы было внедрено десятка полтора систем управления требованиями. Включая пару строго бумажных. Управляя то 20 сотрудниками, то двумя не раз пришлось убедиться, что сапожники все еще без сапог. Хотя разнообразных решений — можно годами раскапывать.
Тема до сих пор актуальна и это как раз вопрос того, что цена зрелости — довольно высока. То, что использует большая команда слишком дорого для маленькой. И переходы от маленькой команды к более крупной — это довольно трудные ступени на лестнице.
Так-то всего пяти уровней модели зрелости — маловато. И переходы не очень-то формализованы. Чаще всего на уровне «рисуем окружности, а следующим шагом рисуем сову». Все так и держится на опыте, который нарабатывается годами. И опыт пяти проектов совсем не обязательно подходит на шестом…
www.klerk.ru/soft/articles/2034/
www.klerk.ru/soft/articles/1880/
Кстати, искал эти ссылки и узнал, что одну из статей использовали в диссертации :) Ну, приятно, что сказать.
За эти годы было внедрено десятка полтора систем управления требованиями. Включая пару строго бумажных. Управляя то 20 сотрудниками, то двумя не раз пришлось убедиться, что сапожники все еще без сапог. Хотя разнообразных решений — можно годами раскапывать.
Тема до сих пор актуальна и это как раз вопрос того, что цена зрелости — довольно высока. То, что использует большая команда слишком дорого для маленькой. И переходы от маленькой команды к более крупной — это довольно трудные ступени на лестнице.
Так-то всего пяти уровней модели зрелости — маловато. И переходы не очень-то формализованы. Чаще всего на уровне «рисуем окружности, а следующим шагом рисуем сову». Все так и держится на опыте, который нарабатывается годами. И опыт пяти проектов совсем не обязательно подходит на шестом…
Очень полезная для понимания нужд аналитика статья!
Имею вопрос касательно
Согласно Каких требований не должно быть?: Спецификация требований не содержит деталей дизайна или реализации. Здесь же явно прописана реализация. Это от недостатка возможности инструмента или просто другой подход к формулировке требований?
По идее клиент выставляет требования без реализации, а реализация — это уже новые требования к GUI, появляются в процессе анализа требований заказчика. Исходя из моего опыта лучше «очищать» исходные требования от планируемой реализации, ибо то, что «на самом деле» хочет заказчик, бывает скрыто под его идеями о том, как это сделать.
PS: У нас тоже имеется «замах» на управление требованиями, но пока свет в конце тоннеля только проглядывает, хотя деревья требований и связи между различными ветками имеются (картинка кликабельна и ведет на статью).
Здесь кое-что имеется из того, что упомянуто в статье. В папке «Предложения» было размещена исходная задача. Для ее решения была создана задача совершенно в другом проекте (PK/backlog), эта задача была, в свою очередь, декомпозирована в требования в других подветвях проекта PK и даже в другом проекте Srv (см. колонку Path). Тут еще и этапы видны (Milestone).
Имею вопрос касательно
Согласно Каких требований не должно быть?: Спецификация требований не содержит деталей дизайна или реализации. Здесь же явно прописана реализация. Это от недостатка возможности инструмента или просто другой подход к формулировке требований?
По идее клиент выставляет требования без реализации, а реализация — это уже новые требования к GUI, появляются в процессе анализа требований заказчика. Исходя из моего опыта лучше «очищать» исходные требования от планируемой реализации, ибо то, что «на самом деле» хочет заказчик, бывает скрыто под его идеями о том, как это сделать.
PS: У нас тоже имеется «замах» на управление требованиями, но пока свет в конце тоннеля только проглядывает, хотя деревья требований и связи между различными ветками имеются (картинка кликабельна и ведет на статью).
Здесь кое-что имеется из того, что упомянуто в статье. В папке «Предложения» было размещена исходная задача. Для ее решения была создана задача совершенно в другом проекте (PK/backlog), эта задача была, в свою очередь, декомпозирована в требования в других подветвях проекта PK и даже в другом проекте Srv (см. колонку Path). Тут еще и этапы видны (Milestone).
«Спецификация требований не содержит деталей дизайна или реализации» — эта фраза, очевидно, взята из стандарта IEEE 830 (который описывает структуру и наполнение SRS):
Вторая фраза явно намекает на то, что стадии сбора требований и проектирования разделены. В Agile подходах, например, это не так. Кстати, примеры в презентации взяты из реального проекта, который мы вели с использованием Agile-практик.
Идея SRS, как и других документо-ориентированных методологий, состоит в максимальном отчуждении знаний от конкретных людей в виде документации. Это оправдано в действительно больших проектах, когда при разработке требований вы ещё не знаете, кто и когда будет их реализовывать. Но в небольших или внутренних проектах (вроде того, который использовался в примере), от такого отчуждения бывает больше вреда, чем пользы. Команда является носителем знаний, цикл от выявления требований до реализации короткий, и вполне можно включать детали реализации в требования (если только вы не собираетесь потом по этим требования создавать всю систему заново).
SRS should not describe any design or implementation details. These should be described in the design stage of the project.
Вторая фраза явно намекает на то, что стадии сбора требований и проектирования разделены. В Agile подходах, например, это не так. Кстати, примеры в презентации взяты из реального проекта, который мы вели с использованием Agile-практик.
Идея SRS, как и других документо-ориентированных методологий, состоит в максимальном отчуждении знаний от конкретных людей в виде документации. Это оправдано в действительно больших проектах, когда при разработке требований вы ещё не знаете, кто и когда будет их реализовывать. Но в небольших или внутренних проектах (вроде того, который использовался в примере), от такого отчуждения бывает больше вреда, чем пользы. Команда является носителем знаний, цикл от выявления требований до реализации короткий, и вполне можно включать детали реализации в требования (если только вы не собираетесь потом по этим требования создавать всю систему заново).
Хорошая система управления требованиями должна поддерживать все пять уровней зрелости, а так же переходные процессы между уровнями, для того чтобы в разных проектах можно было заводить процессы адекватные ресурсам этих проектов.
В самом деле, если у нас проектный офис достаточно гомогенных проектов, нам не так уж много надо — единый процесс, шаблоны, делай раз, делай два, делай три.
А если у нас проекты от пары дней одного сотрудника до нескольких сотен человеко-месяцев большей половины компании — то и вариантов организации процессов на проектах нам потребуется не один и не два.
Плохо когда СУТ не дает нужных возможностей. Но еще хуже, когда СУТ обязывает выполнять недешевые процессы тогда, когда они не обязательны.
В самом деле, если у нас проектный офис достаточно гомогенных проектов, нам не так уж много надо — единый процесс, шаблоны, делай раз, делай два, делай три.
А если у нас проекты от пары дней одного сотрудника до нескольких сотен человеко-месяцев большей половины компании — то и вариантов организации процессов на проектах нам потребуется не один и не два.
Плохо когда СУТ не дает нужных возможностей. Но еще хуже, когда СУТ обязывает выполнять недешевые процессы тогда, когда они не обязательны.
Скоро год с момента написания статьи. Есть ли какие-нибудь позитивные изменения в деле работы с требованиями? Появились ли удобные инструменты?
Супер доклад, спасибо!
Проблемы всегда, когда функции аналитика берут разработчики, и нет времени на поддержание актуальности требований.
Идеал — требования переводят с спеки-сценарии — которые автоматически запускаются и отмечаются — работают они или нет. Тем самым указывается актуальность требований на базе которых были созданы «приемочные» тесты.
Возможно без такой привязки невозможно гарантировать актуальность той или иной постановки.
Проблемы всегда, когда функции аналитика берут разработчики, и нет времени на поддержание актуальности требований.
Идеал — требования переводят с спеки-сценарии — которые автоматически запускаются и отмечаются — работают они или нет. Тем самым указывается актуальность требований на базе которых были созданы «приемочные» тесты.
Возможно без такой привязки невозможно гарантировать актуальность той или иной постановки.
Sign up to leave a comment.
Чего я хочу от инструментов разработки требований. Затычки, костыли и грабли СУТ