Все фреймворки масштабирования процессов управления разработкой
Фреймворк для управления проектами — это набор инструментов, задач и процессов, используемых для организации и выполнения проекта от начала и до завершения. Фреймворк описывает все, что вам нужно для успешного планирования ваших проектов, контроля и управления ими.
Стандартный фреймворк для управления проектами можно разбить на три большие части:
- Жизненный цикл проекта. Ключевое различие между методологиями Waterfall и Agile заключается в том, что эти фреймворки включают в себя разные жизненные циклы. Например, фреймворк Waterfall состоит из пяти стандартных фаз:
- Подготовительный этап
- Планирование
- Исполнение
- Контроль
- Завершение
Фреймворк Agile скорее всего будет использовать модифицированный жизненный цикл, лучше отражающий гибкую и итеративную природу Agile-методологии.
-
Шаблоны, контрольные списки и другие инструменты. Фреймворк проекта содержит необходимую информацию для эффективного планирования проекта — от рекомендаций к задачам, действиям и ресурсам до черновой документации по проекту.
Цель фреймворка для управления проектами состоит в том, чтобы дать четкое и последовательное описание проекта, которое обеспечит надежное и повторяемое выполнение проектов разными командами и компаниями. Фреймоворки документируют и предоставляют в общий доступ лучшие рекомендации, и это выгодно всем. Также они помогают создавать единые стандарты в организациях и целых отраслях.
Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.
В чем разница между методологией и фреймворком?
Методология описывает принципы управления проектами, ценности и лучшие рекомендации, которые нужно соблюдать, в то время как фреймворк показывает способ соблюдения. Другими словами, методология объясняет вам, чего вы ходите добиться, а для фреймворка важно, как вы этого добьетесь.
Например, принципы Lean и Agile гласят, что жизненно необходимо реагировать на изменения. Но эти методологии не объясняют, как сделать так, чтобы ваши проекты хорошо реагировали на изменения — такая информация изложена во фреймворке.
Кто и зачем создал Nexus
В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.
Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.
Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.
В Nexus использованы итеративный и инкрементальный подходы к масштабированию процессов разработки ПО. Каждая команда работает в рамках своего спринта, а потом их результаты объединяются. За счет этого разработку продукта легче координировать.
Является ли бережливое управление проектами (Lean) Agile-фреймворком?
Хотя Lean часто вносят в список Agile-фреймворков, это отдельная методология. Lean и Agile часто группируют вместе, потому что их ценности во многом совпадают. Например, и для Lean, и для Agile важна способность легко адаптироваться к изменениям.
- Устранение потерь
- Повышение качества
- Создание знаний
- Отсроченные обязательства
- Быстрая поставка
- Уважение к людям
- Полная оптимизация
Б. Что общего у Agile-фреймоворков?
Agile-методология управления проектами — это подход к управлению проектами, использующий четыре главных ценности и 12 принципов организации проектов. Agile-фреймворки разработаны для поддержки этих ценностей и принципов.
Agile-процесс отличается от остальных подходов к управлению проектами, так как нацелен на итеративную разработку, гибкость, постоянную обратную связь и убеждение, что люди важнее процессов. Поэтому Agile-фреймворки должны строиться на основе этих базовых ценностей.
Хотя у каждого фреймворка есть свои уникальные аспекты, каждый из них помогает вам следовать основам управления проектами, чтобы довести проект до победного конца. Agile-фреймворки считаются более простыми в сравнении с традиционными фреймворками, поскольку сводят к минимуму объемы правил и документации. Но каждый Agile-фреймоворк должен включать в себя все важнейшие процессы и этапы проекта.
В. Фреймворк Scrum
Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.
Как и в случае других Agile-фреймворков, Scrum использует итеративный подход к управлению проектами. Методология Scrum предписывает разбить проект на спринты длительностью от одной до четырех недель. Каждый спринт заканчивается созданием работоспособной версии черновика продукта.
Короткие итерации, свойственные методологии Scrum, позволяют команде последовательно создавать работающий конечный продукт.
Scrum изначально разрабатывался с помощью программной модели, предусматривающей набор ролей и обязанностей и регулярные совещания. Он достаточно гибок, чтобы его можно было применить в ходе любого сложного проекта в любой отрасли, но лучше всего он подходит для случаев, когда в рамках проекта создается конкретный продукт, а не оказывается услуга.
Scrum считается достаточно простым и гибким, но его трудно освоить из-за трех главных ценностей:
- Прозрачность. Необходимо использовать общий язык и стандартные определения.
- Инспекция. Артефакты и продукты должны регулярно и тщательно проверяться для обеспечения качества.
- Адаптация. Если инспекция выявит качество ниже стандартного уровня, команда обязана как можно быстрее внести корректировки или исправления.
Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:
- Владелец продукта. Владелец продукта в ходе выполнения проекта — это человек, представляющий интересы клиента. Он имеет право решающего голоса в отношении конечного продукта. Задача владельца продукта заключается в том, чтобы обеспечить понимание требований, функционала и приоритетов, а также воплотить в жизнь все эти аспекты.
- Scrum-мастер. Scrum-мастер ответственен за организацию ежедневных совещаний, улучшение взаимодействия в команде и повышение продуктивности. Разница между менеджером проектов и Scrum-мастером состоит в том, что последний стремится быть лидером-служителем. Роль менеджера Agile-проекта часто включает в себя и обязанности Scrum-мастера. Однако он может делегировать эти обязанности участнику команды, который хорошо знает Scrum и обладает организаторскими способностями.
- Команда разработки. Команда разработки — это ваша проектная группа. Обычно это самоорганизующийся и межфункциональный коллектив. Команда включает в себя всех сотрудников, необходимых для проектирования, производства, тестирования и выпуска финального продукта.
- Scrum-команда. Scrum-команда состоит из команды разработки, Scrum-мастера и владельца продукта.
Scrum также имеет собственную уникальную терминологию. Далее приведены важнейшие термины, часто используемые при работе с фреймворком Scrum:
- Бэклог продукта. Бэклог — это список задач и требований, которые должны быть выполнены применительно к конечному продукту. За создание бэклога и управление им отвечает владелец продукта.
- Спринт. Спринт — это период времени для выполнения набора задач из бэклога. Длительность спринтов должна быть одинаковой. Обычно это две недели, хотя спринт может длиться от одной до четырех недель в зависимости от потребностей команды и проекта.
- Планирование бэклога. Планирование бэклога (иногда его еще называют планированием спринта) — это определение задач в бэклоге, которые нужно включить в каждый из спринтов.
- Бэклог спринта. Часть бэклога, назначенная текущему спринту.
- Ежедневный Scrum. Проектная группа встречается каждый день, чтобы обсудить ход работ за последние сутки, ожидаемый прогресс за следующие сутки и возникающие проблемы. Обычно такие встречи называются ежедневный Scrum или стендап и длятся около 15 минут.
- Ретроспектива. Каждый спринт должен заканчиваться обзорным совещанием, которое называется ретроспектива. Команда рассматривает свои достижения и обсуждает возможности что-то улучшить в ходе следующего спринта.
- Scrum-доска. Scrum-доска помогает участникам команды видеть бэклог спринта и управлять им. Доска может быть настоящей или виртуальным инструментом в системе управления проектами. Обычно на доске есть три столбца: «К исполнению», «В работе» и «Выполнено». По мере выполнения объектов из бэклога они перемещаются по доске из одного столбца в другой. Поэтому все видят, что им нужно делать в следующем спринте и как продвигается работа.
- Артефакт. Бэклог продукта, бэклог спринта и инкремент продукта — это три артефакта Scrum в проекте. Бэклог продукта и бэклог спринта отражают работу, которую нужно сделать, а инкремент продукта — это часть продукта, которую команда создала в ходе текущего спринта.
Б. Что общего у Agile-фреймоворков?
Agile-методология управления проектами — это подход к управлению проектами, использующий четыре главных ценности и 12 принципов организации проектов. Agile-фреймворки разработаны для поддержки этих ценностей и принципов.
Agile-процесс отличается от остальных подходов к управлению проектами, так как нацелен на итеративную разработку, гибкость, постоянную обратную связь и убеждение, что люди важнее процессов. Поэтому Agile-фреймворки должны строиться на основе этих базовых ценностей.
Хотя у каждого фреймворка есть свои уникальные аспекты, каждый из них помогает вам следовать основам управления проектами, чтобы довести проект до победного конца. Agile-фреймворки считаются более простыми в сравнении с традиционными фреймворками, поскольку сводят к минимуму объемы правил и документации. Но каждый Agile-фреймоворк должен включать в себя все важнейшие процессы и этапы проекта.
Компоненты Nexus
Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.
Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).
Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.
В Nexus, чтобы помочь с масштабированием методологии, появилась роль Nexus Integration Team (NIT). Это целая команда, в которую входят Product Owner, Scrum Master и представители скрам-команд. Их задача — оценить потенциальные проблемы командной разработки и предотвратить их. Важно отметить, что члены NIT не занимаются непосредственно программированием, а дают рекомендации по применению Scrum- и Nexus-принципов всем остальным участникам.
В целом внедрение NIT помогло улучшить координацию между командами за счет грамотного распределения задач. Однако участники ИТ-сообщества говорят, что новая роль также поспособствовала созданию своеобразного «бутылочного горлышка» — когда члены NIT решают организационные вопросы, команда разработки простаивает в ожидании инструкций.
Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).
В журнале пожеланий проекта перечислены общие требования к функциональности — так называемые пользовательские истории, отсортированные в порядке убывания важности. Они помогают получить представление о том, как должен выглядеть конечный продукт.
Журнал пожеланий спринта — список функций для реализации, выбранных владельцем продукта. На основе этого списка разработчики отслеживают задачи, которые нужно завершить до конца одного спринта.
В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.
События. Все члены команды ходят на собрания, которые иногда называют общим термином «события». «Свиньи» проводят их ежедневно, а «куры» — в начале и конце проекта или спринта. Собрания нужны, чтобы обсудить ход разработки, прикинуть планы, выявить узкие места.
Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:
- Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
- Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
- Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
- Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.
Г. Другие популярные Agile-методики управления проектами
Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:
1. Kanban
Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.
Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.
Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.
2. Экстремальное программирование (XP)
Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.
Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:
- Игра в планирование
- Частые небольшие релизы
- Приемочное тестирование клиентом
- Простота проектирования
- Парное программирование
- Разработка через тестирование
- Рефакторинг
- Непрерывная интеграция
- Коллективное владение кодом
- Стандарт оформления кода
- Метафора системы
- 40-часовая рабочая неделя для программистов
3. Функционально-ориентированная разработка (FDD)
Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.
Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:
- Разработка общей модели
- Составление списка необходимых функций системы
- Планирование работы над каждой функцией
- Проектирование функции
- Реализация функции
4. Метод разработки динамических систем (DSDM)
Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.
Этот фреймворк основан на восьми основных принципах:
- Фокус на потребностях бизнеса
- Своевременная поставка
- Сотрудничество
- Постоянно высокое качество
- Инкрементный подход на прочном фундаменте
- Итеративная разработка
- Постоянное и четкое взаимодействие
- Демонстрация контроля
5. Crystal
Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.
Когда стоит использовать Nexus
В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.
Тогда компания пригласила эксперта по Scrum, и он предложил перенести рабочую схему Scrum на многокомандный уровень — внедрить Nexus. Сейчас по Nexus-методологии работают уже шесть команд, которые стабильно выпускают новые релизы ПО каждые две недели.
Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.
Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.
Отметим, что хотя Nexus и помогает скоординировать работу множества команд разработки при работе над крупным проектом и ускорить выход релизов (как в случае с TPP), он все же не способен решить проблемы, связанные с внутренним устройством организации. К примеру, фреймворк не окажет заметного эффекта, если в командах будет не хватать специалистов для решения всех задач.
Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.
P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:
Ж. Бесплатные инструменты для управления Agile-проектами
Все, что вы используете для управления Agile-проектами, является Agile-инструментом для управления проектами. Самый простой пример — это доска со стикерами, но и многие сложные цифровые инструменты также позволяют работать с Agile-фреймворками, такими как Scrum и Kanban.
В этой, восемнадцатой статье из серии «Менеджмент цифрового мира» (оглавление) я буду рассказывать о фреймворках масштабирования Agile на большие подразделения или компанию в целом. Эту тему я уже начал в прошлой статье «Kanban и Lean - эволюция вместо революции»: Kanban также позволяет оркестровать работу в рамках компании, но он нем я здесь говорить больше не буду.
Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».
Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.
Большинство фреймворков, о которых я буду говорить, ориентированы на обеспечение только основной операционной работы компании. Однако, следует учитывать, что границы ответственности команд могут быть существенно различны. Достаточно распространенной является практика, когда в ответственность команд передается найм и увольнение сотрудников, их обучение, а также финансовая ответственность за создаваемый продукт, то есть команда становится независимым подразделением.
В других случаях HR остаются независимым подразделением, так же как бухгалтерия и юридическая служба, и тогда их работа может быть организована как сервисная инфраструктура для команд, работающая по Kanban или одним из гибридных Agile-методов. Сохранение традиционной организации тоже возможно, однако, важно обеспечить хорошее качество сервиса и не служить препятствием для движения команд основного операционного контура.
И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.
Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.
Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.
Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.
Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.
Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.
Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).
Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.
При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.
Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.
Однако, то что задача по реализации нового функционала делится на несколько, каждую из которых выполняет своя команда, сильно увеличивает количество необходимых синхронизаций и время разработки. Поэтому часто применяется и другой способ организации, кросс-функциональные команды, включающие специалистов по всем приложениям и делают все доработки для новой фичи. При этом возникает общее владение кодом, и надо дополнительно принимать меры для удержания целостности архитектуры каждого приложения, а также обучения и передачи опыта, потому что внутри команды такие специалисты не могут учиться. И это получается структура, похожая на клан в Spotify.
Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт компании ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал, как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам, и все это - за один год, и продолжая мониторинг производительности, чтобы не допустить деградации.
Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.
Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.
Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.
Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.
На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…
В современном мире технологии стремительно развиваются. Каждую минуту создаются новые сайты, приложения и разновидные программы. Для ускорения работы над проектами разработчики используют фреймворки.
Фреймворк — это программные продукты, которые упрощают создание и поддержку технически сложных либо нагруженных проектов. Он содержит только базовые программные модули, а все специфичные компоненты реализуются программистом на их основе. Таким образом достигается высокая скорость разработки.
На сегодняшний день существует большое количество фреймворков. Выбрать становится все тяжелее и тяжелее. Мы в Artjoker на протяжении многих лет разработки проверили на собственном опыте множество платформ. В конечном итоге для себя мы выбрали Laravel. Но мы не призываем прямо сейчас перестать поиски подходящего для себя фреймворка и начать пользоваться только этим. В этой статье мы рассмотрим объективно, какой фреймворк стоит выбрать в 2022 году и почему именно его.
Если бы фреймворков не существовало, то создание сайта длилось бы долго. А так он даёт возможность подключаться к различным типам СУБД без погружения в специфику организации инфраструктуры. В нем есть готовые решения для работы с файловой системой, инструменты для оптимизации и ускорения работы приложения.
Рассмотрим основные преимущества фреймворков:
- Простой процесс диагностики и отладки.
Повышенная эффективность кода.
Фреймворки также способствуют повторному использованию кода, что, в свою очередь, повышает его эффективность. Чтобы не писать сложные структуры, содержащие сотни строк кода с нуля, можно обратиться к базе платформы. Используя такой метод разработчик получает код, в котором легко внести изменения и применить дополнительные функции. Также можно создать собственный код, чтобы использовать его в последующих проектах.
Ускоренная разработка
Фреймворки содержат базовые программные модули, библиотеки, удобный интерфейс, гибкую среду кодирования и другие функции, которые упрощают работу. Разработчикам не нужно заботиться об обезличивании данных, управлении сессиями, обработке ошибок, аутентификации и т.д. Платформа отлично справляется с большинством из этих функций. Это позволяет программисту сразу начать писать код, не отвлекаясь на другие задачи.
Анализируя все преимущества можно сказать, что фреймворк выполняет большую часть работы. Например, разработчику не нужно задумываться над тем, как записать данные в файл, для этого просто достаточно вызвать метод, который решит эту задачу.
Какой фреймворк выбрать в 2022 году? Вопрос не из лёгких, ведь их количество увеличивается с каждым годом. На видео можно посмотреть, как менялись лидеры в течении последних девяти лет. В 2021 году топ 6 стали Laravel, Django, Flask, Express JS, Ruby on Rails и Spring. Рассмотрим каждый из них подробнее.
Laravel – это бесплатный PHP фреймворк общего назначения с открытым кодом. Платформа использует общие библиотеки с Symfony. Подходит для разработки веб-приложений, основанных на базе паттерна MVC, который разделяет данные и бизнес-логику от визуализации.Так как платформа имеет открытый исходный код, это предоставляет большие возможности для кастомизации, модификации и расширения приложений. Разработанное таким образом веб-приложение является более практичным и структурированным. В этом Laravel превосходит своих конкурентов.
Преимущества:
- Улучшенная производительность
- Мощное сообщество и открытый исходный код
- Легкое юнит-тестирование
- Простая разработка многоязычных приложений
- Быстрое время выхода продукта на рынок
Где используется:
Многие отрасли промышленности и бизнеса используют Laravel для разработки своих приложений. Благодаря своему широкому функционалу к нему обращаются отрасли, нуждающиеся в приложениях корпоративного уровня: банки, здравоохранение, индустрия развлечений, электронная коммерция. Также Laravel дает возможность разрабатывать платформы, где требуется обработка данных, большой трафик и сложность.
Приложения на Laravel обеспечивают более высокую производительность по сравнению с ресурсами, созданными с помощью других PHP фреймворков. Это возможно благодаря защите от SQL-инъекций, системе кэширования и встроенной системе очереди.
На сегодняшний день Laravel используют такие компании как 9GAG, BBC, Crowdcube, FedEx, Lenovo, Pfizer и другие.
Django — это бесплатный веб-фреймворк, подходящий для разработки сложных сайтов и веб-приложений, написанный на языке программирования Python и следует архитектурному шаблону MVC-MVT. Платформа реализована по принципу DRY — don’t repeat yourself. То есть, используя Django, нe нужно несколько раз переписывать один и тот же код. Он справляется с большим количеством поставленных задач и большими нагрузками.
Преимущества:
- Масса библиотек;
- Возможность масштабирования по мере необходимости;
- Мощный интерфейс автоматического администрирования, который можно использовать для управления содержимым веб-сайта;
- Многоязыковая поддержка, которая используется для перевода текста на разные языки.
Стоит помнить, что Django не поддерживает WebSockets, поэтому он плохо подходит для работы в реальном времени.
Где используется:
Django идеально подходит для быстрой разработки и для создания чистого и практичного дизайна. Большое количество библиотек позволяет разработчикам сосредоточиться на уникальных частях проекта, а не уделять время базовой функциональности.
Его применяют для создания коммуникационных платформ, сервисов бронирования номеров, платформ управления документооборотом, приложений с возможностью пользовательской настройки. Django можно использовать не только для написания сайтов с минимальным количеством кода, но и для разработки сложных систем. Например, систем управления отношениями с клиентами и контентом коммуникационных платформ.
Также Django подходит для создания алгоритмических генераторов, платформ для электронных рассылок, систем верификации, платформ для анализа данных и сложных вычислений, машинного обучения.
Flask — это микрофреймворк, разработанный на языке Python. Главной его особенностью является отсутствие инструментов и библиотек. В его основе используется шаблонизатор Jinja2 и набор инструментов Werkzeug. Тем не менее, Flask имеет базовый набор возможностей. Если требуется расширить перечень, то всегда можно установить дополнения. Платформа очень проста в использовании, поэтому подходит не только для профессионалов, а и для новичков тоже. В Flask нет шаблонного кода или зависимостей, которые могут отвлекать от основной функции приложения.
Преимущества:
- Предоставляет сервер разработки и отладчик
- Совместимость с Google App Engine
- Интегрированная поддержка модульного тестирования
- Использование Jinja2
- Совместим с WSGI 1.0.
- Поддержка безопасных файлов Cookie
- Большое количество расширений для улучшения функций
Где используется:
Flask используют для создания небольших проектов которые работают преимущественно со статическим контентом. Кроме этого, также подходит для создания микросервисов.
ExpressJS — простой и быстрый веб-фреймворк для приложений Node.js. Платформа предоставляет обширный набор функций для мобильных и веб-приложений. Является одним из самых мощных сервисных фреймворков. Основная особенность в том, что для него характерен небольшой объем базового функционала. Все остальные функции можно добирать с внешних модулей. ExpressJS используется в качестве промежуточного обработчика для управления серверами и маршрутами. Он подходит для разработки простых приложений, которые могут обрабатывать несколько запросов одновременно.
Преимущества:
- Простота и гибкость
- Ориентация на браузер
- Хорошая масштабируемость
- Широкий выбор подключаемых модулей
- Является частью стека MEAN, где он объединен с MongoDB, Angular и Node Js, что позволяет разрабатывать приложение от начала до конца.
ExpressJS больше всего подходит для:
- Начинающих разработчиков
- В проектах, где необходима долгосрочная поддержка приложений
- Больших проектов с кастомизацией
С платформой работают такие фирмы как Accenture, Fox Sports, IBM, Uber, Exove.
Ruby on Rails — это многоуровневый MVC-фреймворк для построения веб-приложений, написан на языке программирования Ruby. Является открытым программным обеспечением, то есть с открытым исходным кодом.
Стоит сказать, что эта платформа не для новичков. Чаще всего на языке Ruby работаю профессионалы, поэтому уровень программистов, которые выбрали Ruby on Rails, достаточно высок. Популярность платформы может быть обусловлена использованием системы подключаемых плагинов. Эти плагины с открытым исходным кодом называют «джемами». Они реализуют наиболее востребованные функции. Джемы бывают низкоуровневые и высокоуровневые. Первые отвечают за аспекты внутренней работы приложения, а вторые представляют из себя отдельные модули для решения целого спектра задач. Возможность подключать отдельные компоненты и библиотеки, которые хорошо протестированы и обеспечивают наилучшее решение, ускоряют процесс разработки в разы.
Преимущества:
- Экономическая эффективность благодаря множеству модулей, которые ускоряют разработку.
- По умолчанию Ruby on Rails установлен и включен с некоторыми мерами безопасности
- Возможность создания веб-приложения с использованием фронтенда и бэкенда.
- Легко сочетается с библиотеками сторонних программ.
- Помогает сохранить организованность и расшифровку проекта, так как разработчикам приходится следовать стандартным соглашениям по хранению файлов и программированию.
Ruby on Rails подходит как для разработки быстрых, обычных сайтов, которые нужно сделать отказоустойчивыми и работающих под большой нагрузкой, так и для веб-приложений со сложной бизнес-логикой и динамичным интерфейсом.
Spring — универсальный фреймворк с открытым исходным кодом для разработки Java-приложений. Платформа разработана как ответ на сложную спецификацию JEE 2, предлагая структуру, включающую такие технологии, как: аспектно-ориентированное программирование (AOP), внедрение зависимостей (DI), простой старый Java объект (POJO). Но, несмотря на такое количество технологий, Spring является легкой платформой, которую можно использовать для создания масштабируемых, безопасных и надежных корпоративных веб-приложений.
Преимущества:
- Возможность разработки приложения как набора слабосвязанных компонентов
- упрощение инициализации и настройки компонентов
- упрощение модульного тестирования
- упрощение разработки и поддержки приложения в целом.
- хорошее документирование, которое очень помогает при отладке приложения;
Мы в Artjoker уже 15 лет занимается разработкой. За это время мы попробовали много разных языков программирования и фреймворков. Прежде всего, наши разработчики искали такую платформу, которая будет содержать все необходимое для работы в одном месте. И для себя мы выбрали Laravel.
Laravel удобная среда разработки, так как у него обширная экосистема и большое комьюнити как англоязычное, так и русскоязычное. В чатах и форумах всегда можно найти ответы на тему возможностей фреймворка или по решению типовых задач. Также он позволяет закрывать большинство типового функционала сайта: регистрация, авторизация (как базовая, так и через соцсети), ролей пользователей, нотификации и т.п.
Создано уже более 50 000 пакетов с готовыми решениями, что значительно ускоряет и упрощает работу разработчика. Мне же остается сконцентрироваться только на особенностях проекта. Это способствует достаточно высокой скорости разработки.
Разработка на Laravel — быстрый выход на рынок
Для быстрой выдачи продукта на рынок Laravel использует модульную систему. То есть, платформа содержит множество готовых функций и структур, которые работают на базе передовых принципов PHP, тем самым сокращая время на разработку отзывчивых веб-приложений. Поскольку Laravel имеет открытый исходный код, разработчики все время совершенствую платформу, расширяя её функционал и создавая удобную среду для работы. Это ускоряет процесс разработки веб-приложений, делая Laravel быстрым и интуитивно понятным. C Laravel вы не тратите долгие часы и недели на написания нескольких строк кода. Фреймворк не только сделает вашу работу комфортной, а и поможет сэкономить время.
Авторизация и аутентификация в один клик
Laravel имеет простую и легкую систему аутентификации благодаря механизмам OAuth. Пользователи могут выполнить вход, регистрацию, сброс пароля и авторизоваться через различные сервисы. Laravel это делает с помощью всего лишь одной команды. Он также предоставляет простой способ организации логики авторизации и контроля доступа к ресурсам. А ещё имеет разнообразные драйвера для работы с email и рассылкой SMS уведомлений.
Архитектура MVC в Laravel Framework
Важным отличием Laravel от других PHP-фреймворков является то, что его архитектура основана на MVC. Это паттерн проектирования веб-приложений, который включает в себя несколько более мелких шаблонов. Концепция MVC состоит из трёх компонентов: модель — разделяет и изменяет данные, представление — отвечает за отображение информации (визуализацию), контроллер — обеспечивает связь между пользователем и системой. Такое разделение позволяет внести изменения в одном из компонентов, не меняя при этом два оставшиеся. Например, если мы внесём изменения во внешний вид, это ничего не изменит в бизнес-логике и наоборот. Наличие MVC значительно упрощает работу программиста и минимизирует количество новых багов из-за внесенных изменений.
Автоматизированное и модульное тестирование
Ещё одним из значительных преимуществ Laravel является его необычная система тестирования. Модульное тестирование позволяет проверить код и убедиться, что он работает правильно. Это неотъемлемый процесс при работе над веб-приложении. Чтобы убедиться, что все неполадки исправлены и приложение работает, Laravel обеспечивает поддержку автоматизированного тестирования. Во время интенсивного тестирования приложения система имитирует базовое поведение пользователей (например, выполнение запросов, анализ результатов, нажатие на формы). Функция модульного тестирования Laravel позволяет проверить каждый компонент или модуль приложения, чтобы убедиться, что все элементы в совокупности работают хорошо. В результате разработчик получает хорошо работающие веб-приложения с оптимизированным кодом.
Автоматизированное выполнение и планирование задач
Каждое веб-приложение нуждается в механизме планирования задач. Это может быть отправка писем подписчикам, уведомления пользователям или же очистка базы данных для ускорения работы приложения. Такая система планирования помогает в будущем автоматизировать их выполнение, когда это станет необходимо. Когда-то нужно было создавать запись конфигурации Cron для каждой задачи, которую нужно было запланировать на своём сервисе. Планировщик команд Laravel предлагает новый метод управления запланированными задачами на сервисе. Он позволяет быстро создавать и определять расписание команд в самом фреймворке.
Эта функция Laravel делает ваше веб-приложение высокопроизводительным и более быстрым, и вдобавок помогает вам сэкономить на стоимости хостинга.
Любой, кто начинает свою карьеру в качестве разработчика, наверняка сталкивался с проблемой выбора фреймворка. В индустрии разработки программного обеспечения доступно большое количество разновидных платформ. И как среди такого большого выбора найти подходящий?
Современные платформы имеют множество функций, которые позволяют разработчикам реализовать любые идеи. И при выборе стоит обращать внимание на особенности каждого из них.
Даже если мы сами написали код, возвращение к нему спустя некоторое время может быть трудным и важно, чтобы программа смогла нам упростить этот процесс. Выбирайте фреймворк с хорошей историей документации и обучения, так как это позволяет гораздо легче понять код и реализовать потенциал платформы в полной мере.
Не все фреймворки одинаковые и не все из них имеет одинаковые требования к работе. Не каждый нуждается в новейших элементах, чтобы хорошо выполнять поставленные задачи. Но вы должны, по крайней мере, убедиться, что интересующий вас фреймворк не работает на устаревших функциях. Это может привести к ошибкам в продуктах, что может плохо отразиться на вашем приложении, разработчиках и организации в глазах клиента.
Каждый фреймворк имеет свои преимущества. У одних богатый выбор библиотек, а у других хорошая документация. Но самым важным фактором при выборе есть то, чтобы фреймворк закрывал поставленные вами задачи. А если вы хотите найти многофункциональную платформу, которая сможет найти решение на каждый ваш вопрос, то Artjoker рекомендует Laravel.
В январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка
Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?
Ни один фреймворк не является универсальным, так что очень важно оценить отдельные проекты и потребности команды.
Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).
- Оцените объемы проекта. Большой длительный проект может быть трудно разбить на двухнедельные спринты. Но если его размах трудно определить и он может расти, то Agile, скорее всего, лучше подойдет, чем более традиционный фреймворк.
- Определите движущие факторы проекта. Очень важно знать экономическое обоснование проекта и его ценность для организации. Какие преимущества он даст вашей компании?
- Составьте представление о ключевых целях клиента, ожидаемых результатах и приоритетах проекта.
- Выявите все факторы, цели, результаты и приоритеты проекта, на которые могут повлиять различные методологии. Например, если ваша цель — максимальная экономичность, возможно, вам подойдет бережливая методология Lean. Если клиент рассчитывает получить подробную документацию, правильным выбором может стать FDD.
- Составьте список возможных методологий, подходящих для вашего проекта, и расставьте их по порядку на основе критериев, выявленных на прошлом этапе.
- Выбирайте фреймворк, подходящий для большинства факторов, целей, результатов и приоритетов. Если какие-то результаты важнее остальных, можете расставить приоритеты, чтобы не упустить самое важное. Вам нужно выбрать фреймворк, который даст наилучший результат с наименьшим риском.
- Выбрав фреймворк, отслеживайте его эффективность. Суть всех Agile-методологий заключается в гибкости и адаптивности. Если выбранная вами методология не дает желаемого результата, следует модифицировать или даже заменить ваш фреймворк.
Д. Определение эпика Agile
В Agile-методологии управления проектами эпики — это «крупные истории пользователей».
История пользователя по своей сути — это то, что пользователь хотел получить. В данном случае, это результаты, которые запросил ваш клиент. В идеале история пользователя достаточно компактна, чтобы уместить ее в один спринт. Допустим, вы работаете над книгой. Если бы вы могли уложить каждую главу в отдельный спринт, то каждая глава была бы историей пользователя.
Но что если на написание каждой главы потребовалось бы восемь недель? История пользователя оказалась бы слишком большой для одного спринта и считалась бы крупной историей или эпиком.
Для эпиков нет жестких ограничений по размеру. Все зависит от длительности спринтов у вашей команды и от потребностей проекта.
Еще один важный термин — это «тема». Тема — это набор историй пользователей, которые связаны между собой или могут быть отнесены к одной категории. Например, если вы планируете строить дом, то можете сгруппировать все электротехнические требования в одной теме, а требования к качеству строительных конструкций в другой.
История, эпик и тема — это термины, которые используют многие Agile-команды, чтобы упростить обсуждение и планирование бэклога продукта. В бэклоге продукта может оказаться требование, слишком масштабное, чтобы назначить его одному спринту, но если вы обозначите его как эпик, каждый участник поймет, что его нужно разбить на части, прежде чем помещать в бэклог спринта.
Точно так же группировка требований по темам может помочь вам запланировать бэклог спринта. Ведь собранные вместе условия может быть удобно выполнить в рамках одного спринта.
Управление проектами с использованием эпиков сводится к управлению бэклогом исполняемым образом. Это гарантирует, что требования будут достаточно компактными, чтобы их можно было выполнить в период от одной до четырех недель.
- Вы можете отслеживать крупные, нечетко определенные идеи в своем бэклоге. Можно записать требование как эпик, а затем изменить его по мере выполнения проекта.
- Вы можете установить иерархию для элементов вашего бэклога. Эпик остается в бэклоге в виде оригинальной идеи или требования. Связанные с ним истории пользователей отслеживают аспекты продукта, которые позволят это требование удовлетворить.
Однако команды могут запутаться в эпиках и историях и часто прилагают слишком много усилий для их оценки, отслеживания и уточнения.
Эпики задумывались как полезный инструмент группировки в вашем бэклоге, но если они создают для вас сложности, возможно, вам лучше обойтись без них.
Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.
Читайте также: