?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

ГОСТ-овский стиль управления

Posted on 2010.08.22 at 17:32

Comments:


george8128 at 2010-08-25 13:04 (UTC) (Link)
>Описанные проблемы возникают не с ТЗ, а с отсутствием управления приоритетами.

Согласен. Но:

> И ГОСТ никак не противоречит скраму. Итерация = этап, и все. ГОСТ вообще не накладывает ограничений на процесс разработки внутри.

ГОСТ 19.102 накладывает достаточно жесткие ограничения: как минимум, даже с учетом 1-го примечания, сначала разработка (рабочий проект) всего-всего, и только потом - внедрение у клиента. Явно противоречит agile-методикам. итеративности выше стадий не предусмотрено.


С остальным не могу не согласиться. Да, ПГР нужен. Ключевые ТТ - тоже. Порядок (общий) сдачи-приемки нужен.
Gaperton
gaperton at 2010-08-25 13:41 (UTC) (Link)
> ГОСТ 19.102 накладывает достаточно жесткие ограничения: как минимум, даже с учетом 1-го примечания, сначала разработка (рабочий проект) всего-всего, и только потом - внедрение у клиента. Явно противоречит agile-методикам. итеративности выше стадий не предусмотрено.

Да, формально это так. Так написано в стандарте.

На практике же все гибче. То есть:

Если работа короткая, и должна по своей логике вестись в один этап - то она так и ведется. Это элементарный здравый смысл - зачем его нарушать? Все понимают, и никто не нарушает.

Если работа по своей логике подразумевает поэтапный ввод системы в эксплуатацию - то после каждого этапа таки должно быть внедрение, как ни крути, и данная работа делается серией ТЗ.

Если же внедрения на промежуточных итерациях не будет - то ничего не мешает оформить результаты итераций как прототипы в рамках эскизного и/или технического проектов. Так, вообще, правильно.

При этом - обратите внимание, - "эскизный проект" и прочие - это _стадия_, внутри которой могут быть _этапы_. А что у нас ГОСТ говорит об этапах?

2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

Бинго. Обитерируйся. :) С учетом первого пункта - вообще красота. Короче, ГОСТ очень гибок. :)

Вот и все. Все что делает ГОСТ - устанавливает общую терминологию в названиях стадий. Это удобно.

На практике, если того требует ситуация, и никто не фанатично не следит за буквой, допустимо вообще класть на названия стадий, и делать так, как надо. Я специально консультировался у "гуру" на эту тему - это нормальная практика, если заказчик не государственный. Проходит вполне нормально.
Евгений
sandu at 2012-03-05 10:23 (UTC) (Link)
Вы несколько раз упомянули, что на каждый этап можно делать отдельное ТЗ. А помимо этого, видимо, и остальные сопутствующие документы? Какое итоговое количество документов вы можете получить (реально получали на практике) и кто в них будет разбираться? Что важнее — кто их будет использовать? Раз ТЗ — это документ, регламентирующий отношения, то, значит, к нему надо аппеллировать разным людям — а для этого надо знать его. И что если вследствие десятка этапов получился десяток ТЗ?

Подозреваю, что пример с Redmine был неспроста. Думаю, ГОСТ-методику работы можно использовать в случае внедрения системы управления требованиями, формируя ТЗ по мере необходимости. Вы, видимо, именно таким вариантом предпочитаете пользоваться?
Gaperton
gaperton at 2012-03-12 14:24 (UTC) (Link)
Необходимым минимумом является наличие двух документов - ТЗ и "Программы и методики испытаний". Они предствляют собой формальный или неформальный "контракт" между заказчиком и исполнителем, и являются руководящими документами при выполнении работ. Их составляют и читают технические специалисты. Для мелких проектов - это обычные программисты, для крупных - руководители. В советской конструкторской школе руководитель является в первую очередь инженером ("архитектором"), это надо учитывать.

ТЗ касается границ проекта (технические требования) и промежуточных контрольных точек (этапы). ТЗ - это короткий документ, несколько страниц.

"Методика испытаний" - описывает подход к приемочному тестированию. Также короткий документ - несколько страниц.

"Программа испытаний" - перечень приемочных тестов, пересечение "методики" и "ТЗ". Этот документ может получится длинным, но представляет собой "чеклист" (контрольный список), и для интересов дела не обязан быть собственно документом. Его успешно заменяет группа задач в трекере.

Все остальные "документы" не являются необходимыми для того, чтобы работала методика. А перечисленные - не обязаны быть документами.

Для больших проектов принято не раздувать ТЗ, а выписывать частные ТЗ на составные части работ, выделив эти составные части. Главное ТЗ определяет задание на все "изделие", а ПМИ к нему - "интеграционные тесты".

Совсем не обязательно ЧТЗ должны впрямую соответствовать этапам - так на практике бывает редко, хотя и возможно.

Ничего страшного в том, что получится 10 ЧТЗ, нет. Особенно, если ЧТЗ будет представлять собой задачу в трекере.

В случае ЧТЗ "заказчиком" является руководитель (который также инженер), ответственный за подразбиение работ на определенном уровне.

В сумме, это совсем не много "документов". И, возможно, полное их отсутствие, при грамотном использовании трекера задач + вики.
Евгений
sandu at 2012-04-16 07:17 (UTC) (Link)
Ухх! Гениально! Жаль только, крайне трудно этот подход пробовать, находясь в госконторе :) Увы, в моем случае это обязательно будут документы, и десятки документов. Но основную идею я понял и попробую применить! Афтар пешы ищо! ©
Gaperton
gaperton at 2010-08-25 13:44 (UTC) (Link)
Короче, все дело в отношении к ГОСТ.

Если относиться к нему как к инструменту - он становится гибок, и полезен. Ибо он таки, не смотря на страшный вид, аккумулирует большой опыт отношений заказчик-исполнитель.

В конце концов, с ГОСТ-19 очень просто аргументированно разбить оплату контракта на этапы, и продать это заказчику. Своими словами попробуй объясни, что за проектирование платить надо.

А вот если относится к нему как к ограничениям - то он будет тупо путаться под ногами и мешать.
george8128 at 2010-08-25 15:20 (UTC) (Link)
С этом полностью согласен.

Спасибо за пояснения к статье. Подход действительно интересный.
Previous Entry  Next Entry