понедельник, 1 сентября 2014 г.

О правилах и специфичности разработки программного обеспечения

Эта статья подготовлена для блогов журнала PCWeek.
Разработка программного обеспечения как вид человеческой деятельности появилась достаточно недавно. Возможно, в следствие этого, а может быть, по другим причинам очень многие верят в то, что ее «аршином общим не измерить, у ней особенная стать» и далее по тексту. Вот об этом предлагаю сегодня и поговорить.
Зарождением промышленной разработки можно смело считать появление OS/360 от компании IBM. Методологий разработки тогда еще не было, и как все это выглядело, можно представить по книжке, в первой редакции которой на обложке были изображены динозавры, утопающие в битумном озере. Да, вы правильно поняли: речь идет о «Мифическом человеко-месяце» от Фредерика Брукса.
А потом появились они – правила. Первая фундаментальная попытка разработать методологию выразилась в стандарте МО США: DOD-STD-2176A. Методология старалась охватить все сферы разработки и включала 250 обязательных требований к процессам и объектам проектирования. Правил оказалось слишком много, и методология не получила широкого распространения.
Следующей попыткой стал RUP, включавший 30 ролей, 20 мероприятий и 70 артефактов. Но и он оказался чрезмерно сложным. Один из разработчиков RUP Уокер Ройс так отозвался о методологии: «Основная проблема RUP в том, что его слишком легко использовать неправильным образом. Она проистекает из того факта, что RUP пытается быть своего рода энциклопедией практик разработки. Он старается включить в себя все. RUP перечисляет все возможные роли, и все варианты процедур в наиболее тяжелом виде, специфицирует артефакты, и пр.» (источник)
Затем появились XP с 13 элементами, Scrum c 8 и даже Kanban c 3. Но до сих пор многие разработчики говорят о специфичности своих задач, нередко в следующих формулировках: «Фу, нам это не подходит, мы сами знаем, как правильно». То есть, несмотря на то, что CMMI MSF позволяет Microsoft разрабатывать командой из более чем двух тысяч человек продукт, добавляя новый функционал в веб-версию ежемесячно и в desktop-версию каждые три месяца, не подходит команде из Тмутаракани, потому что она (команда) специфическая. Они сами изобретут велосипед по разработке программного обеспечения вместо того, чтобы воспользоваться мировыми стандартами.
Кроме того, в последнее время благодаря активной рекламе гибких методологий стала наблюдаться еще одна интересная картина: с кем ни начнешь говорить, все «Скрам» и «Аджайл». Если вы тоже «Аджайл», то проведите простой эксперимент: возьмите лист бумаги и напишите 4 базовых идеи Agile. Ну, и задание со звездочкой - 12 принципов, разъясняемых Agile-манифестом. Написали? Сверьте.
Подводя итоги, можно констатировать следующее: если вы как заказчик слышите про специфичность разработки программного обеспечения – бегите, потому что на нее спишется все. То, что вместо написания кода и покрытия его модульными тестами появляются тысячи багов, которые правятся и после релиза. И то, что вместо сбора требований вам скажут: «Да ладно, сейчас напишем, потом поправим». Да и, в конце концов: «Что вы пристали со своими сроками, у нас специфичная область, у нас сроки всегда нарушаются».

Комментариев нет:

Отправить комментарий