Фирма

«Инрэко ЛАН»

Как говорится, «всё новое – это хорошо забытое старое». :-) Так называемая «гибкая» (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;
  • иногда мы довольно успешно «боремся с заказчиками», любящими писать жёсткие ТЗ, посредством заключения рамочных договоров и написания «общесловесных» ТЗ (ОТЗ). :-)

Метки: agile | гибкая разработка | методологии разработки | разработка | управление

Добавить комментарий

Защитный код
Обновить