Логотип StingRay

Социальные сети
FacebookInstagramRSSTwitterYouTubeВ контактеОдноклассники
FacebookInstagramRSSTwitterYouTubeВ контактеОдноклассники
Силуэт человека

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

Как говорится, «всё новое – это хорошо забытое старое». :-) Так называемая «гибкая» (agile) разработка программного обеспечения (ПО) – это не какая-то принципиально новая методология, а всего лишь «новое дыхание» давно известных методологий. Есть несколько трактовок термина:

  • eXtreme Programming (XP), Scrum, Feature-Driven Development (FDD), методология Crystal Clear и т. п. в чистом виде – как эффективные методологии для разработки небольших систем;
  • компромисс между (ну или гибрид) RUP и XP – двумя крайностями («тяжёлой» и «лёгкой» методологиями);
  • придание большей гибкости «тяжёлым» методологиям вроде RUP или MSF посредством их подстройки.

В любом случае главная идея состоит именно в гибкости процесса разработки по отношению к текущим (постоянно изменяющимся) требованиям и условиям.

Манифест

Существует так называемый «Манифест о гибкой разработке ПО» (agilemanifesto.org), подписанный известными товарищами (Kent Beck, Martin Fowler, Alistair Cockburn и другими):

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

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

То есть, несмотря на то, что ценность есть и в правой части этих пунктов, мы больше ценим то, что слева [жирным]».

Принципы

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

Данные принципы тесно связаны с манифестом.

Варианты

Существует несколько вариантов «гибких» методологий разработки ПО:

Элементы

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

  • «кадры решают всё» (в том числе за счёт сознательности и самоорганизуемости), а не то, на чём пишут ПО;
  • главное – написать ПО, а не документировать его;
  • написанное ПО должно соответствовать текущим потребностям заказчика, а не когда-то написанному техническому заданию (ТЗ) на него;
  • для этого надо постоянно работать с заказчиком и часто показывать ему новые версии ПО;
  • наиболее эффективная форма взаимодействия как с заказчиком, так и внутри команды – личные встречи и устное общение.
  • архитектуру ПО надо стараться поддерживать в максимально простом и гибком виде, готовом к любым изменениям.

Применение

Мы в «Инрэко ЛАН» уже давно применяем гибкие методологии разработки в том или ином виде:

  • для небольших проектов мы используем BugTracker.NET – при всех его недостатках он является максимально гибким;
  • в своих проектах я активно практикую стимуляцию самоорганизации команды и самостоятельности её участников;
  • в рамках TFS нами был разработан шаблон жизненного цикла артефактов малого проекта именно на основе MSF for Agile;
  • иногда мы довольно успешно «боремся с заказчиками», любящими писать жёсткие ТЗ, посредством заключения рамочных договоров и написания «общесловесных» ТЗ (ОТЗ). :-)
Добавьте свой комментарий или войдите, чтобы подписаться/отписаться.
OpenId
Предпросмотр Улыбка Подмигивание Дразнит Оскал Смех Огорчение Сильное огорчение Шок Сумасшествие Равнодушие Молчание Крутизна Злость Бешенство Смущение Сожаление Влюблённость Ангел Демон Вопрос Восклицание Жирный Курсив Подчёркивание Зачёркивание Размер шрифта Гиперссылка Цитата
Загрузка…