[Управление проектами, Agile] С чего начать внедрение методологий. Любимый Scrum
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Пора внедрять методологии в рамках учебной дисциплины "Управление IT-проектами". Будем работать по 2 методологиям: Waterfall и Scrum. Надо следить за результатами и сравнивать прогресс. Расписала начальный план, как это будет происходить и хочу поделиться.WATERFALLРаботаем по PMBOK. Проходимся по стадиям инициация-планирование-исполнение-мониторинг и контроль-закрытие. (все документы, которые нужно составить стр.25 PMBOK) 1 этап: Составление устава проекта (со стр.34 PMBOK) и инициация Stakeholders. Что должно быть в уставе (можете просто документ сделать сами, можете взять шаблон и писать по шаблону. Как показывает практика в шаблоне много лишних данных, которые вы не будете знать как заполнить, поэтому просто пропишите лучше все пункты, которые я указала): Конечная цель проекта (должна соответствовать критериям SMART), всех конечных пользователей, стейкхолдеров, спонсоров, проектного менеджера, участников проектного комитета и проектной команды, перечисление этапов и процессов во время жизненного цикла проекта, ключевые точки и зависимости между процессами, список с необходимыми ресурсами: оборудованием, ПО, материалами, риски, которые вы видите на начальном этапе проекта и как вы будете это решать, точно просчитанный бюджет и сроки проекта, от которого вы отойти не можете.2 этап: выявление и документирование всех требований. Есть несколько типов требований: функциональные, нефункциональные и тд. (стр.6 книга Вигерса). Мне от вас нужны все. Понимайте, что потом по этим требованиям вам работать, поэтому это очень важный этап. (С требованиями работаем по книжке Вигерса, что-то непонятно - за консультацией к Жене, это профессиональная область бизнес-анализа). Есть 2 документа по требованиям, которые можно составить: SRS и Vision and Scope Document. (Советую делать второй документ, он проще, меньше, скидываю пример, по которому будете делать). 3 этап: Из требований получаем ИСР - Иерархическая структура работ или ещё WBS - Work Breakdown Structure. Опять же, на него обратить внимание, потом из него вы будете получать все задачи и оценивать их. Если эти этапы сделаете хорошо, то дальше будет проще. Уже больше будете контролировать, а не всякие документы делать. (стр.156 PMBOK, на странице 158 PMBOK конкретный пример как это должно выглядеть). Не забываем сюда включать задачи не только по разработке, но и по тестированию, по макетам.4 этап: Из прописанных работ, каждую оцениваем по срокам. Помним, что есть работы, которые можно запараллелить, а есть которые должны выполняться последовательно, так одна работа может блокировать начало другой (составляем сетевой граф работ и считаем критический путь). Из этих оценок получаем Расписание проекта.5 этап: Рассчитываем бюджет проекта. Для расчета бюджета обязательно: у каждого человека в команде должна быть своя ставка в час для заказчика (например 20$ в час). И также должна быть ЗП человека в месяц, и при этих всех данных проект должен быть рентабельным: т.е. получать от заказчика вы должны больше, чем платить человеку ЗП, чтобы не уйти в минус по проекту. Да, РМ - это ещё и тот, кто считает все деньги. Берите, пожалуйста, реальные ЗП с рынка. Представьте, что у вас в команде есть и Junior, и Senior-разработчики. 6 этап: Планирование управления коммуникациями. Составляете документ, где прописываете где, сколько, как часто будете общаться и с кем. 7 этап: Идентификация рисков. Надо составить документ, какие риски могут возникнуть и как вы будете их решать. Например: кто-то уйдет из команды, пропадет мотивация, конфликт 2-х менеджеров, несоблюдение дедлайнов и тд.). Смотрим какие бывают источники рисков проекта, стр.406 PMBOK, все риски классифицируем. Дальше прописываем риски по таблице 11-1 (стр. 407 PMBOK). Далее делаем качественный и количественный анализ рисков и составляем S-кривую. (стр. 433 PMBOK). 8 этап: Всё, дальше вы начинаете саму разработку, когда все тщательно продумали. Тут от вас нужны отчеты перед заказчиком, контроль команды, укладываетесь ли вы в сроки и бюджет. После всего этого проведение тестирования.Артефакты, которые должны быть:
- Устав проекта
- Документ со всеми Stakeholders
- SRS/Vision and Scope Document
- WBS
- Сетевой граф
- Рассчитанный критический путь
- Расписание проекта с конкретными датами
- Документ со всеми ЗП людей, в том числе менеджера и ставки, за которые эти все люди проданы заказчику на проект
- Все расходы и доходы по проекту, всё считаем
- Документ о коммуникациях
- Документ рисков (идентификация рисков, как каждый будете решать, классификация рисков по источнику)
- S-кривая рисков проекта
- Доска Trello со всей командой, задачами, сроками и т.д.
- В конце презентация проекта (туда включаем то, как работали менеджеры и информацию по сайту)
- Готовый сайт, сделанный в срок
- RACI-матрица
SCRUM
Работаем по Scrum Guide1 этап: Научиться Скраму, его принципам, знать какие церемонии там проводятся. После сразу же научить всю команду, объяснить ценность скрама. 2 этап: выявление и документирование всех требований. Есть несколько типов требований: функциональные, нефункциональные и тд. (стр.6 книга Вигерса). Мне от вас нужны все. Понимайте, что потом по этим требованиям вам работать, поэтому это очень важный этап. (С требованиями работаем по книжке Вигерса, что-то непонятно - за консультацией к Жене, это профессиональная область бизнес-анализа). Есть 2 документа по требованиям, которые можно составить: SRS и Vision and Scope Document. (Советую делать второй документ, он проще, меньше, скидываю пример, по которому будете делать). 3 этап: Из требований получаем ИСР - Иерархическая структура работ или ещё WBS - Work Breakdown Structure. Опять же, на него обратить внимание, потом из него вы будете получать все задачи и оценивать их. Если эти этапы сделаете хорошо, то дальше будет проще. Уже больше будете контролировать, а не всякие документы делать. (стр.156 PMBOK, на странице 158 PMBOK конкретный пример как это должно выглядеть). Не забываем сюда включать задачи не только по разработке, но и по тестированию, по макетам.4 этап: Из прописанных работ получаем product backlog, который будет храниться в Trello.5 этап: Начинаем работать спринтами, проводим planning poker. 0 спринт - делаем по Канбану, чтобы оценить velocity команды в story points. (много непонятых слов, как раз будет время разобраться). В конце этого спринта получаем velocity команды.6 этап: Планирование спринта, проводим planning poker, вся команда оценивает задачи в story points, дальше берем в спринт то количество задач, которые суммарно равны нашей velocity, получаем sprint backlog.7 этап: Daily meetings. Каждый день!!!! Кроме выходных вся команда с менеджерами собирается и вы проводите это 15-минутное мероприятие, чтобы все знали кто чем занимается, вы ведете записи этих митингов.8 этап: Demo. В конце каждого спринта проводите демонстрацию своего продукта, в конце каждого спринта это должна быть самостоятельно работающая единица. На демо мы также составляем отчет каждый спринт и защищаем его.9 этап: Ретроспектива. Собираетесь и в конце каждого спринта обсуждаете все наболевшие проблемы, что было хорошо, что было плохо, что можно улучшить. Результат ретроспективы - задачи по улучшения процесса на следующий спринт и ответственные за эти задачи. (Например: проблема - daily meetings длятся 30 мин, хотя по регламенту должны быть не более 15 мин. Решение - назначаем ответственного человека, который контролирует время этого мероприятия и как только проходит время, прерывает его.)10 этап: Мы работаем по типу контракта Time&Materials. То есть проект вы не рассчитываете сумму заранее, а по ходу считаете сколько заказчик должен вам и сколько вы, как компания должны людям зарплаты. Для расчета бюджета обязательно: у каждого человека в команде должна быть своя ставка в час для заказчика (например 20$ в час). И также должна быть ЗП человека в месяц, и при этих всех данных проект должен быть рентабельным: т.е. получать от заказчика вы должны больше, чем платить человеку ЗП, чтобы не уйти в минус по проекту. Да, РМ - это ещё и тот, кто считает все деньги. Берите, пожалуйста, реальные ЗП с рынка. Представьте, что у вас в команде есть и Junior, и Senior-разработчики.11 этап: Планирование управления коммуникациями. Составляете документ, где прописываете где, сколько, как часто будете общаться и с кем. 12 этап: Идентификация рисков. Надо составить документ, какие риски могут возникнуть и как вы будете их решать. Например: кто-то уйдет из команды, пропадет мотивация, конфликт 2-х менеджеров, несоблюдение дедлайнов и тд.). Смотрим какие бывают источники рисков проекта, стр.406 PMBOK, все риски классифицируем. Дальше прописываем риски по таблице 11-1 (стр. 407 PMBOK). Далее делаем качественный и количественный анализ рисков и составляем S-кривую. (стр. 433 PMBOK).Артефакты, которые должны быть:
- SRS/Vision and Scope Document
- WBS
- Product backlog, который в процессе может изменяться и дополняться
- Изначальную velocity вашей команды и потом последующую velocity (каждый спринт!)
- BurnDown-diagram (по вашей velocity, каждый спринт!)
- Sprint backlog (каждый спринт!)
- Записи daily meetings (каждый спринт!)
- Отчет за каждый спринт! и его защита
- Результаты ретроспективы (каждый спринт!)
- Документ со всеми ЗП людей, в том числе менеджера и ставки, за которые эти все люди проданы заказчику на проект (кстати время, затраченное на коммуникации, тоже оплачивается заказчиком)
- Все расходы и доходы по проекту, всё считаем
- Документ о коммуникациях
- Документ рисков (идентификация рисков, как каждый будете решать, классификация рисков по источнику)
- S-кривая рисков проекта
- Доска Trello со всей командой, задачами, сроками и т.д.
- В конце презентация проекта (туда включаем то, как работали менеджеры и информацию по сайту)
- Готовый сайт, сделанный в срок
- RACI-матрица (обязательно определите кто Product Owner, а кто Scrum Master)
===========
Источник:
habr.com
===========
Похожие новости:
- [Agile] Ловушка шаблонного мышления – как не попасться?
- [Управление проектами, Управление персоналом, Бизнес-модели] Мы компания в айти — нам всё равно, куда идти
- [Управление проектами] Trello адаптирует дизайн к будущему цифровой работы
- [Мессенджеры, Open source, Системное администрирование, PHP, Программирование] Рефакторинг пет проекта: докеризация, метрики, тесты
- [Управление проектами, Agile] Если ваш бэклог не детализируется, значит вы делаете что-то не так (перевод)
- [Управление проектами] Чип и Дейл больше не спешат на помощь
- [Управление проектами] Школа или как завалить архитектурное планирование
- [Nginx, Управление проектами, Лайфхаки для гиков, Мозг] Уточняем детали проекта методами практической психологии
- [Программирование, Управление разработкой, Управление проектами, Учебный процесс в IT, Изучение языков] Как прорешать SICP: Отчёт о создании решебника для самого известного в мире задачника по программированию (перевод)
- [Программирование, Управление разработкой, Управление проектами] Оценка трудозатрат в веб- и мобильных проектах
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_agile, #_scrum, #_waterfall, #_project_management, #_project, #_pmbok, #_scrum_poker, #_upravlenie_proektami (
Управление проектами
), #_agile
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 21:16
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Пора внедрять методологии в рамках учебной дисциплины "Управление IT-проектами". Будем работать по 2 методологиям: Waterfall и Scrum. Надо следить за результатами и сравнивать прогресс. Расписала начальный план, как это будет происходить и хочу поделиться.WATERFALLРаботаем по PMBOK. Проходимся по стадиям инициация-планирование-исполнение-мониторинг и контроль-закрытие. (все документы, которые нужно составить стр.25 PMBOK) 1 этап: Составление устава проекта (со стр.34 PMBOK) и инициация Stakeholders. Что должно быть в уставе (можете просто документ сделать сами, можете взять шаблон и писать по шаблону. Как показывает практика в шаблоне много лишних данных, которые вы не будете знать как заполнить, поэтому просто пропишите лучше все пункты, которые я указала): Конечная цель проекта (должна соответствовать критериям SMART), всех конечных пользователей, стейкхолдеров, спонсоров, проектного менеджера, участников проектного комитета и проектной команды, перечисление этапов и процессов во время жизненного цикла проекта, ключевые точки и зависимости между процессами, список с необходимыми ресурсами: оборудованием, ПО, материалами, риски, которые вы видите на начальном этапе проекта и как вы будете это решать, точно просчитанный бюджет и сроки проекта, от которого вы отойти не можете.2 этап: выявление и документирование всех требований. Есть несколько типов требований: функциональные, нефункциональные и тд. (стр.6 книга Вигерса). Мне от вас нужны все. Понимайте, что потом по этим требованиям вам работать, поэтому это очень важный этап. (С требованиями работаем по книжке Вигерса, что-то непонятно - за консультацией к Жене, это профессиональная область бизнес-анализа). Есть 2 документа по требованиям, которые можно составить: SRS и Vision and Scope Document. (Советую делать второй документ, он проще, меньше, скидываю пример, по которому будете делать). 3 этап: Из требований получаем ИСР - Иерархическая структура работ или ещё WBS - Work Breakdown Structure. Опять же, на него обратить внимание, потом из него вы будете получать все задачи и оценивать их. Если эти этапы сделаете хорошо, то дальше будет проще. Уже больше будете контролировать, а не всякие документы делать. (стр.156 PMBOK, на странице 158 PMBOK конкретный пример как это должно выглядеть). Не забываем сюда включать задачи не только по разработке, но и по тестированию, по макетам.4 этап: Из прописанных работ, каждую оцениваем по срокам. Помним, что есть работы, которые можно запараллелить, а есть которые должны выполняться последовательно, так одна работа может блокировать начало другой (составляем сетевой граф работ и считаем критический путь). Из этих оценок получаем Расписание проекта.5 этап: Рассчитываем бюджет проекта. Для расчета бюджета обязательно: у каждого человека в команде должна быть своя ставка в час для заказчика (например 20$ в час). И также должна быть ЗП человека в месяц, и при этих всех данных проект должен быть рентабельным: т.е. получать от заказчика вы должны больше, чем платить человеку ЗП, чтобы не уйти в минус по проекту. Да, РМ - это ещё и тот, кто считает все деньги. Берите, пожалуйста, реальные ЗП с рынка. Представьте, что у вас в команде есть и Junior, и Senior-разработчики. 6 этап: Планирование управления коммуникациями. Составляете документ, где прописываете где, сколько, как часто будете общаться и с кем. 7 этап: Идентификация рисков. Надо составить документ, какие риски могут возникнуть и как вы будете их решать. Например: кто-то уйдет из команды, пропадет мотивация, конфликт 2-х менеджеров, несоблюдение дедлайнов и тд.). Смотрим какие бывают источники рисков проекта, стр.406 PMBOK, все риски классифицируем. Дальше прописываем риски по таблице 11-1 (стр. 407 PMBOK). Далее делаем качественный и количественный анализ рисков и составляем S-кривую. (стр. 433 PMBOK). 8 этап: Всё, дальше вы начинаете саму разработку, когда все тщательно продумали. Тут от вас нужны отчеты перед заказчиком, контроль команды, укладываетесь ли вы в сроки и бюджет. После всего этого проведение тестирования.Артефакты, которые должны быть:
Работаем по Scrum Guide1 этап: Научиться Скраму, его принципам, знать какие церемонии там проводятся. После сразу же научить всю команду, объяснить ценность скрама. 2 этап: выявление и документирование всех требований. Есть несколько типов требований: функциональные, нефункциональные и тд. (стр.6 книга Вигерса). Мне от вас нужны все. Понимайте, что потом по этим требованиям вам работать, поэтому это очень важный этап. (С требованиями работаем по книжке Вигерса, что-то непонятно - за консультацией к Жене, это профессиональная область бизнес-анализа). Есть 2 документа по требованиям, которые можно составить: SRS и Vision and Scope Document. (Советую делать второй документ, он проще, меньше, скидываю пример, по которому будете делать). 3 этап: Из требований получаем ИСР - Иерархическая структура работ или ещё WBS - Work Breakdown Structure. Опять же, на него обратить внимание, потом из него вы будете получать все задачи и оценивать их. Если эти этапы сделаете хорошо, то дальше будет проще. Уже больше будете контролировать, а не всякие документы делать. (стр.156 PMBOK, на странице 158 PMBOK конкретный пример как это должно выглядеть). Не забываем сюда включать задачи не только по разработке, но и по тестированию, по макетам.4 этап: Из прописанных работ получаем product backlog, который будет храниться в Trello.5 этап: Начинаем работать спринтами, проводим planning poker. 0 спринт - делаем по Канбану, чтобы оценить velocity команды в story points. (много непонятых слов, как раз будет время разобраться). В конце этого спринта получаем velocity команды.6 этап: Планирование спринта, проводим planning poker, вся команда оценивает задачи в story points, дальше берем в спринт то количество задач, которые суммарно равны нашей velocity, получаем sprint backlog.7 этап: Daily meetings. Каждый день!!!! Кроме выходных вся команда с менеджерами собирается и вы проводите это 15-минутное мероприятие, чтобы все знали кто чем занимается, вы ведете записи этих митингов.8 этап: Demo. В конце каждого спринта проводите демонстрацию своего продукта, в конце каждого спринта это должна быть самостоятельно работающая единица. На демо мы также составляем отчет каждый спринт и защищаем его.9 этап: Ретроспектива. Собираетесь и в конце каждого спринта обсуждаете все наболевшие проблемы, что было хорошо, что было плохо, что можно улучшить. Результат ретроспективы - задачи по улучшения процесса на следующий спринт и ответственные за эти задачи. (Например: проблема - daily meetings длятся 30 мин, хотя по регламенту должны быть не более 15 мин. Решение - назначаем ответственного человека, который контролирует время этого мероприятия и как только проходит время, прерывает его.)10 этап: Мы работаем по типу контракта Time&Materials. То есть проект вы не рассчитываете сумму заранее, а по ходу считаете сколько заказчик должен вам и сколько вы, как компания должны людям зарплаты. Для расчета бюджета обязательно: у каждого человека в команде должна быть своя ставка в час для заказчика (например 20$ в час). И также должна быть ЗП человека в месяц, и при этих всех данных проект должен быть рентабельным: т.е. получать от заказчика вы должны больше, чем платить человеку ЗП, чтобы не уйти в минус по проекту. Да, РМ - это ещё и тот, кто считает все деньги. Берите, пожалуйста, реальные ЗП с рынка. Представьте, что у вас в команде есть и Junior, и Senior-разработчики.11 этап: Планирование управления коммуникациями. Составляете документ, где прописываете где, сколько, как часто будете общаться и с кем. 12 этап: Идентификация рисков. Надо составить документ, какие риски могут возникнуть и как вы будете их решать. Например: кто-то уйдет из команды, пропадет мотивация, конфликт 2-х менеджеров, несоблюдение дедлайнов и тд.). Смотрим какие бывают источники рисков проекта, стр.406 PMBOK, все риски классифицируем. Дальше прописываем риски по таблице 11-1 (стр. 407 PMBOK). Далее делаем качественный и количественный анализ рисков и составляем S-кривую. (стр. 433 PMBOK).Артефакты, которые должны быть:
=========== Источник: habr.com =========== Похожие новости:
Управление проектами ), #_agile |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 21:16
Часовой пояс: UTC + 5