Одна из ключевых целей при планировании проекта – общими усилиями собрать требования. Но зачастую бывает сложно решить, с чего начать и на чем сосредоточиться. Визуализация функционала (story mapping) – увлекательная работа, где все члены команды участвуют в формировании списка требований (бэклога) – расклеивают карточки на стене, а не пишут скучную 100-страничную спецификацию.
Структура карты: Цели — Действия — Задачи — Истории
А для выполнения действия пользователь должен решить задачу
Для достижения цели нужно выполнить те или иные действия
Для этого расставляются цели
Перед началом визуализации нужно обрисовать себе весь проект целиком.
Визуализация функционала — это нисходящий способ сбора требований, которые представляются в древовидной форме.
User Story Mapping
визуализация функционала
KANBAN
Контроль за выполнением задач
Сколько в среднем находиться одна
задача в одно из статусов
Days in stutus (трекать количество
дней нахождения в одном статусе)
Раз в квартал:
Встреча по стратегии
Раз в месяц:
Операционная встреча по качеству
Встреча по рискам
Раз в две недели:
Task overview | Обзор задач
Планирование поставки
Обзор сервиса
Ежедневно: актуализация задач
Board Kanban
В каждом статусе на человека не больше 2- задач
Разделение на классы приоритетов: срочные
(вне очереди), среднесрочные...
Приоритетность та же справа налево и сверху вниз
Работа с блокерами
Приоритет задач, сверху вниз по времени их поступления
Приоритет задач, которые ближе к колонке Done
Задачи двигаются слева направо
Новые задачи добавляются в любое время
Ранжируем задачи по ВРЕМЕНИ их поступления
SCRUM
Самоорганизация
Metrics
Velocity chart
Burn down chart
Board Scrum
Jira
Days in stutus (трекать количество дней), сколько задача находится без изменений статуса. 01:16 лекции.
Насторить: https://www.youtube.com/watch?v=iQRKCFh3gIQ
Estimations
T-shirt
xs s m l xl xxl \ час день неделя месяц квартал год
Числа Фибоначчи
Team velocity
Velocity
Кол-во Story Points, которые команда делает за Sprint
Story points
Hours
Teams
Developer team
Scrum master
Ведет backlog
Организовывает meetings
Следит за графиком
Помогает решать вопросы команды
Prodoct owmer
Meetings
Release
Своеобразный «выход в свет», release. Выпуск целого приложения или его части (например, багфикс) в продакшн-версии для конечного пользователя или в промежуточной для внутреннего тестирования. В идеале каждый спринт должен заканчиваться релизом.
Retrospective
Daily Scrum
Оценить прогресс
Актуализировать прогресс
Выявлять блокеры (задачи, которые нельзя сделать, пока другой член команды не выполнит свою задачу)
Проверять задачи с зависшими статусами (залежались)
Синхронизовать команду
Добавить или убрать задачи
Оценить, укладываемся ли мы в график
Planning
Scoring
Estimation
Artifacts
Инкремент
(софт)
Беклог
Спринта
Беклог
Продукта
Backlog
Оценка
Часы / Story Points
Приоритезация
RICE и ICE Scoring
Sprint backlog
ЗАПУСК
Deploy / Развертывание
ИНИЦИАЦИЯ
Выявить риски
Определить потребность ресурсов
Согласование ближайших ресурсов
Аллоцирование (распределение) ресурсов
Устав | Цели+Требования (Requirements)
+Риски+Бюджет+Расписание+
Контрольные события (Milestones)
Сделка
Statement of Work / Техническое задание
WBS | Структура работ проекта /
Выписать спецификацию
Уточненные Оценки
Договор / Контракт
Счет / Invoce
Оплата
Pre-Sale
Scoring / Сортировка
Концепция проекта
Lean Canvas
Бриф / Выявление потребностей
Запросить всю информацию
Формирование проектного решения
(как делать, на чем делать ...)
Outline + Блок-схема
Request for Proposal
Estimates
Предварительные оценки
КОНТЕНТ
РАЗРАБОТКА
Тестирование
ПОДГОТОВКА
Тест стратегия
Тест план
-Тест кейсы
-Матрица покрытия тестами
ТЕСТИРОВАНИЕ
Функциональное тестирование
Кроссбраузеность
Unit тестирование
Компонентное тестирование
Регрессионное тестирование
Админ панель
Нагрузочное тестирование
Совместимость - интеграции
Нефункциональное
Контрольное
Пользовательская документация
Предоставить доступы к сайтам
(не к коду)
Финальное тестирование +
регрессионное тестирование
Финально поправить
Освободить ресурсы
Разработка по Фичам *n раз/
Спринты
CSS/HTML Layout
BE
-API интеграции
FE
-Верстка
UI Review By Designer
Функциональное тестирование
(Кроссбраузерность)
Fixing Bugs
Demo
Fixing
Контрольное тестирование
Регулярная отчетность
Оплаты / инвойсы
Учетные записи
Архитектурные решения
База данных
Сервера купить и развернуть
(Dev, stage,prod,GIT)
Доступы (Git, env)
Детальные декопозиции
Финальные оценки на специалистах
Менеджер задач
(Сформилировать и поставить)
CI/CD Pipeline - автодоставка
ДИЗАЙН
Выгрузить картинки
Отчет по дизайну
Согласовать
Выставить счет
Получить оплату
Выгрузить исходные материалы
Поискать изменения
Зарегистрировать
Оценить
Планирование изменений
UI-дизайн
Главная страница
Адаптив главной страницы
Телефон, планшет, ПК
Страница 2, n страниц
Адаптив страницы 2, n страниц
Телефон, планшет, ПК
Согласование всего пакета дизайн макетов
Бриф
Бренд бук и фирменный стиль
Ресерч дизайна конкурентов
Референсы (примеры)
Moodboard
Учетные записи в программах
ПЛАНИРОВАНИЕ
Продолжительность работ
Потребность ресурсов
Переаллоцирование ресурсов
Сводный план проекта
Согласование плана проекта
Roadmap + Диаграма Ганта
Бюджетирование
Согласование (Предоставить)
Ресурсы заказчика
Контент
Бэклог
Переоценка проекта
WBS | Структура работ проекта
Валидировать
Подготовить материалы
Подготовить наиболее уместную ексельку
Оценочная сессия
Груминг состава работы по оценкам
Согласование оценок
Требования
ПРОТОТИПИРОВАНИЕ
Storymap / Костяк ТЗ
Рефакторинг
UX (Wireframes) Part 1
Демо / FB Сессия - Правки - Согласование
UX (Wireframes) Part 2
UX (Wireframes) Part n
Финальное согласование
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
(Story + AC / Спецификация / ТЗ)
Функциональные требования
Нефункциональные требования
Согласование *n раз
Подготовка
Research/Discovery
Менеджер задач
Поставить (Сформулировать) задачи
Создание учетных записей /
Раздача доступов
Kick-out meeting
Support Поддержка
Аккаунтинг (фин.отчеты)
Коммуникации
Демо
Проектный менеджмент
Завершение
Поддержка
Мониторинг
Исполнение
Трекать время разработчикам и ПМ!
! Задача - правильно выбрать фреймворки разработки
Нетехнические фреймворки разработки
● Waterfall
● Incremental
● Iterative
● Spiral
● Lean
○ Agile Agile-манифест https://agilemanifesto.org/iso/ru/manifesto.html
■ Scrum
■ Kanban
● RAD
● V-model
● PMI
Технические фреймворки разработки:
● Dynamic systems development method (DSDM)
● Rational Unified Process (RUP)
● Unified Process (UP)
● Featured Driven Development (FDD)
● Behavior Driven Development (BDD)
● Extreme Programming (XP)
● Rapid Application Development (RAD)
● Microsoft Solutions Framework (MSF)
Планирование
Постановка задач
Какие еще типы задач?
● Задача на рефакторинг
● Хот-фикс
● Задача на исследование
● Задача на инициализацию / разворачивание
приложения
● Архитектурные задачи
Что должно быть в задаче?
● Суть и условия задачи
● Предыстория*
● Цепочка выполнения задачи*
● Вариант решения*
● Не писать в имени задачи что нужно делать, только о чем задача!
Оценка рисков и неопределенностей
● Внутренние сложности календарного планирования
● Увеличение требований со стороны заказчика в ходе
реализации проекта
● Текучка кадров
● Нарушение спецификаций
● Низкая производительность
● новая технология
● неопытность исполнителя в области выполнения задачи
● недостаток информации о задаче на момент оценки
https://blog.iteam.ru/metod-kriticheskoj-tsepi-effektivnoe-upravlenie-proektami-s-ispolzovaniem-buferov-vremeni-i-resursov/
Бюджет. Важно убедиться, что с бюджетом все ок.
Расписание Бюджета
Необходимо вовремя получать оплату на отдельных этапах работы.
Т.е. заранее сообщать заказчику три основных вопроса по бюджету:
● Когда?
● Сколько?
● На что?
Бюджетирование может быть выполнено по:
● по видам работ;
● статьям затрат;
● отчетным периодам;
● рискам;
● иной структуре.
Расписание проекта
Необходимо учесть:
● в какой момент времени какие ресурсы будут задействованы
● на какой момент какие ресурсы будут необходимы
● когда в базовый план могут вноситься изменения
● на каких работах какие результаты будут предоставлены
● отметьте основные вехи или milestones
● ........
Инструменты: Roadmap, Baseline, Gantt chart,
Project Schedule, Project Calendar
Архитектурные навыки
● Quality Attributes
● Cross-cutting Concerns
● Reference Architecture
● Microservices
● Single Page Application
● RESTful services
Определить ресурсы со стороны клиента
Определить Stakeholders
Важно! заказчик - это Product Owner, т.е. член команды.
С ним всегда надо быть на связи и согласовывать ПОЭТАПНО все стадии проекта.
Сотрудники:
• Лица, принимающие решения;
• Специалисты и консультанты со стороны клиента;
• Лица, отвечающие за оплату и инвойсы.
Технические ресурсы:
• Доступы
• Вся необходимая документация
• Консультации и лицензии (при необходимости)
• Сервера и софт
Определить ресурсы компании
Сотрудники:
• Проверьте, чтобы они были свободны на время проекта
• Что они знакомы со всеми необходимыми технологиями
• Что у них есть все доступы и информация
• Что их расписание совпадает с расписанием проекта
Технические ресурсы:
• Сервера
• ПО
• Устройства для тестирования
• Консультации и лицензии (при необходимости)
Принципы планирования
● Планировать сроки должны программисты, а не менеджеры (декомпозировать задачи)
● Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи (буфер примерно 10-20 %)
● Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов
● Члены команды должны максимально плотно взаимодействовать друг с другом
● Распределять роли разработчиков
● Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование
● Нельзя торопиться, нарушать план и уменьшать время разработки ПО. Немного опережать сроки.
● Задокументируйте планирование с помощью подходящего таск-менеджера
● Расставляйте приоритеты задачам и концентрируйтесь на главном (спросить у заказчика, что самое главное!)
● Всегда писать им задач кратко, без описания. Для быстрого поиска.
● Согласовать версии ПО по совместимости, например Windows 95 и 2016
Инициация
Запуск проекта
Поступление денег на наш счет
Подписание контракта
Итоговая встреча
Максимальное понимание задач и требований!
Не давать доступ к коду
Еще раз проговорите детали
Контракт: изменения, поддержка
Будьте внимательны с пунктами:
• Предмет договора
• Сроки
• Права и обязанности
• Порядок расчетов
• Сдача - приемка работ
• Ответственность и гарантии
• Срок действия и порядок расторжения
• Возможность изменения стоимости и времени при переоценки проекта.
• Контент! Временные условия залива контента! Будем отчитываться по результатам: основная стадия - оплата, заливка контента - оплата остатка.
• Внесение изменений, после подписания контракта оплачиваются отдельно.
Договоры на поддержку
Будьте аккуратны! Примените SLA
Менеджер ДОЛЖЕН знать контракт!
Виды контрактов:
• Firm Fixed Price
• Time & Materials
• Dedicated Development Center
Оценка сроков, стоимости и ресурсов.
Когда? Сколько?
Что главное в оценивании?
• Все согласны?
• Сколько лиц оценивали?
• Ничего не забыть, проверить оценки
• Проверять оценки у других спецов
• Регулярные оценки на разных стадиях проекта
Опрос клиента, шаблон оценки,
Statement of Work)
Подтверждение оценки
• Почему так много?
• Почему так мало?
• А это тут зачем?
• А почему это забыли?
• Почему двоякие формулировки?
• Где риски, буфер, тестирование?
• Где встречные вопросы?
Процесс оценивания
• Внутреннее сопротивление
• Внешнее сопротивление
Методики оценки
Story Points 🃏
Этот метод оценки трудоемкости задач в Agile и Scrum. Оценка сложности реализации User Story и других задач.
Ключевая особенность «Стори Поинтов» состоит в том, что эта метрика не привязывается к конкретному времени, такому как дни или часы разработки. Вместо этого используются относительные единицы, которые не позволяют определить точное время, которое будет затрачено на разработку, но при этом помогают быстро и эффективно приоретизировать задачи в зависимости от их сложности.
• Expert Judgment estimating
• 3 point estimating / PERT Оценка по 3 пунктам
• Comparative estimating
Сравнительная оценка (аналог)
Сравнительная оценка включает сравнение текущих или завершенных задач или проектов, для которых у вас есть определенные меры времени и необходимых ресурсов. Этот метод основан на прошлом опыте, а не на мнении, но он полезен только в том случае, если аналогия верна. Сравнительный метод обеспечивает прочную основу для оценки того, доступна ли информация. Затем эту информацию необходимо будет увеличить или уменьшить для удовлетворения потребностей оцениваемого проекта.
• Parametric estimating
Статистическая оценка «обратного моделирования»
Параметрическая оценка использует определенные параметры, с помощью которых можно измерить проект, такие как время или стоимость, затраченные на создание конкретного результата проекта. Этот процесс можно повторить для ряда различных результатов, умноженных на количество каждого из параметров, необходимых для выполнения требований проекта. Требуется разумный объем надежных данных, чтобы сделать этот метод оценки легко доступным.
• Bottom-Up estimation Оценка «Снизу вверх»
Наиболее точный способ оценки — это построение иерархической структуры работ (WBS) и для оценки всех компонентов работы самого нижнего уровня. Здесь проект или задача разбиваются на более мелкие задачи до тех пор, пока не появится возможность оценивать каждую в отдельности.
Этот подход не следует использовать для первоначальной оценки проекта т.к. требует больше всего времени, тогда как приблизительная оценка может быть всем, что требуется для того, чтобы дать проекту добро или нет.
Применимость оценивания
От системного архитектора к команде
Плюсы:
скорость оценивания, есть
конкретный ответственный.
Минусы:
команда может быть не согласна
и делать работу без энтузиазма, оценка
может быть не точной
От команды на утверждение…
Плюсы:
изначальное вовлечение в проект,
более точная оценка с возможностью
распределить по задачам.
Минусы:
может занять больше времени,
ответственность за оценку распределена
между всеми членами команды
Лучшая в мире практика оценки!
Это когда оценивает проект та же команда, которая
будет его делать…
Этапы оценивания
-50% - +100% Оценка порядка величины
-30% - +50% Концептуальная оценка / Ballpark estimation
-20% - +30% Предварительная оценка
-15% - +20% Окончательная оценка
-10% - +15% Контрольная оценка
● Диаграмма Гантта
● Roadmap
Определяем требования и делаем наброски структуры проекта
Проектная документация
• Бриф / RFP (Request for proposal) / Canvas +
• Outline / Общее задание на проектирование
/ Project Proposal
• Statement of work (Техническое задание)
/ Project Charter
• Дизайн / Research Phase
/ Техническое задание
Знакомство и работа с клиентом
Личная встреча с клиентом, Сэилзом, ПМ и Лидом
Задача – понять потребности клиента
Задача – понять психотип клиента
