С чего начать внедрение методологий. Любимый Scrum

Пора внедрять методологии в рамках учебной дисциплины "Управление 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 этап: Всё, дальше вы начинаете саму разработку, когда все тщательно продумали. Тут от вас нужны отчеты перед заказчиком, контроль команды, укладываетесь ли вы в сроки и бюджет. После всего этого проведение тестирования.

Артефакты, которые должны быть:

1. Устав проекта

2. Документ со всеми Stakeholders

3. SRS/Vision and Scope Document

4. WBS

5. Сетевой граф

6. Рассчитанный критический путь

7. Расписание проекта с конкретными датами

8. Документ со всеми ЗП людей, в том числе менеджера и ставки, за которые эти все люди проданы заказчику на проект

9. Все расходы и доходы по проекту, всё считаем

10. Документ о коммуникациях

11. Документ рисков (идентификация рисков, как каждый будете решать, классификация рисков по источнику)

12. S-кривая рисков проекта

13. Доска Trello со всей командой, задачами, сроками и т.д.

14. В конце презентация проекта (туда включаем то, как работали менеджеры и информацию по сайту)

15. Готовый сайт, сделанный в срок

16. RACI-матрица

SCRUM

Работаем по Scrum Guide

1 этап: Научиться Скраму, его принципам, знать какие церемонии там проводятся. После сразу же научить всю команду, объяснить ценность скрама.

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).

Артефакты, которые должны быть:

1. SRS/Vision and Scope Document

2. WBS

3. Product backlog, который в процессе может изменяться и дополняться

4. Изначальную velocity вашей команды и потом последующую velocity (каждый спринт!)

5. BurnDown-diagram (по вашей velocity, каждый спринт!)

6. Sprint backlog (каждый спринт!)

7. Записи daily meetings (каждый спринт!)

8. Отчет за каждый спринт! и его защита

9. Результаты ретроспективы (каждый спринт!)

10. Документ со всеми ЗП людей, в том числе менеджера и ставки, за которые эти все люди проданы заказчику на проект (кстати время, затраченное на коммуникации, тоже оплачивается заказчиком)

11. Все расходы и доходы по проекту, всё считаем

12. Документ о коммуникациях

13. Документ рисков (идентификация рисков, как каждый будете решать, классификация рисков по источнику)

14. S-кривая рисков проекта

15. Доска Trello со всей командой, задачами, сроками и т.д.

16. В конце презентация проекта (туда включаем то, как работали менеджеры и информацию по сайту)

17. Готовый сайт, сделанный в срок

18. RACI-матрица (обязательно определите кто Product Owner, а кто Scrum Master)