Просмотр сообщений
16
ПО Аналитика / Re: Управление изменениями требований
« : 01 Апреля 2016, 18:22:59 »
По данной теме я встану на сторону Дениса. Не в том смысле, что не люблю инструменты, а в том, что сперва, нужно иметь хорошее представление об изменениях, а только потом надеяться на инструменты.
Из своего опыта могу сказать след.:
1. Качество проработки изменения напрямую зависит от ваших знаний о системе, в которую изменения вносятся. Если не знаете систему, то первой обязанностью является изучать её на высоком уровне, а только потом изменять. В реальной ситуации может не быть возможности достаточно глубоко погрузиться (особенно в начале проекта), но держать в голове приоритет изучения системы нужно всегда.
2. Если вы не достаточно хорошо знаете систему, то полагаться на документацию нужно с оглядкой на то, что она может не соответствовать коду, быть неполной и некачественной. Очень часто именно так и бывает. В первую очередь, изменения влияют на живое тело проекта, т.е. на его код. Иными словами, оперировать нужно по телу, а не по мед.карте, а вся ответственность за жизнь пациента на вас. Поэтому, при анализе влияния изменений нужно проявлять максимальную дотошность к текущему фактическому состоянию системы. Аналитик вообще её должен всегда проявлять. Кажется, что это окупается с лихвой.
(Немножко оффтоп) 2.1 Купер сравнивает изменения ПО с рубцом после операции. Большое количество рубцов приводит к потере гибкости и хрупкости организма. Хорошо проработанные изменения отличаются не только полным описанием влияния, но и тем, что они стремятся к уменьшению количества рубцов в перспективе. Я не могу сказать, что всегда получается этому следовать, но держать это в голове тоже стоит.
3. Изменения в больших системах подразумевает правку кода в куче мест сразу. Поэтому, на большие изменения можно писать отдельный документ. Может не всегда нужно это делать, но если не уверены в качестве анализа влияния, то можно подсунуть команде на ревью.
Я видел ситуации, когда даже сами разработчики затрудняются оценить последствия изменения для системы. Это вполне может встретиться на больших проектах. Я никогда не видел ситуации, чтобы команда ругала отдельный документ на большие изменения. Кажется, он всем нравится. В любом случае, документ - это выражение вашей осмысленной работы над изменением.
Есть другой вариант. Если все спецификации содержатся в одном большом документе, то в качестве документа об изменении можно использовать diff версий(например - tfs + share point.wiki). Если по проекту несколько спецификаций, то нужно обеспечит так, чтобы изменения во всех документах можно было просмотреть в одном месте. Не следует разработчикам заставлять лазить по куче разрозненных документов. Велика вероятность, что кто-нибудь что-нибудь да пропустит ...
Лично мне нравится для изменения дополнительно описывать причину, источник, и ещё пару параметров.
Ещё мне нравится CR(change request) из той же самой DOORS. Видео можно на youtube найти.
4. Для изменений на больших данных с большой динамикой изменения стоит продумывать пути отступления. Это может и не очень частая ситуация, но стоит держать в голове гипотетическую ситуацию неотката.
5. Нужно выбросить из головы идею о том, что какой-либо инструмент когда-нибудь защитит от "человеческого фактора на 100%" в плане анализа влияния изменений. Дело в том, что человеческий фактор начинается с момента внесения требований в это самый инструмент. Если внесены кривые, неполные и неактуальные требования, то инструмент не поможет в любом случае.
6. Иногда изменения затрагивают большое количество чужих подсистем. Для таких случаев полезно иметь актуальные dfd или деплоймент диаграммы или диаграммы компонентов или спеки по интеграции. В любом случае, если вы знаете что, с вашей системой / подсистемой связана другая чужая, то всегда следует проверить возможное влияние на ней.
Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше. Он не создает рамок. Инструменты загоняют в рамки различныхbest practice. Само по себе это не плохо, но всему свое время. Надо научиться видеть картину сверху, чтобы потом суметь адаптировать свой подход к изменениям в любой команде и к любому инструменту. Кажется, это будет универсально.
Обещать не буду, но может поищу материалы, которые сойдут за гайдлайны по изменениям.
Простите если кого утомил. многобуков. Не сдержался
Из своего опыта могу сказать след.:
1. Качество проработки изменения напрямую зависит от ваших знаний о системе, в которую изменения вносятся. Если не знаете систему, то первой обязанностью является изучать её на высоком уровне, а только потом изменять. В реальной ситуации может не быть возможности достаточно глубоко погрузиться (особенно в начале проекта), но держать в голове приоритет изучения системы нужно всегда.
2. Если вы не достаточно хорошо знаете систему, то полагаться на документацию нужно с оглядкой на то, что она может не соответствовать коду, быть неполной и некачественной. Очень часто именно так и бывает. В первую очередь, изменения влияют на живое тело проекта, т.е. на его код. Иными словами, оперировать нужно по телу, а не по мед.карте, а вся ответственность за жизнь пациента на вас. Поэтому, при анализе влияния изменений нужно проявлять максимальную дотошность к текущему фактическому состоянию системы. Аналитик вообще её должен всегда проявлять. Кажется, что это окупается с лихвой.
(Немножко оффтоп) 2.1 Купер сравнивает изменения ПО с рубцом после операции. Большое количество рубцов приводит к потере гибкости и хрупкости организма. Хорошо проработанные изменения отличаются не только полным описанием влияния, но и тем, что они стремятся к уменьшению количества рубцов в перспективе. Я не могу сказать, что всегда получается этому следовать, но держать это в голове тоже стоит.
3. Изменения в больших системах подразумевает правку кода в куче мест сразу. Поэтому, на большие изменения можно писать отдельный документ. Может не всегда нужно это делать, но если не уверены в качестве анализа влияния, то можно подсунуть команде на ревью.
Я видел ситуации, когда даже сами разработчики затрудняются оценить последствия изменения для системы. Это вполне может встретиться на больших проектах. Я никогда не видел ситуации, чтобы команда ругала отдельный документ на большие изменения. Кажется, он всем нравится. В любом случае, документ - это выражение вашей осмысленной работы над изменением.
Есть другой вариант. Если все спецификации содержатся в одном большом документе, то в качестве документа об изменении можно использовать diff версий(например - tfs + share point.wiki). Если по проекту несколько спецификаций, то нужно обеспечит так, чтобы изменения во всех документах можно было просмотреть в одном месте. Не следует разработчикам заставлять лазить по куче разрозненных документов. Велика вероятность, что кто-нибудь что-нибудь да пропустит ...
Лично мне нравится для изменения дополнительно описывать причину, источник, и ещё пару параметров.
Ещё мне нравится CR(change request) из той же самой DOORS. Видео можно на youtube найти.
4. Для изменений на больших данных с большой динамикой изменения стоит продумывать пути отступления. Это может и не очень частая ситуация, но стоит держать в голове гипотетическую ситуацию неотката.
5. Нужно выбросить из головы идею о том, что какой-либо инструмент когда-нибудь защитит от "человеческого фактора на 100%" в плане анализа влияния изменений. Дело в том, что человеческий фактор начинается с момента внесения требований в это самый инструмент. Если внесены кривые, неполные и неактуальные требования, то инструмент не поможет в любом случае.
6. Иногда изменения затрагивают большое количество чужих подсистем. Для таких случаев полезно иметь актуальные dfd или деплоймент диаграммы или диаграммы компонентов или спеки по интеграции. В любом случае, если вы знаете что, с вашей системой / подсистемой связана другая чужая, то всегда следует проверить возможное влияние на ней.
Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше. Он не создает рамок. Инструменты загоняют в рамки различных
Обещать не буду, но может поищу материалы, которые сойдут за гайдлайны по изменениям.
Простите если кого утомил. многобуков. Не сдержался
