|
Страница 1 из 5
Форма созданных человеком вещей меняется всякий раз, когда он обнаруживает в них уже существующие или потенциальные недостатки" - пишет Генри Петроски (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 подходит гораздо лучше, чем любой традиционный подход к разработке ПО. В конце этой статьи вы найдете ссылки на более подробное изложение теории адаптивных систем.)
|
