Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения   ::   Коуберн Алистэр

Как же мы были поражены, услышав следующее: "Нет, спасибо. Нам больше нравится рисовать на доске, да и не хочется тратить время на то, чтобы заносить все эти рисунки в компьютер. Хотя… мы бы, наверное, взяли из всего вашего набора средств графический редактор". Как оказалось, прочие разработчики подобных программ получали похожие отзывы. Обычно пользователи соглашались, в конце концов, использовать "только графический редактор". Другими словами, перед нами стояли:

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение. Такое положение дел уже начинало меня беспокоить, и я стал заниматься методологиями разработки ПО (проектировал объектно-ориентированную методологию по заказу IBM Consulting Group (1992-94)). На этот раз, чтобы не наступать на те же самые грабли, я заранее опросил более дюжины различных компаний, которые работали над ОО проектами в различных странах, и тщательно записал все, что они мне рассказали. Изучая эти заметки, я сделал несколько интересных выводов:

Те команды, которые успешно работают над своими проектами, используют инкрементные процессы разработки [Co95]

При проектировании любая техника, сложнее "CRC-карточек" [B87] считается слишком сложной и не используется [Co94].

У тех, кто занимается проектированием, всегда есть возможность отказаться от любого программного продукта или техники, которые им не нравятся. Достаточно сказать начальнику: "Это замедляет работу. Если я буду этим пользоваться, то не уложусь в срок", и он разрешит проектировщикам поступать по собственному усмотрению. В то время это наблюдение не казалось мне особенно важным, но, тем не менее, я его записал и назвал "проектным ограничением" методологии. После этого я разработал весьма привлекательную и, как мне казалось, настолько не формальную, насколько это возможно, методологию и опробовал ее на одном из проектов. Наш опыт описан в документации по проекту Winifred [Co98]. Основной идеей техники проектирования, которую я рекомендовал к использованию, и которой я обучал разработчиков, были CRC-карточки.

Несколько месяцев спустя, я решил, что теперь пора побыть не консультантом, а этнографом, и стал наблюдать за тем, как ведет себя моя команда разработчиков. То, что я увидел, потрясло меня:

Рабочий процесс, который использовала моя команда, был настолько сложным и запутанным, что едва ли его вообще можно было описать. Впрочем, даже если бы мне удалось это сделать, никто бы не смог его повторить [Co98p]. Мою методологию этот процесс напоминал только весьма и весьма отдаленным образом.

Ни один из тех двух дюжин проектировщиков, которых я обучил своей методологии, не использовал CRC-карточки. Другими словами, хотя я и использовал свой "этнографический подход", все равно передо мной стояли:

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение. Такой процесс повторялся еще несколько раз, и я окончательно разуверился в своей способности "видеть то, что происходит на самом деле". Я мог сказать лишь, что в разработке проекта есть какой-то очень важный аспект, который мы никак не можем вычислить. Не так давно я попробовал решить эту проблему, работая в паре с этнографом. Мне нужна была помощь просто для того, чтобы дать название происходящему [Ho]. Вообще, консультанту хорошо работать вместе с этнографом, однако на этот раз мы едва ли смогли начать работу. Проблема была очень простая и непреодолимая: невозможно сказать, что ты видишь, до тех пор, пока у тебя нет для этого подходящего названия.