— А как вы разрабатываете? Kanban, XP, Waterfall?
— Срам.
— Может быть Скрам?
— Нет, срам: каждый день стыдобушка, в конце месяца срамота
До июня месяца года 2016 я не задавалась вопросом применения технологии к управлению разработкой, все шло как шло.
Но случилось так, что набор моих компетенций расширился и лавинообразно прибавилось задач.
В попытке работать как прежде - потоково, я просто стала не успевать все делать в рабочее время и стала забирать работу на дом.
На текущем проекте заказной разработки ухудшились взаимоотношения с проектной командой, качество моей работы стало постепенно снижаться. Личного времени не осталось.
Встал вопрос личного таймменеджмента и анализа своей рабочей загрузки.
Основная проблема свелась к тому, что на проекте заказной разработки (особенность - работа без организации проекта, по обращениям Заказчика) работа с требованиями и их реализацией шла потоково. Из-за чего не удавалось ни планировать свою загрузку, ни загрузку разработчиков, ни толком анализировать взаимосвязь требований, чтобы обрабатывать их одним пакетом.
И вот тут начальник отдела посоветовал посмотреть в сторону SCRUM.
Изучила технологию. Понравилась. Сделала описание порядка взаимодействия проектной команды на основе SCRUM. Провела совещание с командой и предложила такой вариант работы. Сейчас находимся на выполнении второго спринта и я только накапливаю данные для анализа и статистики (с которой позже поделюсь). Но в целом уже сейчас могу сказать, что технология себя оправдывает в условиях:
— Срам.
— Может быть Скрам?
— Нет, срам: каждый день стыдобушка, в конце месяца срамота
До июня месяца года 2016 я не задавалась вопросом применения технологии к управлению разработкой, все шло как шло.
Но случилось так, что набор моих компетенций расширился и лавинообразно прибавилось задач.
В попытке работать как прежде - потоково, я просто стала не успевать все делать в рабочее время и стала забирать работу на дом.
На текущем проекте заказной разработки ухудшились взаимоотношения с проектной командой, качество моей работы стало постепенно снижаться. Личного времени не осталось.
Встал вопрос личного таймменеджмента и анализа своей рабочей загрузки.
Основная проблема свелась к тому, что на проекте заказной разработки (особенность - работа без организации проекта, по обращениям Заказчика) работа с требованиями и их реализацией шла потоково. Из-за чего не удавалось ни планировать свою загрузку, ни загрузку разработчиков, ни толком анализировать взаимосвязь требований, чтобы обрабатывать их одним пакетом.
И вот тут начальник отдела посоветовал посмотреть в сторону SCRUM.
Изучила технологию. Понравилась. Сделала описание порядка взаимодействия проектной команды на основе SCRUM. Провела совещание с командой и предложила такой вариант работы. Сейчас находимся на выполнении второго спринта и я только накапливаю данные для анализа и статистики (с которой позже поделюсь). Но в целом уже сейчас могу сказать, что технология себя оправдывает в условиях:
- лояльного Заказчика, готового к работе с релизами
- небольшой команды с загрузкой на нескольких проектах
- неполное участие или отсутствие РП (технология рассчитана на самоорганизовывающуюся группу)
- отсутствие возможности/средств/времени на полноценное документирование требований и описания реализации
Ощутимые преимущества:
- Выпуск релизов позволяет планировать и свою загрузку, и загрузку прочих участников команды.
- Заказчик знает какой функционал получит в релизе.
- Документирование сводится к бизнес-описанию и описанию-проектированию от разработчика + итоговое описание функционала в релизе.
- Заказчик на основе итогового описания имеет возможность с минимальными трудозатратами довести до сведения пользователей особенности нового функционала.
Комментариев нет:
Отправить комментарий