Гибкие методы

Материал из PraxOS

Гибкие методы (англ. agile methods) -- это название, которое дали 17 отцов-основателей различных систем организационных практик разработки софта (software methodologies) тем системам практик, которые соответствуют принципам, изложенным в "Манифесте гибкости" (http://agilemanifesto.org/, 2001г.). Принципы "гибкости" свелись к тому, нужно ценить:

• личности и взаимодействие больше процессов и инструментов
• работающий софт больше всеобъемлющей документации
• сотрудничество с заказчиком больше переговоров при контрактации
• ответ на изменения больше следования плану.

Отцы основатели представляли самые разные организационные практики (Scrum 1986г, Экстремальное программирование 1996г., Crystal Clear, Adaptive Software Development и т.д.) которые все основывались на принципах гибкости: переход от "предсказательного планирования" к "планированию от опыта".

Примерно в это же время (1995г.) в промышленности появилось определение "гибкого производства" (agile manufacturing, http://en.wikipedia.org/wiki/Agile_manufacturing), включающее:

• поставку заказчику какой-то ценности (delivering value to the customer)
• готовность к изменениям
• признание ценными знаний и способностей людей
• формирование виртуальных партнерств

и все это для гибкости (agile -- "ловкость", "шустрость", "проворство"), понимаемой как скорость перестройки производства с одного вида продукта на другой.

В промышленности из многих конкурирующих подходов в конце концов победили методы "экономного производства" (lean manufacturing, http://en.wikipedia.org/wiki/Lean_manufacturing) и движение управления сетями поставок (Supply Chain Management), основанное на теории ограничений . "Гибкое производство" устарело, едва родившись и не стало модой -- хотя его принципы существенно используются во всех современных бизнес-философиях . В области же программирования гибкие методы стремительно набрали силу и стали стандартом де-факто для заказных софтверных проектов во многих и многих фирмах.

В последние два-три года (примерно с 2005г.) гибкие методы начали восприниматься как альтернатива классическим методологиям управления проектами ( PMBoK , PRINCE2 -- прежде всего в сервисных организациях (например, проведение мероприятий), но также и в производственных, и уже не могут быть признаны специфически программистскими практиками. Вышло несколько книг, в которых прямо говорится, что предлагаемые в них гибкие методы были опробованы на софтверных проектах, но сейчас предлагаются для любых проектов (например, Manage It! by Johanna Rothman, 2007 -- http://www.pragmaticprogrammer.com/titles/jrpm/, Effective Project Management by Robert Wysocki, 2006 -- http://www.amazon.com/Effective-Project-Management-Traditional-Adaptive/dp/0470042613).

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

Наиболее распространены гибкие методы в группах разработчиков числом 3-15 человек.

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

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

Но, конечно, софт тоже активно используется. Наиболее распространенным типом софта, который используют при работе гибкими методами, являются системы отслеживания результатов (issue trackers, http://en.wikipedia.org/wiki/Issue_tracking_system). Только в самое последнее время стали появлятья специализированные продукты, поддерживающие определенные методологии гибких методов -- см., например,

• http://www.extremeplanner.com/ который упирает на то, что работает не со списками задач, а отслеживает "фичи" (свойства разрабатываемого продукта). Впрочем, это свойство всех систем поддержки гибких методов, ибо в программистских проектах основная метрика хода проекта -- число реализованных "фич" (пользовательских "историй").
• http://www.versionone.net/products.asp с особым упором на поддержку полного спектра управленческих задач -- управления программами , управления проектами , управления итерациями (шагом проекта) и настройкой шаблонами на конкретные методологии (Scrum, XP, AgileUP, DSDM, кастомизированную для нужд пользователя и т.д.).
• http://www.targetprocess.com/ с интегрированной системой контроля версий и управлением тестами
• http://www.trackplus.com/ -- со встроенной поддержкой бюджетов и трат, импортом и экспортом из MS Project и многими другими возможностями, приближающими issue tracking к классическому управлению проектами

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