В дебрях водопада
May. 15th, 2013 11:42 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_r
- Waterfall:
- You need well defined requirements or at least clear goals to speak with people that give you money.
- Agile:
- You take the money and then ask your sponsors how to burn it.
Подозреваю, проектов через пять-семь тупые агильщики, начав трепаться про ужасы старых жестких методологий, будут вызывать у меня истерический смех. Не потому, что они не правы в теории, это банальная глупость. А потому, что они дико наивны и даже вообразить не могут, насколько реальность формальных моделей пластичнее того, о чём пишут в книжках. Даже не смотря на то, что книжек этих они не читали.
Впрочем, эта тема дальше не пойдёт. Надо взять чего-нибудь попроще.
Весь опыт работы вокруг спецификаций говорит о том, что в книжках, докладах и сертификатах всё более или менее фигня. Единственное абсолютное и необходимое требование на требование - это наличие двух полей:
- Owner
- Stakeholder(s)
Всё остальное - сахар и может меняться, дополняться, обговариваться, содержать ошибки или вообще отсутствовать. Может быть записано в толстых документах, которые никто не в силах прочесть, может быть запихнуто в тул, может быть зарисовано на салфетке. Всё это восстановимо и исправимо. Иногда дорого, но практически всегда не критично.
И только одно надо вбивать в голову канделябром, выжигать на лбу калёным железом, выдрессировать с помощью всех административных, экономических и психологических кнутов и пряников: всегда и везде писать кто данную конкретную фигню написал и кому она нужна.
Пусть там, даже, стоит «TBD», «UNKNOWN» или «Х/З». Это гораздо лучше, чем десятки и сотни человеколет, которые сгорают в попытках найти того, у кого есть хоть-какая-то информация.
В одном недавнем проекте ко мне подошёл один местный гений и сообщил:
- Надо исправить обработку. Мы тут нашли не используемую колонку «Req_Owner» и будем вставлять туда флаг для разрешённых исключений, чтобы твоя программа не ругалась, когда из требования уровня программного модуля выводится спецификация на интеграционный тест.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-05-16 11:16 am (UTC)Owner
Stakeholder(s)
Да!!!
Это надо писать крупными буквами на обложке каждой книги по Requirements Engineering)
no subject
Date: 2013-05-16 11:48 am (UTC)(ППКС репост) В дебрях водопада
Date: 2013-05-17 07:57 am (UTC)одно мелкое замечание :)
Date: 2013-06-18 05:53 pm (UTC)Вообще речь шла вроде бы о требованиях, нет? Обычно ошибки в требованиях это не "иногда дорого", а скорее "очень дорого" и к тому же приводит к срывам сроков.
А если у нас в проекте сроки и цены некритичны - то что тогда вообще в нем критично? :)
В целом же мысль очень правильная. Особенно когда в проекте много заинтересованных лиц с разными потребностями, и он развивается много лет. На фоне смены части коллектива разработчиков бывает очень забавно когда пытаешься понять, зачем и кому могло понадобиться некое исторически существующеее в системе требование.
Re: одно мелкое замечание :)
Date: 2013-06-18 06:01 pm (UTC)Срыв сроков - это типичное состояние для большинства проектов.
Дорого или нет зависит не от чисел, а от того, сколько ресурсов выделено и сколько можно урвать.
Если требования можно восстановить (даже переделкой после сдачи софта в эксплуатацию) это не критично. Проблема, когда информация потеряна безвозвратно. Тут уже можно только гадать и не известно, какие системные ошибки заложены в результате.
А если у нас в проекте сроки и цены некритичны - то что тогда вообще в нем критично? :)
Обычно, имидж менеджера. В немецких ещё весёлое и радостное настроение команды или изображение этого состояния.