Весной 1992 года я участвовал в конференции по разработке программного обеспечения (Software Development Conference), организованной компанией Miller Freeman. Один из семинаров был посвящен такой скользкой теме, как «структурированное» и «неструктурированное» управление процессом разработки программного обеспечения. Я сидел рядом с одним из представителей компании Nanomush, отвечающим за разработки. Он был всецело на стороне ковбоев. Его позиция заключалась в том, что полному раскрытию потенциала разработчиков препятствуют руководители, которые стремятся ввести стандарты, ограничения или во всеуслышание заявляют об ожидаемых результатах. По его мнению, нужно просто отойти в сторону и не мешать программистам делать свое дело. Структурированные методы, регламентированная разработка, моделирование на бумаге и оценка программного обеспечения — все это неоправданно ограничивает возможности свободного творческого самовыражения наших блестящих ковбоев-программистов. Неудивительно, что продукты, поставляемые такими компаниями, так непредсказуемы в работе.
Почему нужно выпустить четыре релиза и задействовать 12000 сайтов бета-тестинга (это не шутка!) для того, чтобы выражение «необратимая ошибка в работе приложения, ок?» заменить на более понятное? Но ковбои не любят, когда их обуздывают с помощью особых критериев качества. Ковбоям не нравится заранее думать о том, какие функции продукта действительно необходимы. Нет, давайте лучше просто заскочим в старый добрый загон для разработки и настрочим какой-нибудь код — мы ковбои! Можно придумать симпатичный графический интерфейс и применить искусные методы кодирования — как-никак мы творческие ж гениальные личности. Но к черту юзабилити и надежность — для этого может потребоваться планирование или дисциплина (боже упаси).
Не стоит выделять какую-либо из компаний, разрабатывающих программное обеспечение. На рынке имеется бесчисленное множество примеров, подходящих для иллюстрации. Тем не менее очень редко в соответствующей литературе или на семинарах специалистов можно ветре-тить беспристрастную оценку зрелости разработчиков и качества методов программирования.
Зрелость индивидуалистов
Зрелость является центральным вопросом в разработке программного обеспечения. Методисты хотят знать, сколько времени должно пройти для того, чтобы проектирование программного обеспечения созрело как дисциплина. Менеджеры беспокоятся об уровне «зрелости процесса» в тех подходах к разработке, которые применяются в их организациях. Наконец, руководителей проектов интересует зрелость тех индивидуумов, руководить которыми их пригласили.
