понедельник, 31 марта 2008 г.

Классические ошибки разработки ПО

Важное свойство разработки ПО как профессии - необходимость постоянно обучаться.
Мы должны постоянно оценивать свою работу, обучаться новым технологиям и походам и т.п.
Любой успешный разработчик решает для себя эту задачу, или он перестаёт быть успешным :)
Но вот странная тенденция, которую я наблюдаю - подавляющее большинство людей, занимающихся разработкой ПО, предпочитают обучаться новым технологиям разработки, не пытаясь получить представление о работе других членов команды и самом процессе разработки.
Подозреваю, что с новешими фичами Framework 3.5 сейчас знакомо больше разработчиков, чем с "кирпичом" Code complete МакКоннелла.

Список из 30+ самых распространенных ошибок в разработке ПО, составленный МакКоннеллом - пример небольшого и невероятно ценного куска информации.
Список этот сейчас не обсуждается на форумах и, подозреваю, не висит ни у кого на стене, в отличие от диаграммы классов .net framework :)

Если ошибки из него возвести в ранг общепринятой терминологии, как "Паттерны проектирования", качество нашей работы должно вырасти больше, чем от перехода на .net framework 6.0

Ошибки, связанные с сотрудниками
1. Подрыв мотивации
2. Слабая команда
3. Неспособность управлять «проблемными» сотрудниками
4. Сверхвысокие обязательства, «героизм» команды
5. Добавление людей к отстающему проекту
6. Шумное рабочее место
7. Плохое взаимодействие разработчиков и клиентов
8. Нереальные планы
9. У команды нет «своего человека» среди топ-менеджеров компании-разработчика
10. Не все стороны заинтересованы в продвижении проекта
11. Отсутствие взаимодействия с конечными пользователями продукта
12. Политические решения в ущерб содержательной работе
13. Пассивное принятие желаемого за действительное

Ошибки, связанные с процессом разработки
14. Чрезмерно оптимистичные сроки
15. Недостаточное управление рисками
16. Проблемы с субподрядчиками
17. Недостаточное планирование
18. Команда с нереальными сроками игнорирует задачи планирования и сам план
19. Потеря времени на предпроектных процедурах (утверждение бюджета и т.п.)
20. Время на анализ и проектирование урезается в пользу кодирования
21. Неверные результаты проектирования
22. Время на процедуры Quality Assurance урезается в пользу кодирования
23. Задачи управления проектом не решаются
24. Слишком ранняя, слишком частая сборка проекта в релиз
25. В плане нет многих необходимых работ
26. Команда не укладывается в сроки, решением считается ускоренная работа на поздних стадиях
27. Неуправляемая «быстрая и грязная» разработка (code-like-hell)

Ошибки, связанные с продуктом
28. Множество ресурсоемких требований, в действительности необязательных
29. Добавление новых требований в ходе разработки (feature creep)
30. Множество интересных самим разработчикам требований, в действительности необязательных
31. Пассивные переговоры с клиентом, принятие нереальных планов под давлением
32. Необязательные исследовательские, «красивые» задачи в требованиях

Ошибки, связанные с технологиями
33. Синдром серебряной пули
34. Переоценка эффекта применения новых инструментов и методов
35. Смена инструментов разработки в ходе работы над проектом
36. Отсутствие автоматической системы управления кодом

Новые ошибки (не включенные в список за 1996г)

• Плановые оценки превращаются в сроки
• Чрезмерное «распараллеливание»: член команды одновременно решает слишком много задач
• Игнорирование, недооценка проблем организации работы команд, распределенных географически (global development)
• Нечеткое видение проекта (project vision)
• Положения в плане и проекте имеют приоритет над действительным положением дел (trusting the map more than the terrain)
• Аутсорсинг как средство снижения затрат

В конечном счете, кто может поспорить хоть с одним пунктом? И какой разработчик не сможет изменить свой проект к лучшему, держа в уме только этот список?
Перевод выполнен мною, он не полон и не идеален. Перевести на русский описание каждой ошибки оказалось сликом большим трудом, поэтому получился такой вот cheatsheet.
Оригинал этого списка есть здесь и здесь, каждый пункт обстоятельно откомментирован.
На написание этого поста меня сподвиг блог Coding Horror

Комментариев нет: