Agile история: Неизвестная история возникновения Agile

История создания «Манифеста Agile-разработки ПО» – SkillsCup by DBlinov.com

• Как появился Agile? А если точнее, то как создавался «Манифест гибкой разработки ПО»?
• Кто организовал встречу и зачем?
• Почему именно такой состав участников?
• Авторы довольны результатом?

Встреча в 2000 в Орегоне

Весной 2000 на встречу в The Rogue River Lodge для обсуждения разных вопросов по XP, которая называлась «Extreme Programming Leadership Conference», Кент Бэк пригласил:

• активных практиков XP, включая (Uncle) Bob Martin, Ron Jeffries, Ken Auer, Martin Fowler,
• других заинтересованных, в частности, Alistair Cockburn, Jim Highsmith, Dave Thomas.

На встрече они обсуждали связь между XP и другими методами, которые в то время называли Lightweight Methods. Найдя много общего, участники договорились, что (Uncle) Bob Martin соберёт встречу с представителями более широкого круга методов. В это же время Alistair Cockburn собирал похожую встречу.

Два списки объединили, да и вообще, постарались собрать всех активных, кому может быть интересно. Рабочим названием встречи было «Lightweight Methods Summit». [3, 4]

Встреча в 2001 в Snowbird в Юте

Кого приглашали? Кто приехал?

Естественным образом организацию встречи подхватил Alistair Cockburn, с бронированием ему помогал Jim Highsmith.

Кто-то из ~20 приглашённых приехать не смог, например, Grady Booch (один из авторов языка UML) и «Big Dave» Thomas (тёзка другого Дейва — «Pragmatic Dave» Thomas, который приехать смог).

The Lodge at Snowbird

В итоге 11–13 февраля 2001 года 17 «умников» [3] экспертов-практиков разработки ПО собрались в кондоминиуме The Lodge горнолыжного курорта Snowbird в горах Уосатч в штате Юта — это в западной части континентальных США недалеко от Солт-Лейк Cити.

Каждый практиковал какую-то альтернативу тяжеловесным процессам, основанным на документации. Они собрались поговорить, покататься на лыжах, отдохнуть и найти то общее, что объединяет их процессы/методы, которые в то время уже называли lightweight/легковесными. [2-JH, 3-MF]

• Extreme Programming,
• Scrum,
• DSDM, Dynamic Systems Development Method, 
• Adaptive Software Development,
• Семейство Crystal, вкл. Clear,
• FDD, Feature-Driven Development,
• Pragmatic Programming,
• и другие.

Авторы Манифеста Agile-разработки ПО

Какова цель встречи? Какими были ожидания?

Боб Мартин запустил встречу, поделившись своим взглядом на общее в существующих легковесных процессах, и предложил цель — зафиксировать эти общие характеристики во благо всей отрасли для создания полезного ПО. [4-BM]

Martin Fowler & Ward Cunningham стали фасилитаторами встречи. Кстати, знаменитую фотографию на странице Манифеста сделал именно Ward.

Snowbird Lodge. Создание Agile Manifesto

Ожидания от встречи у всех были разными, но не завышенными.

Я не ожидал, что конкретно эта группа сможет договориться о чём-то значительном.

Alistair Cockburn [2]

Я надеялся, что мы сможем узнать друг друга получше, и общение приведёт к чему-то интересному. Однако мы быстро нашли много общего.

Martin Fowler [3]

Дядя Боб Мартин в последствии охарактеризовал их так: [2-JH]

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

О чём договорились?

Договорились о многих аспектах разработки ПО, и поэтому решили оформить этот общий базис в виде боевого клича для всей отрасли. Хотели показать, что мы отстаиваем и чему сопротивляемся. [3-MF]

Вообще-то, это я и Мартин Фаулер, рисуя на доске во время обеда, сформулировали первые 3 сравнения.

Группа расширила их до 5, а затем сократила до 4. 

«PragDave» Thomas [4-BM]

«Мы хотим восстановить баланс» [2-JH]

Мы поддерживаем моделирование, но не ради того, чтобы диаграмма пылилась в корпоративном репозитории.

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

Мы планируем, но признаём ограничения планирования в турбулентной среде.

Jim Highsmith [2]

Snowbird Lodge. Создание Agile Manifesto

Название, веб-страница, альянс

Группа оформила зафиксированные 4 ценности в виде «Манифеста Agile-разработки ПО«.

Почему именно «Манифест»? Читайте в статье «Почему Agile так называется? Были другие варианты?«

Надеюсь, что Манифест прояснит, что является и не является agile.

Мартин Фаулер [3]

Группа назвала себя «The Agile Alliance.»  [2-JH]

Черновик 12 принципов группа записала во второй части встречи, и ещё пару месяц дорабатывала их.  Ward Cunningham, который изобрёл технологию wiki, создал страницу AgileManifesto.org [3-MF, 4-BM].

Итоговые впечатления

Я очень доволен результатом.

Мартин Фаулер в 2006 [3]

Думаю, я никогда не участвовал во встрече, на которой группа так сохраняла фокус и достигла целей с лёгкостью и минимумом конфликтов.

Uncle Bob Martin в 2007 [4]

Лично я в восторге от итоговой формулировки Манифеста. Я был удивлён, что и другие так же довольны итоговыми фразами. Так что, мы всё же договорились о чём-то значительном.

Alistair Cockburn в 2001 [2]

После встречи

В следующий раз почти все снова встретились в октябре 2001 на конференции OOPSLA, где сказали, что не хотят какой-то выделенной роли в распространении ценностей и принципов Agile-разработки, и это могут делать не только они. [3-MF]

В конце 2001 организовали НКО Agile Alliance для развития Agile-методов.

[3-MF]

Размышления Боба Мартина в 2016 году

Цель Agile: Вылечить разрыв между бизнесом и программированием.

Кент Бэк на встрече в 2001

«Использование Agile-подходов требует дисциплины,» это включает:

1. Фиксированные временные интервалы.
2. Оценка в относительных величинах.
3. Общение с клиентом.
4. Сотрудничество, и мн. др.

Agile был о дисциплине, профессионализме, ремесле.

Боб Мартин, 2016

• Agile — бизнес-практики.
• Ремесло — технические практики.

Это нужно исправлять: улучшать технические практики и снова объединять бизнес и ИТ.

Далее произошло разделение, снова:

[весь параграф из 1-BM]

---

Читайте по теме

1. Что привело к необходимости появления «Манифеста Agile-разработки ПО»?
2. История создания «Манифеста Agile-разработки ПО» (эта статья)
3. Что такое Agile?
4. Почему Agile так называется? Были другие варианты?
5. Ответы на вопрос «Что такое Agile?» в разных источника Сети
6. Как правильно произносить Agile? И как переводится?

Источники информации

Все источники — от авторов «Манифеста Agile-разработки ПО».

Если упорядочить по вкладу в эту статью, то так: 3, 2, 1.

1. Видео-лекция 2016 Robert «Uncle Bob» Martin с хронологией развития программирования «The Future of Programming».
2. Заметки 2001 Jim Highsmith сразу после встречи на курорте Snowbird — важная страница на сайте AgileManifesto.org, которую мало кто читает, а зря 😉
3. Заметки 2001–2006 Martin Fowler о создании Манифеста «Writing The Agile Manifesto».
4. Заметки 2007 Дяди Боба Мартина «The Founding of the Agile Alliance».

Oсновы методологии Agile

У методологии управления проектами Agile есть множество преимуществ для следующих типов организаций и проектов:

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

Перечислим 5 основных преимуществ применения метода Agile:

Непрерывное контактирование с клиентами

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

Способность к адаптации 

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

Ускоренная сдача результатов

Метод Agile предполагает непрерывную разработку, то есть ваша команда будет регулярно предоставлять функционирующие продукты. А значит, клиенту больше не придется ждать конечного результата 6–12 месяцев, он будет получать рабочую версию через короткие промежутки, обычно раз в 2–4 недели. 

Минимизация рисков проекта

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

Непрерывное внедрение инноваций

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

Что такое пользовательская история? / Хабр

Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.

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

Но что такое пользовательская история?

Чтобы ответить на этот вопрос, давайте разделим это понятие на части:

• История, в данном контексте, — это «устное или письменное изложение материала в художественной форме».

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

Таким образом, можно сказать, что история пользователя — это письменное повествование об использовании системы.

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

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

Как <тип пользователя>, я хочу <некоторое желание>, чтобы я мог <получить некоторую компенсацию>.

Шаблон пользовательской истории

Давайте приведем несколько примеров обычных историй для иллюстрации?

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

• Как руководитель компании, я хочу знать среднюю величину дохода по каждому проданному продукту, чтобы решить, куда вкладывать больше или меньше средств.

Одно из преимуществ следования этой модели заключается в том, что автор истории вынужден сосредоточиться на «ЧТО», а не на «КАК» — за последнее отвечает команда разработчиков.

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

Кто является действующими лицами или персонами в историях?

Это конечные пользователи историй. Именно они часто их пишут или запрашивают.

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

Только ли PM должен писать истории?

Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.

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

Плохие пользовательские истории

Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?

• A) «Не хватает кнопки загрузки».

• B) «Я бы хотел, чтобы на прикрепленном экране отображалось больше информации о продукте».

• C) «Включите больше изображений».

Один из способов превратить плохие истории в нечто полезное — использовать метод 5 Whys ( 5 “Почему«). Он также помогает автору быть более подготовленным и правильно описать свою следующую историю.

Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.

Проблема: «Не хватает кнопки загрузки».

• 1-й. Почему ?: — «Чтобы я мог скачать отчеты».

• 2-й. Почему ?: — «Чтобы я мог использовать данные в excel».

• 3-й. Почему ?: — «Чтобы я мог перепроверять информацию с данными из других источников».

• 4-й. Почему ?: — «Чтобы я мог предоставить полный отчет с информацией о продажах и доходах».

• 5-й. Почему ?: — «Совету директоров нужна точная информация о продажах и доходах, чтобы принимать важные инвестиционные решения для компании.»

Обладая этой информацией, можно было бы улучшить исходную историю, например:

• Как BI-аналитик;

• Я хочу экспортировать данные из отчета XYZ в формате CSV;

• Чтобы вы могли предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.

Критерии приемки

Не стоит забывать, что хорошая пользовательская история также содержит четко сформулированные критерии приемки.

Критерии приемки, как следует из названия, — это критерии, по которым история может быть принята или отклонена.

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

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

Вот совет для написания хороших критериев приемки — необходимо подумать о том, как продемонстрировать функциональность, когда она будет готова. Как это будет работать? Какие для этого нужны шаги ?

Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:

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

Критерии приемки:

— При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;

— При нажатии на кнопку загрузка начинается автоматически;

— Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;

Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет «Agile» (гибко), если это история с 423 критериями приемки.

---

Перевод подготовлен в рамках курса «Системный аналитик. Advanced».

Всех желающих приглашаем на открытый урок «Бизнес- и системный анализ как подготовка к тестированию качества программного продукта». На этом демоуроке обсудим:
— Зачем нужны User story для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?

РЕГИСТРАЦИЯ

Неизвестная история инноваций в стиле Agile

Управление инновациями

Даррел Ригби , Джефф Сазерленд , Хиротака Такеучи

11 мая 2016

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

Хотя вообще-то Agile пришел к нам не оттуда.

Некоторые возводят появление Agile аж к 1620 году, когда Фрэнсис Бэкон сформулировал основные принципы научного подхода. Более правдоподобная дата — 1930-е, когда экономист и статистик Уолтер Шухарт, сотрудник Bell Labs, начал применять цикл «Планируй-проверяй-изучай» (Plan-Do-Study-Act, PDSA) в целях усовершенствования продуктов и процессов. Шухарт обучил методу гибкой инкрементной разработки Уильяма Эдвардса Деминга, и тот после Второй мировой войны активно внедрял его в Японии. Toyota пригласила Деминга обучить сотни менеджеров, и его опыт в значительной степени был интегрирован в знаменитую систему кайдзен Toyota. Методы гибкой инкрементной разработки сыграли ведущую роль также и при создании сверхзвукового самолета-ракетоплана Х-15 в конце пятидесятых.

В 1986 году один из нас (Такеучи) в соавторстве с Икуджиро Нонака опубликовал в HBR статью «Новая игра в развитие». Изучив компании, заметно опережавшие по инновациям своих конкурентов, авторы выявили тот командно-ориентированный подход, который изменил дизайн и процессы производства таких, например, продуктов, как копировальные устройства Fuji-Xerox, автомобильные двигатели Honda, фотокамеры Canon. Вместо традиционной «эстафеты», в которой одна группа специалистов, завершив свою стадию работы, перепоручает продукт своим преемникам, эти фирмы применяли то, что назвали scrum, то есть «команда старается пробежать всю дистанцию как единое целое, передавая друг другу мяч, словно игроки в регби».

советуем прочитать

Диана Малкахи

Войдите на сайт, чтобы читать полную версию статьи

советуем прочитать

Анна Натитник

Карстен Лунд Педерсен,  Томас Риттер

Джефф Сандерс

IV международная конференция по гибкому управлению Agile Поволжья «Истории Вашего бизнеса»

19. 10.2021г.

IV международная конференция по гибкому управлению Agile Поволжья «Истории Вашего бизнеса»

11 ноября 2021 года на территории Исторического парка «Россия – Моя история» пройдет конференция Agile Поволжья, которая за 4 года приобрела статус конференции международного уровня. Самые востребованные эксперты-практики со всего мира на собственном опыте расскажут о трансформации бизнеса и поделятся результатами внедрения новых инструментов: как это помогло компаниям перенастроить процессы, разработать новые продукты и достичь кратного роста.

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

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

На конференции крупные федеральные компании, такие как, Xsolla (г. Пермь), АО «Банк «Агророс» (г. Саратов), ScrumTrek (г. Москва), Торэкс (г. Саратов) поделятся своим опытом формирования проектных команд, работы над продуктами, выстраивания систем оценки персонала, что позволит малому и среднему бизнесу найти инструмент для решения внутренних проблем и перенять лучшие управленческие практики.

Более подробную информацию о теме и спикерах Agile Поволжья Вы можете получить на нашем сайте Agilevolga

выберите процесс из проекта Azure DevOps — Azure Boards

• Статья
• 01/04/2022
• Чтение занимает 9 мин

Были ли сведения на этой странице полезными?

Да Нет

Хотите оставить дополнительный отзыв?

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

Отправить

В этой статье

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013

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

• модель процесса относится к модели, используемой для поддержки проектов, созданных для организации (Azure DevOps Services) или коллекции проектов (Azure DevOps Server). Для организации или коллекции одновременно поддерживается только одна модель процессов. Сравнение трех моделей процессов — наследования, ЛОКАЛЬНОГО XML и размещенного XML-кода осуществляется — в области —.
• Процесс определяет стандартные блоки системы отслеживания рабочих элементов и поддерживает модель процесса наследования для Azure Boards. Эта модель поддерживает настройку проектов с помощью пользовательского интерфейса WYSIWYG.
• Шаблон процесса определяет стандартные блоки системы отслеживания рабочих элементов и другие подсистемы, доступ к которым осуществляется с помощью Azure DevOps. Шаблоны процессов используются только с размещенными и локальными моделями XML-процессов. Настройка проектов осуществляется путем изменения и импорта XML-файлов определений шаблонов процессов.

Дополнительные сведения о создании проекта с помощью выбранного процесса см. в разделе Создание проекта. Дополнительные сведения о моделях процессов см. в разделе Настройка процесса отслеживания работы.

Совет

Чтобы получить доступ к последним версиям шаблонов процессов по умолчанию:

Объекты отслеживания работы, содержащиеся в процессах по умолчанию и шаблонах процессов — Basic, Agile, CMMI и Scrum, — одинаковы и описаны ниже. базовый процесс доступен в Azure DevOps Server 2019,1 и более поздних версиях. Для простоты они называются «процессом».

Совет

Сведения о просмотре унаследованных моделей процессов и управлении ими см. в разделе Управление процессами.

Выберите базовый, гибкий процесс, Scrum и CMMI.

Процессы по умолчанию различаются главным образом в типах рабочих элементов (WIT), которые они предоставляют для планирования и отслеживания работы.

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

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

Основной

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

Задачи поддерживают отслеживание оставшейся работы.

Agile

Выберите Agile , если ваша группа использует гибкие методы планирования, включая Scrum, и отслеживает действия по разработке и тестированию отдельно. Этот процесс работает отлично, если вы хотите относить пользовательские истории и (необязательно) ошибки на доске Канбан, а также контролировать ошибки и задачи в taskboard.

Дополнительные сведения о методологиях Agile можно получить в Agile Alliance.

Задачи поддерживают отслеживание исходной оценки, оставшейся работы и выполненной работы.

Координатор

Выберите Scrum , если ваша команда Scrum. Этот процесс работает отлично, если вы хотите контролировать элементы невыполненной работы по продукту (PBI) и ошибки на доске Канбан, а также разбивать PBI и ошибки на задачи в taskboard.

Этот процесс поддерживает методологию Scrum в соответствии с определением в Организации Scrum.

Задачи поддерживают отслеживание только оставшейся работы.

CMMI

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

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

Если требуется более двух или трех уровней невыполненной работы, можно добавить дополнительные зависимости от используемой модели процессов:

Основные различия между процессами по умолчанию

Процессы по умолчанию предназначены для удовлетворения потребностей большинства команд. Если команда имеет необычные потребности и подключается к локальному серверу, можно настроить процесс, а затем создать проект. Также можно создать проект на основе процесса, а затем настроить проект.

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

Область отслеживания

Состояния рабочего процесса

• Необходимые действия:
• Выполнение
• Готово

• Оператор new
• Активен
• «Разрешено»
• Закрыто
• Удалено

• Оператор new
• Approved
• Фиксация
• Готово
• Удалено

• Предложено
• Активен
• «Разрешено»
• Закрыто

Планирование продукта (см. примечание 1)

• Пользовательская история
• Ошибка (необязательно)

• Элемент невыполненной работы по продукту
• Ошибка (необязательно)

• Требование
• Ошибка (необязательно)

Невыполненные работы портфеля (2)

• Легенда
• Компонент

• Легенда
• Компонент

• Легенда
• Компонент

Планирование задач и спринтов (3)

• Задача
• Ошибка (необязательно)

• Задача
• Ошибка (необязательно)

• Задача
• Ошибка (необязательно)

Управление невыполненной работой по ошибкам (1)

Управление проблемами и рисками

• Проблема
• Риск
• Просмотр

Примечание

1. Эти WIT можно добавить на доскеневыполненной работы по продукту или Канбан. Невыполненная работа по продукту представляет собой единое представление текущей невыполненной работы, которая может быть динамически переупорядочена и сгруппирована. Владельцы продуктов могут быстро расставить приоритеты для работы и структур зависимостей и связей.
   Кроме того, каждая команда может настроить способ отображения ошибок в журналах ожидания и на досках.
2. Использование невыполненных работ портфеля позволяет определить иерархию невыполненной работы, чтобы понимать объем работы нескольких команд, а также видеть, как эти работы свертываются в более масштабные инициативы. Каждая команда может настроить, какие невыполненные работы портфеля будут отображаться для их использования.
3. Можно определить задачи из невыполненной работы спринта и taskboard. С помощью планирования ресурсов команды могут быстро определить, превышает ли их емкость спринта.

Состояния, переходы и причины рабочих процессов

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

Важно!

для Azure DevOps Services и Azure DevOps Server 2019 по умолчанию переходы рабочего процесса поддерживают любое состояние в любой переход состояния. Эти рабочие процессы можно настроить для ограничения некоторых переходов. См. раздел Настройка объектов отслеживания работы для поддержки процессов вашей команды.

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

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

История, проблемы, иерархия задач

История, вопрос, Рабочий процесс задачи

Примечание

базовый процесс доступен при создании нового проекта на основе Azure DevOps Services или Azure DevOps Server 2019,1. Для предыдущих развертываний в локальной среде выберите Agile, Scrum или CMMI Process.

Пользовательская история

Компонент

Легенда

Bug

Задача

Элемент невыполненной работы по продукту

Компонент

Легенда

Bug

Задача

Требование

Компонент

Легенда

Bug

Задача

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

Рабочий процесс можно изменить для поддержки других состояний, переходов и причин. Дополнительные сведения см. в разделе Настройка отслеживания работы.

Состояния Удаленный, Закрытый и Завершенный.

Когда изменяет состояние рабочего элемента на Удаленное, Закрытое или Завершенное, система реагирует следующим образом:

• Закрыто или Готово: рабочие элементы в этом состоянии не отображаются на страницах невыполненной работы портфеля и невыполненной работы. Однако они отображаются на страницах невыполненной работы спринта, на доске Канбан и taskboard. Кроме того, при изменении представления невыполненной работы портфеля на отображение элементов невыполненной работы, например, для просмотра функций элементов невыполненной работы по продукту, отображаются рабочие элементы в состоянии закрыто и готово.
• Удалено. рабочие элементы в этом состоянии не отображаются в невыполненной работе или на доске.

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

Примечание

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

Если необходимо окончательно удалить рабочие элементы, см. раздел Удаление или удаление рабочих элементов.

Типы рабочих элементов, добавленные во все процессы

Следующие WIT добавляются ко всем процессам, за исключением базового процесса.

Команды создают следующие типы рабочих элементов с помощью соответствующего средства:

• План тестирования, набор тестов, общие шаги тестового случая и общие параметры: Microsoft Test Manager.
• Запрос отзыва и ответ на отзыв: Запрос отзыва.
• Запрос на проверку кода и отклик на проверку кода: «Моя работа» (из командного обозревателя) и Запрос на проверку кода.

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

Примечание

если вы обновили проект с Azure DevOps 2013 или более ранней версии до более поздней версии, может потребоваться добавить wit, которые не существовали в более ранних версиях. Дополнительные сведения см. в разделе Настройка компонентов после обновления.

В указанную версию программного обеспечения добавлены следующие WIT:

• Общие параметры, добавленные с помощью операций разработки Azure 2013,2
• план тестирования и набор тестов добавлены с Azure DevOps 2013,3

Типы рабочих элементов, поддерживающие работу теста

WIT, которые поддерживают тестовую среду и работают с Test Manager и веб-порталом, связаны друг с другом с помощью типов ссылок, показанных на следующем рисунке.

На веб-портале или Microsoft Test Manager можно просмотреть, какие тестовые случаи определены для набора тестов. Вы также можете просмотреть, какие наборы тестов определены для плана тестирования. Однако эти объекты не связаны друг с другом через типы связей. Настройте эти WIT так же, как любые другие WIT. См. раздел Настройка объектов отслеживания работы для поддержки процессов вашей команды.

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

Связанные статьи

Процесс можно настроить до или после создания проекта, который использует этот процесс. Используемые методы зависят от используемой модели процессов. Дополнительные сведения см. в разделе Настройка отслеживания работы.

дополнительные вопросы см. на странице поддержки Azure DevOps.

«Agile — это история о творчестве и доверии»

24. 11.2016 09:00     

 

Главный редактор

Все статьи автора

Руководитель проектов McKinsey Евгений Устинов перевел на agile-рельсы уже не одну крупную компанию по всему миру. Поэтому кто, как не он, может в красках рассказать об особенностях этого модного направления, его плюсах и подводных камнях.

— Тема agile сейчас мегапопулярна, но ведь этому направлению, как я понимаю, не один десяток лет?

— Не секрет, что в ведущих российских банках локальные применения agile-подхода к работе практиковались достаточно давно и довольно успешно. Само движение к agile началось не сверху, на уровне топ-менеджмента, а снизу, на уровне отдельных команд.

— Расскажите об истории этой методики. 

— Термин agile (дословно: гибкий, динамичный) появился в 2001 году с манифеста, в котором люди, продукт и готовность к изменениям ставились выше согласований, бумажек и первоначального плана. Но организации, работавшие по этому принципу, возникли еще в 60-х годах XX века, причем даже не подозревая, что они agile. Просто люди делали так, как чувствовали, и все. Сейчас agile ассоциируется прежде всего с разработкой программного обеспечения, с передовыми технологиями. На самом деле agile-организации можно встретить в разных областях, и пионеры этого подхода встречались в совершенно неожиданных сферах.

Мой любимый пример: в 60-х годах в США был такой летчик, военный стратег Джон Бойд. Он придумал теорию OODA, по которой воздушный бой выигрывает не самый лучший самолет с точки зрения техники, а пилот, который принимает максимальное количество решений за определенный отрезок времени и моментально реагирует на изменяющиеся обстоятельства. В общем, побеждает наиболее быстрый и гибко мыслящий. Теория Бойда активно применялась в те времена в военной сфере. Но это лишь один из многих эпизодов, показывающих, где agile был востребован.

— Что он представляет собой в современной интерпретации? 

— Надо сказать, что agile — это зонтичное понятие, а не конкретная технология или какое-то одно решение. Это понятие объединяет множество различных методов и подходов, которые в совокупности делают организацию другой. Ядро agile, главный его компонент, — это небольшая команда. Причем есть четкое научное обоснование ее оптимального размера — от шести до двенадцати человек. Команда должна быть кросс-функциональной, то есть включать людей разных специализаций: продуктовиков, маркетологов, юристов, дизайнеров, IT-специалистов и так далее. Все они образуют единый организм и в идеале должны работать в одном помещении. 

— То есть удаленка в agile не приветствуется?

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

Работают люди небольшими отрезками. Они сознательно себя ограничивают, договариваются между собой, что продвигаются дистанциями спринта, а не марафона. Эти отрезки так и называют — спринтами. Каждый может длиться от недели до месяца, но наиболее часто используемый стандарт сейчас — две недели. То есть команда свою работу планирует только на этот срок. Почему так? Очень просто: человек плохо умеет прогнозировать, все исследования это подтверждают. Составить реалистичные планы на годы вперед невозможно. Можно ставить долгосрочные цели, это правильно. Но просчитать, что конкретно и когда ты будешь делать, получается максимум на месяц. Команда строит работу так, чтобы произвести в этот отрезок времени целостный и жизнеспособный продукт, который можно отдать клиенту или вывести на рынок.

