Максим Дроздов, Project Manager, ISS Art.
Работаю в ИТ более 8 лет. Руковожу большими и интересными проектами. Навожу порядок в процессах и снижаю энтропию :) Professional Scrum Master. Работал программистом и люблю это дело. Образование — прикладные математика и физика.
Источник радости для меня — настраивать процессы и видеть слаженную команду, где учитывают мнение каждого участника и всю энергию направляют на доставку качественного продукта в соответствии с целями проекта.
В своем докладе хочу показать, что навести порядок в сложном проекте могут простые и широко известные средства, которые нужно правильно применять.
5. О чём проект
Массовые почтовые
отправления по США с
помощью разных
транспортных компаний.
Команда до 12 человек
Методология Agile
Лояльный заказчик
Интеграция более, чем с 12
внешними сервисами: транспортные
компании, сервисы отслеживания
отправлений, поддержка пользователей,
карты, платежные сервисы и т.д.
Мобильные клиенты и API.
Технологии: PHP, MySQL,
Objective-C, Java.
51. История
6. Сложности
● много внутренних связей
● много интеграций
● высокая изменчивость требований
● распределённая команда
61. История
7. Проблемы
● сложности с оценкой задач
● превышение оценок
● нарушение сроков
● лишение премий
71. История
8. больно оттого, что
при оценке задачи тяжело учесть все связи с:
● функционалом системы
● архитектурой системы
А ещё учесть все значимые риски.
81. История
9. Ищем причины
● думаем, как улучшить ситуацию
● ищем причины превышений оценок
9
Главная причина:
требования
обрывистые, изменчивые
1. История
10. Находим решение
★ предлагаем заказчику аналитика
★ успешно продаём эту идею
★ аналитик описывает систему
★ неопределенность начинает снижаться
101. История
12. Безвыходная ситуация
● заказчик вне себя
● и теперь требует договора в формате fixed price
● нужны честные оценки (без искусственных завышений)
● требования сумбурные и противоречивые
● нет аналитика
121. История
17. Чек-лист юз-
кейсов
(функционала)
При оценке задачи
необходимо учесть её
влияние на все
возможные юз-
кейсы
Формат чек-листа
Эктор : Блок вариантов использования -> Вариант
использования
Пример чек-листа юз-кейсов по экторам
1. Admin
a. Admin : Users -> Activity
b. Admin : Settings -> Edit prices
c. Admin : Reports -> Filter Settings
d. Admin : Providers -> On/Off carrier
e. …
2. Primary User
a. Primary User : Shipping -> Send parcels via Store Portal
b. Primary User : Shipping -> Send parcels via Wizard
c. Primary User : Shipping -> Track parcels
d. ...
3. System
a. System : Settings -> Set the commmision
b. System : Reconciliation -> Import report
c. ...
4. ...
171. История
18. Чек-лист
компонентов
архитектуры
При оценке задачи
необходимо учесть её
влияние на все
возможные
компоненты
системы
Формат чек-листа
Простой иерархический
Пример чек-листа компонентов системы
● Services
○ Providers:
■ USPS
■ Stamps.com
■ Intuiship
■ Fedex
■ UPS
■ Express 1
○ Payment services:
■ PayPal
■ Authorize.Net
○ Store Integration
○ Shipsurance
● Login system
● Sign up system
● Stores
○ Orders
○ Batches
○ eBay
○ Amazon
○ ...
181. История
19. Шаблон
описания
задачи
И это тоже чек-лист
для процесса
проектирования и
оценки изменений
● Analytics
○ Description (пользовательская история,
краткое описание функционала)
○ Business goal (цель заказчика,
обычно связана с прибылью)
○ Use cases (зависимые юз-кейсы из чек-листа)
○ Non-functional Requirements (Usability,
Reliability,Performance,Supportability)
○ Suggestions (предположения команды)
○ Questions (вопросы к заказчику)
● Architecture
○ Data (изменение схемы данных)
○ Technologies (затрагиваемые технологии из
всего стека)
○ Components (зависимые компоненты из чек-
листа)
○ Implementation and estimation (декомпозиция
с оценками и рисками)
○ Deployment
191. История
20. и ещё чек-листы
● чек-лист рисков, с опорой на специфику проекта
● общие требования к UI проекта
● тестовые чек-листы - тезисный список тест-кейсов
Ответственный за чек-листы и их обновление -
менеджер проекта.
201. История
22. ProfitProfitProfit
● Аналитика сделана
● трассировка требований
● разработчики получили новый
опыт в смежной области
● оценивать задачи стало проще
● оценки начали соблюдаться
● заказчик понял риски
● самые выгодные фичи были
реализованы в первую очередь
● продукт вышел в свет!
● все получили премию :)
Приятные плоды
221. История