В теме 7 ответов, и 3 участника, последнее обновление сделано пользователем 
Belle Morte 12 г, 10 мес. назад.
-
Сообщения
-
Наверное, это зависит от процесса разработки. У вас итеративный процесс разработки? Получается, что перед каждой итерации должна быть новая версия SRS. А что если после первой итерации выясняется, что нужно полностью переделывать документ? И как в этом случаи вносить изменения в историю?
Или вы после согласования SRS больше не работаете над ним?
В одной книге пишется, что если SRS требует частых изменений, то значит это плохая работа аналитика. В другой книги пишется, что это итеративный процесс и SRS постоянно меняется. У кого какой опыт? К чему лучше стремиться?
Все зависит, скорее, от процесса разработки и соглашений с заказчиком, чем от крутости аналитиков.
В классическом водопадном/итеративном процессе — да, законченная SRS — это точка входа в разработку в рамках проекта/итерации. В жизни подобное встречается нечасто. Видели наверняка такой постулат — "требования изменчивы". И с этим не всегда можно бороться.Таким образом, можно выделить 2 базовые причины (их можно и дальше детализировать/классифицировать, если нужно), почему SRS приходится обновлять:
- Обновления в требованиях, навязанные заказчиком/проектом
- Все остальноеОтвечая на ваши вопросы:
У вас итеративный процесс разработки? Не текущем проекте скорее ближе к agile.
А что если после первой итерации выясняется, что нужно полностью переделывать документ? Странная ситуация. Если это ваша вина — то вынести урок и переделать
. Если так хочет заказчик — то определитесь, выгодно ли это вам/компании/проекту. Это отдельная долгая тема; если вкратце, то в итоге либо начинайте этому противодействовать (если есть, на чем базировать свои аргументы) или по принципу "хозяин — барин" переделайте все.
И как в этом случаи вносить изменения в историю? А в чем проблема? Что является причиной, то и указывайте в истории. Я наверное не до конца понимаю вопрос…
Или вы после согласования SRS больше не работаете над ним? В реале такого практически не бывает. Обычно SRS меняется, и не раз.
К чему лучше стремиться? К успешной, обоюдно выгодной реализации проектаВсе зависит, скорее, от процесса разработки и соглашений с заказчиком, чем от крутости аналитиков.
Может аналитик на столько крут, что сразу понял, что хочет заказчик. Затем перенес грамотно его потребности в SRS, которые почти не меняются. Я так хотел бы :-)
В классическом водопадном/итеративном процессе — да, законченная SRS — это точка входа в разработку в рамках проекта/итерации. В жизни подобное встречается нечасто. Видели наверняка такой постулат — "требования изменчивы". И с этим не всегда можно бороться.
Я бы лучше сказал не «водопадном/итеративном», а «водопадном/детерминированном». Вот что делают книжки с людьми
Хотя могу ошибаться. А возможно просто проблема в терминах и понятиях. Итеративный процесс постоянно подстраивающийся то бишь гибкий (agile). Если я что-то не понимаю, то сразу рубите с плеча! Недопонимание лучше сразу уничтожить.Таким образом, можно выделить 2 базовые причины (их можно и дальше детализировать/классифицировать, если нужно), почему SRS приходится обновлять:
- Обновления в требованиях, навязанные заказчиком/проектом
- Все остальноеГы… )))
Отвечая на ваши вопросы:
[i]У вас итеративный процесс разработки?[/i] Не текущем проекте скорее ближе к agile.
Я думал, что в agile вместо слова «итерации» используется слово «спринт» + ещё всякое. Но agile вроде как итеративный/адаптивный процесс, да?
[i]А что если после первой итерации выясняется, что нужно полностью переделывать документ?[/i] Странная ситуация.
Такого пока не было, но я думаю что вероятность такого не так мала. Всё переделывать реже конечно чем значительную часть SRS. Но всегда ли после первой итерации заказчик даёт подтверждение правильного пути?
Если это ваша вина — то вынести урок и переделать
. Если так хочет заказчик — то определитесь, выгодно ли это вам/компании/проекту. Это отдельная долгая тема; если вкратце, то в итоге либо начинайте этому противодействовать (если есть, на чем базировать свои аргументы) или по принципу "хозяин — барин" переделайте все.
За SRS ответственен аналитик так что всегда будет он крайний.
[i]И как в этом случаи вносить изменения в историю?[/i] А в чем проблема? Что является причиной, то и указывайте в истории. Я наверное не до конца понимаю вопрос…
«Пункт №2. Дата. Все не так. Все переделано». Я думал, что детально необходимо фиксировать изменений — «Пункт №2. Дата. Внесено новое требование ФТ-234» и т.д. Или лучше создать новый документ с новой историей?
[i]Или вы после согласования SRS больше не работаете над ним?[/i] В реале такого практически не бывает. Обычно SRS меняется, и не раз.
Каждое изменении фиксируется в истории? На каком шаге вы предоставляете новую версию SRS?
[i]К чему лучше стремиться?[/i] К успешной, обоюдно выгодной реализации проекта
Ну даа… Сейчас даже с начальством трудно найти общий язык, что уж говорить когда будет внешний заказчик. Эх…
Может аналитик на столько крут, что сразу понял, что хочет заказчик. Затем перенес грамотно его потребности в SRS, которые почти не меняются. Я так хотел бы :-)
Тут скорее дело не в этом. Чаще заказчик меняет свою точку зрения с течением времени, в связи с чем требования и меняются.
Я бы лучше сказал не «водопадном/итеративном», а «водопадном/детерминированном». Вот что делают книжки с людьми
Хотя могу ошибаться. А возможно просто проблема в терминах и понятиях.Думаю, что да, вопрос в терминах. Я хотел донести именно два типа процессов — итеративный (и водопадный в то же время) и неитеративный (тоже водопадный; итераций нет — есть одна большая итерация, называемая "проект"
). Я думал, что в agile вместо слова «итерации» используется слово «спринт». Вот и всё
Ну.. в какой то мере оно так… Лучше вместо слова agile брать конкретные названия процессов, допустим scrum. Agile я рассматриваю скорее как парадигму процессов, а не как конкретный набор методик. Agile отчасти и славен именно тем, что процессы подстраиваются под изменчивые требования. Поэтому изменчивость спецификаций в agile (если они вообще есть) позиционируется не как негативное явление, а как одна из основных причин выбора того или иного agile процесса.
За SRS ответственен аналитик так что всегда будет от крайний.
Не знаю, как у вас, но так абсолютно утверждать — неправильно. Как я уже сказал, тут можно много чего понаписать. Пример: спецификация согласована, система сделана -> заказчик говорит, что хотел совсем не то. Поставят ли это в вину аналитику? Все зависит от кучи факторов. Если это T&M проект + заказчика можно убедить, что все было зафиксировано и нефиг менять хотелки, а ему при этом пипец как надо, то вы получаете в 2 раза больше бабла для компании.
«Пункт №2 все не так. Все переделано». Я думал, что детально необходимо фиксировать изменений типа внесено новое требование ФТ-234 и т.д. Или лучше создать новый документ с новой историей?
Andre, у вас есть одна явная беда. Вы пытаетесь четко следовать неким рекомендациям и правилам. В чем принципиальная разница, как фиксировать историю? Если вы вчера мелкое изменение расписали в истории на 2 абзаца, а сегодня напишете "весь документ был переделан исходя из новых требований заказчика" — чем это плохо? Вы должны оценить и решить для себя: какой для вас лично с точки зрения качества, условий проекта, адекватности команды и т.д. будет оптимальный подход к написанию SRS. Нет единых правил по составлению истории изменений, решайте сами для себя.
Ну даа… Сейчас даже с начальством трудно найти общий язык, что уж говорить когда будет внешний заказчик.
А все, что было расписано выше — это не реальная ситуация? Проекта с заказчиком нет?
Тут скорее дело не в этом. Чаще заказчик меняет свою точку зрения с течением времени, в связи с чем требования и меняются.
Да. Начальство не всегда это может понять. Особенно когда внутренний заказчик приближенный к начальству и он в принципе не может быть крайним.
Думаю, что да, вопрос в терминах. Я хотел донести именно два типа процессов — итеративный (и водопадный в то же время) и неитеративный (тоже водопадный; итераций нет — есть одна большая итерация, называемая "проект"
).
Понятно. Лучше «водопад» — одна большая итерация.
Лучше вместо слова agile брать конкретные названия процессов, допустим scrum.
У вас scrum и вы для него создаете SRS? Допускаю такое, но не читал о таком варианте просто. Обычно там минимум если вообще есть документация. Все типа на доске
Agile я рассматриваю скорее как парадигму процессов, а не как конкретный набор методик. Agile отчасти и славен именно тем, что процессы подстраиваются под изменчивые требования. Поэтому изменчивость спецификаций в agile (если они вообще есть) позиционируется не как негативное явление, а как одна из основных причин выбора того или иного agile процесса.
Согласен.
Не знаю, как у вас, но так абсолютно утверждать — неправильно.
Сейчас у нас так.
Как я уже сказал, тут можно много чего понаписать. Пример: спецификация согласована, система сделана -> заказчик говорит, что хотел совсем не то. Поставят ли это в вину аналитику? Все зависит от кучи факторов. Если это T&M проект + заказчика можно убедить, что все было зафиксировано и нефиг менять хотелки, а ему при этом пипец как надо, то вы получаете в 2 раза больше бабла для компании.
Заказчик внутренний. Приближенный к руководству поэтому он не может быть виновным.
Что есть «T&M»?Andre, у вас есть одна явная беда. Вы пытаетесь четко следовать неким рекомендациям и правилам. В чем принципиальная разница, как фиксировать историю? Если вы вчера мелкое изменение расписали в истории на 2 абзаца, а сегодня напишете "весь документ был переделан исходя из новых требований заказчика" — чем это плохо? Вы должны оценить и решить для себя: какой для вас лично с точки зрения качества, условий проекта, адекватности команды и т.д. будет оптимальный подход к написанию SRS. Нет единых правил по составлению истории изменений, решайте сами для себя.
Эх… когда нет примера на который можно ровняться плохо
А все, что было расписано выше — это не реальная ситуация? Проекта с заказчиком нет?
Что-то с реальной жизни, а что-то нет. Есть проблемы с внутренним заказчиком. Крайний тут могу быть только я (даже когда я ссылаюсь на письма, даты и игнорирования). Меня это не пугает. Просто так меня не съесть
но из этого я хочу сделать хороший урок для себя.
Ушёл домой. Спокойно ночи. Буду завтраЧто есть «T&M»?
Time and Material — вид контракта, при котором оплачиваются трудозатраты, к примеру по часам (упрощенно — принцип "мне пофиг, сколько вы будете работать, главное сделайте проект, а я уж оплачу все, что наработали"). Альтернатива — fixed price, при котором контракт заключается на фиксированную стоимость проекта, без учета ваших трудозатрат.
Эх… когда нет примера на который можно ровняться плохо
Вырабатывайте сами. Сейчас вы, к примеру, не знаете, как оформлять историю изменений. Сделайте так, чтобы было понятно вам лично. По мере поступления комментов от кого бы то ни было допиливайте подход.
Gerych благодарю за ответы!
Жду также ответов от Belle Morte как очень активного участника сего форума да и всех остальных тоже! Не надо стесняться.
Не могу вспомнить ни одного раза, чтобы не пришлось внести хотя бы 1 изменение в SRS уже после того, как уже все было согласовано: как правило, незначительные поправки бывают всегда, реже — что-то меняется кардинально. Бывает, что когда система дойдет до заказчика и он увидит ее в живую, у него сразу появляется еще +100 идей, что еще туда можно добавить. Бывает, что за это время изменятся условия бизнеса: например, выйдет новый закон. Бывают и ошибки со стороны аналитика, куда ж без этого. Бывает, что в процессе разработки и/или тестирования открываются новые факты и что-то приходится переделать. Если изменения несущественны — казалось бы, можно и не трогать SRS, сразу все реализовать — и нет проблем. Но как показывает практика, лучше SRS поддерживать в актуальном состоянии всегда. Иначе возникают проблемы с QA, не всегда можно быстро найти ответ на вопрос заказчика, да и если аналитик поменяется — ему гораздо труднее придется.Я бы сказала, что частота обновления SRS зависит не только и не столько от процесса разработки, сколько от конкретно специфики проекта, в том числе — особенностей заказчика.
У нас процесс итеративный. Для небольших проектов, по которым все с самого начала понятно, создаем одну SRS, покрывающую весь скоуп проекта. В проектом плане делаем разбивку по версиям и определяем, что из фич войдет в первую итерацию. Если нужно, по результатам первой итерации обновляем SRS. Для больших и сложных проектов, когда к тому же нужно распараллелить анализ и разработку, создается SRS для первой итерации, чтобы разработчики могли начинать работу, остальные требования только перечисляются: их конкретизация начинается уже вместе с разработкой первой версии (и все это записывается в пределах одного документа).Был опыт работы на большом проекте, в котором целесообразным оказалось создавать отдельные документы на каждую фичу. Вообще если речь идет о системе, состоящей из отдельных более-менее равноценных компонентов, есть смысл создавать отдельные документы на каждый компонент + один общий, который описывает, как между собой увязываются эти компоненты. Дело в том, что если все пихать в один документ, он вырастает до астрономических размеров, пугает своей величиной разработчиков и оказывается трудным для чтения.
Если после первой итерации оказывается, что нужно полностью переделывать документ: во-первых, надо выяснить, почему так получилось, чтобы (если проблема в аналитике) не повторять ошибок в дальнейшем или (если проблема не в аналитике) пересмотреть процесс работы с требованиями и найти, где заключается проблема. Если проблема в том, что заказчик подписывает документы не глядя, написанием новой SRS проблемы не решить.
Затем я бы оценила масштабы трагедии: действительно ли надо переделывать абсолютно все, или какие-то отдельные фичи останутся такими, как есть? Если время, которое потребуется на переделывание документа, больше, чем время, необходимое на подготовку требований "с нуля", лучше начать "с нуля", на мой взгляд.Касательно "если SRS требует частых изменений, то значит это плохая работа аналитика": это может быть обусловлено как плохой работой аналитика, так и другими факторами.
А стремиться надо к тому, чтобы SRS была актуальной, покрывала все требования заказчика и содержала всю информацию, необходимую разработчикам (и другим заинтересованным лицам).
Вы должны авторизироваться для ответа в этой теме.
