Программистское мракобесие

[metaclass]

Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.

А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

Comments

[russian-sla.livejournal.com]

"разработка новых моделей автомобилей" - так ведь я же написал, что для инновационных проектов (задач) нужен немного свой подход
"военное дело" - т.е. уставы и руководства вообще не имеют право быть в военном деле? все можно выиграть только "силой духа"? :)
"Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного" - ну уж я этим заниматься не буду. :) и рекомендовать это делать никому не буду. CMMI я порекмендую применять именно в том объеме и в том виде, которые позволят получать более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

[gaperton.livejournal.com]

> так ведь я же написал, что для инновационных проектов (задач) нужен немного свой подход

Любой проект по разработке ПО сопряжен с решением проблем, и является в той или иной степени "инновационным". Проект по внедрению готового ПО - нет.

> "военное дело" - т.е. уставы и руководства вообще не имеют право быть в военном деле? все можно выиграть только "силой духа"? :)

Не понимаю, из каких моих слов можно сделать такой вывод, не подключая фантазии. Уставы и руководства имеют весьма посредственное отношение к содержательной части планирования военных действий, и к выигрышу в войне, так же как и соблюдение coding standard не поможет сделать коммерчески успешный продукт. Речь не о них.

> "Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного" ну уж я этим заниматься не буду. :) и рекомендовать это делать никому не буду.

Это я привел для иллюстрации того, чем разработка ПО отличается от изготовления гамбургера. Соблюдение технологии не _гарантирует_ вам успеха. Таких гарантий у вас нет и быть не может.

> CMMI я порекмендую применять именно в том объеме и в том виде, которые позволят получать более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Тезис CMMI про снижение рисков при повышении уровня - как минимум спорен, и многие уважаемые и опытные специалисты его не разделяют, см. аргументацию по этому поводу Тома ДеМарко в Peopleware в качестве примера. Это при том, что те же люди сходятся на том, что критерии зрелости CMMI, в целом, неплохая штука, основанная на best practices.

[(Anonymous)]

более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Скажите, это действительно ВЫБОР? Предсказуемость одного измерения результата достигается за счет другого?

Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?

[metaclass.livejournal.com]

"Порекомендуете ли Вы CMMI при целевой функции вида "не очень дорого И достаточно качественно"?"

В этом случае на CMMI надеятся бесполезно, имхо. Там может быть "очень дорого и качественно" или "очень дорого и можно пользоваться".

[(Anonymous)]

"религия денег", ага

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

[russian-sla.livejournal.com]

Под "выбором" я имел в виду следующее. Любые изменения (в процессах, вообще в организации дел) должны проводится ради решения конкретных проблем и (или) улучшения имеющегося (в т.ч. предсказуемости каких-либо (!) показателей, примеры которых я и привел). И этот принцип должен действовать независимо от того, что из моделей, методологий вы собираетесь внедрять. Хоть CMMI, хоть Scrum, хоть XP, хоть еще чего.

Любые изменения сами по себе затратны. Но это, прежде всего, инвестиции, результат использования которых и надо потом определить. Если не оценить результат - это бессмысленные изменения. Если используете CMMI в качестве базы - определитесь: чего вы хотите добиться этим. Потом сопоставьте ожидаемые затраты и сопоставьте: дорого это или нет. Многое в затратах, связанных с внедрением CMMI, занимают официальные мероприятия и подготовка к ним. Если же официальный "публичный" рейтинг вам не важен, то затраты на внедрение будут не на много больше, чем любой другой методологии или модели.