Гибкие Фреймворки управления проектами
Выбери формат для чтения
Загружаем конспект в формате docx
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Лекция Гибкие фрейворки управления проектами
Как уже было отмечено в предыдущей лекции методика управления проектами — это уже готовый алгоритм применения методов, часто их называют фреймворки. Внедрение гибких методик позволяет руководству компании повысить заинтересованность и мотивацию сотрудников, а также ускорить доставку продукта заказчику. Agile, помимо Kanban и Lean, включает в себя такие практики, подходы и методологии, которые помогают создавать продукт более эффективно, например1:
• экстремальное программирование (Extreme Programming, XP);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистои комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
В данной лекции мы рассмотрим подробнее две наиболее популярных методики Scrum и Kanban.
Scrum появился в 1986 году как способ «наладить взаимодействие нескольких команд, работающих ради единой цели». К разработке продукции этот термин впервые применили в 1980-х годах два японца — Хиротака Такэути и Икудзиро Нонака. Scrum сочетает в себе идеи традиционного проектного управления и Agile, являясь одновременно структурированным и гибким способом управления проектами. Современный Scrum создан двумя айтишниками — Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Основные категории Scrum – это команда, события, артефакты и метрики.
Scrum команда:
• Product owner – управляет бэклогом. BackLog – набор требований, которые надо реализовать для того, чтобы продукт был готов. Задачи product owner собрать BackLog, сделать его понятным для команды, выставить приоритеты. BackLog постоянно обновляется в зависимости от текущих целей разработки.
• Development team – команда разработки. Люди должны быть кросс-функциональны, т.е. иметь унифицированные компетенции (каждый должен уметь делать все).
• Scrum master – координирует команду. Специалист по Scrum, досконально знает этапы, церемонии, артефакты Scrum разработки.
Общая схема Scrum
Подразумевается, что Scrum-команда может самостоятельно сделать из бэклога готовый продукт с новой функциональностью.
Scrum события (Процессы) :
• Sprint – время, за которое создается инкремент продукта — готовый для конечного пользователя продукт.
• Планирование Sprint’а – участвует вся команда. На планировании Спринта решается, каким будет инкримент, и как организовать работу, чтобы успеть сделать все задачи. Выбираются задачи из бэклога продукта (формируется бэклог спринта).
• Ежедневные митинги (daily meeting) – на них обсуждается, что сделано за предыдущий день, что будет делаться сегодня, какие проблемы мешают достижению целей спринта.
• Sprint review meeting (обзор спринта) — подведение итогов спринта, демонстрация инкремента продукта для product owner или заказчика. Все члены команды участвуют в этом митинге.
• Ретроспектива – на нем высказываются о прошедшем спринте: что было сделано хорошо, то надо улучшить в следующем спринте.
Scrum артефакты:
• Бэклог продукта;
• Refinement — уточнение бэклога продукта (уточнение и упорядочение бэклога). Проводит product owner;
• Definition of ready — критерии подготовленности – фокус на требованиях к задачам в бэглоге до планирования итерации;
• Definition of done — критерии готовности – определяются на планировании спринта, сводится фокус на инкременте, который надо проверить на соответствие общей идеи продукта.
• Пользовательские истории (user stories) – задачи бэклога и спринта.
• Покер планирование (Planning poker) — оценка сложности user stories.
• Бэклог спринта — максимальное количество user stories в спринте
• Инкремент продукта.
Как производится оценка? Она является относительной. Например, берут какую-то задачу, небольшую, стандартную, понятную всем, объявляют ее эталоном — она занимает 1 story point. Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше, т.е. занимает 2 story point. Таким образом раскладывают все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Т.е. не предполагается, что программист или маркетолог работает 8 часов и с одинаковой эффективностью, а реально измеряется, сколько команда может проживать story point за спринт.
Для формирования оценок обычно используется покер-планирование.
Метрики:
• Velocity (скорость) – среднее количество задач, которое команда выполняет в спринт;
• Capacity (ёмкость) — доступное время команды;
• Диаграмма сгорания задач;
• Накопительная диаграмма потока.
Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.
По горизонтали отмечаем дни — это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой — истории пользователей или элементы бэклога. Пунктирная линия — это линия идеального Burn Down Charts. Верхняя — сколько мы сделали историй пользователей, нижняя — количество story point.
Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта не будет ноль задач или story point. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.
Набор принципов, процесс разработки происходит в жесткие регламентированные отрезки. В конце каждого спринта должен быть работающий продукт с новым функционалом. Здесь используется итеративный инкрементальный подход. Особенность Scrum является возможность корректировать предыдущие этапы.
Канбан (kanban) – это вторая по популярности методика. Kanban появился в Японии как часть системы производства Тойоты «точно вовремя», поэтому методология исключает излишнее накопление задач. Этим словом называлась бумажка с пул-запросом на какие-то действия.
Для целей гибкого управления проектами Kanban появился в 2010 г., автор — Дэвид Андерсон2. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban (один из будущих трендов).
Методика направлена на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс3.
Принципы Kanban:
• Уважать и использовать то, что есть сейчас: имеющиеся роли, обязанности и должностные инструкции.
• Постоянно оптимизировать и совершенствовать процесс разработки, но не допускать слишком резких перемен
• Поощрять в команде стремление к лидерству4
В Kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер, где указаны все задачи, этапы и их статус.
Пример доски в таск-менеджере Trello5
Kanban-карточки ― это задачи, которые движутся по потоку и перетекают в другие столбцы в зависимости от их состояния. На карточке или стикере пишут название задачи и прикрепляют в начало доски. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Реализуется принцип ограничения количества одновременно находящихся в работе задач — WIP (Work in Progress). Скорость прохождения задачи в такой системе и количество одновременных задач связывает формула Дж. Литтла. Чем меньше WIP, тем быстрее задачи проходят цепочку.
Время цикла = Работа в процессе/Пропускную способность.
Время цикла — время, требуемое каждой задаче для прохождения процесса от начала до конца.
Работа в процессе — число задач, на которыми вы трудитесь одновременно.
Пропускная способность — среднее время на выполнение одной задачи.
В Kanban можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали — количество задач. Разными цветами показаны разные этапы.
6