— Давайте разберем ситуацию на простом примере — создании сайта.

— Давайте. Как он создается при классическом поэтапном подходе, который получил название waterfall? Приходит в компанию заказчик и рассказывает о своих желаниях: хочу красивый дизайн, все виды оплаты, каталог товаров на четыре тысячи наименований, чат… «Ну хорошо, — говорят разработчики, — давайте все детализируем и задокументируем». Пишется толстенная кипа бумаг, делается множество презентаций. Все это несется дизайнерам, потом переходит к разработчикам, потом к тестировщикам… В итоге что получается: пока все детально расписывали — прошел месяц, пока рисовали — еще месяц, в разработке у девелоперов сайт с огромным количеством товаров застрянет еще на полгода точно. Тестировщики забрали недели четыре. В итоге длительность производства сайта составила восемь месяцев. За это время случилось что? 

— Запустилось еще пять подобных сайтов.

— Совершенно верно, а ваш еще и морально устарел. Потому что технологии меняются стремительно. Придерживаясь идеологии agile, мы за две недели, максимум за месяц, подготовим какую-то одну продуктовую линейку к размещению на сайте, сделаем доступными самые распространенные способы оплаты, создадим пробный дизайн и выпустим продукт на рынок. Потому что работа будет вестись не поэтапно, как в случае waterfall, а короткими спринтами, каждый из которых вмещает все этапы создания продукта. Группа из разных специалистов во главе с владельцем продукта, который видит общую картину и несет ответственность за конечный результат, садится вместе и начинает все обсуждать. Например, дизайнер предлагает идею внешнего вида сайта, а разработчик тут же обдумывает способ ее реализации. Или, наоборот, сразу говорит: «То, что ты предлагаешь, технически выполнить невозможно». В итоге в конце каждого спринта получается MVP (minimum viable product) — минимальный продукт, готовый к жизни и реальному тестированию на рынке.

— А как работает agile в крупных корпорациях?

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

— Как «племена» между собой взаимодействуют?

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

— Заказчик вовлекается в проект?

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

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

Agile — это, конечно, история и о технологиях. Любая доработка IT-продукта моментально становится релизом, те же Amazon и Google выкатывают тысячи обновлений ежедневно. Но в первую очередь это история о людях, о культуре доверия. Причем как внутри организации, так и вне ее: под зонтиком agile умещается в том числе клиент, которого очень внимательно слушают, пытаются максимально понять его запросы, мысли и мечты. То есть в таких группах очень развита эмпатия.

— Это все красиво звучит, но насколько в нашей стране работает? Особенно в банках, где обычно очень сильна властная вертикаль и без бумажки мало что можно сделать, как мне кажется. Готовы ли наши компании меняться?

— За свою карьеру я сотрудничал со многими международными компаниями — южноафриканскими, европейскими, азиатскими, так что мне есть с чем сравнивать. Могу с уверенностью сказать, что в этом плане Россия не уникальна. Идеология «без бумажки ты никто» не чужда всем. В каждой стране эту проблему решают по-своему, но практически всегда успешно.

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

— Назовите самые распространенные заблуждения, связанные с agile.

— Одно из самых популярных: agile не предполагает «архитектуры», генплана, каждый делает что хочет. Это, конечно, не так. Люди немного по-другому работают с «архитектурой», но общую картинку обязательно получают. Другое заблуждение — вообще нет документации. Она есть, но только самая необходимая, и вводится по мере надобности, а не вся сразу на старте проекта. На самом деле при правильном применении agile дает большую прозрачность, чем традиционные методы работы. 

— Мне кажется, львиная часть документов в современных компаниях создается для снятия ответственности. «Я две недели назад написал служебку, Вася на нее не отреагировал, его вина». Или: «Я это не обязан делать, у меня и документ имеется»… 

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

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

— Вот приходите вы в организацию и с чего начинаете делать ее agile-ориентированной? 

— Есть два магистральных направления: сверху вниз и снизу вверх. В чем заключается первый подход. Руководители организации решают жить по-новому. Они садятся — с консультантом или без — и планируют заново всю структуру. Делят людей на команды, объединяют их в «племена», обучают сразу всех сотрудников новому подходу к работе, подкручивают корпоративные процессы во всех областях — от HR до финансирования. Этот подход хорош тем, что предполагает масштабные изменения, которые дают быстрый результат. Вся организация делает большой скачок, не возникает проблем с тем, что кто-то уже перешел на agile-рельсы, кто-то еще нет.  

Другой подход — снизу вверх. В организации создается одна команда, которая проходит обучение и начинает работать по-новому. Остальные сотрудники, видя довольных жизнью коллег с горящими глазами, говорят: «Мы тоже так хотим!» И постепенно, по цепочке, вся организация становится agile. Этот путь более органичный, но долгий.  

— С плюсами все понятно, а есть ли какие-то минусы, подводные камни?

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

Переход на agile требует изменения мотивации людей. При этом подходе не применяются, например, индивидуальные KPI, потому что результат работы — командный. Для кого-то это отличная новость, для кого-то не очень.  

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

— В каких сферах лучше не применять agile?

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

Фото: Надя Дьякова

История Agile | Planview LeanKit

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

Agile становится мейнстримом

Чтобы помочь распространить информацию о Манифесте Agile, отцы-основатели в истории Agile решили создать более постоянную организацию, и так родился Agile Alliance.Agile Alliance — это некоммерческая организация, которая существует до сих пор. Цель организации — делиться информацией об Agile, предоставлять ресурсы командам, желающим внедрить методологию Agile, и продолжать развивать подход для удовлетворения меняющихся потребностей.

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

По мере того, как Agile набирала обороты, роль Agile Alliance росла. В 2003 году ставший уже официальным Agile Alliance вернулся в Юту на первую ежегодную конференцию по Agile — важную веху в истории Agile. Группа описала это мероприятие как «посвященное продвижению принципов Agile и созданию площадки для процветания людей и идей». Эта ежегодная конференция под названием Agile 20XX продолжается и по сей день.

С годами Agile Alliance также расширился географически.Сегодня Agile Alliance поддерживает партнерские группы по всему миру, которые продвигают Agile на местных рынках и помогают близлежащим организациям принять Agile Manifesto.

Agile набирает обороты

В то время как Agile набирает обороты в начале 2000-х, мы видим, что Agile Manifesto набирает обороты в 2010-х.

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

Полная история гибкой разработки программного обеспечения

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

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

Сначала наступил кризис

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

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

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

Лидеры мнений были разочарованы

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

Другие отрасли тоже претерпевали изменения. Автомобильной промышленности потребовалось шесть или более лет, чтобы спроектировать новый автомобиль, а в 1990-х годах это время сократилось почти вдвое.AT&T распалась, и так называемые Baby Bells резко сократили расходы на телефоны и обслуживание.

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

И родилась Agile

Эти разочарования по поводу, казалось бы, непродуктивной деятельности по разработке программного обеспечения, которую разделили профессионалы-единомышленники, привели к ставшей знаменитой встрече Snowbird в Юте в начале 2001 года.Но это была не первая встреча этой конкретной группы лидеров программного обеспечения. Они собрались за год до этого, в Rogue River Lodge в Орегоне, весной 2000 года. сегодня в agile-сообществе. Agile как практика не была конечной целью; на самом деле, слово «agile» еще не использовалось в официальном разговоре до этого времени.На той встрече термины «легкий» и «облегченный» были более распространены, хотя никто из участников не был особенно удовлетворен этим описанием.

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

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

Реакция на тяжеловесные процессы

Agile никоим образом не критически относится к методологиям разработки, разработанным в 1970-х и 1980-х годах в ответ на хаотичные и незапланированные подходы, которые часто использовались на заре разработки программного обеспечения.На самом деле период с 1970 по 1990 год в значительной степени был периодом возникновения фундаментальных теорий и практик разработки программного обеспечения. Идея заключалась в том, чтобы приравнять программную инженерию к физической инженерии и позаимствовать как можно больше из фактического проектирования и построения.

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

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

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

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

Просим не согласиться

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

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

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

У провидцев разные взгляды на разработку программного обеспечения

Некоторая негативная реакция также была вызвана крупнейшим разработчиком программного обеспечения в мире: правительством США. В частности, стандарты Министерства обороны (DoD) для разработки программного обеспечения (в частности, DOD-STD-2167) явно отдавали предпочтение модели водопада до конца 1990-х годов, когда они были изменены для явной поддержки итерационных процессов.

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

