Текст книги "Путь камикадзе [Смертельный марш]"

Автор книги: Эдвард Йордон

сообщить о нарушении

Текущая страница: 13 (всего у книги 17 страниц)

5.4 «Достаточно хорошее» программное обеспечение

Определение приоритетов требований, обсуждавшееся выше, может быть одним из способов, помогающих безнадёжному проекту двигаться в «разумном» направлении. Для достижения успеха вовсе не обязательно реализовывать все требования; будет «достаточно хорошо», если мы сможем реализовать требования, которые «необходимо выполнить», и приемлемое количество требований, которые «следует выполнить».

Существует, однако, ещё один аспект в разработке ПО, порождающий трудности в безнадёжных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количества дефектов (ошибок), но может быть также выражено в терминах переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах достаточно трудно удовлетворить всем этим требованиям, а в безнадёжных проектах сделать это просто невозможно. Вместо этого проектная команда должна придти к решению – и по возможности согласовать его с акционерами и заинтересованными лицами – относительно того, какое качество является достаточно хорошим.

Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресурсы проекта – особенно время. Если вы хотите разработать сертифицированную, не содержащую ошибок программу и математически доказать её корректность, на это потребуется время. Это может также потребовать более высокого уровня таланта и способностей, чем те, которыми располагает проектная команда. Кроме того, одному или более участникам команды придётся расходовать дополнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, выполнение таких требований, как надёжность, переносимость и сопровождаемость, невозможно без компромиссов, и это необходимо учитывать в процессе определения приоритетов требований.

Командам безнадёжных проектов приходится сталкиваться с такой неприятной реальностью лицом к лицу, поскольку альтернатива – «совершённое» ПО, которое не будет готово даже тогда, когда пройдут все мыслимые сроки. Лучше всего, когда команда с самого начала проекта настроена прагматично на создание достаточно хорошего ПО, однако, мой опыт, к сожалению, говорит о том, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, когда упираются в тупик – например, когда оказываются в кризисном положении за месяц или два до окончания проекта.

Вплоть до этого момента времени они выражают своё недовольство: «Как вам понравится, если мы будем использовать ваш „достаточно хороший“ подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадёжный проект для создания такого рода высоконадёжных приложений, тогда я просто перестану летать на самолётах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадёжными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьёзны.

В любом случае, совершённая надёжность, сопровождаемость, переносимость и т.д. не являются необходимыми, практичными или даже желательными в большинстве безнадёжных проектов. В самом деле, достичь такого совершенства невозможно даже в «нормальных» проектах, хотя в этом случае мы можем позволить себе установить планку своих стандартов гораздо выше, поскольку не связаны такими жёсткими ограничениями на время, бюджет и людские ресурсы. Что же касается безнадёжных проектов, то пользователям в действительности нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро – вот в чем заключается их определение «достаточно хорошего» ПО.

Почему же нам не удаётся создать «достаточно хорошее» ПО? Это обычно объясняется совокупностью следующих причин:

7) Мы стремимся определять качество только в терминах дефектов, не задумываясь о других его аспектах – которые, с точки зрения пользователя, включают, например, готовность к определённой дате.

8) Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое качество – хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.

9) Мы стремимся определить требования к качеству (дефектам) один раз, в самом начале проекта, и зафиксировать их, хотя обстоятельства могут измениться в течение проекта не один раз.

10) Мы так долго твердили, что процессы являются критически важными, что при этом зачастую забываем об их «нейтральности» – дурак, вооружённый процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям методологии структурного анализа или рекомендаций SEI-CMM.

11) Мы рассматриваем обеспечение качества как процесс, укладывающийся в жёсткую схему, заданную в начале проекта раз и навсегда (или, что ещё хуже, для всех проектов во всей компании).

12) Мы недооцениваем нелинейный характер зависимостей между такими ключевыми параметрами проекта, как численность персонала, плановые сроки, бюджет и количество дефектов – все эти аспекты в безнадёжных проектах являются ключевыми.

13) Мы игнорируем динамику процессов: запаздывания, циклы обратной связи и т.д. Например, большое количество сверхурочной работы в течение данной недели может выразиться в повышении продуктивности и прогрессе в работе над проектом в целом; но, с другой стороны, оно может повлечь за собой большее количество ошибок на следующей неделе (о которых конечные пользователи и высшее руководство могут ничего и не узнать), которые снизят продуктивность работы (в терминах конечных результатов) и, может быть, даже отбросят проект назад.

14) Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для работы и др.

Каким же образом мы сможем создать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:

15) Утилитарная стратегия – искусство количественного анализа и максимизации чистого выигрыша в неопределённых ситуациях – обобщает идеи системного анализа, управления рисками, экономики, теории принятия решений, теории игр, теории управления и нечёткой логики.

16) Эволюционная стратегия – рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.

17) Героические команды – не Могучие Гениальные Программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.

18) Динамическая инфраструктура – противоположность бюрократии и засилью политики. Высшее руководство уделяет необходимое внимание проектам, уделяет внимание положению на рынке, предупреждает и разрешает конфликты между проектами, и становится на сторону проекта в случае конфликта между ним и бюрократами.

19) Динамические процессы – процессы, поддерживающие работу в эволюционирующей среде. Динамический процесс, в свою очередь, является часть идентифицируемого мета-процесса и всегда может подвергаться изменениям.

5.5 Наилучшая практика и наихудшая практика

Не один раз уже в этой книге я предупреждал об опасностях, связанных с вмешательством блюстителей методологии и попытками насильно внедрить в практику проектной команды лишённые гибкости методологии или процессы создания ПО. То же самое касается внешних консультантов, гуру, знахарей, целителей, заклинателей змей и книг. Дажеэтой книги: если то, что я рекомендую, не находит должного понимания, и проектная команда не испытывает по этому поводу особого энтузиазма, то такую рекомендацию лучше проигнорировать!

Однако это особенно справедливо по отношению к методологиям и процессам создания ПО. Вместо того, чтобы следовать рекомендуемой кем-либо практике – или, что ещё хуже, практике, навязываемой сверху руководством и комитетами по методологии, которые обычно сами не знают то, о чем они говорят – гораздо лучше следовать практике, которую сама команда считает «наилучшей» в данных обстоятельствах. В этом заключается существо подхода «наилучшей практики», который стал популярным в последние пару лет: основного подхода, принятого на вооружение организациями-разработчиками ПО, признанного удачным настоящими разработчиками.

К сожалению, у команд безнадёжных проектов практика такого рода зачастую отсутствует, поскольку их проект, как правило, рассматривается как первый проект такого рода в организации. Если он даже не первый, то все равно рассматривается как исключение – поэтому никто не побеспокоился заранее составить перечень хорошо и плохо зарекомендовавших себя методов. Что ещё хуже, большой процент безнадёжных проектов заканчивается провалом (иначе они не назывались бы «смертельными маршами»!). Таким образом, люди, которые могли бы помочь полезными советами в последующих безнадёжных проектах, уже ушли, были уволены, покончили жизнь самоубийством, заработали нервное расстройство или превратились в закоренелых циников.

Если вы в самом деле начинаете первый в организации безнадёжный проект, то, вероятно, самое лучшее, что вы можете сделать – это документально фиксировать все реально работающие процессы, которые могли бы пригодиться в последующих безнадёжных проектах. Один из способов сделать это – провести «ревизию» в самом конце проекта. Тем не менее, это делается редко, и результаты обычно настолько неинтересны, что никому неохота их читать. Причины этого очевидны: как было отмечено выше, проектная команда к концу проекта находится в таком измочаленном и потрёпанном состоянии, что предложение документально описать их опыт будет скорее всего встречено градом насмешек; кроме того, многие из тех, кто внёс наибольший вклад в работу, к концу проекта уже давно исчезли.

Таким образом, альтернативой может быть серия «мини-ревизий» в течение всего проекта. Если ваша работа состоит из мини-этапов, таких, как передача новой версии прототипа пользователю, запланируйте полдня на проведение мини-ревизии сразу после окончания этапа. Решите, что в практике работы было хорошим, а что оказалось негодным; что заслуживает особого внимания на следующем этапе, а от чего следует отказаться. Следует отметить, что такого рода «самокопание» полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безнадёжных проектов, может подсластить пилюлю. Кроме того, такое подведение итогов в конце этапа обычно поднимает дух команды, их суждения становятся более оригинальными, искренними и не такими циничными.

Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд http://www.christine.com. Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.

Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):

20) Формальное управление рисками – я буду обсуждать его позже в данной главе.

21) Согласованные интерфейсы – аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.

22) Экспертные оценки – экспертизы, проверки, сквозной контроль. Это весьма распространённая и понятная практика, однако в безнадёжных проектах от неё зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадёжных проектов каждый успевает только делать своё дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.

23) Планирование и управление, основанное на метриках – речь идёт о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадёжных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчёта потерь, понесённых командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадёжном проекте – хотя бы для того, чтобы убедиться в их безумной оптимистичности!

24) Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.

25) Свободный доступ к информации о проектных планах и фактических результатах – это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.

26) Фиксация дефектов в соответствии с заданными показателями качества – одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.

27) Конфигурационное управление – как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.

28) Ответственность и подотчётность руководства перед сотрудниками – увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».

Одно из наиболее значительных достижений данного проекта министерства обороны – это понятие наихудшей практики ; особенно хорошо оно применимо к безнадёжным проектам, где зачастую бывает более важно предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведён ниже:

29) Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов – разумеется, если вы действительно в это верите, то не следует даже и начинать безнадёжный проект!

30) Не пытайтесь использовать новую технологию как средство для сокращения сроков – у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.

31) Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.

32) Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.

33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля – если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.

34) Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков – проектная команда не должна об этом беспокоиться, поскольку она уже знает, что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадёжным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.

35) Не следует ожидать, что в результате более чем 10-процентного отставания от плана удастся избежать более чем 10-процентного снижения функциональности разработанного ПО – эта рекомендация является критически важной для команды безнадёжного проекта, поскольку вероятность отставания от плана более чем на 10 процентов во время выполнения проекта достаточно высока. В самом деле, для безнадёжного проекта опасно даже 10-процентное запаздывание, поскольку команда, вероятно, уже так много работает сверхурочно, что у них просто не хватит сил, чтобы тратить каждый день на работу ещё на 10 процентов больше времени. Однако, самым главным в этой рекомендации министерства обороны является следующее: менеджер проекта должен помнить, что зависимость между временем работы команды и функциональностью ПО не является линейной.

В течение прошлого года на своих семинарах в разных концах света я задал нескольким сотням менеджеров проектов два вопроса: «Если ваш коллега предпринимает свой первый безнадёжный проект, какой единственный совет для достижения успеха вы могли бы ему дать? И что единственное вы бы посоветовали ему не делать?» Я был весьма заинтригован, обнаружив, что никто даже не упомянул средства или технологии в качестве «одной самой важной вещи»; не были также упомянуты и формальные методологии и методы, такие, как структурный анализ или объектно-ориентированное проектирование. Некоторые рекомендовали стратегии управления человеческими ресурсами (например, «наймите хороших исполнителей» и «добейтесь, чтобы команда была действительно нацелена на успех»), однако почти все рекомендации были направлены на проведение переговоров, контроль за выполненным объёмом работ (которому хорошо способствует обсуждавшееся ранее определение приоритетов требований) и управление рисками (о котором речь пойдёт ниже).

Ещё один последний подход, заимствованный из упоминавшегося проекта министерства обороны, может оказаться полезным для безнадёжных проектов, хотя он в большей степени предназначен для менеджеров за пределами проекта, чем для менеджера самого проекта и участников его команды. Он называется «тест на алкоголь»: какие вопросы следует задать команде безнадёжного проекта, чтобы быстро определить, не утратили ли они чувство реальности до такой степени, что проект пора прекращать? Вопросы такого рода часто задаются консультантами, которых высшее руководство уполномочило проанализировать состояние проекта. Я сам был в таком положении, и я обычно могу заключить, что проект находится в плачевном положении, когда вижу остекленевший взгляд менеджера проекта, который напоминает взгляд лани, застигнутой светом фар приближающегося автомобиля.

Иногда безобидный вопрос типа «знаете ли вы, кто является вашим заказчиком?» приводит всех в полное замешательство, и в гробовом молчании каждый озадаченно смотрит на своего соседа, а потом все внимательно вглядываются в пол. Если вас интересуют некоторые другие вопросы «теста на алкоголь», ниже приведён их список:

36) Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?

37) Располагаете ли вы утверждённым планом и бюджетом?

38) Знаете ли вы, за разработку какого ПО несёте ответственность?

39) Можете ли вы перечислить первые десять проектных рисков?

40) Известен ли вам процент сжатия вашего плана по сравнению с нормальным?

41) Каков оценочный объём вашего ПО? Каким образом он вычисляется?

42) Известна ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?

43) Достаточными ли знаниями о предметной области располагают ваши специалисты?

Как было отмечено выше, «тест на алкоголь» проводится в том случае, когда кто-либо в организации – как правило, не менеджер проекта, а кто-либо, стоящий на существенно более высоком уровне иерархии – почувствует, что проект идёт не так, как надо. Для того, чтобы выжить в политических схватках, менеджеру проекта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта вообще все время следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если в соответствии с официальным графиком PERT все выглядит как положено. Такими признаками могут быть:

44) Уход ключевых участников команды – это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участники проекта веру в свою способность завершить проект. Если начнут уходить ключевые разработчики, другие могут последовать за ними.

45) «Фактор обратной корреляции Дильберта» – чем больше карикатур Дильберта появляется на дверях в офисе и на досках объявлений, тем хуже идут дела в проекте.

46) Чрезмерный юмор висельников – если проектная команда начнёт носить в офисе чёрные рубашки и проигрывать на аудиосистеме погребальные мелодии, значит, что-то идёт не так.

47) Проекту даются новые имена, например, «Проект Титаник» – другая разновидность юмора висельников, которая, однако, является более серьёзным признаком того, что проектная команда утратила веру в успех, чувство причастности к проекту и вообще какой-либо интерес к работе.

48) Зловещее молчание конечных пользователей и высшего руководства, которые обычно каждый день интересовались ходом проекта – к тому моменту, когда вы это осознаете, может оказаться слишком поздно, чтобы наверстать упущенное, однако у вас может быть по крайней мере несколько дней, чтобы обновить своё резюме.

49) Бестолковая суета – бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи «мини-этапов» и стратегии «ежедневной сборки проекта».