Адаптивная разработка ПО - Краткое руководство

Что такое Agile?

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

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

Agile Manifesto

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

Манифест Agile - это -

Мы открываем лучшие способы разработки программного обеспечения, занимаясь этим и помогая в этом другим. Благодаря этой работе мы пришли к выводу:

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

То есть, хотя предметы справа имеют ценность, мы больше ценим предметы слева.

Характеристики ловкости

Ниже приведены характеристики ловкости -

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

  • Это способствует совместной ответственности и подотчетности.

  • Облегчает эффективное общение и постоянное сотрудничество.

  • Командный подход позволяет избежать задержек и времени ожидания.

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

  • Совместная работа позволяет своевременно сочетать различные точки зрения при внедрении, исправлении дефектов и внесении изменений.

  • Прогресс постоянный, устойчивый и предсказуемый с упором на прозрачность.

Гибкие методологии

Ранние реализации Agile-методов включают Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature-Driven Development и Dynamic Systems Development Method (DSDM). Теперь они все вместе называются Agile-методологиями после того, как в 2001 году был опубликован Agile-манифест.

В этом руководстве мы изучим методологию Agile - Adaptive Software Development.

Что такое адаптивная разработка программного обеспечения?

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

Джим Хайсмит опубликовал книгу об адаптивной разработке программного обеспечения в 2000 году. По словам Хайсмита:

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

Модель жизненного цикла разработки программного обеспечения (SDLC) - это структура, которая описывает действия, выполняемые на каждом этапе проекта разработки программного обеспечения.

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

  • Requirements Gathering- Собраны требования к разрабатываемому программному обеспечению. Эти требования будут изложены на языке, понятном покупателю / пользователю. Рекомендуется использовать определенную для домена терминологию.

  • Analysis - Собранные требования анализируются с точки зрения реализации, и спецификации программного обеспечения составляются, чтобы охватить как функциональные, так и нефункциональные требования.

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

  • Construction - На этом этапе код разрабатывается, модульно тестируется, интегрируется, тестируется интеграция и создается сборка.

  • Testing- На этом этапе проводится функциональное тестирование созданного программного обеспечения. Это также включает тестирование нефункциональных требований.

Есть два подхода к выполнению этих действий:

  • Prescriptive - Модели SDLC, которые предоставят вам способы выполнения действий в установленном порядке, как это определено структурой.

  • Adaptive- Модели SDLC, которые дадут вам гибкость в выполнении действий, с определенными правилами, которые необходимо соблюдать. Гибкие методы в основном следуют этому подходу, и у каждого из них есть свои правила. Однако следование адаптивному или гибкому подходу не означает, что программное обеспечение разрабатывается без соблюдения какой-либо дисциплины. Это привело бы к хаосу.

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

Когда вы выбираете модель SDLC для своего проекта, вы должны понимать -

  • Контекст вашей организации
  • Ваш технологический контекст
  • Состав вашей команды
  • Ваш клиентский контекст

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

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

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

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

Модель водопада - сильные стороны

Сильные стороны модели Waterfall:

  • Легко понять, легко использовать.
  • Предоставляет структуру неопытной команде разработчиков.
  • Основные вехи хорошо изучены.
  • Устанавливает стабильность требований.
  • Идеально подходит для управленческого контроля (планирование, мониторинг, отчетность).
  • Хорошо работает, когда качество важнее стоимости или графика.

Модель водопада - недостатки

Слабые стороны или недостатки модели водопада:

  • Идеализированный - не соответствует действительности.

  • Нереалистично - нельзя ожидать точных требований в начале проекта.

  • Не отражает итеративный характер более распространенной исследовательской разработки.

  • Вносить изменения сложно и дорого.

  • Программное обеспечение поставляется только в конце проекта. В связи с этим -

    • Задерживает обнаружение серьезных дефектов.

    • Возможность доставки устаревших требований.

  • Значительные накладные расходы на управление, которые могут быть дорогостоящими для небольших команд и проектов.

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

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

  • Опыт кросс-функциональных команд не разделяется, поскольку каждый этап выполняется изолированно.

Когда использовать модель водопада?

Вы можете использовать модель водопада, если -

  • Требования хорошо известны.

  • Определение продукта стабильное.

  • Технология хорошо изучена.

  • Новая версия существующего продукта.

  • Перенос существующего продукта на новую платформу.

  • Крупная организация со структурированными кросс-функциональными командами.

  • Каналы связи хорошо налажены внутри организации, а также с клиентами.

Модель эволюционного прототипирования

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

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

Модель эволюционного прототипирования - сильные стороны