Несмотря на то, что в 1980-х и 1990-х годах преобладала модель водопада, промышленные и академические лидеры сопротивлялись. Важным первоначальным ответом был Джеймс Мартин с быстрой разработкой приложений или RAD. Цель RAD состояла в том, чтобы сократить этап подготовки и быстро перейти к разработке, чтобы бизнес мог сразу начать сотрудничество с командой разработчиков, увидев рабочий прототип всего за несколько дней или недель.

Был также переход к так называемой итеративной разработке программного обеспечения. Хотя итеративная разработка программного обеспечения берет свое начало по крайней мере в 1960-х годах, концепция постепенных улучшений закрепилась благодаря работе гуру качества У. Эдвардса Деминга и других еще раньше. Концепция заключается в том, что вы выполняете действие, измеряете основные характеристики, вносите изменения, основанные на здравом смысле, и снова измеряете для улучшения.

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

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

Практики хотят повторять разработку

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

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

Примерно в то же время Кент Бек был нанят в качестве консультанта по экспериментальному проекту разработки программного обеспечения в Chrysler. Со временем его назначили руководителем проекта, и, стремясь добиться успеха, он был полон решимости довести лучшие практики до экстремального уровня, дав название методологии XP. В то время как проект был в конечном итоге отменен, когда был приобретен Chrysler, Бек опубликовал книгу под названием «Объяснение экстремального программирования », и его имя стало синонимом одной из ведущих альтернативных методологий.

Возможно, различные гибкие и итерационные методы все еще были бы в меньшинстве, если бы не Agile Manifesto, систематизированный на той встрече 2001 года в Snowbird. Несмотря на неопределенные цели этой группы, «Манифест» является наиболее ясным и кратким изложением цели подхода, который был противоположностью модели водопада, которая все еще преобладала в то время.

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

К ловкости и не только

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

На конференции Better Software/Agile Development West в 2011 году Кент Бек выступил с основным докладом о том, как ускорить доставку программного обеспечения. Он провел этот часовой доклад, ни разу не упомянув Agile.

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

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

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

Продолжайте учиться

Гибкая разработка программного обеспечения: история

Сноуберд, штат Юта, — маловероятное место, где можно совершить революцию в программном обеспечении. Расположенный примерно в 25 милях от Солт-Лейк-Сити, Сноуберд — это, конечно, не Силиконовая долина; он не известен ни солнечным климатом, ни умеренным климатом, ни центрами технологических инноваций, ни изобилием нетерпеливых предпринимателей. Но именно здесь, в белоснежных горах на горнолыжном курорте, в 2001 году собралась группа мятежников программного обеспечения, чтобы составить и подписать один из самых важных документов в истории своей отрасли, своего рода Декларацию независимости для кодирования. задавать.Этот небольшой трехдневный ретрит поможет определить, как создается, создается и доставляется большая часть программного обеспечения — и, возможно, то, как устроен мир.

Независимо от того, знаете ли вы его название, вы, вероятно, сталкивались с Agile или, по крайней мере, с компаниями, которые его используют. Представители Spotify и eBay подтвердили, что обе компании в настоящее время используют Agile, а на веб-сайте Twitter есть список вакансий «тренера по Agile». Следы хлебных крошек в Интернете предполагают, что многие другие известные технологические компании, по крайней мере, экспериментировали с этим в прошлом.И дело не только в Силиконовой долине: по сообщениям, Walmart начал экспериментировать с Agile много лет назад. Agile Alliance, некоммерческая организация, продвигающая использование Agile, включает в себя всевозможных корпоративных гигантов, включая Lockheed Martin, ExxonMobil и Verizon, среди своих корпоративных членов.

Помощники Agile, кажется, повсюду, принося с собой целый ботанический лексикон инструментов и трюков, чтобы сделать рабочие места более эффективными: подумайте о ежедневных стендапах и спринтах. Если принять за чистую монету, это может показаться еще одним бессмысленным корпоративным модным словом, используемым людьми, занимающимися управлением проектами. Но на самом деле это очень специфическая философия, изложенная в документе из 68 слов и четырех пунктов, подписанном в Snowbird.

* * *

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

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

Водопадный процесс (любезно предоставлено Музеем компьютерной истории)

Многие приписывают происхождение этой модели статье Уинстона Ройса 1970 года, но есть большая загвоздка: хотя на второй странице появляется диаграмма, похожая на водопад, статья Ройса на самом деле не одобряет создание программного обеспечения таким образом.

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

И есть проблема с ожиданием завершения проекта, чтобы протестировать все это, указывает Кусумано: если вы поймаете ошибку на последнем этапе, это может быть беспорядочно — или даже фатально — пытаться вернуться и исправить Это. Некоторые программные проекты зависали и просто никогда не поставлялись.

«Люди составляли подробные списки того, какие задачи должны быть выполнены, в каком порядке, кто должен их выполнять, [и] какими должны быть результаты», — вспоминает Мартин Фаулер, главный научный сотрудник ThoughtWorks, присутствовавший на Snowbird. встреча.«Разница между одним программным обеспечением и другим проектом настолько велика, что вы не можете планировать все заранее». В некоторых случаях сама документация становилась громоздкой. Несколько человек, с которыми я разговаривал, поделились ужасными историями: требования на целую книжную полку в папках или 800-страничный документ, переведенный на три разных языка.

Другой участник Snowbird, Кен Швабер — соучредитель Scrum и основатель Scrum.org — говорит, что Waterfall «буквально разрушил нашу профессию.«Это сделало так, что люди рассматривались как ресурсы, а не как ценные участники». С таким большим планированием сотрудники стали просто винтиком в колесе.

По мере того, как в 1980-х и начале 1990-х чисто последовательная модель давала сбои, некоторые компании начали экспериментировать с различными способами работы над проектами, создавая процессы, которые, как говорит бывший академик в области науки и технологий Стюарт Шапиро, позволяли разработчикам «Поднимитесь обратно к водопаду».

В статье 1997 года о Microsoft Кусумано и его соавтор Ричард У.Селби описывает, как Waterfall «постепенно теряет популярность… потому что компании обычно создают более качественные продукты, если они могут изменять спецификации и дизайн, получать отзывы от клиентов и постоянно тестировать компоненты по мере развития продуктов».

На рубеже веков несколько мошенников в индустрии программного обеспечения начали активно сопротивляться. Они хотели создать процессы, которые дали бы им больше гибкости и фактически позволили бы им поставлять программное обеспечение вовремя. Некоторые из этих процессов, такие как Scrum и Extreme Programming (XP), назывались «легкими» или «облегченными» процессами. Но ни одно подмножество не прижилось. Итак, в 2001 году парни легкого веса решили объединить усилия.

«Я думаю, что в тот момент мы все как бы искали легитимность, что мы были как бы сами по себе, делая подобные вещи, но на самом деле это не имело большого успеха в сообществе», — вспоминает Джим Хайсмит, исполнительный консультант ThoughtWorks.

Неясно, кому пришла в голову идея встречи, которая в конечном итоге состоится в Snowbird. Многие из участников были лидерами в сообществе разработчиков программного обеспечения, и некоторые помнят, как эта идея обсуждалась на отраслевых встречах.Когда наконец пришло приглашение на ретрит, оно пришло по электронной почте от Боба «дяди Боба» Мартина. Мартин, ветеран индустрии и основатель Uncle Bob Consulting, ведет блог The Clean Code Blog и обладает прекрасным чувством юмора: видео на YouTube, размещенное на его веб-сайте, показывает, среди прочего, что Мартин взлетает на астероид. Мартин говорит, что они с Фаулером встретились в кофейне в Чикаго, где составили и отправили электронное письмо. Фаулер ничего не помнит об их встрече, но говорит, что «вероятно» все произошло именно так.

Перебрав несколько вариантов — таких как Чикаго («холодно и нечем заняться», — писал Хайсмит в 2001 году) и Ангилья («тепло и весело, но дорога занимает много времени»), группа остановилась на Юте ( «холодно, но весело»), заказав экскурсию в Snowbird. Там, начиная с 11 февраля 2001 года, мужчины — а все они были мужчинами — выходили на склоны и обсуждали программные процессы.

* * *

Джеймс Греннинг, основатель Wingman Software, вспоминает метель. «Нас завалило снегом, — говорит он, — и это было похоже на лавину.Никто никуда не собирался уходить. Это было удивительно».

Вьюги, наверное, не было. Исторические данные о погоде от Dark Sky показывают, что в дни, предшествовавшие и во время отступления, выпал небольшой снег. Но выходные действительно — по крайней мере, образно говоря — похоронили многое из того, что было до них.

«За свою карьеру я участвовал во многих подобных собраниях, — вспоминает Хайсмит. «Этот был действительно особенным».

Я разговаривал с 16 из 17 участников.(Кент Бек, технический тренер Facebook, отказался давать интервью для этой статьи.) Более полутора десятилетий спустя они размышляли о ретрите. «Это был один из тех моментов, когда вы думаете: «Знаете, вы соберете кучу людей в комнате, и они будут болтать, и ничего не произойдет», — говорит Мартин. «И это просто не то, что произошло. Эта группа людей устроилась, организовалась и выпустила этот манифест. На самом деле было удивительно наблюдать».

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

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

Уорд Каннингем, соучредитель Cunningham & Cunningham (известный в сообществе программистов, среди прочего, тем, что придумал термин «вики»), размышляет об этом моменте.«Когда это было записано на доске, несколько человек были в коридоре на перерыве», — вспоминает он. «И я был в коридоре, и [кто-то] сказал:« Подойди сюда и посмотри на это. Посмотрите, что мы написали». И мы просто стояли и смотрели на доску, в восторге от того, как много в ней суммировалось то, что у нас было общего. Знаете, это был такой драматичный момент, что вместо того, чтобы все разговаривали небольшими группами, мы стояли вокруг доски и изучали ее».

Каннингем говорит, что он вскочил на стул и сфотографировал этот момент, «потому что я мог сказать, что произошло что-то важное.

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

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

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

Мужчины закончили Манифест во время отступления. Остальное время они потратили на работу над 12 принципами нового документа и, ну, катание на лыжах. (Некоторые утверждают, что принципы считаются официальной частью Манифеста; другие считают сам Манифест просто ценностями.)

Эта новая философия нуждалась в названии, и не всех устраивало рабочее название «Легкий вес». «Почему-то это звучит как группа тощих, слабоумных, легковесных людей, пытающихся вспомнить, какой сегодня день», — вспоминает Хайсмит другого участника, Алистера Кокберна. Кокберн, который сегодня является независимым консультантом по программному обеспечению, помнит, как облегчал поиск слова. «Это не было похоже на то, что кто-то сказал:« Agile! О, отлично, поехали», — говорит мне Кокберн. «Это было действительно много работы.Другим финалистом, по его словам, был «Адаптивный».

«Единственное беспокойство по поводу термина «гибкий», — пишет Хайсмит в своем резюме ретрита в 2001 году, — исходило от Мартина Фаулера (британец для тех, кто его не знает), который допускал, что большинство американцев не знаю, как произносить слово «agile». В конце концов Фаулер справился с этим, хотя, поговорив с ним по телефону, я не мог не заметить, что он по-прежнему произносит это слово с британским акцентом: элегантный ah- gile , вместо американского ah-gel .

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

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

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

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

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

* * *

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

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

Марик соглашается. «Я думаю, дело было в том, что люди могли выразить свое разочарование, цитируя тезисы Мартина Лютера, прибитые к двери, и они могли поставить на них свою подпись», — говорит он. «Это то, что действительно придало ему импульс».

Возможность подписать документ закончилась в июле 2016 года. (Каннингем перенастроил хостинг и начинает относиться к Манифесту как к историческому документу.) Но за 15 лет с момента его первой публикации, по его словам, более 20 000 человек подписали Agile-манифест.

* * *

Манифест, конечно, был только началом. «Боже мой, как бы я хотел быть там», — говорит мне Грэди Буч. Буч, главный научный сотрудник отдела разработки программного обеспечения IBM Research, был приглашен на ретрит в Snowbird, но говорит, что отказался в последнюю минуту, чтобы иметь дело с «назойливым клиентом». Буч не сомневается в основополагающем происхождении Agile или его последующем влиянии. Он говорит мне, что 1990-е были «невероятно богатым временем в разработке программного обеспечения, когда у вас были буквально десятки, если не сотни людей, которые выдвигали новые идеи в области разработки программного обеспечения.Все это, по его словам, «дошло до апогея» в Snowbird.

Agile-процесс (любезно предоставлено Музеем компьютерной истории)

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

Возможно, Agile или что-то в этом роде было неизбежным: если проекты программного обеспечения собирались быть успешными в гибком цифровом будущем, они должны были иметь возможность, как говорится на техническом языке, поворачиваться — реагировать на изменения.Интернет коренным образом изменил способ доставки программного обеспечения. Современное программное обеспечение обычно не записывается на CD-ROM и не хранится на полке в магазине; обновления могут быть отправлены на ваш ноутбук или смартфон удаленно. Это упрощает добавление функций или исправление ошибок после выпуска продукта.

«Чтобы преуспеть в новой экономике, — пишет Хайсмит в своем резюме ретрита 2001 года, — чтобы активно двигаться в эпоху электронного бизнеса, электронной коммерции и Интернета, компании должны избавиться от своих Проявления Дилберта надуманной работы и тайной политики. Эта свобода от бессмыслицы корпоративной жизни привлекает сторонников Agile-методологий и отпугивает фанатиков (слово «дерьмо» нельзя использовать в профессиональной статье) от традиционалистов».

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

Кокберн считает, что это потому, что то, что Agile «удалось расшифровать, было чем-то чисто умственным, основанным на командной деятельности» — и что «это просто историческая случайность, что именно программисты расшифровали это.

По сравнению с «более распространенными, более похожими на водопад идеями», которые «очень подробно излагают то, что делает каждый», Agile «гораздо больше расширяет возможности людей, выполняющих работу», — говорит Фаулер. И поскольку Agile был принят целым рядом профессий, Ари ван Беннекум заходит так далеко, что предлагает заменить слово «программное обеспечение» на «решения», чтобы сделать Agile доступным для всех.

Несмотря на дискуссии о том, следует ли вносить поправки в сам Манифест, многие из тех, кто первоначально подписал документ, считают его историческим, а не живым документом.«Это похоже на Декларацию независимости в истории США», — говорит Кокберн. «Ты не вернешься и не перепишешь это».

«Я думаю, что эти четыре пункта актуальны как никогда», — говорит Греннинг. «Я не ожидаю, что они изменятся».

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

Но здесь есть особая ирония: Agile — это философия, а не набор бизнес-практик. Четыре пули определяют способ мышления, основу для определения приоритетов всех сложных частей проекта. Они не говорят вам, какое программное обеспечение покупать или как проводить ежедневные собрания команды.«Теперь вы можете пойти на конференцию, и там ряд за проходом людей, которые продают вам компьютерные инструменты для запуска вашего процесса. И они говорят, что это Agile», — говорит Каннингем. Он указывает на первую ценность Манифеста Agile. «В нем говорится: «Люди и взаимодействие важнее процессов и инструментов». Как Agile стал бизнесом, основанным на процессах и инструментах?»

Каннингем считает, что «другие люди видели знаки доллара и хотели делать то же самое». Он добавляет: «Деньги были заработаны».

Ван Беннекум, который сегодня является идейным лидером в Wemanity, говорит: «Я вижу, что люди, работающие Agile-коучами, совершенно не понимают, о чем говорят», что «расстраивает.

Между тем, Джон Керн, главный архитектор Fire Planning Associates, признает, что он «как бы вышел из круга Agile» — измученный после того, как многие люди просто не поняли его. «У вас есть много людей, просто продавцов змеиного масла — людей, которые говорят, что используют Agile, когда Agile только на словах», — говорит он. Керн сравнивает Agile с йогой, утверждая, что его практика носит личный характер и что он не «пытается рассказывать другим людям, как практиковать».

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

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

Некоторые дошли до того, что заявили, что Agile мертв. Но Кокберн утверждает, что всегда есть некоторая польза от использования Agile, даже если он не идеален: «Даже плохо сделанный, Agile превосходит все альтернативы или, по крайней мере, основную старую альтернативу [Waterfall], которая существует.»

Сложности — и страсти — этих дебатов демонстрируют, насколько большой стала Agile. Когда я спрашиваю Керна, чего он ждал от Snowbird столько лет назад, он смеется. «Для 10-го [юбилейного] воссоединения мы пытались придумать какие-нибудь слова, чтобы надеть футболку, — объясняет он, — и мое предложение было: «Четыре жалкие пули, и все это дерьмо случилось».

Полная история гибкой разработки программного обеспечения

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

Если вам пришлось ждать три года, чтобы решить проблемы, с которыми сталкивается ваш бизнес, ваши бизнес-требования, системы и даже весь бизнес могут измениться за три года.Из-за этого временного кризиса предприятия отменяли многие проекты на полпути. И многие проекты не соответствовали требованиям и нуждам.

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

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

• Установить требования и объем работ для проекта
• Разработка продукта на основе предварительно определенных требований
• Создайте продукт
• Протестировать продукт
• Выявление проблем во время тестирования
• Устранить проблему
• Запуск готового продукта

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

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

Промышленность была разочарована водопадным подходом

