Меню

Методологии SCRUM, Agile, Kanban для управления SAP проектами

|

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

Оглавление

Agile

Kanban

Scrum

Управление SAP проектами

Методологические разработки зарождались на проектах, выполняемых для военных организаций, где изначально программисты работали хаотично и зачастую срывались сроки сдачи функционала. Военные использовали свои внутренние регламенты для управления проектами. Благодаря этому впервые появилась методология водопада (Waterfall), по которой продукты делали сразу целиком. Этапы проекта характерные для методологии Waterfall:

 Идея → Техническое задание → Дизайн → Программирование → Тестирование → Релиз. Когда на этапе тестирования появлялась новая идея, приходилось игнорировать её или переделывать предыдущие этапы. Это было неэффективно — продукты или получались хуже, чем могли бы, или выбивались из сроков и бюджетов.

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

Agile

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

Agile Манифест — это документ, который определяет ценности Agile. Он содержит четыре фундаментальные идеи:

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

Принципы методологии, фокусирующие команду на нуждах и целях клиентов, они:

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

Kanban

Kanban — это метод улучшения процессов разработки и часть agile-философии. В его основе ― «Манифест гибкой разработки программного обеспечения».

Основные принципы этой методологии:

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

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

Kanban доска (Рис.1.) — это обязательный элемент для гибкой методологии. Она есть в Scrum (определение дано ниже), есть и в Kanban. Каждый член команды получает к ней доступ в любое время и видит, на каком этапе находится задача. Доска подойдёт и реальная, и виртуальная: можно использовать простую пробковую или программы (Trello, Jira).

У каждого проекта есть план процесса работ. План анализируется, и доска разделяется на столбцы, которые отражают этапы. Например, для процесса создания IT-проекта этапы могут быть такими:

Рисунок 1. Kanban-доска

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

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

Scrum

Scrum — методология итеративной разработки, определяющая несколько характеристик при работе с проектами:

  • Правила

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев8

Комментарий от  

Игорь Плужников

  |  24 декабря 2019, 12:33

Свежий взгляд это всегда хорошо! Поэтому прототипизация проекта - да. Маленькие компании - да. Гринфилд проекты - да, но зависит от размера. Глобальные компании - нет. Браунфилд проекты - скорее нет. В итоге все равно всё скатывается к ватерфольной модели

Комментарий от  

Иван Тюменьев

  |  24 декабря 2019, 16:57

Большое спасибо за статью. Уже не первый год внедряю скрам/канбан на проектах в SAP и не только. В статье, как мне кажется, упущена самые главные преимущества канбана/скрама над вотерфолом - это итеративность и инкрементальность процесса. То есть, что в каждый оговоренный срок (спринт) выдаётся работоспособный продукт, который далее улетает в продакшн и им начинают пользоваться конечные юзеры. Если этого не происходит и конечные пользователи получают продукт в конце проекта - то смысла намазывать какую-либо методологию нет. В этом и заключается основная ценность.
Ещё вы пишите про команды консультантов/программистов. Опять же команда сама по себе должна быть самодостаточной. Иначе остаются все те же самые проблемы вотерфола.
 
Из своего опыта добавлю, что скрам и его производные (Нексус, например) отлично подходят для проектов с нуля. Как и канбан, если у участников не полная занятость на проекте.
Канбан в свою очередь отлично ложится на отдел сопровождения уже готовых продуктов и на базисников.
 
Если вдруг появились вопросы - всегда рад проконсультировать лично (:

Комментарий от  

Олег Точенюк

  |  26 декабря 2019, 13:45

Свежий взгляд это всегда хорошо! Поэтому прототипизация проекта - да. Маленькие компании - да. Гринфилд проекты - да, но зависит от размера. Глобальные компании - нет. Браунфилд проекты - скорее нет. В итоге все равно всё скатывается к ватерфольной модели

Глобальные компании - нет - На сколько компания начинает быть глобальной, что для нее да переходит в нет?

Комментарий от  

Игорь Плужников

  |  26 декабря 2019, 16:48

Глобальные компании - нет - На сколько компания начинает быть глобальной, что для нее да переходит в нет?

Проблема в различных требоваяних регулирующих органов (законодательство, бух и налоговый учет) в каждой стране. Что хорошо для одних, может не работать для других. Хорошо если не работает, а если сломали то, что работало? Правильно сказали, для такой скорости внедрения команда должна быть самодостаточной. А представьте, что 3-4 команды параллельно работают на 3-4 разных страны над схожими задачами. Какова вероятность, что они что-то сломают друг другу? Или будут решать схожую задачу, но разными способами. Тут никак без синхронизации. А синхронизация это значительное увеличение команды внедрения и усложнение процессов, увеличение сроков из-за согласования. А что если ваша система объединяет 50 стран из них 10 стран в стадии разработки? Кто будет проверять решение на совместимость с другими 40 странами?

Комментарий от  

Олег Точенюк

  |  28 декабря 2019, 15:53

Проблема в различных требоваяних регулирующих органов (законодательство, бух и налоговый учет) в каждой стране. Что хорошо для одних, может не работать для других. Хорошо если не работает, а если сломали то, что работало? Правильно сказали, для такой скорости внедрения команда должна быть самодостаточной. А представьте, что 3-4 команды параллельно работают на 3-4 разных страны над схожими задачами. Какова вероятность, что они что-то сломают друг другу? Или будут решать схожую задачу, но разными способами. Тут никак без синхронизации. А синхронизация это значительное увеличение команды внедрения и усложнение процессов, увеличение сроков из-за согласования. А что если ваша система объединяет 50 стран из них 10 стран в стадии разработки? Кто будет проверять решение на совместимость с другими 40 странами?

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

Комментарий от  

Игорь Плужников

  |  28 декабря 2019, 16:09

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

какой вопрос, такой ответ

Комментарий от  

Олег Башкатов

  |  03 января 2020, 13:01

Екатерина, есть 2 вопроса:
1) Куда делись карточки 2 и 10 с рисунка 1 ? и в связи с этим: какие бы Вы порекомендовали подходы по оценке результативности (performance) спринта (или даже спринтов)? Delivery Team может взять 3 карточки и хорошо с ними справиться, но при этом быть загруженными на 10%. как оценивать, что спринт 1 лучше спринта 2 и в чем он лучше и что нужно улучшить?
 
2) почему на рисунке 2: тестирование предшествует настройке? что имелось ввиду под этапом "Настройка"?

Комментарий от  

Олег Точенюк

  |  11 января 2020, 13:09

какой вопрос, такой ответ

>>Маленькие компании - да.
 
Это вроде как ваш ответ, вот я и хотел бы уточнить, а то знаете ли маленький, большой это как-то странные параметры для оценки. Так что как бы какой ответ, такой вот и вопрос.