Документ описывает основные антипаттерны в управлении проектами разработки программного обеспечения, выделяя семь ключевых ошибок, таких как пренебрежение качеством и отсутствие тестирования. Для каждой ошибки предлагаются решения и рекомендации по улучшению процессов, включая управление рисками и важность архитектуры. Автор подчеркивает необходимость акцентирования внимания на качестве и предотвращении распространенных проблем с помощью проактивного подхода к управлению проектами.

1. Борис Вольфсон

2. Вольфсон Борис
Технический директор

3. Проекты
• Размер проектов
– От 3 месяцев до нескольких
лет
• Типы проектов
– Коммерческое ПО
– Веб-сайты
• Размер команды
– Не более 20 человек
– Большая часть справедлива и
для более больших команд

4. О чем доклад?
Антипаттерны из собственного опыта по
следующей схеме:
Способы
Антипаттерн Причины Результаты
устранения

5. 1. Пренебрежение качеством ради
сроков

6. Псевдовыход
• Делаем быстрей, но хуже
• Не исправляем мелкие баги
• Увеличиваем технический долг

7. Результаты
Увеличение стоимости
Стоимость разработки
разработки в будущем
Кратковременный
рост скорости
Время

9. Демотивация команды

10. Как избежать?
1. Не жертвуйте качеством, а ставьте его
на первое место
2. Быстро исправляйте ошибки, не
«храните» их
3. Проводите политику нетерпимости к
дефектам
4. Используйте инженерные практики

11. 2. Добавление разработчиков в
конце опаздывающего проекта
• На проект опаздывает: «Что делать?»
• Конечно же увеличить «ресурсы»!

12. Срок = Трудозатраты / Ресурсы

13. Мифический человеко-месяц

14. Закон Брукса
Если проект не
укладывается в
сроки, то добавление
разработчиков
задержит его еще
больше

15. Что лежит в основе закона
Брукса?
• Затраты на интеграцию новых
разработчиков
• Зависимость частей программной
системы
• Количество взаимодействий между
разработчиками растет квадратично

16. Что делать?
1. В начале проекта сформируйте
небольшое ядро команды
2. Наращивайте размер команды только
после разработки архитектуры
3. Держите размер команды
минимально возможным для
конкретного проекта

17. 3. Откладывание тестирования
на самый последний момент
Сбор и анализ
требований
Создание
архитектуры
Разработка
Тестирование

18. Причины
• Излишний оптимизм команды и
менеджеров
• Недооценка времени на
тестирование и отладку
– Около 25% длины проекта в
среднем
• Желание быстрей сделать
проект
• Отсутствие Definition of Done

19. Проблемы?
• Поздний фидбек от
тестировщиков
• Отсутствие контроля качества
на предыдущих этапах
• Непредсказуемое время на
отладку
• Срыв сроков проекта «в самом
конце»

20. Делайте проекты итерационно!
Анализ Анализ Анализ Анализ
Планирование
Планирование
Планирование
Планирование
Планирование
Дизайн Дизайн Дизайн Дизайн
Кодирование Кодирование Кодирование Кодирование
Тестирование Тестирование Тестирование Тестирование
Выпуск Выпуск Выпуск Выпуск
Итерация / Спринт
Не откладывайте тестирование в
итерации на конец!

21. 4. Закрытие глаз на проблемы
Оптимизм
всего лишь недостаток информации

22. Закрытие глаз на проблемы:
причины
• Наказание «гонца» с
плохими вестями
• Общий оптимизм команды
• Культура команды
– «Не принято говорить о
плохом»
– «Мы решаем проблемы по
мере поступления»

23. Управляйте рисками превентивно!
1. Составьте список рисков
2. Оцените риски
3. Назначьте владельцев рисков
4. Выработайте контрмеры
5. Следите за исполнением контрмер
6. Обновляйте список рисков регулярно

24. 5. Отсутствие технического
процесса
• Надо максимально быстро запустить
проект
• Надо выдавать максимум «business
value»
• Проект растет… и замедляется скорость
добавления нового функционала
Я прихожу в гости только
к тем, кто просрочивает
проекты

25. Что делать?
• Стройте процесс с самого начала
проекта
• Визуализируйте процесс
• Используйте практики экстремального
программирования

26. 6. Игры в технологии
• «Давайте использовать новый веб-
фреймворк, вчера вышла альфа-версия»
• «Я на конференции послушал про новую
тулзу, я за месяц переведу наш проект на
нее»

27. Результаты
• Резкий рост технологических рисков
• Желание «поиграться в технологии»
является самоподдерживающимся:
– Распространяется на всю команду
– Успех (или псевдоуспех) воспринимается
как повод к новым внедрениям
• Бизнес-фокус заменяется на
технологический

28. Что делать?
• Выработайте политики
использования и внедрения
новых технологий
– Технологии должны приносить
бизнес-ценность
– Технологии как конкурентное
преимущество
• Следите за новинками, и учитесь
не внедрять первыми, а внедрять
быстро

29. 7. Отсутствие архитектуры

30. Причины
• Хотим быстро запустить проект
• «У нас Agile, архитектура сама
появится»
• «Требования будут
изменяться, пока не стоит делать
архитектуру»
• «У нас нет времени на
технические задачи, надо делать
бизнес-функционал»

31. Что делать?
• Проектируйте архитектуру на старте
проекта
• Совершенствуйте архитектуру во время
реализации проекта
• Распространяйте знания об архитектуре

32. Семь смертных грехов
1. Пренебрежение качеством ради сроков
2. Добавление разработчиков в конце
опаздывающего проекта
3. Откладывание тестирования на самый
последний момент
4. Закрывание глаз на проблемы, думая, что
они сами рассосутся
5. Отсутствие технического процесса
6. Игры в технологии
7. Отсутствие архитектуры

33. Как быть «ангелом»?

34. Как быть «ангелом»?
1. Ставьте качество на первое место
2. Планируйте формирование команды
3. Начинайте тестирование как можно
раньше
4. Управляйте рисками превентивно
5. Проектируйте технический процесс в
соответствии с вашими нуждами
6. Осознанно выбирайте технологии
7. Выделяйте время на проектирование
архитектуры продукта

35. Вопросы и контакты
borisvolfson@gmail.com
www.facebook.com/borisvolfson
www.twitter.com/borisvolfson
Мы ищем специалистов в департамент разработки –
резюме можно присылать по адресу
b.volfson@hh.ru