Знакомьтесь, Water-SCRUM-Fall!

Тимофеев А.Н.

Скачать pdf-версию статьиЗа последние пять лет среди моря публикаций об успехах и проблемах Agile-методологий все более широкую акваторию стали занимать материалы, посвящённые гибридным методологиям разработки программного обеспечения. Это интереснейшее явление зародилось в начале 21 века в недрах ИТ-индустрии США и, судя по небольшому количеству публикаций на русском языке, оно малоизвестно нашим ИТ-специалистам и бизнесу. Цель статьи — познакомить с этим явлением и показать причины его возникновения.

Знакомство

В этом году минуло 15 лет со дня принятия Agile Manifesto. Все эти годы одна часть мира ИТ следила за проникновением методологий Agile в ИТ-проекты, а другая участвовала в их развитии и внедрении. И если верить ранним статистическим отчётам, то мир ИТ все эти годы двигался в сторону Agile и все больше уходил от классических методологий. Так, в 2011 году исследовательская компания Standish Group в очередном CHAOS Manifesto настолько высоко оценила перспективы повсеместного внедрения Agile, что назвала Agile-процесс «универсальным средством от провала проектов по разработке программного обеспечения» [1].

Однако в CHAOS Manifesto 2013 года Standish Group  неожиданно снизила рейтинг Agile, оповестив о том, что Agile-процесс отныне «олицетворяет философию малых проектов» [2]. Что же послужило причиной для смены флага?

Добро пожаловать в WaterScrumFall!

— объявил в начале 2011 года Джон Симпсон, вице-президент по маркетингу компании Jama Software и автор отчёта о состоянии управления требованиями [3].

«Нет никаких сомнений в том, что Agile стал основным направлением движения, но реальность такова, что самый большой сегмент команд, 40 процентов, не являются пуристами [1], следующими какой-либо одной предписываемой методологии. Не существует ни одного совершенного процесса — серебряной пули, — Waterfall, Agile (Scrum), RUP или иного» — написал он затем в своём отчёте.

Далее он отметил: «Вместо этого большинство команд использует гибридный, постоянно развивающийся процесс, который  наилучшим образом соответствует потребностям именно их проекта. Согласно международному отчёту ESI International’s о тенденциях в управлении  проектами на 2011 год руководители проектов «должны избавить стейкхолдеров и топ-менеджмент от иллюзий, навязанных ИТ-консультантами, СМИ и сообществом поставщиков, что Agile — это очередная «серебряная пуля».

Вслед за этим отчётом независимая исследовательская компания Forrester Research опубликовала отчёт Дейва Уэста (Dave West) (тогда главного аналитика компании, а через два месяца её вице-президента и директора по исследованиям) и его команды аналитиков, который называется  «Water-Scrum-Fall — реальность Agile для большинства организаций сегодня» [4].

В нем Дейв Уэст и его коллеги написали, что за 10 лет наблюдений за внедрением Agile в организациях компания Forrester пришла к выводам: «То, как Agile реализуется на практике, сильно отличается от оригинальных идей, описанных в Манифесте и во многом эта реализация схожа с тем, что Forrester называет Water-Scrum-Fall».

Явление, о котором идёт речь в этих отчётах — Water-Scrum-Fall, — это гибридная методология процесса создания ПО. Она возникла как ответная реакция на попытки адаптации Agile к реальным условиям работы организаций.

Типичная схема Water-Scrum-Fall показана на рисунке 1. Эта схема отражает часто встречающееся распределение работ по стадиям Water, Scrum и Fall.

water-scrum-fall

Рисунок 1. Water-Scrum-Fall

 

На стадии Water выполняется разработка требований и проектирование системы на их основе, что используется затем для оценки стоимости всего проекта и его планирования. На стадии Scrum — итеративная разработка ПО и unit-тестирование. А на стадии Fall —  системное тестирование выпущенного релиза, по результатам которого он либо отправляется на доработку, либо получает «добро» на поставку и развёртывание. При необходимости на этой стадии осуществляется и интеграционное тестирование. В случае успеха осуществляется выпуск продукта.

Тенденции

Вернёмся к отчётам. Оба отчёта являются знаковыми — до их публикации никто не описывал Water-Scrum-Fall как развивающуюся реальность мира ИТ. Особенно это касается наиболее цитируемого отчёта Forrester. Он отнюдь не пышет оптимизмом относительно скорой победы Agile над этой тенденцией. Наоборот, в нем с некоторой грустью фиксируется обилие проблем на этом пути, показывается реальность и долговременность такого явления, как Water-Scrum-Fall.

Оба отчёта породили волну биполярных публикаций и дискуссий, неутихающую и по сей день. Одни авторы оценивают это явление как анти-паттерн, от которого нужно избавиться, и даже предлагают решения, как «убить» Water-Scrum-Fall, в то время, как другие считают Water-Scrum-Fall нормальным явлением, которое было, есть и будет, и дают объяснения его природе [6 — 28].

Важно то, что гибридные методологии возникли задолго до 2011 года. Тот же отчёт Forrester Research, да и другие источники, регистрируют их появление уже в 2002 году, то есть, сразу после публикации манифеста Agile [5]. Начиная с этого времени гибридные методологии  появляются под такими названиями, как Iterative Agile, ScrummerFall, WaterScrum, AgileFall, Water-Agile-Fall и т.д., отражая в названиях взгляды их авторов, подчёркивающие в этом явлении важные для них моменты.

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

Причины живучести Water-Scrum-Fall

Результаты анализа опубликованных за последние пять лет материалов позволяют выделить три основные причины появления и развития Water-Scrum-Fall:

  1. Чувство самосохранения.
  2. Правила управления инвестициями.
  3. Жизненный цикл продукта.

Рассмотрим их подробней.

А. Чувство самосохранения

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

Во-первых, это влияние корпоративной культуры.

Культура ест стратегию на завтрак

— сказал великий Питер Друкер (Peter Drucker).

Иначе говоря, культура организации оказывает сопротивление внедрению новых стратегий и методологий, потому что они несут в себе угрозу и этой культуре и структуре организации [29,40,41].

Во-вторых, внедрение новой методологии требует инвестиций в изменение структуры организации, менеджмент, ИТ, обучение и т.д.. Но сегодня нет методик, позволяющих рассчитать экономический эффект от внедрения Agile в уже работающее и приносящее доходы производство. Есть только итоговые данные о чужом опыте, представленные в статистических отчётах. Однако и эти итоговые данные неоднократно подвергались серьёзным сомнениям и в США и в Европе [36,37]. Методики построения статистических выборок и их обработки в этих отчётах, как правило, закрыты и это не позволяет сделать однозначных выводов ни о качестве данных, ни о качестве полученных на них результатов. Дебаты на эту тему идут уже второе десятилетие, но исследовательские компании отказываются предоставить доступ к используемым методикам.

В-третьих, внедрению полноценного Agile препятствуют данные о проблемах его адаптации [38]. Ярким примером является Agile проект в Universal Credit. Его неудачи с 2012 года показывают, каких крупных инвестиций и изменений в управлении организацией, её культуре и ИТ требует внедрение Agile в организации [30,31].

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

B. Правила управления инвестициями

Проекты по созданию ПО делятся на две категории — проекты, в которых ПО  создаётся для внутреннего использования и проекты, в которых ПО создаётся для внешнего заказчика.

В США финансовый учёт и отчётность любых проектов ведутся в соответствии с установленными FASB (Financial Accounting Standards Board) и FASAB (Federal Accounting Standards Advisory Board) стандартами для государственных и частных компаний.

Правила финансового учёта и отчётности, установленные в стандартах SoP 98-1 [33] FASB и SFFAS 10 [34] и TR-16 [35] FASAB таковы, что использование Agile методологий при создании ПО для внутренних проектов не вызывает проблем. И это одна из причин  успехов внедрения Agile во внутренние  ИТ-проекты в США.

С внешними проектами совсем иная картина. Их финансирование попадает в США под правила учёта для капитальных вложений (CAPEX) — тут в силу вступают другие требования регулятора. В частности, финансистам заказчика ПО необходимо предварительно рассчитать стоимость проекта и предполагаемый доход от его создания и внедрения. Сделать они это могут только на основе разработанных требований к создаваемому программному продукту. При этом точность расчёта стоимости проекта и  дохода от его реализации напрямую зависят от детальности разработанных требований и их качества.

Парадигма Agile и особенно SCRUM напрямую не согласуется с таким подходом. Она не предусматривает выделенных этапов проектирования, согласования его результатов, оценки стоимости всего проекта и формирования плана выпуска, поставки и внедрения ПО. Помимо этого, итерационные поставки ПО в SCRUM попадают под категорию постоянных эксплуатационных расходов (OPEX) и должны так и учитываться, а это вступает в противоречие с правилами регулятора [32]. Таким образом, в США «чистый» Agile конфликтует с требованиями финансового учёта и правилами управления бизнесом.

Решение этой проблемы и нашло своё отражение в виде компромиссного решения – гибридной методологии: для соответствия правилам регулятора организации выполняют разработку требований, а затем оценку стоимости их реализации и осуществляют планирование  в рамках стадии Water. А далее, результаты этой стадии поступают в группу разработки, практикующую, например,  SCRUM.

C. Жизненный цикл продукта

Довольно часто ПО не имеет самостоятельной ценности для потребителя. Так, в проектах по созданию телевизоров, автомобилей, спутников и т.д., ПО — это всего лишь составная часть этих продуктов.  В этом случае процесс разработки ПО является одной из стадий процесса создания продукта и адаптируется к его условиям.

Обычно процесс создания таких продуктов требует детального проектирования системы в целом до начала её реализации — изготовления «железа» и ПО.

Это необходимо для:

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

Поэтому попытки внедрения Agile в жизненный цикл таких продуктов локализуются на уровне разработки ПО. При этом разработка ПО выполняется по ранее разработанным требованиям.  Так и образуются стадии Water и Scrum (см. рис 2).

Рисунок 2. Типовая схема выпуска продукта по Water-Scrum-Fall

Рисунок 2. Типовая схема выпуска продукта по Water-Scrum-Fall

Далее, для финального тестирования ПО необходимо дождаться поставки «железа», чтобы обеспечить реальные условия проверки функций ПО. Таким образом, весь процесс завершается интегрированием и комплексным тестированием продукта в целом — стадия Fall.

Все сказанное выше применимо не только к проектам по созданию интеллектуальной техники, но и к сложным информационным системам — без распараллеливания работ сроки поставки таких систем были бы неприемлемыми, а распараллелить работы невозможно без предварительного проектирования системы в целом [39]. Финальная сборка и тестирование, также является необходимым этапом жизненного цикла таких систем.

Заключение

Таким образом, причины возникновения и живучести Water-Scrum-Fall носят объективный характер, и на сегодня нет фактов, которые указывали бы на скорое исчезновение этого явления.

Правила управления бизнесом, финансового учёта и отчётности при производстве ПО в США остаются неизменными. Неизменна и зависимость процесса создания ПО от процесса создания продуктов в целом. А корпоративная культура по-прежнему противодействует изменениям в отработанных и приносящих прибыль процессах и препятствует внедрению «чистого» Agile [42,43].

И парадокс этого явления заключается в том, что чем больше организаций пытаются внедрить  Agile, тем большее распространение получают гибридные методологии.

Тимофеев А.Н. Знакомьтесь, Water-Scrum-Fall! //Практика проектирования систем.-2016. [электронный ресурс] — Режим доступа: http://reqcenter.pro/water-scrum-fall/, свободный. — Загл. с экрана

[1] Пурист борец за чистоту нравов, религии

Литература

  1. The Standish Group Report. CHAOS MANIFEASTO 2011.
  2. The Standish Group Report. CHAOS MANIFEASTO 2013.
  3. John Simpson. The State of Requirements Management Report. — 2011.
  4. Dave West with Mike Gilpin, Tom Grant, Ph.D., and Alissa Anderson. Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today/ Forrester Research, Inc. — 2011.
  5. Kane Mar. The Staggered-Iterative-Waterfall (Anti-)Pattern. Рart 1. — 2005.- https://kanemar.com/2005/11/03/the-staggered-iterative-waterfall-anti-pattern-part-1/
  6. Christopher R Goldsbury. Have the Pragmatists Won? Water-Scrum-Fall Is the Norm. — 2011.- https://www.infoq.com/news/2011/12/water-scrum-fall-is-the-norm
  7. Cameron McKenzie. Water-Scrum-fall: It’s not an Agile methodology. — 2012.- http://www.theserverside.com/tip/Water-Scrum-Fall-Its-not-an-Agile-methodology
  8. Cameron McKenzie. Scott Ambler vilifies water-Scrum-fall at Innovate — 2012 .- http://www.theserverside.com/news/thread.tss?thread_id=65352
  9. Dave West. ALM With power comes great responsibility/ Forrester Research, Inc. — 2012.
  10. Manav Mehan. Water-Scrum-Fall – Agile Reality for Large Organisations/ Tata Consultancy Services Limited. — 2012.- http://www.agileconference.org/wp-content/uploads/2012/10/Water-Scrum-Fall-Manav-Mehan.pdf
  11. Bernhard Fischer. Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft?/ ScrumMed. — 2013.- http://www.bfischer-consulting.de/water-scrum-fall_final.pdf
  12. Scott Ambler, Mark Lines. Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise / IBM Press. — 2012.
  13. Scott W. Ambler. Going Beyond Scrum. Disciplined Agile Delivery. Disciplined Agile Consortium. White Paper Series. — 2013
  14. Dan Galorath. World’s Largest Agile Program Goes Back to Waterfall. — 2013. — http://galorath.com/wp/worlds-largest-agile-program-goes-back-to-waterfall/
  15. Samuel Roberts. Waterfall & Agile — Why Everyone Should Use Agile But Most End Up With Waterfall. — 2014.- http://www.klooddigital.com/blog/agile-waterfall-project-management/
  16. Bry Willis. Homeopathic Agile Development Is No Cure: Water-Scrum-Fall Is an Anti-pattern. — 2014.- https://www.linkedin.com/pulse/20140617043455-14270686-homeopathic-agile-development-is-no-cure-water-scrum-fall-is-an-anti-pattern
  17. Sander Bannink. Challenges in the Transition from Waterfall to Scrum – a Case study at Portbase. University of Twente. — 2014.- http://referaat.cs.utwente.nl/conference/20/paper/7427/challenges-in-the-transition-from-waterfall-to-scrum-a-casestudy-at-portbase.pdf
  18. Matthew Finnegan. Agile and waterfall – is a hybrid approach best for enterprise app development? / Computerworld UK. — 2014.- http://www.computerworlduk.com/it-management/agile-waterfall-is-hybrid-approach-best-for-enterprise-app-development-3572875/
  19. Georgios Theocharis, Marco Kuhrmann, Jürgen Münch, Philipp Diebold. Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices. — 2015.- https://www.researchgate.net/publication/281546858_Is_Water-Scrum-Fall_Reality_On_the_Use_of_Agile_and_Traditional_Development_Practices
  20. Andy Hiles. Are You Doing Water-Scrum-fall? — 2015.- http://www2.radtac.co.uk/blog/are-you-doing-water-scrum-fall/
  21. Ben Linders. Delivering Software with Water-Scrum-Fall. — 2015.- https://www.infoq.com/articles/delivering-software-water-scrum-fall
  22. Steve Curtis. Pondering, and then Walking Away From, Agile-fall. 2015 .- https://civicactions.com/blog/on-pondering-and-then-walking-away-from-agile-fall/
  23. Douglas M. Brown. DSDM: The New Old Agile-fall. — 2015.- https://www.linkedin.com/pulse/dsdm-new-old-agile-fall-douglas-brown?forceNoSplash=true
  24. Manoj Sanhotra. Water-Scrum-Fall. The first step toward agility. — 2015. — https://www.scrumalliance.org/community/articles/2015/june/water-scrum-fal
  25. Tony Timbol. Enterprise Agile: ‘Water – Agile – Fall’ Makes a Splash in New Forrester Report. — 2015. — http://www.softwarevalue.com/insights/blog/posts/2015/december/
    enterprise-agile-water-agile-fall/
  26. Michael O. Church. Why “Agile” and especially Scrum are terrible. — 2015.- https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
  27. Farrah Burke. The Adoption of Agile: How Are Organizations Coping as Roles and Expectations Change. — 2016.- https://www.axian.com/2016/04/29/the-adoption-of-agile-how-are-organizations-coping-as-roles-and-expectations-change-2/
  28. Maxwell Cooter. Don’t go chasing waterfalls, please stick… Hang on. They’re back. – 2016.- http://www.theregister.co.uk/2016/06/07/problems_for_agile/
  29. Джамшид Гараедаги. Системное мышление. Как управлять хаосом и сложными процессами. Платформа для моделирования архитектуры бизнеса / Джамшид Гараедаги – М.,: Гревцов Букс, 2011.
  30. Pollyanna Pixton, Shane Hastie. Causes of UK Agile Mega-Project Failure Examined. ¬- 2013.- https://www.infoq.com/news/2013/10/noa-uc-failure-report
  31. Justine Stephen. Learn from failure: the key lesson that Universal Credit should take from agile. ¬- 2013.- http://www.instituteforgovernment.org.uk/blog/6562/learn-from-failure-the-key-lesson-that-universal-credit-should-take-from-agile/
  32. Christopher R Goldsbury. The Root Cause of Water-Scrum-Fall. ¬- 2012.- https://anagilestory.com/2012/01/30/the-root-cause-of-water-scrum-fall/
  33. Statement of Position 98-1. Accounting for the Costs of Computer Software Developed or Obtained for Internal Use // FASAB. — 1998.
  34. Accounting for Internal Use Software. Statement of Federal Financial Accounting Standards 10 // FASAB. — 1998. — http://: www.fasab.gov/pdffiles/handbook_sffas_10.pdf.
  35. Implementation Guidance For Internal Use Software. Federal Financial Accounting Technical Release 16 // FASAB. — 2016. — http://www.fasab.gov/pdffiles/handbook_tr_16.pdf.
  36. J. Laurenz Eveleens and Chris Verhoef, Vrije Universiteit Amsterdam. The Rise and Fall of the Chaos Report Figures. IEEE Software, 2010.
  37. Dirk Basten, Oleg Pankratz, Dominik Joosten.«Assessing the assessors – an overview and evaluation of it project success reports». Proceedings of the 21st European Conference on Information Systems. 2013.
  38. Peggy Gregory , Leonor Barroca, Katie Taylor, Dina Salah, Helen Shar. Agile Challenges in Practice: A Thematic Analysis // 16th International Conference on Agile Software Development, XP 2015, 25-29 May 2015, Helsinki.
  39. Case Study: Water Agile Fall in Practice. — 2016. — https://www.planittesting.com/uk/Insights/2016/Case-Study-Water-Agile-Fall-in-Practice
  40. Torben Rick. Organisational culture eats strategy for breakfast, lunch and dinner. — 2014. — http://www.torbenrick.eu/blog/culture/organisational-culture-eats-strategy-for-breakfast-lunch-and-dinner/
  41. Jon Katzenbach, Paul Leinwand. Culture eats strategy for breakfast. – 2015. http://www.strategyand.pwc.com/media/file/Katzenbach-Center_Webinar_Culture-Eats-Strategy-for-Breakfast.pdf
  42. 10th Annual State of Agile Report. VersionOne. – 2015.
  43. The Agile Cultural Shift: Why Agile Isn’t Always Agile. CGI. – 2016.