Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/03f39.shtml

ФАКТ 39

Факт 39
       Общепризнано, что обзоры, сделанные постфактум (их также называют ретроспективными), важны как с точки зрения интересов потребителя (пользователя ПО), так и с точки зрения совершенствования процесса. Однако в большинстве организаций ретроспективные обзоры вообще не делаются.

Обсуждение
       Если принять во внимание все факты, изложенные выше, то наличие ошибок в свежевыпущенном программном продукте не должно вызывать удивления. Как не должно вызывать удивления и то, что жизненный цикл программного продукта не настолько безмятежен, насколько этого хотелось бы всем участникам группы разработки.
       И насколько удивительно, что мы как отрасль проявляем тенденцию совершенно игнорировать такое положение. Да, мы не перестаем выискивать ошибки - с помощью таких подходов, как альфа- и бета-тестирование, регрессионные тесты и т.д., обдумываем результаты и записываем свои соображения о том, как в следующий раз сделать все это лучше.
       И каков результат? По окончании типичного программного проекта все уроки, извлеченные из него, или отвергаются или выбрасываются на ветер. Почему? Потому, что в безумной гонке сроков, которой охвачена индустрия софтостроения, программисты, работающие над вчерашним проектом, уже перебежали в проект завтрашний. А там они слишком связаны требованиями нового расписания, чтобы остановиться и обдумать то, что случилось сколько-то месяцев тому назад.
       Месяцев? Здравый смысл подсказывает, что сразу после завершения проекта, может быть, слишком рано суммировать его уроки (потому что многие результаты использования ПО еще неизвестны). Большинство сторойников обзоров постфактум, или, как их называет Керт [Kerth, 2001], ретроспективных обзоров, считают, что оптимальный срок для осмысливания результатов составляет от 3 до 12 месяцев. Но в индустрии ПО это целая вечность. Поэтому Керт предлагает рассматривать результаты проекта через 1-3 недели после его завершения - к этому времени можно как следует прояснить если не вопросы, связанные с использованием ПО, то, по крайней мере, технические аспекты проекта.
       Что может входить в ретроспективные обзоры? Их сторонники называют два компонента (по сути дела, два разных обзора): свойства продукта сточки зрения пользователя и мнение самих разработчиков о том, что и как в продукте было лучше, а что — хуже.
       Но это неважно. О том, из чего должны состоять эти обзоры, думали очень много, но в современную эпоху их просто никто не делает. (Вот такая ирония — мы, кажется, находим время, чтобы потом устранять последствия повторяющихся отказов ПО, отказов, которые можно было бы предотвратить, взявшись за дело с выученными уроками прошлого.) Какой позор. Как следствие индустрия ПО застряла и не может двинуться вперед, делая одни и те же ошибки в одном проекте за другим. Бросслер [Brassier, 1999] сказал, что "группы разработки не извлекают пользы из опыта и повторяют ошибки бесконечно". Мы говорим об отыскании лучших практических способов, но беглый анализ большинства лучших практических документов показывает, что в них на все лады повторяется то, о чем уже несколько десятилетий пишут почти во всех книгах по программированию. Чего нет, так это "о, смотри, что мы тут натворили" и "вот как мы это исправили".
       Разрешите мне сделать небольшое отступление. К тому, что я только что сказал о пробуксовывающем ПО, надо кое-что добавить. Мой австралийский коллега Стив Дженкин (Steve Jenkin) изложил мне свой взгляд на скорость, с которой развивается программирование как профессия. Средний уровень мастерства, сказал он, с течением времени, похоже, не меняется. На первый взгляд звучит странно, правда? Он, однако, имел в виду то, что на фоне лавинообразного притока новых сил в эту бурно развивающуюся отрасль растущее мастерство стареющих специалистов более чем превосходит низкую квалификацию новичков, прибывающих ордами. Немного поразмыслив над словами Стива, я пришел к выводу:

