Методологии SCRUM, Agile, Kanban для управления 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
Ещё вы пишите про команды консультантов/программистов. Опять же команда сама по себе должна быть самодостаточной. Иначе остаются все те же самые проблемы вотерфола.
Из своего опыта добавлю, что скрам и его производные (Нексус, например) отлично подходят для проектов с нуля. Как и канбан, если у участников не полная занятость на проекте.
Канбан в свою очередь отлично ложится на отдел сопровождения уже готовых продуктов и на базисников.
Если вдруг появились вопросы - всегда рад проконсультировать лично (:
Комментарий от
Олег Точенюк
| 26 декабря 2019, 13:45
Игорь Плужников 24 декабря 2019, 12:33
Свежий взгляд это всегда хорошо! Поэтому прототипизация проекта - да. Маленькие компании - да. Гринфилд проекты - да, но зависит от размера. Глобальные компании - нет. Браунфилд проекты - скорее нет. В итоге все равно всё скатывается к ватерфольной модели
Комментарий от
Игорь Плужников
| 26 декабря 2019, 16:48
Олег Точенюк 26 декабря 2019, 13:45
Глобальные компании - нет - На сколько компания начинает быть глобальной, что для нее да переходит в нет?
Комментарий от
Олег Точенюк
| 28 декабря 2019, 15:53
Игорь Плужников 26 декабря 2019, 16:48
Проблема в различных требоваяних регулирующих органов (законодательство, бух и налоговый учет) в каждой стране. Что хорошо для одних, может не работать для других. Хорошо если не работает, а если сломали то, что работало? Правильно сказали, для такой скорости внедрения команда должна быть самодостаточной. А представьте, что 3-4 команды параллельно работают на 3-4 разных страны над схожими задачами. Какова вероятность, что они что-то сломают друг другу? Или будут решать схожую задачу, но разными способами. Тут никак без синхронизации. А синхронизация это значительное увеличение команды внедрения и усложнение процессов, увеличение сроков из-за согласования. А что если ваша система объединяет 50 стран из них 10 стран в стадии разработки? Кто будет проверять решение на совместимость с другими 40 странами?
Комментарий от
Игорь Плужников
| 28 декабря 2019, 16:09
Олег Точенюк 28 декабря 2019, 15:53
Хороший ответ. Можно я буду его приводить как пример ответа, который показывает, как можно ответить на то что не спрашивали?
Комментарий от
Олег Башкатов
| 03 января 2020, 13:01
1) Куда делись карточки 2 и 10 с рисунка 1 ? и в связи с этим: какие бы Вы порекомендовали подходы по оценке результативности (performance) спринта (или даже спринтов)? Delivery Team может взять 3 карточки и хорошо с ними справиться, но при этом быть загруженными на 10%. как оценивать, что спринт 1 лучше спринта 2 и в чем он лучше и что нужно улучшить?
2) почему на рисунке 2: тестирование предшествует настройке? что имелось ввиду под этапом "Настройка"?
Комментарий от
Олег Точенюк
| 11 января 2020, 13:09
Игорь Плужников 28 декабря 2019, 16:09
какой вопрос, такой ответ
Это вроде как ваш ответ, вот я и хотел бы уточнить, а то знаете ли маленький, большой это как-то странные параметры для оценки. Так что как бы какой ответ, такой вот и вопрос.