Сильные стороны или преимущества модели эволюционного прототипирования:

  • Заказчики / конечные пользователи могут визуализировать системные требования по мере их сбора, глядя на прототип.

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

  • Обеспечивает гибкий дизайн и разработку.

  • Взаимодействие с прототипом стимулирует осознание дополнительных необходимых функций.

  • Неожиданные требования и изменения требований легко приспосабливаются.

  • Появляются устойчивые и видимые признаки прогресса.

  • Поставка точного и обслуживаемого конечного продукта.

Модель эволюционного прототипирования - слабые стороны

Слабые стороны или недостатки модели эволюционного прототипирования следующие:

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

  • Эта модель получила плохую репутацию за быстрые методы работы.

  • В целом ремонтопригодность может быть упущена из виду.

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

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

Когда использовать модель эволюционного прототипирования?

Вы можете использовать модель эволюционного прототипирования -

  • Когда требования нестабильны или требуют уточнения
  • Как этап уточнения требований к модели водопада
  • Разработать пользовательские интерфейсы
  • Для недолговечных демонстраций
  • Для новых или оригинальных разработок
  • Для внедрения новой технологии

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

Итеративная инкрементная модель - сильные стороны

Преимущества и сильные стороны итеративной инкрементальной модели:

  • Сначала вы можете разработать приоритетные требования.

  • Первоначальная доставка продукта происходит быстрее.

  • Заказчики получают важные функции на раннем этапе.

  • Снижает начальную стоимость доставки.

  • Каждый выпуск представляет собой приращение продукта, поэтому у клиента всегда будет под рукой рабочий продукт.

  • Заказчик может предоставить обратную связь по каждому приращению продукта, избегая таким образом сюрпризов в конце разработки.

  • Изменения требований могут быть легко адаптированы.

Итеративная инкрементная модель - недостатки

Недостатки итеративной инкрементальной модели:

  • Требуется эффективное планирование итераций.

  • Требуется эффективный дизайн для обеспечения включения необходимых функций и возможности внесения изменений в будущем.

  • Требуется раннее определение полной и полностью функциональной системы, чтобы можно было определять приращения.

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

  • Общая стоимость всей системы не ниже.

Когда использовать итеративную инкрементную модель?

Итеративная инкрементная модель может использоваться, когда -

  • Большинство требований известно заранее, но ожидается, что со временем они будут развиваться.

  • Требования являются приоритетными.

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

  • У проекта длинные графики разработки.

  • В проекте есть новая технология.

  • Домен является новым для команды.

Модель быстрой разработки приложений (RAD) состоит из следующих этапов:

  • Requirements Planning phase - На этапе планирования требований необходимо провести семинар для структурированного обсуждения бизнес-проблем.

  • User Description phase - На этапе описания пользователя используются автоматизированные инструменты для сбора информации от пользователей.

  • Construction phase - На этапе построения инструменты повышения производительности, такие как генераторы кода, генераторы экранов и т. Д., Используются внутри временного интервала с подходом «Сделать до завершения».

  • Cut Over phase - На этапе перехода выполняется установка системы, приемочное тестирование и обучение пользователей.

Модель быстрой разработки приложений - сильные стороны

Преимущества или сильные стороны модели быстрой разработки приложений заключаются в следующем:

  • Сокращение времени цикла и повышение производительности с меньшим количеством членов команды означало бы снижение затрат.

  • Вовлеченность клиента на протяжении всего цикла сводит к минимуму риск недостижения требований клиента и ценности для бизнеса.

  • Фокус переместится на код в режиме «что видишь, то и получаешь» (WYSIWYG). Это вносит ясность в то, что строится правильно.

  • Использует концепции моделирования для сбора информации о бизнесе, данных и процессах.

Модель быстрой разработки приложений - недостатки

Недостатки или сильные стороны модели быстрой разработки приложений следующие:

  • Ускоренный процесс разработки должен давать быстрые ответы пользователю.

  • Риск никогда не закрыть.

  • Трудно использовать с устаревшими системами.

  • Разработчики и заказчики должны стремиться к быстрой работе в сокращенные сроки.

Когда использовать модель быстрой разработки приложений?

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

  • Пользователь может участвовать на протяжении всего жизненного цикла.
  • Проект может быть ограничен по времени.
  • Функциональность может предоставляться поэтапно.

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

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

Спиральная модель имеет четыре квадранта. Обсудим их подробнее.

Квадрант 1 - Определение целей, альтернатив и ограничений

  • Objectives - Функциональность, производительность, аппаратный / программный интерфейс, критические факторы успеха и т. Д.

  • Alternatives - Сборка, повторное использование, покупка, субподряд и т. Д.

  • Constraints - Стоимость, расписание, интерфейс и др.

Квадрант 2 - Оценка альтернатив, выявление и устранение рисков

  • Изучите альтернативы, связанные с определенными целями и ограничениями.

  • Определите риски, такие как отсутствие опыта, новые технологии, сжатые графики и т. Д.

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

Квадрант 3 - Разработка продукта следующего уровня

Типичные виды деятельности включают -

  • Создать дизайн
  • Обзор дизайна
  • Разработать код
  • Проверить код
  • Тестовый продукт

Квадрант 4 - Планирование следующего этапа

Типичные виды деятельности включают -

  • Разработать план проекта
  • Разработайте план управления конфигурацией
  • Разработайте план тестирования
  • Разработайте план установки

Спиральная модель - сильные стороны

Преимущества или сильные стороны метода спирали:

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

Спиральная модель - слабые стороны

Недостатки или недостатки метода спирали:

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

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

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

  • Новым членам команды сложно понять спиральную модель.

  • Требуется экспертиза оценки рисков.

  • Спираль может продолжаться бесконечно.

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

Когда использовать спиральную модель?

Модель Spiral может использоваться, когда -

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

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

  • Командное сотрудничество.
  • Сотрудничество с клиентами.
  • Постоянное и непрерывное общение.
  • Реакция на изменения.
  • Готовность рабочего продукта.

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

Гибкие методы - сильные стороны

Преимущества или сильные стороны Agile-метода:

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

Гибкие методы - недостатки

Недостатки или недостатки метода спирали:

  • Доступность клиента может быть невозможна.

  • Команды должны быть опытными, чтобы следовать правилам метода.

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

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

  • Команда должна обладать эффективными коммуникативными навыками.

  • Новые команды могут быть не в состоянии организовать себя.

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

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

Когда использовать гибкие методы?

Методы Agile можно использовать, когда:

  • Приложение критично по времени.

  • Объем ограничен и менее формален (ведется масштабирование гибких методов для более крупных проектов, с некоторыми расширениями некоторых гибких методов).

  • Организация использует дисциплинированные методы.

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

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

По словам Джима Хайсмита, «среда адаптивной разработки программного обеспечения основана на многолетнем опыте использования традиционных методологий разработки программного обеспечения, консультировании, практике и написании статей о методах быстрой разработки приложений (RAD), а также работе с высокотехнологичными компаниями-разработчиками программного обеспечения над управлением разработкой их продуктов. практики ».

Было обнаружено, что модель водопада характеризуется линейностью и предсказуемостью, а также скудной обратной связью. Его можно рассматривать как последовательностьPlan → Build → Implement.

Модели эволюционного жизненного цикла, такие как спиральная модель, переместили детерминированный подход в адаптивный, с Plan → Build → Revise Cycles.

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

Адаптивный жизненный цикл

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

Адаптивное развитие идет дальше своего эволюционного наследия по двум ключевым направлениям:

  • Он явно заменяет детерминизм на эмерджентность.

  • Это не только изменение жизненного цикла, но и более глубокое изменение стиля управления.

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

  • Speculate - Speculate заменяет детерминированное слово «планирование», «планирование спецификаций продукта» или «планирование задач управления проектом».

  • Collaborate - Collaborate представляет собой баланс между

    • Управление в традиционном смысле управления проектами, и

    • Создание и поддержание совместной среды, необходимой для появления.

  • Совместная деятельность позволяет создавать продукты, не отставая от изменений в окружающей среде.

  • Learn - Learn направлен как на разработчиков, так и на клиентов, использовать результаты каждого цикла разработки, чтобы узнать направление следующего.

В этой главе мы поймем различные концепции адаптивной разработки программного обеспечения.

Теория сложных адаптивных систем (CAS)

Брайан Артур и его коллеги из института Санта-Фе использовали теорию сложных адаптивных систем (CAS), чтобы произвести революцию в понимании физики, биологии, эволюции и экономики.

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

Эти два мира различаются по поведению, стилю и культуре. Они призывают -

  • Различные методы управления
  • Различные стратегии
  • Различное понимание

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

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

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

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

Для решения проблем этого второго мира Джиг Хайсмит предложил структуру, адаптивную разработку программного обеспечения, которая отличается от детерминированной разработки программного обеспечения.

Адаптивная разработка программного обеспечения фокусируется на решении сложных систем -

  • Адаптивная разработка программного обеспечения для жизненного цикла разработки.

  • Методы адаптивного управления, требующие отличного от традиционных методов управления проектами мышления.

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

Адаптивная разработка программного обеспечения (ASD) основана на двух точках зрения:

  • Концептуальная перспектива, основанная на теории сложных адаптивных систем (CAS), изложенная в первом разделе этой главы.

  • Практическая перспектива на основе

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

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

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

Концепции сложных адаптивных систем (CAS)

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

  • Emergence
  • Complexity

Возникновение

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

Это может произойти в результате появления, как показано в теории сложных адаптивных систем (CAS). Это можно понять на простом примере стайного поведения птиц.

Когда вы наблюдаете стаю птиц, вы замечаете, что -

  • Каждая птица пытается

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

    • Сопоставьте скорости с птицами в окрестностях.

    • Двигайтесь к воспринимаемому центру масс птиц по соседству.

  • Для группы нет правил поведения. Единственные правила касаются поведения отдельных птиц.

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

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

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

Сложность

В контексте разработки программного обеспечения сложность означает -

  • Отдельные лица команды, такие как разработчики, клиенты, поставщики, конкуренты и акционеры, их количество и скорость.

  • Размер и технологическая сложность.

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

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

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

Качественный

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

Практика RAD

Практика RAD обычно включает комбинацию следующего:

  • Эволюционный жизненный цикл
  • Фокус-группы для клиентов, сессии JAD, технические обзоры
  • Ограниченное по времени управление проектом
  • Непрерывная разработка программного обеспечения
  • Выделенные команды с боевыми комнатами

У проектов RAD есть неотъемлемый адаптивный, эмерджентный вкус. Многие ИТ-организации выступают против RAD. Однако Microsoft и другие разработали невероятно большое и сложное программное обеспечение, используя методы, сравнимые с RAD, потому что это вызывает вопросы об их фундаментальном мировоззрении.

Практики RAD и процесс Microsoft являются примерами адаптивной разработки в действии. Присвоение им ярлыка (например, «Адаптивное развитие») и осознание того, что объем научных знаний (например, теории CAS) растет, объясняет, почему они работают. Это должно обеспечить основу для более широкого использования этих практик.

Адаптивная разработка программного обеспечения произошла от практики RAD. К этим практикам также были добавлены командные аспекты. Компании от Новой Зеландии до Канады для широкого спектра проектов и типов продуктов использовали адаптивную разработку программного обеспечения.

Джим Хайсмит опубликовал книгу «Адаптивная разработка программного обеспечения» в 2000 году.

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

Фазы жизненного цикла РАС

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

  • Speculate
  • Collaborate
  • Learn

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

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

Размышлять

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

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

Сотрудничать

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

Сотрудничество потребует способности работать совместно для получения результатов, обмена знаниями или принятия решений.

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

Учиться

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

  • Технические обзоры
  • Ретроспективы проекта
  • Группы поддержки клиентов

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

  • Об изменениях в продукте

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

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

Спекулировать - Сотрудничать - Изучать цикл в целом

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

Мы наблюдаем следующее из адаптивного фреймворка.

  • Трудно сотрудничать без обучения или учиться без сотрудничества.

  • Трудно рассуждать без обучения или учиться без размышлений.

  • Трудно спекулировать без сотрудничества или сотрудничать без спекуляции.

Жизненный цикл адаптивной разработки программного обеспечения имеет шесть основных характеристик:

  • Миссия сосредоточена
  • На основе функций
  • Iterative
  • Time-boxed
  • Управляемый рисками
  • Толерантный к изменениям

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

Ориентированный на миссию

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

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

На основе функций

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

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

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

Итеративный

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

Ограниченный по времени

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

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

Риск-ориентированный

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

Толерантный к изменениям

Адаптивная разработка программного обеспечения толерантна к изменениям, рассматривая изменения как возможность использовать конкурентное преимущество, а не как проблему для разработки.

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

Жизненный цикл адаптивной разработки программного обеспечения посвящен -

  • Непрерывное обучение
  • Изменить ориентацию
  • Re-evaluation
  • Вглядываясь в неопределенное будущее
  • Интенсивное сотрудничество между разработчиками, руководством и клиентами

Адаптивный SDLC

Адаптивная разработка программного обеспечения сочетает в себе RAD с передовыми методами разработки программного обеспечения, такими как:

  • Запуск проекта.
  • Адаптивное планирование цикла.
  • Параллельная разработка компонентов.
  • Проверка качества.
  • Окончательный контроль качества и выпуск.

Практики адаптивной разработки программного обеспечения можно проиллюстрировать следующим образом:

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

  • Спекулировать - Инициирование и планирование

    • Инициирование проекта

    • Установление временных рамок для всего проекта

    • Определите количество итераций и назначьте для каждой временной интервал.

    • Разработайте тему или цель для каждой итерации

    • Назначьте функции каждой итерации

  • Collaborate - Параллельная разработка функций

    • Сотрудничество для распределенных команд

    • Сотрудничество для небольших проектов

    • Сотрудничество для больших проектов

  • Learn - Обзор качества

    • Качество результата с точки зрения клиента

    • Качество результата с технической точки зрения

    • Функционирование группы доставки и ее участники используют

    • Статус проекта

Спекулировать - Инициирование и планирование

В адаптивной разработке программного обеспечения фаза размышлений включает два действия:

  • Initiation
  • Planning

В Speculate есть пять практик, которые можно многократно выполнять на этапе инициации и планирования. Они -

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

Инициирование проекта

Инициирование проекта включает -

  • Определение миссии и целей проекта
  • Понимание ограничений
  • Создание проектной организации
  • Выявление и описание требований
  • Выполнение первоначальных оценок размера и объема
  • Выявление ключевых рисков проекта

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

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

Установление временных рамок для всего проекта

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

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

Итерации и тайм-бокс

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

Для приложений малого и среднего размера -

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

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

Разработайте тему или цель

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

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

Назначить функции

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

Во время присвоения характеристик итерациям -

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

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

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

Совместная работа ─ Параллельная разработка функций

На этапе совместной работы основное внимание уделяется разработке. Этап совместной работы включает два действия:

  • Команда разработчиков сотрудничает и поставляет работающее программное обеспечение.

  • Руководители проектов способствуют сотрудничеству и параллельной разработке.

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

Команды должны сотрудничать:

  • Технические проблемы
  • Бизнес-требования
  • Быстрое принятие решения

Ниже приведены практики, относящиеся к этапу совместной работы в разработке адаптивного программного обеспечения.

  • Сотрудничество для распределенных команд
  • Сотрудничество для небольших проектов
  • Сотрудничество для больших проектов

Сотрудничество для распределенных команд

В проектах с участием распределенных команд следует учитывать следующее:

  • Различные партнеры по альянсу
  • Широкие знания
  • Как люди взаимодействуют
  • Как они управляют взаимозависимостями

Сотрудничество для небольших проектов

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

Сотрудничество для более крупных проектов

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

Учитесь - проверка качества

Адаптивная разработка программного обеспечения поощряет концепцию «экспериментируй и учись».

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

  • Найдите ошибки
  • Учитесь у них
  • Сократите количество переделок, найдя мелкие проблемы до того, как они перерастут в большие

В конце каждой итерации разработки есть четыре общие категории вещей, которые нужно изучить:

  • Качество результата с точки зрения клиента
  • Качество результата с технической точки зрения
  • Функционирование группы доставки и группы практик
  • Статус проекта

Качество результата с точки зрения клиента

В проектах адаптивной разработки программного обеспечения получение обратной связи от клиентов является первым приоритетом. Рекомендуемая практика для этого - фокус-группа на потребителе. Эти сеансы предназначены для изучения рабочей модели приложения и записи запросов клиентов на изменение.

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

Качество результата с технической точки зрения

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

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

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

  • Определите, что не работает.
  • Что команде нужно делать больше.
  • Что команде нужно делать меньше.

Статус проекта

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

Обзор статуса проекта должен включать:

  • Где проект?
  • Где проект по сравнению с планами?
  • Где должен быть проект?

Поскольку планы в проектах по разработке адаптивного программного обеспечения являются спекулятивными, важнее, чем вопрос 2 выше, вопрос 3. То есть проектная группа и заказчики должны постоянно спрашивать себя: «Что мы узнали на данный момент, и меняет ли это нашу точку зрения на то, куда нам нужно двигаться?»

Блок-схема традиционного управления программным обеспечением показана ниже.

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

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

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

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

Адаптивное управление

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

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

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

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

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

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

Адаптивное управление помогает изменить принимаемые решения, давая понять, что:

  • Решения временные.
  • Решение руководства не всегда должно быть правильным.
  • Ожидаются доработки.

Существует два типа подходов к адаптивному управлению:

  • Пассивное адаптивное управление.
  • Активное адаптивное управление.

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

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

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

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

Активное адаптивное управление

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

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

Лидерство и управление совместной работой

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

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

Лидеры обладают следующими качествами -

  • Возьмитесь и задайте направление.

  • Влияйте на вовлеченных людей и дайте им рекомендации.

  • Сотрудничайте, помогайте и управляйте командой на макроуровне.

  • Укажите направление.

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

  • Поймите, что иногда им нужно командовать, но это не их основной стиль.