Мудрости в индустрии ПО не становится больше.

       А если не растет мастерство, то и мудрости не прибавляется. В безумном беге к новому мы отвергаем многое из старого. (Например, в самых последних и популярных новинках, таких как экстремальное программирование и гибкое программирование (Extreme и Agile), прослеживается тенденция к отказу от положительного опыта, накопленного более старыми методологиями.)
       Как же приумножить мудрость? Что если применить на практике эти самые "выученные уроки" [IEEE, 1993]? И как насчет ретроспективных обзоров? Насчет "фабрик опыта" (Experience Factories), предложенных Виком Бэсили (Vic Basili) с коллегами в 1992г в университете Мэриленда [Basili, 1992; IEEE, 2002]? Как насчет практических руководств, в основе которых лежит именно практика, а не теории из учебников? Где новые ретроспективные обзоры, аналогичные обзорам Брукса (1995) и Гласса (1998)? Что если главной в нашей профессии сделать задачу накопления коллективной мудрости? В эпоху управления знаниями именно этой коллекцией знаний необходимо овладеть, ею надо управлять, ее надо применять [Brassier, 1999].

Полемика
       Каждый, кто думал о подоплеке данного факта, знает, что тут все не так просто, но такое ощущение, что никто не знает практического способа что-нибудь с этим сделать.
       Потенциальные противоречия, связанные с выводом, сделанным выше, многочисленны. Рецензируя эту книгу перед ее публикацией, Карл Вигерс (Karl Weigers) сказал: "Не согласен... В профессию приходят новые люди, кто-то, постарев, уходит из нее, и при этом нельзя сказать, что последних примерно столько же. Если предположить, что прибывающие приносят с собой хоть какую-то мудрость, то я думаю, что ее совокупная масса растет." И продолжил свою мысль трогательной историей о том, как он, опытный разработчик ПО, и юный новичок, принятый им на работу, вооруженные каждый своей мудростью, соединили их.
       Как бы то ни было я думаю, большинство согласится, что в индустрии ПО все нажимают педаль газа с таким увлечением, что редко находят время подумать о том, как все могло бы идти лучше, а не просто быстрее. Речь идет о том, чтобы работать с большим умом, а не с большим усердием. Но у кого есть время работать с большим умом?
       Кроме того, механизм, позволяющий усваивать извлеченные уроки, в значительной мере утрачен. Информатика, которая могла бы использовать практические уроки, извлекаемые из эмпирических исследований, для формирования новых теорий, кажется, в этом не заинтересована. Как будто теоретики настолько заняты своими теориями, что проверка этих самых теорий на практике не представляется им привлекательной.

Источники
       Источники, относящиеся к этому факту:
       — Basili, Victor I992. "The Software Engineering Laboratory: An Operational Software Experience Factory". Proceedings of the International Conference on Software Engineering. Los Alamitos, CA IEEE Computer Society Press. За последние годы Бэсили написал на эту тему намного больше и ведет посвященные ей семинары. С ним можно связаться, обратившись на факультет информатики в Университете Мэриленда (Computer Science Dept., University of Maryland).
       — Brooks, Frederick P., Jr. 1995. The Mythical Man-Month. Anniversary ed. Reading, MA Addison-Wesley, 1995. Основополагающее ретроспективное исследование проектов. Брукс рассказывает о своем опыте и уроках, извлеченных из работы над одним из крупнейших программных проектов - создании операционной системы IBM 360 (OS/360).
       — Brassier, P. 1999. "Knowledge Management at a Software Engineering Company - An Experience Report". Материалы семинара Learning Software Organisations (LSO,99).
       — Glass, Robert L. 1998. In the Beginning: Personal Recollections of Software Pioneers. Los Alamitos, CA: IEEE Computer Society Press.
       — IEEE. 2002. "Knowledge Management in Software Engineering. Special issue". IEEE Software, May. Содержит несколько статей, посвященных инспекциям постфактум и фабрикам опыта.
       — IEEE. 1993. "Lessons Learned". Спец. выпуск IEEE Software, Sept.
       — Kerth, Norman L. 2001. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House.


<<< Пред. Оглавление
Glass Robert L.
Начало раздела
След. >>>



<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/03f39.shtml