Методология Kanban. 
Создание автоматизированной системы создания и ведения адресных справочников и справочников объектов теплоснабжения

Методология Канбан (Kanban) является самой гибкой из методологий, представленных на обзор в данной дипломной работе. Основным принципом Канбана является минимизация количества выполняемой в данный момент времени работы. Достигается эта цель с помощью визуализации задач проекта посредством карточек, каждая из которых интерпретирует ту или иную задачу. Такие карточки располагаются на Канбан-доске, которая наглядно демонстрирует количество задач в проекте и их текущее состояние.

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

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

Цели проекта:

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

Очередь задач:

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

Проработка дизайна:

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

Разработка:

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

Тестирование:

В этом состоянии производится тестирование разработки. В случае если при тестировании были обнаружены ошибки, задача перемещается обратно в состояние «разработка».

Развертывание:

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

Закончено:

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

Неотложно:

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

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

Всю методологию Канбан можно описать всего тремя основными правилами:

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

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

Главными отличиями Канбан от Скрам являются:

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

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

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

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

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

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