Во время учебы в Apple Developer Academy @ BINUS у меня была возможность стать менеджером проектов и продуктов в течение последних 4 месяцев, создавая KOBAR, образовательное приложение для геймификации.

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

• Sprint управляет механизмом перетаскивания, который ограничивает перегрузку притока,
• Планирование спринта позволяет проводить самооценку каждой задачи, которая инициирует ясность и рост в отношении DoD (определение готовности).
• Ежедневная разработка Scrum улучшает координацию между командой, чтобы показать и выразить свои идеи.
• Обзор спринта включает команду scrum вместе с другими акционерами. Который принимает отзывы от команды Scrum, а также здесь была проведена проверка.
• Ретроспектива спринта дает возможность изучить препятствия на данный момент и получить дополнения к предстоящему спринту.

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

«Те, кто планирует, добиваются большего успеха, чем те, кто не планирует, даже если они редко придерживаются своего плана». - Уинстон Черчилль

В начале проектного периода все незавершенные работы могут быть завершены в соответствии с заранее установленным сроком. Разделение задач было четким и структурированным в соответствии с желаемым графиком. Однако, когда он вступает в период разработки, многое нужно скорректировать, чтобы команде было немного тяжело выполнять поставленные задачи.

Именно тогда возникают проблемы, часто когда задача должна была быть выполнена и начать следующий спринт, команда не смогла ее выполнить. Сначала мы были в недоумении, почему? предоставленного времени недостаточно?

Но известно, что главная проблема в том,

в одном спринте слишком много отставаний, когда мы не можем привести ожидания в соответствие с реальностью.

Тогда почему возникает эта проблема?

• Мы переоценили то, что могли бы сделать за одну итерацию.
• Один из рабочих элементов был намного больше, чем мы ожидали.
• В итерацию вошли сервисные инъекции/незапланированная работа.

Поймите первопричину и найдите, как ее избежать. Моя команда использует ретроспективу спринта, чтобы оценить причину и извлечь из нее уроки. Каждый человек в команде делится своей точкой зрения и способами ее преодоления.

Обсудите будущее каждого бэклога

• Если бэклог имеет высокий приоритет, может быть полезно перенести тот же бэклог на следующий спринт . Может быть, предоставленного времени недостаточно с размером рабочих элементов, так что все еще в порядке.
• Если невыполненная работа имеет низкий приоритет, определите, можно ли разбить ее, и переместите незавершенную работу в невыполненную работу по продукту.

Все это основано на моем опыте и поддерживается ресурсами из:

Любая обратная связь высоко ценится! пожалуйста, ударь меня здесь !

© 2022 Натания Джойс Айрин. Все права защищены.