Адаптивная разработка ПО — Введение

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

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

Agile Manifesto

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

Agile Manifesto — это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile методологии

Ранние реализации Agile-методов включают Rational Unified Process, Scrum, Crystal Clear, экстремальное программирование, адаптивную разработку программного обеспечения, функционально-ориентированную разработку и метод разработки динамических систем (DSDM). Теперь они все вместе называются Agile-методологиями, после того как Agile-манифест был опубликован в 2001 году.

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

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

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

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

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

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

Модели SDLC — Эволюция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SDLC — модель водопада

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

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

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

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

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

Модель водопада — Слабые стороны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программное обеспечение поставляется только в конце проекта. Благодаря этому —

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

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

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

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

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

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

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

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

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

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

• Технология хорошо понятна.

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

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

• Большая организация со структурированными межфункциональными командами.

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

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

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

Технология хорошо понятна.

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

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

Большая организация со структурированными межфункциональными командами.

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

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

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

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

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

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

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

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

• Позволяет гибкий дизайн и развитие.

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

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

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

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

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

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

Позволяет гибкий дизайн и развитие.

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

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

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

Доставка точного и ремонтопригодного конечного продукта.

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

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

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

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

• Общая ремонтопригодность может быть упущена.

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

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

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

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

Общая ремонтопригодность может быть упущена.

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

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

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

Вы можете использовать модель Evolutionary Prototyping —

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

SDLC — итерационная инкрементальная модель

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

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

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

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

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

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

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

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

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

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

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

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

Клиенты получают важные функциональные возможности рано.

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

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

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

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

Итерационная Инкрементальная Модель — Слабые стороны

Недостатками Итеративной инкрементальной модели являются —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Проект имеет длительные графики развития.

• Проект имеет новые технологии.

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

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

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

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

Проект имеет длительные графики развития.

Проект имеет новые технологии.

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

SDLC — модель быстрой разработки приложений

Модель быстрой разработки приложений (RAD) имеет следующие фазы —

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

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

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

• Фаза перехода — На этапе резки выполняется установка системы, приемочное тестирование пользователя и обучение пользователя.

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

Фаза описания пользователя — На этапе описания пользователя используются автоматизированные инструменты для сбора информации от пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработчики и заказчики должны быть преданы делу быстрого запуска в сокращенные сроки.

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

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

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

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

SDLC — спиральная модель

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

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

Квадрант 1 — Определить цели, альтернативы и ограничения

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

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

• Ограничения — стоимость, график, интерфейс и т. Д.

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

Альтернативы — Создание, повторное использование, покупка, субподряд и т. Д.

Ограничения — стоимость, график, интерфейс и т. Д.

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

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

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

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

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

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

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

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

Типичные мероприятия включают в себя —

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

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

Типичные мероприятия включают в себя —

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

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

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

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

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

Недостатками или недостатками спирального метода являются —

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

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

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

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

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

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

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

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

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

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

Спиральная модель сложна для понимания новыми членами команды.

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

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

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

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

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

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

SDLC — Agile Методы

Agile Методы основаны на Agile манифесте и являются адаптивными по своей природе. Agile методы обеспечивают —

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

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

Agile Методы — Сильные стороны

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

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

Agile Методы — Слабые стороны

Недостатками или недостатками спирального метода являются —

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

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

• Соответствующее планирование требуется, чтобы быстро принять решение о функциональности, которая должна быть предоставлена ​​в итерации.

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

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

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

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

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

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

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

Соответствующее планирование требуется, чтобы быстро принять решение о функциональности, которая должна быть предоставлена ​​в итерации.

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

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

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

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

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

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

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

• Приложение срочно.

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

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

Приложение срочно.

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

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

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

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

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

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

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

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

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

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

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

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

• Он явно заменяет детерминизм появлением.

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

Он явно заменяет детерминизм появлением.

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

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

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

• Сотрудничать — Сотрудничать представляет собой баланс между

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

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

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

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

Спекуляция — Спекуляция заменяет детерминированное планирование слова, планирование спецификаций продукта или планирование задач управления проектом.

Сотрудничать — Сотрудничать представляет собой баланс между

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One World представлен детерминистическим развитием, основанным на методах управления, основанных на принципах стабильности и предсказуемости (что в терминах Артура означает уменьшение прибыли)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• появление
• сложность

появление

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

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

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

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

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

  • Сопоставьте скорости с птицами по соседству.

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

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

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

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

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

Сопоставьте скорости с птицами по соседству.

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

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

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

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

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

сложность

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

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

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

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

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

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

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

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

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

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

RAD Практики

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

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

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

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

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

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

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

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

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

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

• спекулировать
• сотрудничать
• Учить

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

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

спекулировать

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

В Adaptive Software Development термин «план» заменяется термином «спекуляция». Размышляя, команда не отказывается от планирования, но признает реальность неопределенности в сложных проблемах. Спекуляция поощряет исследования и эксперименты. Итерации с короткими циклами приветствуются.

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

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

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

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

Учить

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

• Технические обзоры
• Ретроспективы проекта
• Фокус-группы клиентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристики жизненного цикла

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

• Миссия сосредоточена
• Функциональный
• итеративный
• Время в штучной упаковке
• Риск
• Изменить толерантный

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

Миссия-ориентированная

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

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

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

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

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

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

итеративный

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

Время в штучной упаковке

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

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

Риск-привод

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

Изменение толерантных

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

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

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

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

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

Адаптивный SDLC

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

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

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

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

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

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

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

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

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

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

• Совместная работа — разработка параллельных функций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совместная работа — разработка параллельных функций

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

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

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

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

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

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

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

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

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

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

• инициирование
• планирование

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

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

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

Инициирование проекта включает в себя —

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

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

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

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

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

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

Итерации и время

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

Для малых и средних приложений —

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

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

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

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

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

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

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

Во время назначения функций для итераций —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adaptive S / W Development — Управление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует два типа подходов адаптивного управления —

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

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

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

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

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

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

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

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

Лидерство-Управление Сотрудничеством

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

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

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

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

Влиять на вовлеченных людей и давать указания.

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

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

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

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