Максим Дроздов, Project Manager, ISS Art. Работаю в ИТ более 8 лет. Руковожу большими и интересными проектами. Навожу порядок в процессах и снижаю энтропию :) Professional Scrum Master. Работал программистом и люблю это дело. Образование — прикладные математика и физика. Источник радости для меня — настраивать процессы и видеть слаженную команду, где учитывают мнение каждого участника и всю энергию направляют на доставку качественного продукта в соответствии с целями проекта. В своем докладе хочу показать, что навести порядок в сложном проекте могут простые и широко известные средства, которые нужно правильно применять.

1. Чек-листы и
порядок на проекте
www.issart.com
Максим Дроздов

2. Цель
Показать, как простые документы
помогают наводить порядок в
сложных ИТ проектах
2

3. О чём пойдёт речь
1. История одного проекта
2. Когда использовать чек-листы
3. Как использовать чек-листы
3

4. 1. История одного проекта
41. История

5. О чём проект
Массовые почтовые
отправления по США с
помощью разных
транспортных компаний.
Команда до 12 человек
Методология Agile
Лояльный заказчик
Интеграция более, чем с 12
внешними сервисами: транспортные
компании, сервисы отслеживания
отправлений, поддержка пользователей,
карты, платежные сервисы и т.д.
Мобильные клиенты и API.
Технологии: PHP, MySQL,
Objective-C, Java.
51. История

6. Сложности
● много внутренних связей
● много интеграций
● высокая изменчивость требований
● распределённая команда
61. История

7. Проблемы
● сложности с оценкой задач
● превышение оценок
● нарушение сроков
● лишение премий
71. История

8. больно оттого, что
при оценке задачи тяжело учесть все связи с:
● функционалом системы
● архитектурой системы
А ещё учесть все значимые риски.
81. История

9. Ищем причины
● думаем, как улучшить ситуацию
● ищем причины превышений оценок
9
Главная причина:
требования
обрывистые, изменчивые
1. История

10. Находим решение
★ предлагаем заказчику аналитика
★ успешно продаём эту идею
★ аналитик описывает систему
★ неопределенность начинает снижаться
101. История

11. но тут...
заказчик отказывается от
аналитика,
так как не осознаёт пользы от хорошего описания требований
111. История

12. Безвыходная ситуация
● заказчик вне себя
● и теперь требует договора в формате fixed price
● нужны честные оценки (без искусственных завышений)
● требования сумбурные и противоречивые
● нет аналитика
121. История

13. Сумасшедшая идея
● Аналитику делают разработчики
● МП их успокаивает и помогает им
131. История

14. Систематизация знаний о системе
Простые чек-листы по ключевым аспектам проекта:
● перечень юз-кейсов (use case, вариант/сценарий
использования),
● перечень архитектурных компонентов,
● перечень тест-кейсов.
141. История

15. да, просто
несколько
чек-листов
Один чек-лист - одностраничный
документ, тезисный список, без деталей
151. История

16. которые легко
просматриваются
при оценке
каждой задачи
чтобы гарантированно ничего
не забыть
161. История

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. История

21. Checklist
driven
development
:)
Простой способ навести
порядок
Использовались чек-листы:
Юз-кейсы
Компоненты
Риски
Общие требования к UI
Шаблон описания задачи
Процесс оценивания
Тест-кейсы
Планирование сроков и бюджета
211. История

22. ProfitProfitProfit
● Аналитика сделана
● трассировка требований
● разработчики получили новый
опыт в смежной области
● оценивать задачи стало проще
● оценки начали соблюдаться
● заказчик понял риски
● самые выгодные фичи были
реализованы в первую очередь
● продукт вышел в свет!
● все получили премию :)
Приятные плоды
221. История

23. 2. КОГДА использовать чек-
листы
232. Когда

24. Когда
документация
не работает
24
избыточная
устаревшая
противоречивая
беспорядочная
неудобная
2. Когда

25. Когда нет
ресурсов
на создание и
поддержку
полновесной
документации
252. Когда

26. Когда срочно
нужен
порядок
и нет времени ждать
262. Когда

27. 3. КАК использовать чек-листы
273. Как

28. Краткость
Принцип KISS и бритва Оккама в действии.
пользоваться
● удобно
● быстро
● легко
283. Как

29. Системность
итеративный подход
29
инкрементальный подход
3. Как

30. Системность
итеративный подход
30
инкрементальный подход
отдельные
части с
высокой
детальностью
3. Как

31. Системность
итеративный подход
31
инкрементальный подход
отдельные
части с
высокой
детальностью
но не видно
всей системы
3. Как

32. Системность
итеративный подход
32
инкрементальный подход
3. Как

33. Системность
итеративный подход
чек-лист -
уровень
невысокой
детальности
33
инкрементальный подход
3. Как

34. Системность
итеративный подход
чек-лист -
уровень
невысокой
детальности
зато видно
всю систему,
как целое
34
инкрементальный подход
3. Как

35. Актуальность
свежий вид системы всегда
перед глазами
353. Как

36. ИТАК
36

37. Чек-лист не
заменяет
голову
зато он
хорошо ей
помогает
37Итак

38. Чек-лист не
заменяет
голову
зато он
хорошо ей
помогает
38Итак

39. www.issart.com
Дроздов Максим
Email: MDrozdov@issart.com
Skype: mdrozdov_issart
Спасибо за внимание!
39