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

Динозавров - на пенсию!

Сегодня я поделюсь замечательной статьёй Джима Хайсмита (Jim Highsmith) "Устаревшие методологии - на пенсию!" ('Retiring Lifecycle Dinosaurs'), продолжающей серию постов о гибких (agile) методолоиях.

Как и большинство статей по agile, статья строится на том факте, что методологии разработки программного обеспечения могут и должны быть не менее изменчивыми, чем бизнес требования, технологии и сами люди:

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

Автор приводит основы разработанной им адаптивной методологии ASD (Adaptive Software Development), которая позволяет изменять многие параметры процесса прямо по ходу проекта, адаптируясь к новым условиям и обучаясь на ошибках и недостатках:

В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение). Этот цикл ставит своей целью непрерывное обучение. Он связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. (Обратите внимание, что весь этот цикл не всегда представляет собой правильный круг. Даже при итеративном процессе можно иногда отклоняться в сторону, чтобы изучить неисследованные до сих пор области). Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО.

Такой подход меняет традиционную последовательность действий и приоритеты при выполнении проекта, ставя во главу угла обучение:

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

Это и радикально преобразуют весь стиль управления: 

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

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

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

Изложенный подход очень органично перекликается с подходами Мартина Фаулера к необходимости постоянного рефакторинга:

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

Примечательно аргументируется необходимость жёстких временных рамок для успешного протекания процесса:

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

На закуску пару весьма красивых фраз из статьи, призванных убедить всех в необходимости перехода к новым методикам работы: 

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

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


Posted by Vitalii Tsybulnyk on Friday, July 24, 2009 5:22 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading