В продолжение темы предыдущей главы, посвященной стратегии миттельшпиля, в данной главе я сделаю основной акцент на соблюдении сроков и на инструментарии, необходимом для своевременного доведения проектов до финишной черты.
Не забывайте, что у всех проектов, как правило, более одного крайнего срока. У каждого проекта есть промежутки времени, ведущие к концу какого-нибудь этапа или к завершению всего проекта. При этом возникает скрытая опасность, что команду станут усиленно подгонять, чтобы уложиться в срок, хотя она и так прилагает к этому запредельные усилия, понимая, что следующий срок тоже не за горами. Если команда полностью выложится и подойдет к началу следующего этапа в состоянии усталости, депрессии и стресса, то вероятность соблюдения очередного срока резко снизится. Винс Ломбарди (Vince Lombardi) однажды сказал, что накопленная усталость делает всех нас трусливыми. Когда мы измотаны, вернуть нас в работоспособное состояние не сможет никакое количество выпитого крепкого кофе. Как говорит Генри Кайзер (Henry Kaiser), то, как сыграна нота, столь же важно, как и то, какая это нота.
Если команда похожа на загнанную лошадь, то на восстановление интенсивности ее работы до расчетного уровня могут пройти дни или даже недели (рис. 15.1). Хуже того, чем чаще команде устраивают подобные гонки, тем меньше она на них реагирует. Существует некий предел, преодолев который команда перегорает, теряя способность к восстановлению сил в приемлемые сроки.
Рис. 15.1. Ценой аврала, затеянного, чтобы соблюсти один срок, является снижение вероятности соблюдения следующего. Чрезмерные усилия по своевременному выполнению этапа 1 ведут к задержке начала этапа 2
При реализации проекта продуктивность команды лучше рассматривать как ресурс с нулевой суммой:[88] если для соблюдения назначенного срока нужно прикладывать чрезмерные усилия, значит, вы крадете силы, которые вам потребуются в начальной стадии следующего этапа. (Однако если в команде существует специализация ролей, негативные последствия можно снизить за счет перераспределения обязанностей. Чаще всего в процессе работы над проектом у проектировщиков, плановиков, руководителей проекта, тестировщиков и программистов аврал случается в разное время. При правильном распределении работы аврал не может быть сразу у всей команды, поскольку ролевая нагрузка в разное время разная.)
Хуже того, за всем этим следует неравнозначная расплата, поскольку соотношение времени на восстановление сил и на работу в условиях аврала не равно 1:1. На восстановление уйдет намного больше времени, чем на сам аврал (к примеру, если на то, чтобы догнать уходящий поезд, нужно секунд 20, то на то, чтобы отдышаться после этого, может потребоваться несколько минут). Иногда в жертву приносится личная или семейная жизнь, а это уже никак не вяжется с постоянными интересами людей, команды или организации (см. рис. 15.1).
Из этого следует, что хорошее руководство должно обходиться без авралов. Конечно, в серьезных проектах острых углов не избежать, но руководство должно быть заинтересовано в том, чтобы иметь над ними полный контроль, работать преимущественно над тем, чтобы свести их количество к минимуму, и давать реальную оценку их последствиям (не стоит, к примеру, в течение двух недель после начала следующего этапа осыпать команду упреками за вялость и пассивность). Чем продолжительнее работа над проектом, тем больше сил команда теряет на подобные пики активности и тем труднее становится организовать нормальную работу в эндшпиле многоэтапного проекта.
Долгие сроки – это просто сумма нескольких коротких
Чтобы обсудить важные аспекты стратегий миттельшпиля и эндшпиля, мы должны определить в проекте несколько промежуточных сроков. Наиболее важная тройка таких сроков, фигурирующая в простом унифицированном графике работ, относится к переходам между элементами правила трех частей, рассмотренного в главе 2 (рис. 15.2). Каждый переход означает смену области приложения сил команды и должен иметь для этого собственные критерии прохождения.
Рис. 15.2. Внутри этапов имеются ключевые даты, которые нужно отследить, наметить и наделить критериями выхода
Эти критерии представляют собой перечень всего, что предполагается выполнить к концу этапа. В них описывается то состояние проекта, которое он должен приобрести, чтобы этап считался завершенным. Чем раньше определены критерии выхода этапа, тем выше будут шансы на его своевременное завершение.
В каждом этапе есть три основных перехода:
Завершение проектирования (завершение подготовки технических условий). Команда готова к созданию программного кода изделия. Сделано все необходимое для начала реализации проекта: выработаны технические условия, созданы прототипы, составлено краткое изложение замысла. (При этом совсем не обязательно иметь окончательно выработанные технические условия, достаточно иметь в готовности лишь тот объем, который считается необходимым для начала работы, скажем, 20 или 90 %.) Работы по проектированию могут продолжаться (см. раздел «Конвейер по созданию программного кода» главы 14), что-то может переделываться и пересматриваться, но основы в необходимом объеме должны быть заложены.
Завершение реализации заданных характеристик. Команда готова приступить к оптимизации и проверке качества кода. Это означает, что вся функциональность, предусмотренная индивидуальными работами, реализована, выполнено все необходимое, чтобы поведение продукта и его внешний вид отвечали техническим требованиям. Могут оставаться какие-нибудь качественные пробелы или проблемы, но при условии, что руководство их отследило и оценило (ошибки выявлены), основную созидательную работу можно читать завершенной. Все контрольные и качественные показатели, являющиеся частью технических условий, должны быть в пределах допустимых. К этому времени все остающиеся нерешенными проблемы должны быть переведены в разряд ошибок, а база данных, содержащая перечень ошибок, – стать основным (если не единственным) средством отслеживания хода всей оставшейся работы.
Завершение тестирования или этапа в целом. Этап завешен. Качество и оптимизация достигли приемлемого уровня. Начинается работа по плану следующего этапа и (или) поставки программного продукта. Поскольку это последняя фаза этапа, ее иногда называют завершением этапа. Если данный этап бы единственным или последним, то завершается весь проект.
Если не принимать во внимание качество подготовки технических условий, качество оценки работ и способности самой команды, то для соблюдения намеченных сроков будет действовать следующее простое правило: чем точнее определены критерии выхода, тем больше шансов на своевременное завершение.[89] Предполагается, что команда продолжает работать до тех пор, пока критерии выхода не будут соблюдены. Набор критериев выхода должен быть у любой мало-мальски значимой контрольной даты рабочего графика.
Определение набора критериев выхода
Критерии выхода не должны быть слишком сложными (хотя и могут быть таковыми). Тем не менее в наборе критериев выхода должны содержаться следующие элементы:
• Перечень завершаемых работ.
• Показатели качества, с которым должны быть завершены эти работы (взятые, возможно, из параметров тестовых испытаний, планов тестирования[90] и технических условий).
• Перечень необязательных дел, о которых у некоторых сотрудников сложилось мнение, что их обязательно нужно сделать.
• Перечень всего, что не нужно делать, даже если у кого-то сложилось иное мнение (проверка на здравый смысл).
Определять набор критериев выхода, доводить их до всей команды и отслеживать соблюдение можно различными способами. Детали здесь не имеют особого значения (предложите набор критериев команде, соберите отзывы, затем завершите его разработку и доведите результаты до всей команды). Важно, чтобы этот набор был определен как можно раньше, легко воспринимался и использовался открыто для отслеживания хода процесса и реализации принятых решений. Критерии выхода должны соответствовать концептуальному документу и целям проекта, стать наиболее удобными инструментами применения концепции и целей в разрешении всех вопросов и сложностей, возникающих в середине и на завершающей стадии любого этапа.
Обычно критерии выхода означают, что сделано следующее:
Составлены списки технических условий, проектных решений, работ. Как правило, эти списки полезны только как критерии завершения проектирования. Этапы проектирования должны иметь соответствующие критерии выхода независимо от того, какие инструменты или процессы применялись для их выполнения. Возможно, условием выхода из этой стадии станет принятие 90 % общего объема технических условий или создание прототипа с определенной функциональностью.
Выполнены текущие работы. Имеется в виду перечень работ, определенный в начале этапа или фазы проекта. Как только работы будут выполнены в соответствии с требованиями технических условий, этап (фаза) завершится.
Подсчитаны все ошибки по уровням их значимости. Ранее уже шла речь о том, что для выявления и оценки значимости ошибок (дефектов) применяется множество различных способов. Обычно критерии выхода включают создание детального описания обнаруженных ошибок конкретного типа.
Пройден определенный набор тестов. Определение факта завершения этапа может быть обусловлено прохождением некоторых тестов. Если результаты тестирования используются в качестве критерия, на их основе принимаются решения о том, какие ошибки или дефекты подлежат устранению до завершения этапа. Возможно, будет вполне достаточно использовать критерии выхода на основе определенного порога прохождения тестовых испытаний, к примеру: «должны быть пройдены 80 % тестовых испытаний по сценариям, относящимся к приоритетам первой очереди».
Достигнуты определенные показатели производительности или надежности. Если команда производит замеры производительности определенных компонентов (скажем, базы данных или поисковой машины), то критерии выхода должны быть основаны на ее показателях. Если критерии выхода заключаются в увеличении скорости на 10 % по сравнению с показателями предыдущей версии, значит, этап не может считаться завершенным до тех пор, пока не будет достигнуто 10-процентное увеличение.
Потрачено определенное время или деньги. Время является самым простым в мире критерием выхода. Этап завершается по прошествии определенного времени. И все. Лучше всего измерять этап месяцами, тогда не будет никаких сомнений насчет времени его начала, времени окончания и продолжительности. (Ведь меряют же люди остаток своей жизни месяцами и неделями, так почему же не построить на той же основе график разработки проекта?) Все наполовину или частично реализованные характеристики отбрасываются, чтобы учитываться уже на следующем этапе (если он предусмотрен). Деньги также могут стать критерием выхода: когда бюджет исчерпан, энергия иссякает, и работа останавливается.
В отсутствие критериев выхода команда должна придерживаться субъективных мнений относительно того, что для проекта является «вполне достаточным», а что считать бесполезной тратой времени. У каждого на этот счет может быть собственное мнение. Даже если решение принимается единолично, оно все равно будет считаться спорным, пока не созданы некие письменные нормативы. Отсутствие критериев скажется впоследствии вынужденными нелегкими дебатами, в которые команды позже будут втянуты, как только возрастут риски и опасения за судьбу проекта. Не ставьте команду в такие условия, при которых она должна в конце этапа тратить свою энергию на споры вокруг критериев выхода, а лучше спланируйте все так, чтобы она в конце этапа тратила всю свою энергию на реальное достижение этих критериев.
Запомните, что цель заключается не только в том, чтобы уложиться в указанный срок, но и в том, чтобы подвести проект к определенной дате в определенном состоянии. Чем скорее команда поймет, в чем заключается это состояние, тем выше будут шансы на успех. Если критерии известны на ранней стадии, они отражаются на всех решениях, принимаемых в ходе выполнения этапа. Даже если в процессе работы критерии претерпят какие-то изменения, команда будет перестраивать свою работу в едином направлении, дружно подводя проект к легкому эндшпилю.
К примеру, перечень критериев выхода для какого-нибудь этапа реализации проекта по созданию небольшого веб-сайта может быть следующим:
• Выполнить в соответствии с заданными техническими условиями все работы с первой по десятую.
• Достичь 80-процентных показателей потребительских качеств, относящихся к приоритетам первой очереди.
• Пройти все тесты первой очереди в автоматическом и ручном режимах.
• Пройти 80 % тестов второй очереди в автоматическом режиме.
• Классифицировать все найденные ошибки.
• Исправить все ошибки, относящиеся к приоритетам первой и второй очереди.
• Получить разрешение на завершение этапа от команды по маркетингу и развитию бизнеса.
Почему соблюдение сроков напоминает посадку самолета
Цель промежуточных этапов не только в том, чтобы выдержать определенный срок, но и в том, чтобы настроить команду на следующий этап (или на выпуск следующего варианта). Соблюдение сроков – это не только вопрос хронологии: риск, которому подвергается надежность программного кода и выполнение следующего этапа (если таковой имеется), зависит от плавности движения к контрольной дате.
Представьте себе посадку самолета. Удачное приземление облегчает повторный взлет самолета: крылья на месте, шасси исправно, экипаж жив. Все, что нужно – это дозаправка, план полета и сэндвич для пилота. Завершение этапа должно рассматриваться в этом же ключе. Чем круче закладывается вираж для завершения этапа, тем вероятнее, что по его окончании проект окажется не в самом лучшем состоянии.
Типовые графики разработки проектов могут быть сведены к простой диаграмме, наподобие показанной на рис. 15.3. Диаграмма составлена с предположением, что показатель прогресса проекта является постоянной величиной, а проект завершится точно по графику при соблюдении постоянного темпа работы. Разумеется, все это из области фантастики. Эта диаграмма никогда не станет отражением реальных событий, поскольку темпы работы команды и ее продуктивность никогда не будут постоянными величинами (по многим рассмотренным ранее причинам).
Рис. 15.3. Характерный пример графика выполнения этапа с неправдоподобными допущениями
Скорее всего, большинство проектов могут оказаться в ситуации, воспроизведенной на рис. 15.4. В какой-то точке пути по направлению к конечной дате команда поймет, что работа идет не так быстро, как ожидалось. Такое может случиться из-за того, что команде поставили дополнительную задачу (см. раздел «Контроль изменений» в главе 14) или не оправдались сделанные ею оценки. Неважно, по какой причине это произошло, но теперь команда оказалась перед выбором: как преодолеть расстояние, оставшееся до конечной даты? Есть только три варианта:
1. Сдвинуть график. Отодвинуть чуть дальше конечную дату в соответствии с новым пониманием угла наклона линии, отражающей ход выполнения проекта.
2. Изменить угол наклона. Поверить в то, что команду каким-то образом удастся заставить работать быстрее и производительнее, чтобы своевременно компенсировать возникшее отставание (например, приготовиться к аварийной посадке). Можете, конечно, попробовать этот вариант, но чем-то все равно придется пожертвовать. Например, возросшим риском наделать ошибок, вялостью и усталостью команды к началу следующего этапа.
3. Подойти к окончанию этапа, ничего не меняя. Определите те характеристики или работы, на которые придется потратить больше усилий или которые являются более рискованными. Затем либо прекратите ими заниматься, отложив до следующего этапа (если он предвидится), либо снизьте к ним качественные требования и оставьте все как есть.
Рис. 15.4. Реализация графика зачастую расходится с планом. Как с этим справиться – целиком зависит от критериев выхода
На чем остановить свой выбор – полностью зависит от критериев выхода. Это именно та ситуация, в которой наибольший выигрыш складывается из четкого понимания того, что именно подразумевается под окончанием этапа. Вместо того чтобы изобретать критерии на ходу, в состоянии стресса, вызванного трудной посадкой, лучше просто оглянуться назад и внести поправки в критерии, определенные несколькими неделями ранее. Принятие решения в сложной ситуации эндшпиля значительно облегчится, если есть уже знакомые команде критерии, на которые всегда можно сослаться.
Если опять обратиться к аналогии с самолетом, то изменение угла снижения, чтобы попасть на полосу, делает заход на посадку нестабильным. Проекты во многом подобны самолетам – при увеличении скорости снижения (завершения) становятся плохо управляемыми. Чтобы стабилизировать скорость снижения, нужно одновременно проделывать слишком много манипуляций. Если пилот, сидя за штурвалом приземляющегося самолета, видит, что самолет сносит мимо полосы, он заходит на посадку заново (переместить посадочную полосу, в отличие о графика, невозможно). В сложных погодных условиях пассажирские самолеты часто заходят на второй круг. В проектах же такая возможность предоставляется крайне редко. Они подобны самолетам, у которых топливо на исходе: ресурсов хватает только на одну попытку. Имея в запасе единственную попытку, здравомыслящие пилоты будут снижаться очень осторожно и по хорошо продуманному плану. Благоразумные руководители проекта обязательно последуют их примеру. Если дата или набор характеристик должны быть неизменными (как посадочная полоса), вы должны начать готовиться к посадке как можно раньше.
Почему все становится хуже
При расстановке приоритетов в работе действует основной психологический принцип. При прочих равных условиях люди склонны уклоняться от того, что им не хочется делать.[91] А значит, в процессе выполнения графика все оставшиеся работы и неисправленные ошибки становятся неприятной обузой текущего этапа. Пусть даже недоделаны какие-то пустяки, если команда поощряется за определенное количество исправленных за день или за неделю ошибок, у нее появляется естественное стремление выбирать ошибки попроще, чтобы выполнить квоту.
К концу этапа люди становятся усталыми, унылыми и раздражительными, что отрицательно сказывается на производительности труда. Сложные ошибки имеют особенность появляться максимально близко к концу этапа. Программист смотрит на одну из таких ошибок, понимает, что она не из легких, и под гнетом других навалившихся на него забот сваливает ее на кого-нибудь другого, кого можно назначить ответственным за ее устранение. Как писал Вейнберг (Weinberg): «… проблемы не решаются, а просто переходят их рук в руки». Этому естественному искушению поддаются время от времени даже самые лучшие программисты.
Элементарная склонность к затягиванию сложной работы проявляется и в обнаружении ошибок, хотя причины этого кроются уже не в психологии. Дефекты, которые выявляются дольше всех или проявляются под конец этапа, обычно (как и следовало ожидать) оказываются самыми непростыми[92] (рис. 15.5). Если тенденция касается сложных, но низкоприоритетных ошибок, ей не стоит придавать особого значения, но если речь идет о высокоприоритетных ошибках, то такая тенденция становится серьезной проблемой. Подобные ошибки не только выявляются дольше среднестатистических, но и исправляются намного дольше. Обе прямые линии проектного пути, показанные на рис. 15.4, нельзя считать правильными: на самом деле линия приближения проекта к контрольной дате является близкой к асимптоте (кривой) и выглядит примерно так, как на рис. 15.6. Команда может работать с прежней интенсивностью, но результативность – в смысле приближения к целям – падает. Чем ближе контрольная дата, тем справедливее это утверждение.
Рис. 15.5. Самые сложные ошибки почему-то обнаруживаются и устраняются ближе к концу этапа. А это значит, что подход к конечной дате не выглядит прямолинейным – скорее это кривая линия на шкале прогресса (см. рис. 15.6)
Рис. 15.6. Обобщенная, но реалистичная диаграмма угла сближения, в которой предполагается, что работа идет с равномерным напряжением сил
Примерное руководство по достижению нужного угла сближения
Угол сближения этапа или всего проекта с точкой завершения работы не является какой-то тайной за семью печатями. Как и в любой связанной с планированием задачей (см. главу 2), есть определенные размышления о том, как повысить точность предсказания угла.
Обратите внимание на предыдущие показатели производительности команды и на направленность проекта. Чтобы спланировать, каким должен быть этот угол, проанализируйте, как команда справилась с эндшпилем предыдущего проекта сходной направленности. В проектах, выстроенных из множества этапов, посмотрите на кривые предыдущего этапа, сравните запланированную кривую с реальной (здесь не стоит лукавить: нужно взять первоначальный план и самую последнюю версию рабочего графика). Следует исходить из того, что планируемый этап может оказаться сложнее предыдущего независимо от того, что вы о нем думаете. Если у вас нет данных, на основе которых можно определить угол, почему бы не пофантазировать на этот счет? Если остается лишь догадываться, нужно исходить из консервативных взглядов.
Займитесь оценками. Определение угла – всего лишь разновидность задачи по оценке рабочего графика. Соберите нужных людей, разбейте оставшийся объем работы по задачам, обсудите все риски и предположения и перейдите к оценкам. По крайней мере, это позволит общими усилиями найти подходы к завершению этапа; люди, к тому же, почувствуют свою причастность к процессу совместного определения угла. Тогда общий настрой будет работать в поддержку этого процесса, а не против него.
Планируйте получить постепенно искривляющуюся, а не прямую линию. Даже при отсутствии исходных данных нужно планировать замедление темпов прогресса, принимая во внимание снижение производительности, вызванное появлением ошибок (см. рис. 15.6). Исходите из предположения, что работа по мере приближения к концу этапа будет усложняться. Вычерчивайте графики и диаграммы, используя кривые, а не прямые линии.
Не пейте Kool-Aid. Вычертить диаграмму совсем не трудно. Вы можете начертить линию где угодно, не сообразуясь с реальным положением вещей, и вполне вероятно, что вам даже удастся убедить других в том, что в форме линий, которые вы нарисовали, присутствует некая логика. Поставьте себя на место пилота нашего самолета: смогли бы вы полететь под этим углом, исходя из имеющихся у вас сведений? Подымите красный флаг; признайтесь в ошибках. Защитите свою команду от крушения при посадке. Если ваш подход излишне консервативен, то самое страшное, что может случиться, – это преждевременное завершение этапа, в то же время при слишком агрессивном подходе может произойти масса неприятностей.
Создайте свой черный ящик. Если не остается ничего другого, то обеспечьте хотя бы регистрацию объективных данных о производительности труда (см. следующий раздел). Тогда после аварийной посадки у вас хотя бы останутся свидетельства о том, что пошло не так, как надо, и вы сможете оперировать крепкими доводами при согласовании работ над следующим проектом или этапом.
Измерительные инструменты
В периоды миттельшпиля и эндшпиля отслеживание хода работы приобретает особую важность. Чем многочисленнее команда, тем труднее добиться внятной информации о состоянии проекта. Для того чтобы вносить поправки в курс (см. главу 14), необходимо иметь достаточно ясное представление о состоянии проекта, чтобы не только диагностировать те или иные тревожные симптомы, но и прогнозировать реакцию проекта на вносимые изменения.
Независимо от того, какой системе показателей будет отдано предпочтение, процесс должен быть наглядным для всей команды. В главе 14 я говорил о том, что работы являются наиболее важными инструментами для отслеживания прогресса в стадии миттельшпиля. Теперь мы углубимся в иные показатели, подходящие и для миттельшпиля, но особенно удобные для отслеживания прогресса в эндшпиле.
Для эндшпиля можно еще раз воспользоваться любыми ранее использовавшимися показателями, служащими для отражения результатов выполнения проекта; нужно только убедиться, что важные показатели не теряются среди другой информации (опустите те показатели, которые уже утратили свою значимость, например работы). Соответствующее табло нужно вывесить в общем коридоре, а в его роли может выступить простая классная доска с периодически обновляемой информацией или какое-нибудь необычное приспособление наподобие полноэкранного терминала, на который по сети выводятся самые свежие данные (полезно расположить его возле туалета, курилки или другого часто посещаемого места).
Ежедневная сборка
Ежедневная сборка проекта вынуждает разбираться с множеством различных проблемных вопросов в реальном времени, не откладывая их на будущее. Любой может просмотреть текущую сборку и сразу же определить, насколько продвинулся проект. При этом снижается зависимость от людей, работающих над отчетами о состоянии проекта или другой какой-нибудь канцелярщиной. Взамен всегда можно составить примерное представление, загрузив текущую сборку и проверив конкретную функцию или характеристику. Как бы дорого не обходилась ежедневная сборка (и необходимый для этого инструментарий[93]), ею все же стоит заниматься.
Ежедневные сборки позволяют программистам (да и всей команде) сразу же находить те компоненты, работа которых отрицательно сказывается на других компонентах, что помогает сохранить высокий качественный уровень сборки. Назначьте конкретное время для ежедневной сборки проекта, настроив людей на подготовку стабильной кодовой основы, позволяющей запускать тесты по проверке качества сборки. (Такие тесты часто называют «проверками на отсутствие дыма» по аналогии с тестами электронных компонентов, при которых монтажные платы подключаются к напряжению, а окружающие внимательно смотрят, не пойдет ли из плат дым.) После назначенного часа все проверки, касающиеся ключевых ветвей кода, просто переносятся на следующую сборку.
Каждой сборке нужен набор тестов для определения ее качества. Все, что вам нужно, – это три градации качества: хорошее (все тесты пройдены), среднее (пройдено несколько тестов) и плохое (пройдены лишь некоторые тесты или не пройдено ни одного теста). Любая отдельная ошибка, ставшая причиной провала любого теста, должна получить высокий приоритет и быть зарегистрирована вместе с информацией о сборке.
Подобные тесты на качество, известные также как проверочные тесты сборки (Build-Verification Tests, BVT), должны быть включены в набор критериев завершения этапа. На ранних стадиях этапа эти критерии могут быть более мягкими, чем критерии выхода; например, вполне приемлемым может быть получение всего лишь одной «хорошей» сборки в неделю. Однако по мере приближения команды к завершению работы над какой-нибудь функцией или характеристикой критерии должны становиться все более жесткими. Ежедневные сборки и тесты на качество всегда позволят вам иметь и показатели качества, и инструменты управления его уровнем.
Устранение ошибок и дефектов
При завершении реализации той или иной характеристики любые оставшиеся работы, которые должны быть выполнены до окончательной готовности этой характеристики, заносятся в базу данных ошибок. Это должно обеспечить проекту единую систему контроля и показателей. Система отслеживания ошибок должна быть простой, единой и использоваться всеми без исключения. Если некоторые программисты предпочитают собственные системы отслеживания своей работы и все они отличаются друг от друга, то отразить какие-либо контрольные показатели хода проекта будет невозможно. Зачастую когда команда завершает реализацию характеристики, кто-то начинает всем надоедать, требуя, чтобы показатели, отслеженные кем-то самостоятельно, были сведены в единую систему.
Возьмите себе в привычку задавать в подобной ситуации следующий вопрос: «Какой номер присвоен данной ошибке?» Если услышите в ответ, что пока никакой, прервите разговор до тех пор, пока ошибка не получит свой номер. Возможно, кому-то это покажется самодурством, но в данном случае такой шаг продиктован интересами проекта. С данной точки зрения те две минуты, которые потребуются для присвоения ошибке собственного номера, будут потрачены не зря. Если самостоятельное отслеживание процесса не влияет на сборку или на основу программного кода, в нем нет ничего плохого; просто не нужно, чтобы система мониторинга ошибок захламлялась чем-нибудь из разряда личных памяток или тривиальных списков предстоящих дел. (Или, если вы такое позволяете, нужно убедиться, что подобные вольности относятся к особому типу ошибки и могут быть отфильтрованы в отчетах и запросах.)
Чтобы на них можно было ссылаться, все ошибки должны сопровождаться определенными сведениями. Если у вас есть собственная система, которой вы вполне довольны, можете пропустить этот раздел. В системе мониторинга ошибок можно указывать самые разнообразные сведения, но исходя из собственного опыта я считаю, что для эффективной работы над ошибками необходимы следующие ключевые атрибуты:
Приоритетность. Все должно быть проще простого. Приоритет 1 – ошибка должна быть устранена; приоритет 2 – ошибка по возможности должна быть устранена; приоритет 3 – устранение ошибка желательно, но не обязательно; приоритет 4 – ошибка вряд ли будет устранена.
Серьезность. Насколько серьезно влияние данной ошибки? Серьезность 1 – потеря данных, крах системы, проблемы безопасности; серьезность 2 – основная функция не работает так, как ожидалось (предписывалось); серьезность 3 – неосновная функция не работает так, как ожидалось (предписывалось). Серьезность отличается от приоритетности. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе слова «PAPAYA!» одними заглавными буквами в поле ввода электронного адреса на странице регистрации, у нее низкий приоритет (серьезность 1, но приоритет 4).
Данные о том, кто исправит ошибку. Работа над всеми ошибками должна быть поручена конкретным людям. Распределение новых ошибок может быть отложено, но одной из задач классификации ошибок (которую мы вкратце уже рассматривали) является как можно быстрее назначить конкретных ответственных за их устранение. Чтобы показать, что ошибка может проявляться в альфа– и бета-версиях, создайте для нее атрибут под названием «действующая» или «отложенная». Ошибки с таким атрибутом позже должны быть классифицированы и их устранение поручено конкретным людям.
Воспроизведение. Это последовательность действий, позволяющая кому-то вызвать проявление ошибки. В классификации ошибок это, пожалуй, самая важная графа. Сложные случаи воспроизведения отнимают у команды время, заставляя программистов тратить больше энергии, чем необходимо на простое определение природы ошибки. «Хорошие» ошибки воспроизводятся простыми и короткими действиями.[94]
Область действия. Для крупных проектов ошибки должны быть классифицированы по месту их проявления (по области действия). Тогда их можно будет отслеживать не только по исполнителям, которым поручено их устранение, но и по компонентам проекта.
Данные о том, кто обнаружил ошибку. Имя человека, обнаружившего ошибку, с указанием контактной информации.
Статус. Ошибка может иметь только четыре состояния: активна, исправлена, решена или закрыта. Активной считается ошибка, которая еще не исправлена и требует внимания. Исправленной ошибка становится, когда программист решает, что она исправлена. Решенной ошибка становится лишь тогда, когда обнаруживший ее человек согласится с тем, что она исправлена, или с тем, что ее исправление можно отложить. Статус закрытой свидетельствует о том, что ошибки больше нет и команда тестировщиков данный факт подтвердила.
Решение. Если по ошибке принято решение, значит, она лишается статуса активной. Решение по ошибке может иметь несколько разновидностей: она может быть исправлена, отложена до следующего этапа или версии, объявлена двойником другой существующей ошибки или признана неустранимой.
Тип. Ошибки делятся на два основных типа: дефекты и рецидивы. Дефекты – это обыкновенные, хорошо всем известные ошибки. Рецидивы – это ошибки, которые, будучи однажды исправлены, проявляются снова в виде негативных побочных эффектов или каким-нибудь иным образом.
Классификация. Этот атрибут показывает, была ли ошибка классифицирована и каков результат классификации. Иногда единственными ошибками, подлежащими устранению, являются те ошибки, которые были классифицированы и помечены как принятые. Поэтому данная графа может иметь три варианта заполнения: принята, отклонена, исследуется.
Наименование. Все ошибки должны иметь короткое имя, описывающее их таким образом, чтобы суть проблемы была понятна любому человеку.
В большинстве систем мониторинга ошибок предусматривается регистрация каждой ошибки. Она позволяет отследить, кто какие изменения внес в отношении той или иной ошибки и когда он это сделал. Эта регистрация пригодится при обсуждении решений, принятых по конкретным ошибкам. Она также позволяет развеять заблуждения относительно работы над ошибками.
Диаграмма активности
На уровне проекта самое полезное, что могут принести ошибки, – это отслеживание существующих тенденций в процессе их обнаружения, оценки и разрешения. Изучая присущие проекту тенденции, вы можете сделать для себя три полезные вещи: оценить ход выполнения проекта, узнать о том, какие проблемы, относящиеся к проекту в целом, могут иметь место, и осознать, какие действия могут привести к устранению этих проблем.
Даже при наличии самой простой базы данных по учету ошибок можно опрометчиво решить, что на ее основе предельно просто составлять различные виды диаграмм и делать сложные аналитические выкладки.[95] Не стоит слишком увлекаться, имеет смысл составить только самые основные виды диаграмм. Более сложные запросы зачастую носят отвлеченный характер («Гляньте-ка! Наш уровень исправленных ошибок соответствует уровню дождливых дней в Испании!»). Прежде чем тратить свое время впустую на выдумывание новых видов детальных отчетов, задайтесь следующими вопросами:
1. На какие вопросы можно ответить, взглянув на данную диаграмму?
2. Как ответы на эти вопрос могут помочь нам выдержать нужные сроки или достичь нужного качества? Как эти ответы помогут нам достичь определенного критерия выхода или целей проекта?
3. Если числа растут, что это реально означает? Ухудшение? Прежнее состояние?
4. Поможет ли это в конце каждого дня (недели) понять, насколько мы приблизились к завершению?
С помощью диаграммы активности могут быть отслежены простейшие и наиболее важные тенденции. Для каждого дня работы над проектом из базы извлекаются и отражаются в виде линейного графика следующие данные об ошибках:
Активные. Общее количество активных, то есть не исправленных или не решенных ошибок.
Поступившие. Общее количество обнаруженных на данный момент ошибок (до классификации).
Исправленные. Общее количество исправленных на данный момент ошибок.
Рис. 15.7. Основная диаграмма активности по устранению ошибок
На рис. 15.7 можно увидеть диаграмму, отражающую тенденции основной деятельности при реализации среднего по сложности проекта на начальном периоде эндшпиля. Этот период характеризуется большим количеством активных ошибок и сравнительно высоким темпом обнаружения ошибок. Ближе к середине диаграммы (слева направо) начинают проводиться основные тесты, и темп обнаружения ошибок значительно возрастает (как и количество активных ошибок). В конечном счете, когда пройдены все тесты, кривая количества исправленных ошибок пересекается с кривой темпа обнаружения ошибок, а количество активных ошибок начинает падать. На этой простой диаграмме прослеживаются основные взаимосвязи: соотношение обнаруживаемых и исправленных ошибок определяет основную тенденцию завершения работы.
Оценка тенденций
Все диаграммы или аналитические технологии могут указывать на одну из двух вещей: осталась большая часть работы или осталась меньшая ее часть. Например, если количество активных ошибок продолжает возрастать, это означает, что проблемы накапливаются быстрее, чем убывают, и новые проблемы обнаруживаются в неизменно высоком темпе. И наоборот, если количество активных ошибок снижается, работа идет на убыль быстрее, чем обнаруживаются новые проблемы. В любом случае цель анализа тенденций заключается в том, чтобы для любой качественной характеристики понять, в каком из трех состояний она находится.
Ситуация ухудшается. На ранних фазах тестирования проекта подобная ситуация вполне приемлема и даже желательна. Если основные тестовые испытания идут полным ходом или недавно завершились, вполне естественно, что количество ошибок растет намного быстрее по сравнению с тем количеством, которое команда программистов в состоянии исправить.[96] Порой встраиваемые компоненты могут прийти позже запланированного срока, что приводит к обнаружению ошибок чуть позже, чем это ожидалось в ходе процесса. Важно понять причину ухудшения ситуации, степень этого ухудшения и то, что нужно сделать (по возможности), чтобы изменить тенденцию к лучшему.
Ситуация остается прежней. Поскольку одновременно идет процесс исправления старых и обнаружения новых ошибок, вполне возможно, что команда будет топтаться на месте. Темпы выполнения работ могут быть прежними, даже если программисты будут выкручиваться наизнанку. Если когда-либо ключевые показатели застревают на месте, то чтобы понять, что должно случиться, чтобы дело сдвинулось с мертвой точки, нужно исследовать, какие входящие и исходящие факторы влияют на показатели. Нужно обязательно сообщить об этом команде. Многие программисты склонны ударяться в панику, если работают вхолостую, поскольку они не понимают, почему проект стоит на месте (или хуже того, почему он медленно тонет).
Ситуация улучшается. Когда тенденции становятся благоприятными, важно оценить темпы ускорения и развития тенденции к концу этапа. Позитивная тенденция может быть недостаточно позитивной для соответствия критериям выхода. Если тенденция приобрела позитивный характер на начальных стадиях, следует насторожиться. Все ли контрольные тесты пройдены? Есть ли неклассифицированные ошибки? Достаточно ли высоко качество исправления ошибок? Прежде чем воспринять это явление как хорошую новость, убедитесь в том, что полностью осознаете причины, вызвавшие такое улучшение ситуации.
Полезные показатели при работе над ошибками
Существует несколько общих показателей, польза от которых при отслеживании хода эндшпиля выдержала проверку временем. Стоит поискать способы генерации этих статистических данных в автоматическом режиме, чтобы в нужный момент, когда они понадобятся для принятия того или иного решения, не тратить время на построение нового запроса к базе данных.
Темп исправления ошибок. Это скорость, с которой команда исправляет ошибки. Поскольку не все ошибки равнозначны, эта скорость представляет собой время, затрачиваемое на исправление ошибки средней сложности. Если темп исправления ошибок ниже темпа их обнаружения, а все обнаруживаемые ошибки требуют исправления, проект никогда не завершится: количество ошибок будет неизменно возрастать.
Соотношение обнаруженных ошибок к принятым. Сколько новых только что обнаруженных ошибок требуется исправить, не являются ли они дубликатами других ошибок? Не относятся ли они к ошибкам с приоритетами 3 и 4? Знание соотношения обнаруженных и классифицированных ошибок помогает сделать грубые прикидки относительно неклассифицированных ошибок. Как правило, «качество» ошибок со временем должно снижаться: соотношение «хороших» ошибок, имеющих приоритеты 1 и 2, должно уменьшиться. Примерный темп поступления обнаруживаемых ошибок не сможет подсказать, когда именно это сможет произойти.
Время существования активной ошибки. Среднее время пребывания ошибки в активном статусе. Этот показатель свидетельствует об активности команды и о том, как она справляется с текущей рабочей нагрузкой. По мере приближения к контрольной дате время реакции должно увеличиваться, потому что команда должна справляться с меньшим количеством ошибок и быть более агрессивной в классификации и воздействии на обнаруживаемые проблемы. Если время реакции увеличивается, значит, люди чем-то заняты.
Количество ошибок, приходящихся на одного разработчика. Соблюдение сбалансированности нагрузки в команде разработчиков требует следить за количеством активных ошибок, над которыми в данный момент работает каждый разработчик. Стоит также отметить, какой процент активных ошибок на данный момент поручен тестировщикам, разработчикам или руководителям проекта. Ошибки, порученные руководителям проекта или тестировщикам, не попадают на текущий производственный конвейер для исправления и их следует периодически классифицировать.
Коэффициент ответных отказов. Вейнберг (Weinberg) называет темп рецидивов, вызванных исправлением ошибок, коэффициентом ответных отказов (Fault Feedback Ratio, FFR).[97] Если каждая исправленная ошибка вызывает появление двух дополнительных ошибок, коэффициент FFR равен 2,0. Согласно утверждениям Вейнберга, приемлемым коэффициентом является число от 0,1 до 0,3. Если это число больше, значит, качество работы должно быть повышено (и/или снижен темп работы). Многие базы данных ошибок дают возможность связать новые ошибки с уже существующими, позволяя отслеживать показатель FFR. Но я никогда не сталкивался с автоматизацией этого процесса, все строилось на субъективных оценках тех, кто занимался классификацией в масштабе всего проекта. (Учтите, что иногда исправление одной ошибки просто вскрывает существование других ошибок. К FFR это не имеет никакого отношения.)
Элементы управления
Управлять проектом куда сложнее, чем отслеживать ход его выполнения. Оценка качественной информации относится к разряду дедукции, а понимание, каким образом отреагировать на существующие тенденции, требует проявления интуиции. У проектов есть собственная инерция, особенно в эндшпиле, и они не могут менять направление пропорционально оказываемому воздействию. Когда вся деятельность направлена на исправление ошибок, в команде принимается множество индивидуальных решений, что требует постоянного контакта с людьми и напоминаний о том, что, принимая эти решения, они должны придерживаться единых позиций, предположений и целей.
Лучший способ подумать об элементах управления – это рассмотреть частоту их применения. Некоторые высокоуровневые действия, такие как анализ методов управления, нужны не чаще одного раза в месяц. Для других действий, скажем, классификации, эта необходимость возникает ежедневно или ежечасно. В зависимости от необходимого уровня контроля важнее всего рассмотреть интервалы контролирующих действий.
Аналитические совещания
Аналитические совещания главным образом относятся к периоду миттельшпиля. На этих совещаниях руководитель команды должен предоставить сведения о состоянии проекта, сверив его с целями, указаниями старшего руководства, пожеланиями заказчика и самой команды. Аналитические совещания должны настроить всех на обсуждение удачных и неудачных дел и что вокруг этих дел происходило. Формат совещания может быть самым простым. Лучшие совещания, на которых и бывал, были обращены только к главным вопросам. Присутствующим на них хватало зрелости на то, чтобы открыто вскрывать (а не прятать) просчеты, приветствовать (а не осмеивать) просьбу о помощи и обращать внимание на самые главные вещи (а не на те, которые улучшают самочувствие и повышают настроение).
Аналитические совещания должны настраивать людей на реалистическую оценку целей, календарных планов, технологий и ролей. На совещании ничего не нужно оставлять на потом. Любая влияющая на проект проблема должна быть открыта для обсуждения. По этой причине аналитическое совещание является не только элементом отслеживания хода процесса, но и элементом управления, потому что оно предоставляет возможность руководителю и старшему руководству провести открытое обсуждение тех поправок, которые необходимо внести в любой из аспектов проекта. Независимо от масштабов совещания, выводы проведенных дискуссий и слайды, использованные на презентации, должны быть чуть позже предоставлены всей команде на отдельной встрече.
Команды должны планировать периодическое проведение анализа в рабочем графике в течение каждого рабочего этапа. Все должны быть оповещены о времени проведения анализа, поскольку за ним должно следовать совещание в составе всей команды. Многомесячные проекты должны включать ежемесячные аналитические совещания. Для проектов, реализуемых в течение нескольких недель, такие совещания нужно проводить один раз в одну-две недели. Чем чаще они проводятся, тем информативнее и быстрее они должны проходить.
Если ваша команда работает по контракту или имеет какого-нибудь внутреннего заказчика, аналитические совещания могут послужить одним из механизмов прямого получения отзывов от ваших заказчиков. К ним применимо большинство из уже изложенных советов. Важно также отметить, что не стоит рассматривать эти совещания в качестве единственного источника отзывов от заказчика. Периоды между совещаниями бывают слишком длительными, а формат их проведения может осложнить углубленное рассмотрение или обсуждение сложных проблем.
Один из важных аспектов экстремального программирования (XP) заключается в содействии участию представителя заказчика в самом процессе разработки программного обеспечения.[98] Этот человек должен использовать ежедневные сборки и развивать отношения с программистами и их руководителями. Тогда вы и ваша команда смогут получать отзывы о существующих проблемах ежедневно или ежечасно, а не еженедельно или ежемесячно. По началу эти отношения могут быть непростыми (см. раздел «Распределение ролей» в главе 9), но затраты всегда окупятся более разумными проектными решениями и удовлетворением заказчиков готовым продуктом.
Классификация
Любой процесс, в котором берется перечень проблем и проводится их расстановка по приоритетам, является, по сути дела, классификацией. Реальный процесс классификации отличается от других видов приоритетной расстановки тем, что связан с постоянным поступлением новых проблем, которые требуют осмысления и назначения приоритетности их решения по отношению к другим существующим проблемам. Классификация проводится в период миттельшпиля, когда есть некий промежуточный срок, который нужно соблюсти, и качественные показатели, относящиеся к критериям выхода. Но в период эндшпиля классификация становится для команды первостепенной задачей, часто занимая существенную часть ежедневного рабочего времени руководителей проекта и других специалистов.
Задачей классификации является управление производственным конвейером (рассмотренном в главе 14) с целью максимально увеличить степень важности работ, направленных на достижение критериев выхода из этапа. Чтобы достичь успеха, требуются три вещи:
Первичная обработка. Обнаруживаемые ошибки всегда отличаются по важности. Кому-то надо просматривать новые ошибки и делать квалифицированное заключение об их качественном уровне, чтобы их можно было поручить конкретному программисту, а он мог провести исследование и заняться их исправлением. Некоторые ошибки требуют исследований программиста, но фильтрация большинства из них представляет собой вполне обычные процедуры: заполняются поля (серьезность, приоритет и т. п.), уточняются возможности ее рецидива, подтверждается факт, что у нее нет двойника среди существующих ошибок и т. д. Зачастую это чисто канцелярская работа: звонки по телефону, обмен сообщениями по электронной почте и работа с конкретной сборкой для отслеживания нужной информации.
Исследование. После того как ошибки пройдут первичную обработку, начинается исследование. Нужно ли их исправлять? Нарушают ли они общий характер требований (технических условий)? Какие компоненты вызывают данную проблему и какие силы и средства нужно привлечь для их переделки? Прежде чем принять правильное решение, возможно, придется ответить на ряд вопросов как технического, так и другого характера.
Расстановка приоритетов. После первичной обработки и исследований ошибки могут быть расставлены по приоритетам и отправлены на конвейер в соответствии со степенью их важности.
Процесс классификации осложняется тем, что для выполнения любой из этих трех операций знаний какого-то одного человека может не хватить. Чем крупнее проект, тем меньше вероятность, что эффективная классификация окажется по силам одному человеку. Поэтому для большинства команд и большинства проектов классификация является коллективной работой. На ранней стадии классификация силами отдельных специалистов их собственных ошибок вполне допустима, но чуть позже эта работа должна поручаться небольшим группам и подгруппам. Это связано с тем, что ошибки должны быть классифицированы по принадлежности к различным областям проекта (см. ранее радел «Устранение ошибок и дефектов»). Небольшим группам, ответственным за определенную область, проще собираться вместе и классифицировать ошибки независимо от остальной команды.
Чуть позже, ближе к концу эндшпиля, когда каждые решения по ошибкам тщательно анализируются, классификация должна быть централизована в масштабе всего проекта и проводиться основной группой руководителей проекта (мы рассмотрим этот вопрос в разделе «Военный совет»). Теперь важно разобраться с двумя основными разновидностями классификации: ежедневной и целенаправленной.
Рис. 15.8. По мере развития эндшпиля классификация все более централизуется
Ежедневная классификация – это обычный процесс ежедневной обработки обнаруживаемых и активных ошибок. В зависимости от времени, прошедшего с начала этапа, могут потребоваться еженедельные, ежедневные или почасовые классификации. Чем больше времени прошло с начала эндшпиля, тем чаще требуется проводить классификацию.
Цель ежедневной классификации проста – поддерживать порядок. Критический путь эндшпиля проекта проходит через работу программистов, и классификация является единственным способом обеспечить эффективность конвейера. Желательно до того, как каждая новая ошибка попадет на рабочий стол программиста, провести ее первичную обработку и сравнение с существующим фондом ошибок.
Иногда лучше (в интересах эффективной работы команды) в каждой области иметь по одному человеку, занимающемуся ежедневной классификацией ошибок. Предполагая, что программисты и тестировщики согласовали критерии, этот человек должен отвечать за первичную обработку новых ошибок, пометку ошибок-двойников и расстановку обнаруживаемых ошибок по приоритетам. Предполагая, что технических знаний руководителя проекта вполне достаточно для осмысления проблемы и принятия основных решений по ошибке, он является весьма неплохой кандидатурой на эту роль.
Впрочем, классификация может проводиться и на небольшом совещании в присутствии руководителя проекта и представителей от разработчиков и тестировщиков. Если понадобятся другие специалисты из состава команды, скажем, маркетологи, проектировщики или специалисты по потребительским качествам продукта, то их можно пригласить дополнительно. Совещание должно проводиться накоротке. Все, что не может быть решено за пару минут, должно передаваться программисту на исследование.
Как только ошибки будут классифицированы, для них должно быть заполнено поле классификации. Тогда в проекте появятся дополнительные условия для представления данных об ошибках и можно будет отделить количество классифицированных ошибок (в достаточной мере распознанных) от общего количества активных ошибок (еще не прошедших оценку).
При целенаправленной классификации усилия сосредоточиваются на решении конкретных задач. Целенаправленная классификация проводится в дополнение к ежедневным классификациям. Это – одно из средств управления проектного уровня, призванное помочь придать проекту новый импульс и повысить ценность диаграмм работ по устранению ошибок и анализа текущих тенденций. Рассмотрим несколько общих причин проведения целенаправленной классификации:
Низкое соотношение числа классифицированных ошибок к числу активных. Если на 500 активных ошибок приходится лишь 200 классифицированных, то невозможно узнать серьезность оставшихся 300 ошибок. Кто знает, все они могут оказаться ошибками с приоритетом первой очереди, вызывающими полный крах системы, или двойниками уже существующих ошибок. Целенаправленная классификация может иметь особую задачу по ликвидации всех неклассифицированных ошибок к определенному сроку (к завтрашнему полудню). Ели эта проблема приобрела для команды хронический характер, задачей может стать не оставить ни одной активной неклассифицированной ошибки старше определенного количества часов (например, 24 часов).
Изменились критерии выхода. Если руководство команды решило, что критерии выхода должны претерпеть изменения, то классификация станет единственным способом вывести проект на путь этих изменений. Обычно новые критерии выхода используются для изменения угла снижения, исключая определенные классы ошибок из рассмотрения для повышения безопасности этого угла (но при этом жертвуя качеством процесса).
Слишком много незакрытых ошибок. Когда ошибка исправлена, нужно присвоить ей статус решенной и отправить сообщение назад, тому, кто ее открыл, чтобы убедить его в том, что она действительно исправлена. Определенный процент таких ошибок может быть исправлен не так, как следовало бы. Если подобные ошибки числятся незакрытыми, то набирается множество ошибок, требующих исправления, но не попадающих в отчете в число активных. В зависимости от применяемой системы мониторинга ошибок могут быть и другие места, где могут скрываться ошибки. Периодически команду нужно нацеливать на то, чтобы она извлекала их из этих закутков.
Военный совет
Ближе к завершению проекта распределенная до этого власть должна централизовываться. В отличие от проектировки функций и программирования, которые могут быть разумно распределены внутри команды, к концу проекта возможности для распределения ошибок уменьшаются. Решения становятся более критичными, представляя собой кропотливое занятие, а не создание какой-нибудь конструкции. В терминах Microsoft такое централизованное управление называется военным советом (что, по-моему, берет начало от термина военная комната, означавшего то место, где лидеры встречались для решения важных проблем). Доминирующей ветвью исполнительной власти становится небольшая группа руководителей команды. В небольших командах подобное смещение властных полномочий может быть и ни к чему, но для средних и больших команд оно просто необходимо. Оно поднимает планку всех принимаемых решений и реализует функцию принуждения в отношении команды, завершающей игру.
Настоящий военный совет не представляет собой ничего сложного. Все, что нужно для его проведения, – это конференц-зал, старший представитель от каждой штатной структуры (от программистов, от тестировщиков, руководитель проекта или другие равные ему руководители и, возможно, старшие групп) и компьютер, подключенный к большому экрану, чтобы всем присутствующим была видна обсуждаемая ошибка или проблема. Чтобы проблема прошла рассмотрение военного совета, должно быть получено согласие всех старших представителей (в некоторых командах достаточно большинства в две трети, а в некоторых члены военного совета получают право вето). Решение о повестке дня военного совета принимается каждое утро, а в саму повестку может быть внесено рассмотрение любой проблемы. Подобно суду, действующему по нормам общего права, все, что принимается или отклоняется на заседании совета, становится нормой для всей остальной команды. Заседания военного совета должны быть открытыми для команды, приоритет должен отдаваться тем людям, которые вносят конкретные запросы на изменение замысла (DCR, см. предыдущую главу) или предлагают на рассмотрение какие-нибудь ошибки.
Военный совет должен установить очень высокую планку. Любому, кто продемонстрирует военному совету свою неподготовленность или неумение ответить на основные вопросы (Каким выходным критериям это соответствует? К каким рецидивам это может привести? Согласны ли и программисты и тестировщики с тем, что это должно быть исправлено?), должно быть указано на дверь и запрещено возвращаться до тех пор, пока он не подготовится. Время военного совета следует ценить, поскольку драгоценно время всей команды. Каждый руководитель проекта и программист должен иметь четкую мотивацию на приведение своего заявления в строго обоснованный и окончательно сформированный вид, прежде чем выносить его на рассмотрение военного совета. Оказываемое давление создает естественный стимул для всей команды основательно продумать проблему своими силами, прежде чем принимать решение о выносе ее на рассмотрение военного совета. (Здесь нужно проявить осторожность: заседания военного совета могут стать слишком загруженным, а возможностей для пустой траты времени на чью-то рисовку или проявления эгоцентризма существует великое множество. Руководитель группы должен пресечь подобные проявления на самой ранней стадии.)
Команда должна быть честно предупреждена о том, когда и в связи с чем будет созван военный совет. На рис. 15.9 показаны некоторые основные этапы, на которых возникают дела, требующие вмешательства военного совета. Задача состоит в том, чтобы вести постепенную централизацию власти с объявлением дат, когда произойдут подобные подвижки. Рассмотрение DCR-запросов чаще всего становится первым использованием заседаний военного совета, поскольку может произойти на ранних стадиях в ходе миттельшпиля. Позже, когда потребности в оценке и мониторинге ошибок возрастают, в компетенцию военного совета переходит санкционирование помещения ошибок на производственный конвейер (на котором уже должны быть ранее санкционированные ошибки). И наконец, в ходе заключительных недель или дней военный совет рассматривает все обнаруживаемые ошибки, и управление проектом осуществляется полностью в централизованном режиме.
Рис. 15.9. Власть военного совета в ходе эндшпиля постепенно усиливается
Сначала заседания военного совета должны проводиться еженедельно, постепенно переходя в ежедневные получасовые или часовые встречи. В задачи военного совета входит своевременное начало и окончание заседаний (кто-то должен перед началом заседания разъяснить суть повестки дня). Если на заседании должны быть приняты выверенные решения, соответствующие критериям выхода и целям проекта, то за 60 (если не за 30) минут вполне реально рассмотреть множество DCR-запросов и классифицировать множество ошибок. Секрет в том, что в период эндшпиля надо избегать мелочной опеки.
Военный совет не должен заботиться о работе над каждой ошибкой или проблемой. Напротив, ему нужно обеспечить, чтобы решения принимались исключительно в интересах проекта, убедиться в том, что на правильные, внятно заданные вопросы даны хорошие ответы, а для использования оставшегося времени планка установлена на правильной высоте. Военные советы не смогут решать возложенных на них задач, если руководители не доверяют своим командам. Если проблема действительно серьезна, она должна быть обсуждена в рабочем порядке с одним из членов военного совета, а затем уже представлена в улучшенном виде.
В вопросах целей проекта, критериев выхода, решений о распределении ошибок по приоритетам и общения внутри команды существует множество возможностей переложить решения на плечи команды. Иногда процесс рассмотрения на военном совете может быть автоматизирован путем создания веб-форм, позволяющих членам совета рассматривать вопросы дистанционно в удобное для них время. Будьте благоразумны. Найдите способы, позволяющие не превращать военный совет в бесполезную или невольную обузу.
Вообще-то, чем меньше проблем приходится выносить на рассмотрение военного совета, тем лучше высшее руководство на пути реализации проекта справляется с планированием, с выполнением намеченного плана и с руководством командой. Если заседания военного совета постоянно проводятся в виде жестокого трехчасового марафона, это означает, что руководство терпит неудачу в одном или нескольких направлениях и из этого должны быть извлечены уроки для следующего проекта.
Окончание игры
Заключительный период разработки программного продукта – сложный и утомительный процесс. Джим МакКарти (Jim McCarthy) в книге «Dynamics of Software Development» (Microsoft Press, 1995) ссылается на него как на работу с желеобразной массой. При каждом исправлении ошибки вы как будто бы снова и снова прикасаетесь к большому кубу из желе, после чего некоторое время ожидаете, пока он перестанет трястись. Чем больше вы к нему прикасаетесь, тем больше различных вариаций его сотрясений и тем сложнее наложение колебаний, возникающих от этих сотрясений. Веб-сайт или программный продукт – это, по существу, сложнейший набор взаимосвязанных частей, и при каждом изменении одной из них вы вызываете всевозможные новые волны в его поведении. Но в отличие от желе в программном продукте не так то легко понять, когда закончатся эти сотрясения. Код не обладает прозрачностью. Понять, к чему приведет даже одно небольшое изменение, можно только после проверки качества и тщательного ручного исследования сборки.[99]
Это означает, что реально процедура завершения проекта по большей части проходит в ожидании. Час за часом тратится на просмотр и тщательное исследование новых отчетов об ошибках или проблемах, чтобы понять, не будет ли пересечена та грань, за которой желе снова начнет трястись. В больших командах эту ношу взваливает на себя военный совет. Хотя остальная часть команды должна активно выявлять новые проблемы и работать с самыми последними сборками, каждый из них может внести какой-нибудь собственный вклад в политику выжидания.
Но когда ошибка достаточно серьезна, чтобы заставить желе трястись, все опять начинают работать в полную силу. Военный совет берет на себя бремя руководства командой (или, если быть точнее, программистом), пытаясь разобраться с проблемой до такой степени, чтобы можно было применить хирургическую операцию. Затем набор тестов при разных условиях выполняется заново, чтобы гарантировать, что все пришло в прежнее состояние, за исключением той самой маленькой вещицы, которую нужно было изменить. Это очень напряженный процесс. В отличие от масштабных изменений, проводимых в период миттельшпиля, или выявлению ошибок в начале эндшпиля, в завершающие дни уже нет возможности отложить что-либо масштабное на потом. Здесь все очень маленькое, и выплеснуться напряжению некуда.
В этом процессе иные измерения и приоритеты, но они не приводят к существенным изменениям характера работы. Это просто промежуточные этапы на пути к выпуску продукта. Но, по крайней мере, они позволяют скрасить напряженную монотонность поздней стадии эндшпиля.
Баланс нуля ошибок. Когда количество активных и санкционированных (военным советом) к исправлению ошибок становится нулевым, говорят, что команда дошла до баланса нуля ошибок (Zero Bug Bounce, ZBB). Балансом это состояние называется потому, что как только обнаружится очередная ошибка, у команды уже не будет «нуля ошибок». Есть несколько симпатичных теорий относительно дистанции, разделяющей ZBB и текущий выпуск продукта, но ни одна из них не проработана в достаточной степени, чтобы попасть на страницы этой книги.
Нулевое количество решенных ошибок. Решенные ошибки могут представлять собой скрытые проблемы, о которых команда ничего не знает. Пока такая ошибка не будет закрыта (с подтверждением), полной уверенности в том, что ошибка действительно исправлена именно так, как это и предполагалось, быть не может. Достижение нулевого количества решенных ошибок означает, что проект действительно пришел в состояние возможного завершения.
Обнаруживаемыми и активными ошибками в данном случае мы пренебрегаем, поскольку они находятся ниже рассматриваемых критериев. Даже если команда занимается исследованием таких ошибок, пока они не вынесены на рассмотрение военного совета, они в действительности не влияют на продвижение проекта.
Кандидат на выпуск
Первая сборка проекта, которая отвечает всем критериям выхода, называется кандидатом на выпуск (Release Candidate, RC). Как только появится такая сборка, должен быть добавлен новый критерий выхода: какие из найденных в этой RC-сборке проблем могут стать основанием для создания второго кандидата на выпуск? Если такого критерия не существует, следует предположить, что RC-сборка прошла все проверочные тесты и тесты на качество и может быть выложена в Интернете или помещена на компакт-диск и доставлена заказчикам.
Если такой критерий существует, эндшпиль повторяется. Военный совет решает, какие исследования, проектные решения или разработки должны быть проведены, изменения утверждаются и вносятся, и процесс уходит на второй круг.
В мире программных продуктов, особенно продуктов в коробочном исполнении, RC-сборки стоят дорого. Часто применяются дополнительные тесты и процедуры, через которые должна пройти сборка для подтверждения ее прав относительно установки на компьютер, локализации, соответствия торговой марке и т. п. Что касается Интернета, то тут все зависит от того, как проект интегрируется в другие проекты. Этот механизм может напоминать сложное дерево зависимостей, которыми нужно управлять.
Процесс обкатки и связанные с ним действия
Когда завершается работа над финальной RC-сборкой, праздник в команде наступает далеко не для всех. В зависимости от природы проекта финальная RC-сборка может дать толчок для целой серии новых работ. Возможно, для команды тестировщиков и аналитиков качественного состояния продукта работа будет в самом разгаре, им потребуется оценить загруженность сервера или иные разновидности проблем совместимости, которые могут быть протестированы только при наличии финальной RC-сборки. Конечно, решение этих вопросов можно запланировать, но испытания нельзя начать до тех пор, пока все биты не окажутся на своих местах.
Большинство веб-сайтов или веб-продуктов при публикации проходят через последовательность тестовых серверов, в которых задаются различные условия и сопутствующие нагрузки для окончательного тестового охвата. Чем больше платформ или языков должен охватить проект, тем сложнее процесс обкатки. Разумеется, время, требующееся для надлежащей обкатки, может быть примерно определено на этапе первоначального планирования. В зависимости от организации процесса нагрузка по проведению обкатки может лечь на одну подгруппу или разделена на всю команду разработчиков проекта.
Проектная постпрограмма
Поскольку приближается завершение этапа или всего проекта, кто-то должен настроить команду на извлечение уроков из всего только что сделанного. Эту работу часто называют описанием ретроспективы проекта, или постпрограммой. На эти действия наталкивает желание зафиксировать информацию, пока она еще свежа в памяти людей, а когда люди соберутся отпраздновать успех и отложить все дела, им вряд ли захочется возвращаться назад и вспоминать обо всех проблемах, с которыми они недавно имели дело. Многие хотят двигаться вперед, оставляя позади свое прошлое.
И тут снова на первый план выступает руководитель. Руководитель команды должен внести свой вклад в процесс выполнения постпрограммы. Поскольку дел становится все меньше, руководитель должен попросить людей подумать над тем, что удалось, а что нет, и оформить это хотя бы в виде списков на отдельных листках бумаги. Руководитель проекта должен составить план по сбору этих записей и созданию постпрограммного отчета. В отчете должны быть отражены две вещи: анализ и резюме всех извлеченных уроков и обязательство учесть в следующем проекте самую незначительную часть этих уроков (если подборка окажется слишком большой, чтобы попасть в следующий проект, расставьте приоритеты и выберите самое главное).
Возможно, для выполнения постпрограммы имеет смысл нанять профессионала[100] (или взять кого-нибудь не из команды, а из организации). Исполнители, потратив неделю на расспросы всех специалистов команды, на основе изученного материала составят отчет, который должен пройти экспертизу консультанта. Преимущества такого подхода заключаются в объективности взгляда, поскольку сторонний наблюдатель подметит и озвучит то, что ускользает от взгляда других людей.[101] Возможно, более важным станет то, что они принесут в организацию стороннюю оценку, обращенную к нуждам конкретного проекта и команды.
Время устраивать вечеринку
Когда будет утвержден выход финальной RC-сборки, и она пройдет свой путь сквозь процесс становления во внешний мир, настанет время отпраздновать это событие. Спустя многие недели, месяцы или даже годы, то, что вы предполагали создать, наконец-то завершено. Завершение проекта довольно редкое и специфическое событие – в технической сфере многие проекты никогда даже и близко не подходят к такому результату. Руководитель проекта должен проследить, чтобы у каждого, кто участвовал в проекте, была возможность вместе со всеми отпраздновать его завершение. Избегайте корпоративных стереотипов (этот праздник невозможно провести в конференц-зале). Лучше пойдите в ближайший бар, закажите огромный стол в любимом ресторане или пригласите всех ребят к себе домой. Когда в запасе много времени, то питье и еда кажутся вкуснее (а пить и есть нужно побольше). Если вы не способны зажечь и развеселить людей, отыщите такого человека в команде, сговоритесь с ним и организуйте что-нибудь необычное.
У большинства из нас за всю карьеру набирается не так уж много завершенных проектов. Невероятно трудно создать достаточно хорошую вещь, чтобы люди могли использовать ее в своей повседневной жизни. А раз уж вам повезло, и время для грандиозного праздника настало, покажите, что умеете прожигать жизнь.
Выводы
• Долгие сроки – это просто сумма нескольких коротких.
• Каждый этап содержит три коротких срока: завершение проектирования (когда закончена работа по выработке технических условий), реализация заданных характеристик (закончена фаза разработки) и завершение всего этапа (закончены проверка качественных показателей и оптимизация).
• Определение критериев выхода в самом начале этапа повышает возможности команды на его своевременное завершение.
• Своевременное завершение этапа подобно приземлению самолета: то и другое требует приближаться к финишу долго и медленно. При этом нужно быть готовым к внезапному повторному взлету, чтобы не пришлось заниматься серьезным ремонтом.
• Для мониторинга хода проекта нужны оценочные инструменты. Обычно к ним относят ежедневную сборку, работу над ошибками и диаграмму активности.
• Для внесения корректив на уровне проекта нужны элементы управления. Традиционно для управления используют аналитические совещания, классификацию ошибок и военный совет.
• Завершение проекта представляет собой медленный и утомительный процесс. Сложность состоит в том, что пределы возможных изменений сужаются до тех пор, пока не остается достаточно удовлетворительная версия продукта.
• После завершения проекта настает время постпрограммы. Обеспечьте себе и своей команде возможность проанализировать все победы и поражения, имевшие место в ходе реализации проекта, и извлечь пользу из этого анализа.
• Если фортуна смилостивилась над вами и проект все же вышел в свет, порадуйтесь этому событию. Почувствуйте себя счастливым. Многие и не по своей вине никогда не достигают подобного успеха. Спланируйте грандиозную вечеринку. Веселитесь, не боясь экстравагантных поступков (включая приглашение к себе автора этой книги). Пусть будет о чем вспомнить.
Упражнения
1. Когда вы в следующий раз будете работать над проектом в стадии эндшпиля, начните вести список отслеживаемых данных, которые вы хотели бы получить при реализации проекта. Возьмите обязательство вести запись этих данных с начала следующего проекта.
2. В следующий раз при составлении критериев выхода в качестве эксперимента потребуйте от авторов критериев, чтобы они, используя эти критерии, приняли участие в первом совещании по классификации ошибок. Это должно заставить их выдерживать критерии в практическом русле, предоставляя больше возможностей для их усовершенствования в самом начале эндшпиля.
3. При классификации один из программистов настаивает на том, чтобы решать судьбу каждой ошибки. Он грубит, насмехается и делает все возможное, чтобы навязать свое мнение. Проблема в том, что в большинстве случаев он оказывается прав. Что вы должны предпринять?
4. В начале эндшпиля ваша команда взбудоражена тем, что перешла к последней стадии, но вы уже перегорели. Проекту уже отданы все силы. Признаетесь ли вы в этом своей команде или попытаетесь все от них скрыть? Как можно восстановить свои силы?
5. Выберите какую-нибудь другую отрасль: как в ней управляют завершающей частью календарного плана проекта? К интересным примерам можно отнести кинопроизводство, действия любой из групп спецопераций вооруженных сил (Морских котиков, Ниндзя, Спартанцев) или работу ваших любимых ресторанов, выполняющих заказы с доставкой на дом. Подготовьте небольшую презентацию для своей команды, демонстрирующую ваши методы в сравнении с методами, использующимися в этих областях.
6. До выпуска главного обновления вашего веб-сайта новостей, имеющего миллионную аудиторию, осталось два дня. Уже заготовлено шампанское. Но разработчик обнаруживает серьезную проблему, на устранение которой требуется три дня. Сложность в том, что ко дню запуска приурочена реклама стоимостью 10 миллионов долларов, за которую уже заплатили. Что вы сделаете?
7. Представьте, что вы один из пяти лидеров, участвующих в военном совете. На каждой встрече в присутствии множества подчиненных между пятью лидерами вспыхивают жаркие споры, продолжающиеся иногда более десяти минут. Как это повлияет на команду? Составьте перечень различных подходов, которые можно было бы применить как на самих встречах, так и после них.
8. Представьте, что вы только что выпустили самую грандиозную программу за всю историю человечества. Ваша команда попала на обложку журнала «Time», вы все прославились. Как вы отпразднуете это событие? Сколько средств выделите на торжество? Где все это устроите? А теперь подумайте о своем текущем проекте. Он может претендовать на выпуск лучшей программы, когда либо создававшейся в рамках подобных проектов. Неужели команда не заслуживает того, чтобы отметить ее достижения каким-то особым образом?