Эта методология помогла мне успешно завершить проекты
Написано Фелипе Фернандесом Мело, скрам-мастером и членом команды консультантов.
За годы работы с гибкими методологиями я понял, что некоторые проекты не достигли ожидаемого результата, используя традиционную гибкую методологию, известную как Scrum, которая, как мы знаем, представляет собой гибкую структуру и одну из наиболее часто используемых в управлении проектами, ориентированную на сотрудничество. гибкость и поэтапное предоставление результатов.
Посредством коротких циклов, называемых «спринтами», команды работают над приоритетными задачами, адаптируются к изменениям и создают функциональные результаты в конце каждого спринта. Постоянное общение, различные церемонии, такие как ежедневные, планирование, обзор, ретроспективы и непрерывная обратная связь, были ключевыми столпами Scrum, позволяющими командам оптимизировать качество и эффективность итеративного завершения проектов. Scrum сыграл основополагающую роль в развитии моей карьеры, поскольку позволил мне лучше организовывать проекты и даже участвовать в переходе на новый уровень с несколькими командами.
Если для крупных компаний и проектов это работало в большинстве аспектов, то для других проектов адаптировалось не лучшим образом, и благодаря тому, что у меня была возможность выбирать, как я хочу работать и организовывать команды, я понял что в некоторых проектах применение определенных принципов различных методологий и ограничение количества встреч позволило мне завершить проекты вовремя и обеспечить качество и ценность для клиента.
Представляем гибридную гибкую методологию
В этой статье я привожу своего рода гибкую гибридную методологию, которая помогла мне успешно выполнять проекты в короткие сроки и качественно. В частности, он был ориентирован в основном на удаленные команды, гибкую рабочую среду, автономность и сотрудничество.
Ниже я опишу некоторые ключевые моменты и принципы:
Гибридная гибкая методология: ключевые моменты и принципы
Цели:
Оптимизируйте рабочий процесс в гибких командах, устраняя необходимость в обычных последующих совещаниях. С акцентом на непрерывное предоставление ценности и быструю адаптацию, которая позволяет командам максимизировать свою производительность и эффективное сотрудничество.
Принципы и ценности:
Принципы: Сосредоточьтесь на создании ценности, поощряйте постоянное сотрудничество и общение, адаптируйтесь к изменениям и устраняйте потери.
Ценности: прозрачность, гибкость, автономия команды и нацеленность на результат.
Роли и обязанности:
- Владелец продукта: отвечает за определение и приоритезацию невыполненной работы по продукту.
- BA: Отвечает за загрузку подробного функционала и критериев приемки.
- UX UI Designer: отвечает за разработку прототипов функций.
- Менеджер проекта: Фасилитатор, ответственный за обеспечение соблюдения методологии, помогающий команде применять принципы и практики. Он организует работу и обновляет Канбан, он отвечает за устранение внутренних и внешних препятствий, с которыми сталкивается команда.
- Команда разработчиков и тестирования: отвечает за разработку и тестирование пользовательских историй, а также за участие в планировании и принятии решений.
Процессы и практики:
- Планирование итерации: команда ставит четкие цели и выбирает пользовательские истории для реализации во время итерации.
- Управление бэклогом: Владелец продукта поддерживает четко определенный бэклог продукта, готовый к реализации в любое время.
- Оценка работы: команда использует оценки в днях для более точного планирования и отслеживания незавершенной работы.
- Обзоры и демонстрации. Периодические демонстрации проводятся для обмена разработанными приращениями ценности и получения обратной связи.
Артефакты:
- Журнал невыполненных работ по продукту: приоритетный список пользовательских историй и элементов невыполненной работы, которые необходимо реализовать.
- Журнал спринта: выбор пользовательских историй для реализации во время текущей итерации.
- Истории пользователей: описания функций или требований, повышающих ценность продукта или проекта.
Церемонии:
- Еженедельно: еженедельное совещание для анализа прогресса, выявления препятствий и корректировки приоритетов.
- Демонстрация спринта: презентация приращений стоимости, полученных в ходе итерации, для получения обратной связи. Как правило, это одна демонстрация, но ее можно разделить в зависимости от потребностей клиента и времени.
- Планирование спринта не требует собрания, бэклог и бэклог спринта постоянно обновляются с указанием приоритетов, которые необходимо принять, и команда несет ответственность за анализ историй и определение оценки в днях, если возникает что-то пунктуальное, об этом сообщается непосредственно PO. или бакалавр.
Инструменты и технологии:
- Канбан-доска: инструмент для записи и визуального отслеживания пользовательских историй и их прогресса. Менеджер проекта постоянно поддерживает его в актуальном состоянии.
- Платформы онлайн-коммуникации: использование инструментов чата для совместной работы для поддержания плавного общения между членами команды.
Рабочий процесс:
- Элементы бэклога спринта перемещаются из одного столбца в другой на доске Канбан, отражая их текущий статус.
Преимущества и преимущества:
- Повышение производительности и сотрудничества без необходимости проведения обычных последующих совещаний.
- Быстрая адаптация к изменениям и большая гибкость рабочего процесса.
- Устранение потерь и сосредоточение внимания на создании ценности.
Принципы:
- Нет ежедневных. Официальные ежедневные встречи не проводятся. Вместо этого в течение дня поощряется непрерывное и прозрачное общение между членами команды с использованием онлайн-инструментов для совместной работы и гибких каналов связи.
- Нет ухода: традиционные встречи по уходу исключены. Вместо этого он поощряет создание и поддержание четко определенного и актуального журнала невыполненных работ по продукту или пользовательских историй, которые готовы к внедрению в любое время.
- Планирование: асинхронное планирование, при котором участник берет на себя или ему поручается задача для проверки и оценки, всегда поддерживая плавное общение через чат. Если есть дополнительные сомнения, вы можете провести короткую встречу с участником или подождать для еженедельной встречи.
- Нет доработки. Официальные встречи по доработке не проводятся. Вместо этого поощряется непрерывный подход к уточнению и уточнению элементов отставания, поскольку во время разработки возникают вопросы или проблемы.
- Нет ретроспективы. Ретроспективные встречи не являются частью процесса. Вместо этого командам рекомендуется участвовать в постоянной обратной связи и размышлениях во время разработки итераций, что позволяет осуществлять постоянные корректировки и улучшения.
- Одна или несколько демонстраций: включает периодические демонстрации, позволяющие поделиться и получить отзывы о проделанной работе. Эти демонстрации планируются по мере необходимости и направлены на предоставление функциональных, готовых к развертыванию дополнительных преимуществ.
- Итерации продолжительностью 3 недели или месяц: используйте итерации большей продолжительности, продолжительностью 3 недели или месяц. Это дает командам достаточно времени для выполнения задач и достижения целей, поставленных для каждой итерации.
- Оценки в днях. Оценки производятся в днях, а не в баллах, что упрощает планирование, оценку и отслеживание предстоящей работы (перенос).
- еженедельное собрание для поддержания регулярного взаимодействия и эффективного общения внутри команды. Сосредоточено на обзоре прогресса, выявлении и устранении потенциальных препятствий, а также корректировке приоритетов при необходимости. Цель состоит в том, чтобы все члены команды были информированы и согласованы между собой, не допуская чрезмерного количества совещаний.
- Для обеспечения эффективного сотрудничества предлагается использовать единый чат. Этот чат действует как централизованное пространство, где члены команды могут взаимодействовать, делиться обновлениями, задавать вопросы и сотрудничать в режиме реального времени. Наличие единого чата для совместной работы позволяет избежать рассредоточения связи и облегчает доступ к соответствующей информации.
Как описано выше по моему опыту, это помогло мне как в новых проектах с созданием MVP, так и в уже реализованных проектах, находящихся на эволюционно-корректирующей стадии, где поставка функциональности и добавление ценности были непрерывными. Я считаю, что в нем есть аспекты методологии Lean, некоторые моменты, взятые из Scrum, а также использование Kanban для отслеживания и постоянного обновления задач.
Наконец, эти пункты могут частично или полностью помочь в управлении некоторыми программными проектами, но, как я уже заметил, для их реализации необходимо создать условия гибкой рабочей среды.
Если вы хорошо провели время, читая эту статью, почему бы не поделиться ею со своими коллегами? На нашем сайте вас ждет еще много подобного контента.}
Вы можете следить за нами в LinkedIn, Instagram или Twitter.
