Как появился Agile. Часть 3. Призыв

Часть 1. Про то как разработка программ вышла из-под контроля и что из этого вышло

Часть 2. Про поиски «серебряной пули» в управлении разработкой программ

Часть 3. (эта статья) Как «легковесные методы» объединились в Agile

В предыдущих сериях

В части 2 статьи про появление Agile, мы увидели появления рынка «коробочного» ПО (packaged software) и его взрывного роста.

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

Разработчики экспериментировали с итеративно-инкрементальным подходом (ИИП), это дало им увеличение гибкости разработки на основе регулярной обратной связи от заказчика или пользователя. Эксперименты длились все 70-е и 80-е годы XX века, и к началу 90-х ИИП был уже широко известен, и изучен. Для появления Agile в этих подходах не хватало только человеческого измерения, а именно – командной работы и ставки на людей и их взаимодействие.

Человеческий фактор

В 1986 году вышла статья Хиротака Такеучи и Икуджиро Нонака ”The New New Product Development Game”, в которой были представлены результаты исследований успешного опыта быстрого создания принципиально новых продуктов, на примере таких компаний как 3M, Fujitsu-Xerox, Honda, Xerox, Canon, Epson, NEC, Brother и других.

Согласно их исследованию, самые успешные компании использовали итеративно-инкрементальный подхода с «наложением стадий» (модель Sashimi).

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

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

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

Нельзя сказать, что авторы статьи «открыли Америку», т.к. и командный подход, и итеративно-инкрементальные методы, и быстрая обратная связь, было известны довольно давно. Однако, собранные вместе, все эти элементы давали синергетический эффект, значительно ускоряя разработку новых продуктов и делая их действительно полезными для пользователя.

Тяжеловесы и легковесы

Таким образом, к началу 90-х годов XX века были изучены и опробованы два ключевых аспекта, которые лягут в основу Agile:

• итеративно-инкрементальный подход;
• командная работа;

80-90е годы XX века ознаменовались массовым распространением персональных компьютеров (Apple Macintosh, PC-based и других).

Источник: https://arstechnica.com/information-technology/2012/08/from-altair-to-ipad-35-years-of-personal-computer-market-share/

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

Как уже говорилось, в такого рода задачах, нет единого, наилучшего решения, которое можно описать в виде требований в начале разработки, и быть уверенным, что в итоге получится идеальный продукт на все времена. Решение надо «нащупывать» и изобретать по ходу разработки, постоянно отслеживая реакцию пользователей, и делая выводы о необходимых улучшениях.

Например, одна из таких задач — создание текстового редактора. Прежде чем MS Word стал безраздельно царствовать в наших компьютерах, было сделано множество проб и ошибок, появилось множество текстовых процессоров и редакторов, многие из которых сейчас мало кто помнит: WordStar, WordPerfect, Lexicon, XyWriter, Lotus Notes, MacWrite и другие. Разработку такого рода продукта приходится вести с постоянной оглядкой на реакцию пользователя, быстро реагируя на его потребности новыми версиями.

Источник: https://computerhistory.org/blog/microsoft-word-for-windows-1-1a-source-code/

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

В конце 80-х годов XX века появилась V-Model (Verification and Validation Model), которая улучшила «каскадную» модель за счет добавления шага «верификации» на каждом этапе. Это позволяло устранять многие риски и улучшить качество итогового продукта, но скорость разработки не увеличивалась.

Подходы к разработке, базирующиеся на «каскадной модели», с четкими последовательными этапами, и всеохватной документацией получили условное название «тяжеловесных методов» (heavyweight methodologies).

К «тяжеловесным» моделям и подходам относили Спиральную модель, V-Модель, PRINCE2 и другие, основанные на Waterfall.

В то же время, разные специалисты из мира IT стали пробовать работать по-другому, изобретая  новые инструменты, приемы или даже разрабатывая целые методологии, направленные на повышение адаптивности и скорости разработки ценного для пользователя продукта.

