"Форма созданных человеком вещей меняется всякий раз, когда он обнаруживает в них уже существующие или потенциальные недостатки" - пишет Генри Петроски (Henry Petroski), профессор, преподающий гражданское строительство, и автор книги "The Evolution of Useful Things" ("Эволюция полезных вещей"). "Этот принцип справедлив для всех изобретений, инноваций и нововведений. Именно он заставляет работать творческую мысль изобретателей и инженеров". В том же ключе пишет и другой автор, Стюарт Брэнд (Stuart Brand). Он тоже полагает, что постулат "форма проистекает из функциональности" - не более чем иллюзия. В его книге "How Buildings Learn" ("Чему учит строительство") мы читаем: "Луи Салливан (Louis Sullivan) провозгласил, что форма следует за функциональностью, в результате чего большинство архитекторов более ста лет свято верили в то, что могут предвидеть все нюансы функционирования своих творений".

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

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

Сейчас довольно много различных методологий разработки ПО приняли на вооружение итеративный подход. Впрочем, большинство из них упускает из вида такие важные факторы как неупорядоченность и непредсказуемость сложных условий работы (высокая скорость, большой объем изменений). Несмотря на использование итераций, в остальном все базовые положения этих методологий остаются детерминистическими. Можно сказать, что в целом они напоминают несколько коротких "водопадных" циклов, связанных между собой.

Однако темп развития технологий и бизнеса все убыстряется, и статические способы управления становятся непригодными. Старый мир был миром оптимизации, где правили эффективность, предсказуемость и контроль. Новый мир - это мир адаптации, в котором главное место отводится изменениям, импровизации и новым идеям. Такая дихотомия - оптимизация против адаптации - позволяет нам ясно представить себе будущее управления программными разработками.

Странно, что до нас, виновников самых масштабных технологических изменений за всю историю бизнеса, это до сих пор "не доходит". В каждой публикации - будь то статья в "ComputerWorld" или "Business Week", нам вещают о том, что "бизнес никогда не будет прежним". Почему же тогда мы настаиваем, что процесс разработки ПО и методологии управления этим процессом могут избежать этих капитальных изменений? Мы вполне согласны с мыслью, что все должно измениться, чтобы подстроиться под новые правила мира 21 века - мира Интернета. "Да, - говорим мы - все должно меняться, кроме нас с вами и того, как мы привыкли делать то, что мы делаем". Разве есть смысл в такой позиции?

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

Adaptive Software Development (ASD) - одна из новых методологий, которые появились как альтернатива традиционным, ориентированным на процесс, методам управления разработкой ПО. ASD, Extreme Programming (XP), Lean Development, SCRUM и семейство методологий Crystal, конечно, во многом отличаются друг от друга, однако у них всех есть одна общая черта - во главу угла в них ставится человеческий фактор, рельзультаты работы и минимизация самого процесса при максимальном увеличении взаимодействия между людьми. Все эти методологии были разработаны исходя из объективных реалий современного высокотехнологичного бизнеса, который отличается огромной скоростью развития и высокой изменчивостью.

Чем бы вы не руководили - тестированием, командой разработчиков или всем проектом в целом, пришло время пересмотреть те ценности и положения, которые лежат в основе процесса руководства. Практики ASD базируются на принципе непрерывной адаптации, благодаря которой возникает другая философия и другой жизненный цикл проекта, когда постоянные изменения становятся нормой.

В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение).

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

Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО. В конце этой статьи вы найдете ссылки на более подробное изложение теории адаптивных систем.)

Жизненный цикл проекта, ориентированный на внесение изменений Главной предпосылкой типичного цикла управления проектом - Plan-Deliver-Review (Планирование - Поставка - Просмотр) - является относительно стабильное бизнес-окружение. В наши дни найти такое окружение практически невозможно, поэтому традиционные методологии не справляются с постоянным потоком изменений. Первый шаг в таком цикле, планирование, представляет собой наиболее трудный момент для большинства инженеров и менеджеров. Планирование возникло на основе редукционизма (науки сокращать любую вещь до ее составных частей) и почти религиозной веры в то, что тщательное планирование, за которым следует строгое осуществление намеченных планов, приводит к достижению желаемого результата ("мы контролируем ситуацию"). Именно поэтому многим из нас кажется такой странной идея, что сделать все правильно с первого же раза попросту невозможно.

В самом слове "планирование" (в том смысле, в каком его используют в большинстве организаций) слышится большая доля уверенности в результатах работы. При этом как явные, так и скрытые цели "составления плана" существенно ограничивают способность руководителя исследовать новые направления работы, искать новые пути решения возникающих проблем. Работая по плану, вы, скорее всего, сумеете достичь намеченных результатов, вот только эти результаты в итоге могут совсем не совпадать с тем, что вам нужно.

Обдумывание дает гораздо больший простор мыслям и исследованиям, предоставляет возможность прояснить те вопросы реализации проекта, в которых вы пока сомневаетесь, и, наконец, позволяет без всякого страха и угрызений совести отклоняться от намеченных планов. Это вовсе не означает, что планирование устарело и больше не нужно. Просто необходимо сознавать, что в наши дни оно должно быть куда менее полным и категоричным, нежели раньше. Это также означает, что циклы поставки продукта должны быть короткими, и что в них необходимо использовать итеративный подход. Обдумывание не исключает планирования, но в отличие от него, признает правомочность любых необходимых изменений. Чаще всего отклонения от традиционно разработанных планов немедля попадают в разряд ошибок, подлежащих немедленному исправлению, в то время как многие из них являются прекрасной возможностью получить новый опыт и знания. При обдумывании вы отдаете себе отчет в том, что любая сложная проблема имеет неоднозначную природу. Более того, обдумывание подразумевает проведение исследований и экспериментов, направленных на ее выяснение. Обдумывание (которое так сложно воспринимать моим клиентам из банковских кругов) позволяет нам осознать тот факт, что мы не можем знать все. А раз мы признаем, что не знаем все, а следовательно, можем ошибиться, то гораздо легче воспринимаем третий шаг цикла ASD - Обучение.

Между этими двумя циклами есть второй, средний компонент. Имя ему - Взаимодействие. Сложные системы не создаются за один раз - они растут и развиваются. Для того чтобы работать над такой системой, нужно собрать большое количество разнообразной информации, проанализировать ее и понять, как ее можно применить к данной проблеме. Такая работа не под силу одному человеку. "Никто из нас поодиночке не сравнится со всеми нами вместе" - пишут Уоррен Беннис (Warren Bennis) и Патриция Бидерман (Patricia Biederman) в своей книге "Organizing Genius" ("Сплотить таланты").

Большинство разработчиков вполне прилично владеет навыками анализа, программирования, тестирования и т.д. (хотя, разумеется, любые знания всегда стоит пополнять и улучшать). Однако для современного бизнес-окружения характерно постоянное увеличение потока информации (с одной стороны) и необходимость владеть знаниями из самых разнообразных областей (с другой). Так, чтобы создать сайт для электронной торговли, нужно задействовать гораздо более богатый набор технологических решений, знаний в данной сфере бизнеса и других полезных навыков, чем для создания типичного программного продукта пять - десять лет назад. Сейчас весь поток информации не может охватить не только один человек, но даже небольшая команда, поэтому в наши дни, чтобы "знать все" нужно научиться широко взаимодействовать с другими людьми, организациями и командами. Навыки такого сотрудничества - от совместной работы над проектом до совместного принятия решений - уже стали жизненно необходимыми компонентами для успешной работы над любым проектом.

В книге Майкла Шраге (Michael Schrage) "No More Teams, Mastering the Dynamics of Creative Collaboration" ("Команд больше не будет или Постигаем динамику созидательного сотрудничества"), сотрудничество называют "актом совместного создания и/или открытия чего-либо". Проблема, говорит Шраге, вовсе не в команде, а в том, "какие отношения должны строить и поддерживать организации, если они хотят поставить своим заказчикам и клиентам действительно уникальный продукт". Совместная работа не признает тех границ, в которых существуют обычные команды разработчиков. Она охватывает и команду программистов, и заказчиков, и сторонних консультантов, и тех, кто будет торговать этим программным продуктом. Таким образом, сотрудничество и взаимодействие становятся третьим необходимым "китом" для построения более гибкой методологии управления проектом. Команды разработчиков должны взаимодействовать при решении технических проблем и при определении требований к системе. Им необходимо улучшать свою способность принимать совместные решения. Руководству, кстати, пора передать командам больше прав для принятия решений, так как постоянные изменения (и жесткий график работ) совершенно исключают традиционный стиль управления - Command - Control (Приказ - Контроль).

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

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

Так, например, постмортемы проекта очень просты по сути. Они служат исключительно для того, чтобы определить, что прошло хорошо, где были сбои, и, наконец, какие изменения необходимо произвести. Как ни странно, многие организации не делают постмортемы, поскольку подобный обзор проделанной работы непременно превращается у них в политические игры и взаимные обвинения. Очень часто, вместо того, чтобы спросить себя "чему нам надо научиться?" мы начинаем искать ответ на вопрос "кто в этом всем виноват?". Запомните, чтобы ваша организация стала адаптивной и гибкой, ей нужно в первую очередь стать организацией, где умеют и любят обучаться.

Характеристики адаптивного процесса У адаптивного жизненного цикла есть шесть базовых характеристик: Mission Focused (Целенаправленность), Component Based (Компонентный подход), Iterative (Итеративность), Timeboxed (Жесткие временные рамки), Risk Driven (Оценка с точки зрения рисков) и Change Tolerant (Допустимость изменений).

Те, кто работают над проектами в сфере электронного бизнеса, редко с самого начала четко понимают, какими должны быть результаты их работы. Тем не менее, они ясно осознают общую цель, и эта цель достаточно ясно формулируется команде разработчиков. Основные положения цели служат направляющими для первоначального исследования, а далее, в процессе работы над проектом, начинают сужаться. Цель определяет, скорее, границы проекта, а не его конечный результат. Итеративный проект без правильно поставленной общей цели и постоянного пересмотра текущих задач становится "проектом-маятником" - разработки движутся туда-сюда, итерация за итерацией, без видимого прогресса. Артефакты, в которых зафиксирована цель всего проекта (их может быть несколько типов), не только помогают указать нужное направление работ, но и используются для того, чтобы в случае острой необходимости найти компромиссное решение. Если такие артефакты не помогают в принятии решений, то значит, они были созданы неправильно.

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

В итеративном жизненном цикле "переделка" продукта занимает не меньше места, чем его "создание". На производстве все обстоит по-другому. Там специальные программы, следящие за качеством работы станков, помогают избежать "брака" (результата ошибки в процессе изготовления какой-либо вещи) и последующей его переделки. Однако в области программных (и прочих интеллектуальных) разработок дело обстоит несколько по-иному, чем на конвейере, где бездушный автомат каждые несколько секунд штампует одинаковые штуковины. Кстати, весьма вероятно, что сама штуковина была спроектирована и разработана с применением итеративного процесса. Компоненты же, как правило, претерпевают изменения на протяжении нескольких итераций. Это происходит из-за того, что заказчики сообщают разработчикам свои комментарии относительно продукта по мере его развития.

Жесткие временные рамки, или установление фиксированных сроков поставки для каждого итеративного цикла, нередко подвергается яростной критике со стороны поклонников быстрых программных разработок (rapid application development, RAD). Но это происходит потому, что они совершенно неверно подходят к вопросу установления этих сроков. Заранее установленные временные рамки проекта, из-за которых приходится то растягивать работу на долгие часы, то торопиться, жертвуя качеством работы, представляют собой самую настоящую тиранию и произвол, они подрывают ту атмосферу сотрудничества, к которой так стремится адаптивный процесс. В течение нескольких лет я руководил RAD-проектами, прежде чем понял (я вообще человек медлительный), что, говоря о жестких временных рамках, мы должны иметь в виду не столько время и сроки, сколько принятие сложных компромиссных решений. Когда тебя окружают постоянные изменения, нужно периодически задействовать некий фактор, который будет заставлять доводить начатое до конца. Кроме того, существование временных рамок заставляет команду разработчиков и клиентов постоянно пересматривать основные показатели проекта: его границы, расписание работ и поставок очередных версий, ресурсы, дефекты и т.д. Те команды, которые не могут (или не хотят) принимать быстрые решения и делать выбор, никогда не добьются успеха в экстремальных условиях.

Как и в спиральной модели Бэрри Боэма (Barry Boehm), планирование в адаптивном жизненном цикле ведется исходя из осознания и анализа критических рисков. Кроме того, адаптивный способ разработки ПО приемлет и приветствует все возникающие изменения. С адаптивной точки зрения, возможность внесения изменений - это конкурентное преимущество, а не просто еще одна "проблема".

Базовая модель адаптивного процесса Итеративный цикл "Speculate/Collaborate/Learn" ("Обдумывание/Взаимодействие/Обучение") годится для общего описания процесса, но для того, чтобы действительно производить на его основе программный продукт, нужно подробнее остановиться на некоторых деталях. На рисунке 2 изображена базовая модель адаптивного процесса со всеми его компонентами.

Обдумывание: Начальная фаза проекта и планирование циклов разработки "Обдумывание" состоит из семи последовательных шагов:

Провести начальную фазу проекта. Определить временные рамки проекта. Определить оптимальное количество циклов и временные рамки каждого из них. Расписать основные задачи по всем циклам. Связать разрабатываемые компоненты системы с соответствующими циклами. Связать с циклами технологические компоненты и компоненты поддержки. Разработать список задач по проекту. В адаптивном процессе начальная фаза проекта немногим отличается от той, которая существует в любом нормальном процессе управления проектами. Она включает в себя определение целей и задач проекта, осмысление и документирование различных ограничений, изучение расстановки сил в проекте (то есть организацию самого проекта и определение ключевых фигур), выявление и краткое описание требований к системе, первоначальную оценку размера и масштабности проекта, а также определение ключевых рисков. Поскольку одним из важнейших факторов, принимаемых на рассмотрение при использовании адаптивного подхода, является скорость разработки системы, то большая часть изначальной информации по проекту должна собираться во время сессий Joint Application Development (JAD, Совместная разработка программного продукта). Для небольших проектов всю начальную фазу можно уложить в недельный срок. Для более крупных целесообразно запланировать так называемый "нулевой цикл", который позволит разработчикам провести более обширные предварительные исследования и подготовительные работы. ("Нулевой цикл" отличается от всех последующих тем, что его результатом будет не реальная часть системы, а некие подготовительные материалы).

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

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

Определив количество необходимых циклов и график выполнения каждого из них, команда переходит к четвертому шагу: определяет цели и задачи для каждого цикла разработки. Четко поставленная цель должна быть не только у всего проекта в целом, но и у каждого цикла в отдельности. Промежуточные контрольные точки в конце каждого цикла призваны обеспечить доступность и обозримость создаваемого программного продукта для участников проекта. Без этой доступности и обозримости невозможно увидеть и исправить различные дефекты и ошибки, без которых не обходится ни один проект.

В конце каждого цикла заказчик получает определенный набор компонентов системы, которые может (и должен) просмотреть и прокомментировать. Это позволяет ему реально увидеть и опробовать разрабатываемую систему. Для интеграции отдельных компонентов системы в течение каждого из циклов служат промежуточные сборки (builds). Они позволяют увидеть и опробовать систему самой команде разработчиков. Если система постоянно доступна для обозрения, то тестирование становится непрекращающейся и неотъемлемой частью каждого цикла, а не лихорадочной деятельностью в самом конце работ, перед сдачей продукта.

Во время пятого и шестого шагов производится соотнесение определенных компонентов системы с циклами разработки. Главным критерием здесь должно быть такое правило: в конце каждого цикла заказчику поставляется видимая, осязаемая, работающая часть системы. Распределение компонентов по циклам - непростая задача. Среди многих факторов, которые оказывают влияние на принятие того или иного решения, можно назвать следующие:

В конце каждого цикла заказчику должен поставляться некий осязаемый "кусок" системы В первую очередь в разработку должны идти компоненты с наиболее высоким риском График разработки компонентов должен учитывать естественные зависимости между ними Балансировка расходов ресурсов Планировать циклы исходя из разрабатываемых компонентов лучше всего с помощью электронной таблицы (см. рис. 3).

В первой колонке указаны все необходимые компоненты системы. По одной колонке отведено и на каждый из циклов. Как вы видите, когда команда принимает решение разработать определенный компонент в течение какого-либо цикла, в соответствующей строке таблицы ставится крестик. Опыт показывает, что такой тип планирования (им занимается вся команда разработчиков, а не исключительно руководитель проекта) дает возможность разработчикам гораздо лучше понять проект, чем это бывает при обычном подходе с ориентацией на задачи. Планирование, в основе которого лежит график разработки компонентов системы, отражает уникальность каждого проекта. Конечно, для таких видов деятельности как анализ, объектное моделирование или проектирование могут (и должны!) существовать "наилучшие практики", однако именно поставляемые заказчику компоненты вносят в эти виды деятельности те коррективы, которые делают их уникальными для данного конкретного проекта.

И, наконец, специально для тех, кто чувствует себя неуютно без списка задач по проекту - создание каждого компонента может восприниматься как конечный результат соответствующей задачи: Создать компонент А. В список можно вносить и дополнительные задачи, которые хоть и не связаны напрямую с компонентами, но необходимы для успешного завершения работы над проектом. Однако, несмотря на то, что в план проекта и можно вносить дополнительные задачи, его основу должен составлять структурный анализ компонентов системы, а не структурный анализ работ.

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

В небольших командах, работающих в одном месте, согласованность, параллелизм и взаимодействие можно усилить с помощью практик методологии Extreme Programming (ХР). Так, например, при парном программировании два человека работают за одним компьютером: при этом каждый непроизвольно старается отличиться, отчего улучшается общее качество работы.

Совместное владение кодом (еще одна практика ХР) выводит сотрудничество между разработчиками на новый уровень. Благодаря этому подходу каждый может вносить в любой код свои собственные изменения, что заставляет всю команду работать еще более сплоченно. Все разработчики - и по отдельности, и парами - делают все возможное, чтобы максимально повысить качество дизайна системы, кода и тестовых сценариев.

Отношения между людьми являются самым главным моментом современного бизнеса, как пишут в своей новой книге "The Soul at Work: Embracing Complexity Science for Business Success" ("Душа обязана трудиться или Как воспользоваться наукой о сложностях, чтобы добиться успеха в бизнесе") Роджер Луин (Roger Lewin) и Бирют Режин (Birute Regine). Отношения между людьми важны "не только по чисто человеческим причинам, но и как способ для достижения лучшей адаптивности и успеха в бизнесе", - считают эти авторы. На сегодняшний день строгий контроль и процесс (то есть, те составляющие, которые ранее были необходимы для успешного осуществления проектов) должны заменяться на альянсы между различными компаниями, совместное преодоление проблем и совместное принятие решений, а также на обмен знаниями и опытом.

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

Вот то, что нужно знать в конце каждого цикла разработки:

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

Вторым показателем качества продукта является его оценка с технической точки зрения. Стандартный способ определить техническое качество системы - это провести ее технический анализ. Пересматривать дизайн системы можно в конце каждого цикла, тогда как пересмотр кода или плана тестирования может проходить в течение самого цикла. Целью анализа должно быть обучение, а не поиск виноватых.

В-третьих, необходимо следить за самим процессом работы команды, вернее, за людьми и за процессом. Для этого необходимы ретроспективные пересмотры в конце проекта, а также в конце каждого цикла.

Вот какие вопросы вы должны задавать себе во время постмортемов:

Что работает? Что не работает? Чего нам нужно делать больше? Чего нам нужно делать меньше? Никакая другая практика не демонстрирует способность организации к обучению, как подобный анализ. Благодаря нему мы лучше понимаем и самих себя и то, как мы работаем.

И, наконец, последним пунктом нашего плана идет определение статуса проекта, что впрочем, не относится напрямую к вопросам качества. Это ведет к повторному планированию в начале каждого последующего цикла.

Основные вопросы, на которые вам нужно ответить:

На какой стадии развития находится проект? Чем его положение отличается от того, что ожидалось по плану? В каком положении он должен находиться? При использовании компонентного подхода, определение статуса проекта выглядит несколько по-другому. В методе водопада, конец каждой фазы проекта отмечен окончанием работы над определенными его артефактами (например, результатом фазы разработки спецификации является документ, в котором полностью описаны все требования к системе). При компонентном подходе статус проекта будет определяться не одним документом или артефактом, а целым рядом компонентов, которые могут находиться на разных стадиях готовности.

Вполне очевидно, что далеко не каждому понравится такой метод. Многие руководители, привыкшие к традиционным методам, при компонентном подходе почувствуют, что могут частично утерять контроль и влияние на процесс. В таком случае, им лучше пересмотреть свои идеи и соображения относительно прогресса проекта.

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

Вперед, в будущее "Оптимизирующие" культуры ставят во главу угла эффективность, контроль и строгий процесс. Однако эра Интернета уже внесла изменения в фундаментальную основу этих положений - в предсказуемость. Никто уже не возьмется предсказывать (с любой степенью точности) результаты работы над проектом из разряда электронной коммерции, рассчитанного на двенадцать месяцев. (С какой стати он должен быть таким продолжительным - это отдельный вопрос.) Слишком много в нем будет составляющих, которые будут очень часто меняться.

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

Далеко не каждый проект можно считать сложным. В большинстве организаций сложные проекты составляют не более 20% от общего числа (однако это очень важные 20%!). Решение сложных проблем создания и тестирования ПО не означает отказа от старых добрых практик управления проектом и сложившихся методов работы, нужно просто по-новому посмотреть на то, как их использовать. Нужно понимать, что разработка ПО - вовсе не механический, а органичный, нелинейный и недетерминированный процесс. Нужно изменить базовые принципы, на которых организации строят свою работу при решении сложных проблем, а также начать применять новые, связанные с ними, практики. Перейти из разряда оптимизирующих культур в разряд адаптивных означает сделать шаг в будущее, а не прозябать в прошлом.

Джим Хайсмит (Jim Highsmith) (jimh@adaptivesd.com) - президент компании "Information Architects, Inc"., автор книги "Adaptive Software Development: A Collaborative Approach to Managing Complex Systems" ("Адаптивная разработка программного обеспечения: совместный подход к управлению сложными системами), редактор " E-business Application Delivery. Консультирует те IT организации и компании, занимающиеся программными разработками, которые стремятся работать в более высоком темпе.

Ссылки по теме:

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам