Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Новые методологии программирования Мартина Фаулера

Сегодняшний пост пожалуй будет последним из короткого цикла о гибких (agile) методологиях. Сегодня у нас в гостях снова Martin Fowler (Мартин Фаулер), несдвигаемая глыба в области современного проектирования и архитектуры программных продуктов, со своей статьёй 'The New Methodology' ("Новые методологии программирования").

Статья является великолепным обзором истории и нынешного состояния мирового Agile течения (или точнее сказать потока).

Первая часть статьи приводит предпосылки возникновения Agile:

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

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

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

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

Далее Фаулер переходит к некоторым деталям и сложностям построения или перехда на гибкий процесс:  

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

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

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

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

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

Далее в статье приводится замечательный пересказ истории возникновения различных направлений Agile (XP, Scrum, Crystal, Lean, RUP) и их объединения в единый термин Agile.

Статья непременно должна быть прочитана теми, кто работал, работает или собирается работать согласно Agile.


Posted by Vitalii Tsybulnyk on Sunday, August 2, 2009 5:26 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading