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

Методологии разработки ПО:

• Тяжеловесные

• Гибкие

Гибкие методологии разработки ПО - гибкие (agile) или облегченные (lightweight) процессы – учитывают особенности современного заказчика, т.е. частые изменения его требований, привлекательны отсутствием бюрократизма. Необходима малочисленная группа высококвалифицированных разработчиков и грамотный заказчик, согласный участвовать в разработке.

Обзор и сравнительный анализ гибких методологий разработки ПО:

Канбан (организация поддержки);

Lean (оптимизация производства);

Экстремальное программирование ХР (инженерные практики);

Scrum (управленческий фреймворк).

В основе Канбан лежат три базисных принципа:

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

•   Ограничение максимального количества задач на определенном этапе. Этот принцип позволяет свести потери к минимуму - максимальное сосредоточение на своих задачах.

•   Оптимизация существующего процесса. Время на выполнение задачи отслеживается, анализируется, и вырабатываются предложения о том, как можно выполнить работу более совершенно. В процессе не должно быть простоев, равно как и не должна выполняться ненужная работа. Kanban характеризуется утверждением: "Уменьшение выполняющейся в данный момент работы". Данный тип методологии является, пожалуй, самым гибким. Это значит, что она является наиболее требовательной к условиям и ресурсам, в рамках которых предполагается ее эксплуатировать. Сотрудники, работающие по Канбан n, должны быть готовы к экстремальной гибкости и при этом не должны ломаться.

Уникальность методологии Канбан

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

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

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

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

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

Lean

Этот тип методологии подразумевает создание продукта в условиях максимальной экономии ресурсов с целью устранения всех возможных потерь. Изначальный функционал продукта ограничивается до минимально полезного. Таким образом, функционал реализуется путем поэтапного наращивания функционала небольшими порциями, сродни инкрементальному принципу реализации информационных систем. Корни этого подхода относятся к принципам бережливого производства (Lean Manufacturing). Мэри и Том Поппендик, о которых было упомянуто в "Введение в Agile" курса, адаптировали эти принципы для разработки программного обеспечения:

•   устранение потерь;

•   повышение качества;

•   создание знаний;

•   отсроченные обязательства;

•   быстрая поставка;

•   уважение людей;

•   полная оптимизация.

Lean постулирует отказ от всего, что не добавляет ценности создаваемой информационной системе. Разрабатывать необходимо только то, в чем есть абсолютная уверенность, что это нужно делать сейчас. Устранение потерь во всех аспектах работы (бесполезные собрания, избыточные задачи, документация, неэффективные способы работы и т. д.). Акцент на то, что называется "системным подходом", то есть сотрудники работают как единое целое, как команда. Необходимо верхнеуровневое осознание того, что выполняемая работа помогает повышать ценность создаваемого продукта, в сравнении с аналогами. Не нужно заставлять людей работать на 150% их рабочего времени. Не нужно кодировать то, что не нужно. Дополнительный функционал создает дополнительные обязательства для пользователей и руководства. Сотрудники нуждаются в уважении как личностном, так и профессиональном. Нужно давать им ту работу, которую они лучше всего знают, как надо сделать. Смысл программной разработки в постоянном обучении. Принятие управленческих решений нужно выполнять в последний возможный момент. К моменту реализации необходимого функционала сотрудники будут знать уже больше и лучше ориентироваться не только в создаваемой системе, но и в бизнес-процессах и данных организации.