Несколько отраслей начали выражать недовольство каскадным подходом. В 1990-х большое количество команд разработчиков программного обеспечения начали планировать новый подход. Среди них Джон Керн был одним из таких разочарованных идейных лидеров, которые становились все более активными, чтобы найти что-то более «своевременное и отзывчивое».

В начале 2000-х Джон Керн и его группа из 17 разработчиков программного обеспечения начали встречаться в Орегоне.Раньше они обдумывали идею ускорения томов разработки, чтобы быстрее выводить новое программное обеспечение на рынок. Это привело к тому, что они определили два способа воплотить эту идею в жизнь:

• Для решения проблемы соответствия продукта рынку и незавершенного продукта — сокращения задержки выгод для клиентов.
• Для обеспечения полезности нового программного обеспечения и его улучшения — сбор отзывов от клиентов.

Хотя в то время встреча в Орегоне не привела к рождению гибкой методологии; это был первый большой шаг в истории Agile.

Рождение новой идеологии: Манифест истории Agile

После встречи в Орегоне Джон Керн и 17 групп разработчиков (Кент Бек, Уорд Каннингем, Ари ван Беннекум, Алистер Кокберн и еще двенадцать) встретились на горнолыжном курорте Snowbird в Юте в 2001 году. На встрече они обсудили дальнейшие вопросы. разработать более сильное решение проблем развития того времени. За пару дней agile-группа создала «Манифест Agile-разработки программного обеспечения», также известный как Agile-манифест.Манифест обслуживал четыре значения:

1. Индивиды и взаимодействие в процессах и инструментах
2. Рабочее программное обеспечение поверх исчерпывающей документации
3. Сотрудничество с клиентами в ходе переговоров по контракту
4. Реагирование на переход по плану

Группа Agile не остановилась после представления четырех значений. Они добавили красок в манифест, заявив 12 принципов Agile-манифеста. Вот эти принципы:

1. Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет быстрой и непрерывной поставки ценного программного обеспечения
2. Приветствуйте изменяющиеся требования, даже на поздних стадиях разработки.Гибкие процессы используют изменения для конкурентного преимущества клиента
3. Поставлять работающее программное обеспечение часто, от пары недель до пары месяцев, предпочитая более короткие сроки
4. Деловые люди и разработчики должны ежедневно работать вместе над проектом
5. Создавайте проекты вокруг целеустремленных людей. Предоставьте им необходимые условия и поддержку и доверьте им выполнение работы
6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу
7. Работающее программное обеспечение является основным показателем прогресса
8. Гибкие процессы способствуют устойчивому развитию.Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость
10. Простота — искусство максимизировать объем незавершенной работы — необходима
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами
12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, затем соответствующим образом настраивает и корректирует свое поведение

Знакомство с новой эрой: расширение Agile

В 2001 году Agile начал свой путь, но наследие Agile только начиналось. После этой встречи 17 идейных лидеров agile-манифеста начали продвигать ценность agile в мире. Желание продвигать ценность Agile-манифеста побудило их создать организацию. И Agile Alliance был введен в историю Agile.

Agile Alliance — некоммерческая организация, занимающаяся распространением информации об Agile. Его цель — помочь командам внедрить методологию Agile, предоставив ресурсы. Кроме того, организация работает над совершенствованием гибкого подхода для удовлетворения меняющихся потребностей.

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

В 2003 году Agile Alliance организовал свою первую конференцию в штате Юта. Он назывался Agile 20XX, и его целью было расширить принципы Agile и предоставить людям место для реализации своих идей. С годами Agile Alliance расширил свое присутствие. Даже сегодня они организуют agile-мероприятия, поддерживают партнерские группы и продвигают agile-идеологию в организациях.

Итак, каково будущее Agile

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

Популярные компании, такие как Apple, Microsoft, Amazon, Google, Facebook и Netflix, отличаются гибкостью.Хотя они не следуют никакому стандартному agile-словарю, их успех в бизнесе в основном зависит от agile. По данным Capterra, 71% компаний используют agile-подходы. Другое исследование показало, что компании, внедрившие гибкое программное обеспечение, отмечают 60-процентный рост своих доходов. Другое исследование, проведенное McKinsey, показало, что 90% руководителей высшего звена отдают приоритет гибкости, а 10% в настоящее время очень гибки.

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

Авторская биография

Мы — команда профессиональных Scrum-тренеров (PST) и корпоративных agile-коучей, активно работающих в качестве Scrum-тренеров, agile-коучей, Scrum-мастеров/владельцев продукта, стремящихся обеспечить качество и согласованность для наших студентов по всему миру.

История Agile — видео и стенограмма урока

Путь к Agile-методологии

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

Разработка программного обеспечения должна была соответствовать темпам и изменениям, и жесткая методология, которая правила миром SDLC, не могла за ними угнаться.Он просто не мог предоставить программное обеспечение достаточно быстро или эффективно реагировать на изменения требований во время разработки.

К началу 1990-х годов небольшая группа лидеров индустрии программного обеспечения начала разрабатывать и продвигать инновационные подходы к SDLC, которые предусматривали быстрое реагирование и адаптацию к изменяющимся требованиям и технологиям. Быстрая разработка приложений (RAD), Rational Unified Process (RUP), Scrum и экстремальное программирование (XP) стали новыми, быстро реагирующими и гибкими используемыми методологиями разработки программного обеспечения.

В начале 2000-х небольшая группа лидеров индустрии программного обеспечения встретилась в Сноуберде, штат Юта, чтобы обсудить эти новые методологии. Термин гибкой разработки программного обеспечения был придуман в 2001 году для описания гибкого характера программного обеспечения, разрабатываемого поэтапно, и стал общим термином для новых методологий.

Чтобы отличить гибкую разработку программного обеспечения от традиционных методологий, руководители Snowbird, Юта, разработали набор ценностей для использования гибкой разработки, названный Манифестом Agile.В нем авторы продвигают:

• Индивиды и взаимодействие в процессах и инструментах
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в ходе переговоров по контракту
• Реагирование на переход по плану

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

Agile сегодня

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

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

Итоги урока

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

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

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

• Индивидуумы и взаимодействие в процессах и инструментах
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в ходе переговоров по контракту
• Реагирование на переход по плану

Гибкая история и археология — как все это сочетается?

Задумывались ли вы когда-нибудь о том, как развивалась история Agile, и о широкой археологии, стоящей за тем, в каком направлении она движется? Недавно я ответил на вопрос об экстремальном программировании (XP) на дискуссионном форуме и сделал комментарий, что, по моему мнению, использование XP было в значительной степени вытеснено Scrum. Кто-то ответил на мой комментарий и сказал, что не согласен с тем, что Scrum вытеснил XP. Чтобы действительно понять, что происходит, полезно притвориться археологом-любителем, сделать шаг назад и посмотреть на историю развития Agile.

Изображение

с сайта Pixabay

Что такое археология и как она связана с Agile?

Археология — интересная область. Вот теперь «археология» определена:

” Изучение человеческой истории и предыстории посредством раскопок и анализа артефактов и других физических останков.”

https://www.lexico.com/en/definition/archaeology

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

• У майя была очень обширная и развитая цивилизация, которая находилась в расцвете примерно с 200 г. до н.э. до 950 г. н. э. Он начал значительно снижаться примерно в 950 году нашей эры в южных районах Центральной Америки (Белиз, Никарауга и Гондурас), в то время как он продолжался в некоторой степени в северных районах Центральной Америки (таких как Юкатан), пока эти районы не были уничтожены испанскими конкистадорами в 1500-х годах. .
• Майя построили массивные храмы и города со сложной инфраструктурой, которая почти полностью исчезла в подлеске джунглей, пока в 1800-х годах исследователи, такие как Джон Ллойд Стивенс, не начали открывать ее в полном объеме. Исследователи, такие как Джон Ллойд Стивенс, начали открывать, насколько обширной была цивилизация майя, расчищая часть зарослей джунглей, которые полностью покрывали многие очень тщательно продуманные руины майя.

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

Проворная «Археология»

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

Обзор истории Agile

Я не собираюсь описывать каждую деталь, связанную с эволюцией Agile-истории. Я только намереваюсь зафиксировать то, что я считаю наиболее важными элементами этой эволюции, и показать, как они вписываются в периоды эволюции. Вот краткое изложение периодов, которые я использовал для описания этой эволюции: 90 003 года.

Ранний период разработки программного обеспечения

1965 – Программный кризис 1960-х годов

«Разработка программного обеспечения была вызвана так называемым кризисом программного обеспечения 1960-х, 1970-х и 1980-х годов, который выявил многие проблемы разработки программного обеспечения. Многие проекты выходили за рамки бюджета и графика… Кризис программного обеспечения изначально определялся с точки зрения производительности, но эволюционировал, чтобы сделать акцент на качестве».

Период управления проектом

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

• Удовлетворение проектным требованиям в рамках поставленных целей по затратам и графику
• Был хорошо спроектирован в соответствии со стандартами кодирования и архитектуры
• Был тщательно протестирован на отсутствие серьезных дефектов

До этого периода были некоторые катастрофические проектов, и было сильное давление, чтобы улучшить способ разработки программного обеспечения.Давление по улучшению процесса разработки программного обеспечения исходило, в частности, от министерства обороны США. Министерство обороны начало запускать некоторые очень крупномасштабные проекты разработки, которые должны были быть надежными и должны быть относительно близки к их стоимости и запланированным бюджетам.

1969 – Основание PMI

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

1970 – Водопад Модель

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

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

  Период влияния производства

  На Agile сильно повлияли новые разработки в обрабатывающей промышленности, в том числе:

  1978 — Производственная система Toyota

  Тайити Оно публикует книгу «Производственная система Toyota — Помимо крупномасштабного производства», в которой рассказывается о бережливом производстве, бережливом производстве и канбане. «Система производства автомобилей Toyota Motor Corporation — это способ создания вещей, который иногда называют «системой бережливого производства» или «системой «точно в срок» (JIT)…» — история Канбана

  .

  1986 – Игра по разработке новых продуктов

  Два японских бизнес-эксперта опубликовали в Harvard Business Review статью под названием «Игра в разработку нового нового продукта», которая считается ранней основой для мышления, лежащего в основе Scrum — игры в разработку нового нового продукта

  1990 – Бережливое производство

  «Мыслительный процесс бережливого производства был подробно описан в книге «Машина, которая изменила мир» (1990) Джеймса П. Вомак, Дэниел Рус и Дэниел Т. Джонс. В следующем томе «Бережливое мышление» (1996) Джеймс П. Вомак и Дэниел Т. Джонс еще больше свели эти принципы бережливого производства к пяти принципам».

  2007 – Канбан

  Канбан зародился в производственной среде (см. Производственная система Toyota). В 2007 году Дэвид Андерсен описал процесс разработки программного обеспечения, который привел к созданию канбан-доски, канбан-карты и большинства политик канбан, которые применялись при разработке программного обеспечения

  .

  Ранний период, ориентированный на разработчиков

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

  1991 – кристально чистый

  «Crystal Clear» — это очень ранняя методология Agile, разработанная Алистером Кокберном, которая больше не используется. Это один из самых легких и адаптируемых подходов к разработке программного обеспечения Crystal Clear

  .

  1996 — Экстремальное программирование (XP)

  XP был определен Кентом Беком и другими.«Extreme Programming (XP) — это гибкая среда разработки программного обеспечения, целью которой является создание программного обеспечения более высокого качества и повышение качества жизни команды разработчиков. XP — наиболее конкретная из гибких сред в отношении соответствующих инженерных методов разработки программного обеспечения». — Проворный Альянс

  Период уровня решения

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

  1995 — Скрам

  Джефф Сазерленд и Кен Швабер впервые определили Scrum как Agile-фреймворк. «Scrum — это гибкая структура процесса для управления сложной работой, связанной со знаниями, с первоначальным упором на разработку программного обеспечения, хотя она использовалась в других областях и постепенно начинает изучаться для другой сложной работы, исследований и передовых технологий

  .

  1996 — Рациональный унифицированный процесс

  Компания Rational приобрела Objectory Process, написанный Иваром Якобсоном и компанией, и переименовала его в Rational Unified Process (RUP).Rational Unified Process (RUP) — это итеративная структура процесса разработки программного обеспечения. Первоначальная реализация RUP в значительной степени основывалась на инструментах Rational.

  1997 г. — разработка, ориентированная на функциональные возможности

  Feature-driven development (FDD) — это итеративный и поэтапный процесс разработки программного обеспечения, разработанный Джеффом Делука. «Это облегченный или гибкий метод разработки программного обеспечения. Эти методы основаны на клиентоориентированной функциональности (функциях).

  1999 г. — унифицированный процесс предприятия

  EUP — это упрощенная версия Rational Unified Process, разработанная Скоттом Амблер. Это более общий процесс, не зависящий от инструментов Rational, и «в то время как RUP определяет жизненный цикл разработки программного обеспечения, EUP расширяет его, чтобы охватить весь жизненный цикл информационных технологий (ИТ)»

  .

  Период определения Agile

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

  2001 — Agile-манифест

  «Представители экстремального программирования, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и другие, сочувствующие необходимости создания альтернативы основанным на документации тяжеловесным процессам разработки программного обеспечения», чтобы определить общий набор ценности и принципы для объединения Agile.

  Период уровня предприятия

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

  2011 — Масштабируемая Agile Framework

  SAFe — это фреймворк корпоративного уровня, разработанный Дином Леффингуэллом. «Методология Scaled Agile Framework, или SAFe, — это гибкая структура для команд разработчиков, построенная на трех столпах: команда, программа и портфолио.SAFe разработан, чтобы дать команде гибкость и помочь справиться с некоторыми проблемами, с которыми сталкиваются крупные организации при применении agile.

  2012 – Дисциплинированная гибкая поставка

  DAD — это гибридная среда корпоративного уровня, разработанная Скоттом Амблером. «Discipline Agile Delivery (DAD) — это ориентированный на людей, ориентированный на обучение гибридный гибкий подход к доставке ИТ-решений. Он имеет жизненный цикл доставки с учетом риска, ориентирован на достижение цели, ориентирован на предприятия и масштабируем».

  2013 — Управляемая инфраструктура гибкой разработки

  Структура управляемой гибкой разработки — это гибридный подход Agile на уровне проекта, который впервые был определен Чаком Коббом в 2013 году в его книге «Управляемая гибкая разработка: заставить Agile работать для вашего бизнеса». подход к управлению с процессом разработки Agile.

  Общая сводка

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

  За все это время произошли существенные изменения; и, как и при любом значительном изменении, маятник часто качается взад-вперед, прежде чем остановиться на середине.

  Связанные статьи

  Ознакомьтесь со следующими статьями по теме «Понимание Agile»:

  Дополнительные ресурсы

  Ресурсы для онлайн-обучения по гибкому управлению проектами.

  Нравится:

  Нравится Загрузка…

  Откуда взялось «гибкое мышление»?

  Создавайте проекты вокруг целеустремленных людей.

  Предоставьте им среду и поддержку, в которых они

  нуждаются, и доверьте им выполнение работы.

  Эти идеи были подняты в книге по психологии

  компьютерного программирования, которая была

  опубликована в 1985 году; автор сочувствовал

  важности мотивации, которая является

  внутренней направляющей силой (chp10). Кроме того, он

  упомянул, что богатство среды

  придает ей самоподдерживающееся

  качество, которое сопротивляется навязанным

  изменениям. (chp4) [37]

  информация для и внутри команды разработчиков

  лицом к лицу

  разговор.

  Предыдущая книга была посвящена важности

  того, как рабочее пространство может повлиять на

  социальное взаимодействие, которое, в свою очередь,

  повлияет на работу. Автор подчеркнул, как

  общение лицом к лицу помогает передавать полезную

  информацию [37]

  Работающее программное обеспечение является основным мерилом

  прогресса.

  Второй принцип EVO: измеряйте добавленную

  ценность для пользователя по всем измерениям критериев

  [17]

  Гибкие процессы способствуют

  устойчивому развитию.Спонсоры, разработчики и пользователи

  должны иметь возможность поддерживать постоянный темп

  на неопределенный срок.

  В книге «Марш смерти» Эдвард Йордон

  указал на важность управления и

  контроля прогресса и предложил

  концепцию «ежедневной сборки» для достижения успеха в этой миссии

  [39]

  Постоянное внимание к техническому совершенству

  и хороший дизайн повышают маневренность.

  Вероятно, мы могли бы найти ту же идею о

  важности выполнения гораздо более качественной

  работы по программированию (техническое совершенство) в

  знаменитой статье Дейкстры «Скромный

  программист» [40]

  Простота — искусство максимизировать сумма

  невыполненной работы — необходима.

  Знаменитая поговорка о простоте конструкции

  принадлежит Антионе де Сент-Экзюпери:

  «Совершенство достигается не тогда, когда

  больше нечего добавить, а когда есть

  , нечего отнять». [30]

  Лучшие архитектуры, требования и

  проекты создаются самоорганизующимися командами.

  Мы могли найти идею самоорганизации

  команды в проектах с открытым исходным кодом, которые вышли

  примерно в то же время, что и методы Agile.В статье

  Собора и Базара Раймонд

  упомянул разработчиков, поскольку

  они приносят свои собственные ресурсы на стол [28]

  Через регулярные промежутки времени команда размышляет о том, как

  стать более эффективными, а затем настраивает, а

  соответствующим образом корректирует свое поведение.

  No related posts.