Эти новые подходы так или иначе использовали схожий набор принципов и инструментов:

• Итеративно-инкрементальная разработка
• Регулярная обратная связь от заказчика или пользователя
• Командная работа
• Максимальная прозрачность

Семейство таких подходов, стали условно называть «легковесные»  методы (lightweight methodologies).

К легковесным методам причисляли следующие подходы, которые появились в 90е годы XX века: Crystal Clear,  Extreme Programming (XP), Rapid Application Development (RAD) и Dynamic Systems Development Method (DSDM),  ICONIX, Scrum, Adaptive Software Development (ASD), Feature Driven Development (FDD).

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

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

Другие пути

Одновременно в 90-е годы развивались другие направления, которые не всегда однозначно попадали под определение «легковесных», или «тяжеловесных».

Например, Unified Software Development Process, или Unified Process (UP). Этот фреймворк был придуман Иваром Якобсоном в 1988 году во время его работы в Ericsson где он с коллегами занимался гигантским проектом по моделированию огромных телекоммуникационных систем. В публичную плоскость UP был выведен в 1999 году, с публицией книги Ивора Якобсона «Unified Software Development Process». UP создавался как расширяемый фреймворк разработки, который следует настраивать под конкретную организацию и проект (tailoring).  Поэтому на базе UP были разработаны не только Rational Unified Process — RUP (1998), но и Agile-версии процесса — Agile Unified Process – AUP (2005) и Open Unified Process — OpenUP (2006)

Так как UP представляет собой базу для построения процессов разработки, то однозначно отнести его к «легковесным» или «тяжеловесным» методам затруднительно. Все зависит от конкретной реализации. RUP, во-многом, был ближе к «тяжеловесным» методам, хотя базировался на итеративной модели, а OpenUP и AUP стоят ближе к «легковесным» методам.

Параллельно со всем этим, развивались методы в концепции управления качеством (quality management). Это направление следовало в русле работ классика статистического управления качеством Эдварда Деминга, с применением практик и инструментов Toyota Production System (TPS), Бережливого производства (Lean Manufacturing) и Теории ограничений.

В рамках этой парадигмы, в 1995 году Уоттс Хамфри ( Watts Humphrey ), один из основателей и первых научных сотрудников Carnegie Mellon Institute, обнародовал первую версию Team Software Process (TSP). В ней описывался итеративный процесс разработки программного обеспечения командой разработчиков, с церемониями обратной связи, планированием и тд. Каждая итерация представляла собой цикл Деминга-Шухарта (PDCS-PDSA). В рамках этого подхода ставилась цель сформировать зрелую, самоорганизованную команду, которой будет передано много полномочий по тактике достижения цели и организации своей работы. В этой части TSP был довольно близок к тому, что было заложено в Scrum, но в остальном, разница была существенной. В TSP очень много внимания уделяли замерам времени буквально на все, для того, чтобы на основе этой статистики делать выводы об улучшении процесса. Это сильно отвлекало разработчиков от основной работы, и раздражало. Можно почитать впечатления людей от TSP здесь: https://softwareengineering.stackexchange.com/questions/25728/anybody-use-the-team-software-process-tsp-and-or-personal-software-process-ps

Тем не менее в 2010 году, в интервью Гради Бучу, Уоттс Хамфри отмечал множество сходств между Scrum и TSP, и неоднократно говорил, что эти два подхода не противоречат друг другу.

Семейство подходов, основанное на работах Эдварда Деминга было совершенно отдельным путем развития менеджмента, и позже на их базе появился Канбан.

Жажда признания

Классические «тяжеловесные методы» зачастую были официально закреплены как стандарты разработки крупных проектов (например, в Министерстве Обороны США). PMBOK вплоть до 5-й редакции (2013 год) никак не упоминал о «легковесных», адаптивных методах.

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

Если посмотреть на таймлайн возникновения «легковесных» подходов, то можно увидеть, что в 90е годы XX века чуть ни каждые год-два появлялся новый подход.

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

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

«Я думаю, что в тот момент мы все как бы искали легитимности. Каждый из нас мог бы работать по одиночке, и делать похожие вещи по-своему, но это не имело бы успеха и признания в сообществе [разработчиков программного обеспечения]» — вспоминал Джим Хайсмит, автор книги «Adaptive Software Development» и одноименного «легковесного» подхода к разработке.

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

Таким документом стал Agile-манифест, являвшийся призывом к индустрии разработки программного обеспечения (software industry), и провозгласивший новую парадигму менеджмента разработки.

Случайностей не случается (c)

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

Главным организатором встречи, на которой появился Agile-манифест, был Роберт (Боб) Мартин, автор многих книг по программированию, разработчик пяти принципов объектно-ориентированного программирования SOLID, энтузиаст XP, и известный блоггер.

В своей книге «Чистый Agile» он так описывает события, приведшие к этой встрече.

После разочарования в идеях «каскадной» модели, Боб Мартин прочитал книгу Кента Бека об экстремальном программировании (XP) и этот подход ему очень понравился. Он случайно пересёкся с Кентом Беком на одной из конференций и они договорились о партнёрстве. В 1999-2001 годах они вместе проводили тренинг «XP Immersion», который пользовался огромной популярностью, и на нем было обучено несколько сотен человек.

На волне этого успеха, летом 2000 года Кент Бек собрал кворум из сообщества по экстремальному программированию и паттернам проектирования, для обсуждения планов о будущем XP. Боб Мартин предложил собрать встречу в более широком составе, пригласив сторонников конкурирующих между собой «легковесных» подходов, чтобы поделиться опытом и договориться о единстве этих подходов вокруг чего-то общего.

Кент Бек не проявил большого энтузиазма в организации такой встречи, но эту идею поддержал Мартин Фаулер , признанный эксперт в мире разработки, автор основополагающей книги «Рефакторинг», которую знают многие поколения программистов.

За чашкой кофе неподалёку от работы Боба Мартина в Чикаго, эти двое энтузиастов составили список возможных участников встречи, и в тот же день разослали приглашения по email.

Одним из приглашенных был Алистер Коберн, создатель семейства «легковесных» подходов разработки программ — Crystal Methods. Как оказалось, он тоже подумывал о проведении подобной встречи, но список участников составленный Мартином Фаулером ему понравился больше. Алистер предложил объединить списки участников и провести встречу на горнолыжном курорте Сноуберд возле Солт-Лейк-Сити.

Есть большой элемент случайности в составе участников этой знаменательной встречи, и того круга подходов, которые в конечном итоге объединились под зонтиком Agile. Кого-то не пригласили, кого-то забыли, кто-то не приехал сам.

Если посмотреть ниже на скриншот списка email’ов, на которые были высланы приглашения, и немного «погулглить», то можно составить довольно интересный список людей, которых пригласили, но на встречу они не приехали.

Вот имена тех, кто не приехал:

• Гради Буч, Агнета Якобсон, Джим Коплин — известные разработчики, авторы книг по программированию, создатели собственых подходов к разработке программного обеспечения.
• Эрик Реймонд, американский программист и хакер. Пропагандист и идеолог движения за открытое программное обеспечения (open source), сооснователь «Open Source Initiative»
• Питер Коад,  один из разработчиков Feature Driven Development (FDD), признанный гуру в области объектно-ориентированного анализа и проектирования, автор целого ряда книг по этим темам, ставших классикой
• Том ДеМарко — инженер-программист, писатель, автор известных книг по менеджменту разработки программного обеспечения:
  • «Deadline: роман об управлении проектами» (“The Deadline: A Novel About Project Management”);
  • «Человеческий фактор: успешные проекты и команды» («Peopleware: Productive Projects and Teams»);
  • «Балдеющие от адреналина и зомбированные шаблонами» («Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior»)

Неизвестно, каким был бы результат встречи, если бы эти люди приняли в ней участие. Но мне думается, что Том ДеМарко, Гради Буч и Питер Коад могли сильно повлиять на ход встречи, и добавить в нее много интересного, и Agile-манифест мог бы выглядеть совсем иначе.

Но история не знает сослагательного наклонения. 17 человек из списка приглашенных, все-таки приехали в Сноуберд, и приняли участие во встрече. Именно им мы обязаны появлением Agile-манифеста в том виде, в котором мы его знаем.

Давайте посмотрим кто это был, и каким бекграундом обладал.

В составе приехавших в Сноуберд, было несколько групп, которые представляли конкретные «легковесные» методологии:

• Экстремальное программирование (XP) представляли пять человек – Кент Бек, Джеймс Гренинг, Уорд Каннингем, Рон Джеффрис, и сам Боб Мартин;
• Scrum был представлен тремя людьми – Кен Швабер, Джефф Сазерленд, Майкл Бидл;
• Feature Driven Development (FDD) – Джон Керн;
• Dynamic Systems Development Method (DSDM) – Айри ван Беннекум;
• Crystal Methods – Алистер Коберн;

Остальные участники не представляли какой-то конкретный подход или методологию, однако являлись экспертами в Software Engineering, и обладали большим опытом и знаниями, чтобы внести свой вклад в формирование Agile Manifesto

• Мартин Фаулер, автор книги «Рефакторинг». Официально ни к каким подходам не относился. Он симпатизировал всему, что приносит пользу. Многие из представленных методов он хорошо знал сам и активно применял в своей работе.
• Энди Хант и Дейв Томас — авторы книги «Pragmatic Programming: From Journeyman to Master» представляли собственный взгляд на то, как нужно разрабатывать программы. Это была скорее философия, чем методология.
• Брайан Марик является консультантом по тестированию, создателем модели Agile Testing Quadrant. Представлял на встрече сообщество тестировщиков.
• Джим Хайсмит является консультантом по менеджменту разработки, и автором книги «Adaptive Software Development»
• Стив Меллор был основоположником Model-Driven Development (MDD) – разработки на основе моделей. По его собственным словам, на этой встрече он был нейтральным наблюдателем, почти случайно попавшим туда.

Очевидно, что кто-то попал на эту встречу случайно, кто-то шёл туда намеренно, кто-то не доехал, кого-то не позвали. Наверно, состав участников мог быть полнее, но – случилось так как оно случилось.

Три дня в Сноуберде

Изначально, никто их прибывших не ожидал каких-то значимых результатов от встречи. Как вспоминает Мартин Фаулер: «Мы приехали на эту встречу с очень разными, но весьма скромными ожиданиями. Мои ожидания были очень ограниченные — я просто надеялся, что мы лучше узнаем друг друга и что более тесное общение приведёт к чему-то интересному, я не ожидал чего-то большего от этой встречи»

Левая часть комнаты	Правая часть комнаты

Встреча длилась три дня, и как вспоминал Кен Швайбер: «Когда мы начали сравнивать то, как мы строим нашу работу, мы были просто поражены как много между нами совпадений».

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

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

Как выглядит Agile-манифест? В преамбуле говорится: «Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это». Затем в нем излагаются четыре основные ценности:

• Люди и взаимодействие важнее процессов и инструментов
• Рабочее программное обеспечение важнее всеобъемлющей документации
• Сотрудничество с клиентами важнее переговоров по контракту
• Реагирование на изменения важнее следования плану

В конце документа указано, что «хотя то, что справа имеет несомненную ценность, мы больше ценим то, что написано слева».

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

Как вспоминает Мартин Фаулер, участники приняли решение назвать этот документ словом «манифест» (от позднелат. manifestum «призыв»), так как он должен был звучать именно как «призыв к оружию и заявление о наших убеждениях», и привлечь внимание всей индустрии разработки программного обеспечения.

Как вы лодку назовёте…

Интересно как выбирали название для новой парадигмы. По словам Боба Мартина, были предложены названия: Agile, Lightweight Method, Adaptive и другие.  В ходе брейншторма, который фасилитировал Алистер Коберн, в финал вышли два варианта: Agile и Adaptive. Между ними была сильная смысловая связь, но в слове Agile звучала не только адаптивность (adaptive), но и реакция на изменения (response to change), так что участники выбрали это слово, как наиболее подходящее.

Впрочем, Алистер Коберн озвучивал другую версию, почему был выбрано слово «Agile». Якобы «Adaptive» не выбрали, чтобы не давать явного маркетингового преимущества одному из подходов, в котором есть это слово — «Adaptive Software Development» Джима Хайсмита. Версия довольн логичная, учитывая какой интерес вызвало появление Agile-манифеста.

Последствия

После встречи между участниками была активная переписка для выработки 12 принципов Agile, которые уточняли Agile-манифест. Уорд Каннингем вызвался сделать сайт http://agilemanifesto.org и опубликовал на нем Agile-манифест и 12 принципов. На сайте так же предусмотрена возможность подписаться под этими принципами для всех желающих.

Никто из участников не думал, что этот манифест привлечет много внимания, а уж тем более, станет началом целого направления в менеджменте разработки программного обеспечения. Участники разъезжались удовлетворённые результатом, но не особо веря, что у этой истории будет какое-то серьёзное продолжение.

«Когда я спустился с горы, я ехал с парой других авторов Манифеста, и я думал про себя: «Я не уверен, что кто-то обратит внимание на то, что мы сделали», — вспоминает Майк Бидл —  «Мне показалось, что это было как игра в рулетку. Это было похоже на вопросительный знак. Кто знает? Я имею в виду, может быть, люди будут заходить на этот веб-сайт, на котором мы собираемся разместить Манифест, а может быть, они этого и не сделают»

Однако, отклик был, и довольно сильный. Сообщество разработки программного обеспечения заметило Agile-манифест, и очень благожелательно отреагировало на его появление.

Вот что пишет Роберт Мартин в своей книге:
“Когда все было сделано, каждый из нас вернулся к своей обыденной жизни. Предполагаю, что многие из нас считали, что на этом история и закончится.
Никто и подумать не мог, что нас так поддержат. Никто не ожидал, насколько судьбоносными окажутся те два дня. Но чтобы не задирать нос от своей важности и причастности, я непрестанно напоминаю себе о том, что Алистер Коберн тоже был близок к проведению подобной встречи. И поэтому задаюсь вопросом, сколько еще было таких же, как я. Поэтому успокаиваю себя мыслью, что просто настало время, и если бы не мы, 17 человек, собравшихся в горах Юты, то собралась бы другая группа, которая пришла бы примерно к таким же результатам”

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

Что дальше?

Но это было только начало. Дальше была долгая конкуренция Agile с RUP, и другими методами в борьбе за место под солнцем. Была и конкуренция между разными подходами внутри Agile. Долгое время XP было лидером, но постепенно все больше возвышался Scrum, вбирая и адаптируя в себя разные практики, в том числе XP и инструменты Lean Manufacturing. Сейчас Scrum – самый известный и распространённый Agile-подход, хотя на момент создания Agile-манифеста это было совсем не так.

На сегодняшний день, по данным сайта StackOverflow 85% разработчиков используют Agile-подходы при разработкие программных продуктов

Источник: https://insights.stackoverflow.com/survey/2018#development-practices

А по данным Standish Group, количество успешно реализованных проектов, сделанных по Agile в два раза превышает количество успешных проектов сделанных по Waterafall :

Источник: https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/

По данным 14th Annual State of Agile Report среди главных преимуществ, полученных по итогам внедрения Agile:

• 71% опрошенных назвали рост скорости поставки программного обеспечения:
• 65% ответили, что это дало им возможность гибко управлять приоритетами;
• 51% отметил увеличение продуктивности;
• 47% назвали попадание в цели бизнеса

Как обстоят дела с Agile в России, можно узнать из ежегодного исследования Agile Russia: https://scrumtrek.ru/blog/agile-scrum/2388/agilesurvey19/

Есть много других тем, что можно рассказать про Agile. В 2000-х, 2010-х годах конкуренция Agile с другими подходами была сравнима со страстям с “Игрой престолов”, а по мере распространения Agile-подходов среди крупных компаний, появилась новая проблематика — масштабирование, которую пришлось решать через появления Nexus, SAFe, LeSS и других подходов к масштабированию Agile.

PMBOK наконец признал Agile, и 6-я редакция вышла с приложением Agile Guide. Кроме того, появилось направление Agile Project Management, и PMI-сертификация PMI-ACP.

В общем, много еще чего можно рассказать, но задача, которую я ставил перед собой, начиная этот цикл статей, выполнена. Я хотел рассказать, почему вообще сложились предпосылки для появления “легковесных” подходов, и Agile-подходов в частности. И я это сделал.

Надеюсь, у меня получилось. Судить вам 🙂 Благодарю, что дочитали до конца ☺

Часть 1

Часть 2

Источники для третьей части:

• Статья “The New New Product Development Game”
  https://www.academia.edu/40544365/The_New_New_Product_Development_Game
• Hirotaka Takeuchi
  https://en.wikipedia.org/wiki/Hirotaka_Takeuchi
• Ikujiro Nonaka
  https://en.wikipedia.org/wiki/Ikujiro_Nonaka
• Jeremy Reimer “From Altair to iPad: 35 years of personal computer market share”  https://arstechnica.com/information-technology/2012/08/from-altair-to-ipad-35-years-of-personal-computer-market-share/2/
• Stan J. Liebowitz, 1999, “Winners, Losers, and Microsoft: How Technology Markets Choose Products” https://personal.utdallas.edu/~liebowit/book/wordprocessor/word.html
• V-Model
  https://en.wikipedia.org/wiki/V-Model
• Crystal Methods
  https://en.wikiversity.org/wiki/Crystal_Methods
• Alistair Cockburn
  https://en.wikipedia.org/wiki/Alistair_Cockburn
• Extreme Programming
  https://en.wikipedia.org/wiki/Extreme_programming
• Сайт Extreme Programming
  http://www.extremeprogramming.org/
• Kent Beck
  https://en.wikipedia.org/wiki/Kent_Beck
• Feature Driven Development
  https://en.wikipedia.org/wiki/Feature-driven_development
• Dynamic systems development method
  https://en.wikipedia.org/wiki/Dynamic_systems_development_method
• Agile Unified Process
  https://en.wikipedia.org/wiki/Agile_Unified_Process
• Scott Ambler
  https://en.wikipedia.org/wiki/Scott_Ambler
• Unified Software Development Process
  https://en.wikipedia.org/wiki/Unified_Process
• History of the Unified Process
  http://www.enterpriseunifiedprocess.com/essays/history.html
• Ivar Jacobson
  https://en.wikipedia.org/wiki/Ivar_Jacobson
• Книга Боба Мартина «Clean Agile»
  https://www.amazon.com/Clean-Agile-Basics-Robert-Martin/dp/0135781868
• Боб Мартин
  https://en.wikipedia.org/wiki/Robert_C._Martin
• Мартин Фаулер
  https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer)
• Team Software Process
  https://en.wikipedia.org/wiki/Team_software_process
• Фото с встречи в Snowbird https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b
• Статья Алистера Коберна «How I saved Agile and the Rest of the World»
  http://web.archive.org/web/20170626102447/http://alistair.cockburn.us/How+I+saved+Agile+and+the+rest+of+the+world
• Статья Мартина Фаулера «Writing The Agile Manifesto»
  https://martinfowler.com/articles/agileStory.html#TheSnowbirdMeetingAndTheManifesto
• Статья в журнале «The Atlantic» «The Winter Getaway That Turned the Software World Upside Down»
  https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/