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

ФАКТ 01

Факт 1
       Самый важный фактор в разработке ПО — это не методы и средства, применяемые программистами, а сами программисты.

Обсуждение
       В создании ПО важен человеческий фактор. Именно эта мысль главная в данном конкретном факте. Свою роль играют инструментальные средства. Важны и методы. И процессы. Но роль людей намного более значима.
       Идея эта стара, как сама компьютерная индустрия. Она вышла из столь многочисленных научных исследований и докладов за прошедшие годы (она там встречается и сейчас), что к настоящему моменту должна быть одной из самых важных "вечных истин". Но в индустрии ПО о ней по-прежнему забывают. Мы считаем Процесс альфой и омегой разработки ПО. Мы выдвигаем инструментальные средства на роль волшебных палочек, усиливающих нашу способность создавать ПО. Мы собираем вместе разношерстные методы, называем результат методологией и требуем, чтобы тысячи программистов читали о ней, посещали курсы по ней, отполировывали знания путем зубрежки и упражнений и затем применяли ее в ответственных проектах. И все это от имени средств, методов, Процесса, стоящих над людьми.
       Мы даже порой возвращаемся к бесчеловечным подходам. Мы обращаемся с людьми, как с взаимозаменяемыми шестеренками на конвейере. Мы требуем, чтобы люди, поставленные в рамки слишком жестких сроков и ограничительных условий, работали лучше. Мы отказываем нашим программистам даже в самых базовых элементах доверия, а потом ждем от них доверия к нам, когда мы им говорим, что делать.
       В данной связи интересно рассмотреть Институт инженерии ПО (Software Engineering Institute, SEI) и его процесс разработки ПО, модель развития функциональных возможностей (Capability Maturity Model - СММ). Фундаментальное положение модели СММ состоит в том, что хороший процесс - это ключ к хорошему ПО. Основываясь на этом постулате, СММ определяет массу ключевых участков процесса и последовательность ступеней, через которые должны пройти организации-разработчики ПО. Особенно интересной СММ делает тот факт, что SEI занялся кадровым вопросом и заинтересовался ролью человеческого фактора в построении ПО лишь после того, как эта модель просуществовала несколько лет, и благодаря министерству обороны США ей был придан полуофициальный статус способа усовершенствования организаций, производящих ПО, и после того, как образ действия министерства обороны был скопирован другими организациями. Так появилась модель развития кадровых возможностей (People Capability Maturity Model - P-CMM) института SEI. Но она гораздо менее известна, и применяется намного меньше, чем модель СММ, ориентированная на процесс. Скажу еще раз, что многие профессионалы программирования по-прежнему считают, что Процесс важнее, чем люди, подчас поразительно, насколько важнее. Кажется, что мы никогда не сделаем нужных выводов.

Полемика
       Полемика по поводу значения людей едва слышна. Каждый на словах не забывает, что люди важны. Почти каждый согласен, что люди важнее, чем средства, методы и Процесс. Но мы продолжаем действовать так, как если бы это было неправдой. Пожалуй, дело в том, что трудности, связанные с людьми, разрешать сложнее, чем связанные с инструментами, методами и процессом. Прямо как в одном старом анекдоте. (Уже бог знает сколько лет, как рассказывают: пьяный поздно вечером что-то ищет под фонарем. Подходит полицейский, спрашивает, что он тут делает. Пьяница говорит: "Ключи ищу". "Где ты их потерял?" - вопрошает страж порядка.
       "Вон там", - отвечает пьяница, показывая в сторону. "Так чего ж ты их тут-то ищешь?" "А здесь, - отвечает он, - светлее".)
       Все мы, кто занят в сфере программирования, в душе технологи и не прочь изобрести новую технологию, чтобы облегчить себе работу. Даже если в глубине души знаем, что человеческий фактор для дела важнее.

Источники
       Как самую вьщающуюся иллюстрацию значимости людей можно назвать обложку классической книги Барри Боэма [Barry Boehm, 1981] "Software Engineering Economics" (Экономика технологии программирования). На ней представлена гистограмма факторов, способствующих созданию хорошего программного продукта. И что же: самый высокий столбец гистограммы представляет профессионализм людей, выполняющих работу. Эта диаграмма свидетельствует, что люди значат намного больше, чем любые средства, методы, языки и (!) процессы, которые они применяют.
       Эта точка зрения, пожалуй, лучше всего выражена в еще одной классической книге - "Peopleware" [DeMarco and Lister, 1999].1 {Том Демарко, Тимоти Листер "Человеческий фактор: успешные проекты и команды", 2-е издание. - Пер. с англ. - СПб.: Символ-Плюс, 2005.} Как можно предположить из названия, книга целиком посвящена роли людей в создании ПО. В ней можно, например, прочитать, что "Серьезные проблемы в нашей работе имеют не столько технологическую, сколько социологическую природу.", и даже что первостепенное внимание к технологическим вопросам относится к "миражам высоких технологий". Нельзя прочесть книгу "Человеческий фактор" и не убедиться в том, что люди значат гораздо больше, чем любой другой фактор разработки ПО.
       Короче всех остальных утверждение о важности людей сформулировал Дэвиса pavis, 1995], сказав: "Люди - это ключ к успеху". Самые свежие высказывания на эту тему принадлежат сторонникам гибкой (agile) разработки ПО, которые говорят примерно так "Отодвиньте ширму строгой методологии успешного проекта и поинтересуйтесь причиной успеха, и вы узнаете ответ: люди" [Highsmith, 2002]. Раньше всех о важности человеческого фактора" сказали такие люди, как Бучер [Bucher, 1975]: "Больше всего надежность ПО зависит от отбора и мотивирования персонала, а также от управления им", и Руби [Rubey, 1978]: "В конечном счете главным фактором производительности является потенциал отдельного исполнителя".
       Но больше других публикаций, в которых люди были названы самым важным фактором в программировании, мне, пожалуй, понравилась малоизвестная статья на одну жизненно важную тему. Вопрос был сформулирован так "Если бы ваша жизнь зависела от конкретной программы, то что бы вы хотели о ней узнать?" Боллинджер [Bollinger, 2001] ответил: "Больше всего я хотел бы знать, что тот, кто написал эту программу, обладал высокими умственными способностями и был одержим чрезвычайно непреклонным, почти фанатичным желанием заставить ее работать именно так, как она должна. Все остальное для меня вторично...".

Ссылки
       Boehm, Barry. 1981. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall.
       Bollinger, Terry. 2001. "On Inspection vs. Testing" Software Practitioner, Sept.
       Bucher, D. E. W. 1975. "Maintenance of the Computer Sciences Teleprocessing System" Proceedings of the International Conference on Reliable Software, Seattle, WA, April.
       Davis, Alan M. 1995. 201 Principles of Software Development. New York: McGraw-Hill.
       DeMarco, Tom, and Timothy Lister. 1999. Peopleware. 2d ed. New York: Dorset House.
       Highsmith, James A 2002. Agile Software Development Ecosystems. Boston: Addison-Wesley.
       Rubey Raymond L. 1978. "Higher Order Languages for Avionics Software -A Survey, Summary, and Critique" Proceedings of NAECON.


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



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

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


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