Александр спрашивает:
— Мое видение эффективного процесса разработки. Имеет ли право на жизнь? Что улучшить-добавить-убрать?
Когда я вижу такую диаграмму, я пытаюсь воспринимать ее примерно так:
Effective SW Development — это ни что иное, как совокупность Specifications, Development, Time tracking... Которые, в свою очередь, подразделяются на следующие компоненты...
Если посмотреть в самые нижние уровни, можно увидеть, что, пожалуй, не стоит рассматривать диаграмму как декомпозицию:
Version Control:
- History of all changes
- Team work
- Makes work easy
То есть, связь в диаграмме не очень-то похожа на «состоит из / является частью», больше на «как-то связано с». Но тогда получается, что отсутствие линии должно говорить об отсутствии связи, что тоже явно неверное предположение: как же могут оказаться несвязаны User interface or API и Usability testing, или, скажем, Test Driven Development и Meet the specifications.
Тогда это больше похоже на облако тегов. Или «заметки на полях» про которые надо бы не забыть сказать на презентации. Да и основная декомпозиция состоит из странного набора: тут есть и чисто технологические вопросы (Version control, Bug tracking, Code review), есть и методологические проблемы (Development, Specifications, Testing) и общеменеджерские вопросы (Time tracking, Risk management, Early Problem Detection) да и организационные тоже (Common place for all related information).
Выходит, это чеклист? Не забудьте сделать это, это и это — и будет все хорошо? Кто позаботится об этом и этом — у того и будет эффективный процесс разработки?
Кстати, это нельзя называть и процессом. Процесс — это нечто протяженное во времени, активно происходящее в нем. Тут же мы имеем некоторые наброски тем, в которых нет связи со временем. В тексте самых нижних уровней есть кое-какие указания на неоднородность во времени:
- Find problems at early stages
- History of all changes
- No early optimization
- Processes description
- Quick start guides
Нет, в общем, процесса никакого, так, намеки только. Эффективности тоже нет — слово одно. Как считается эффективность, что максимизирует такая «схема» — неизвестно. О каждом пункте можно отдельно рассуждать и спорить, все они, без сомнения, имеют практическую пользу, обсуждаются на конференциях и активно применяются в успешных проектах. Но зачем же их собрали в столь странную компанию и подают под видом процесса?
Я думаю, это подойдет только для игры в Buzzword Bingo. Годный набор, чтобы сделать примерно такие карточки, и слушать, как кто-нибудь со сцены будет все это озвучивать:
| Meet the Specifications | Self Documented Code | Risks Monitoring | Coding Style | Early Problem Detection |
| Test Driven Development | Testing of Maintainability | Avoiding Antipatterns | Refactoring When Needed | Team Work |
| Assign Issues to Responsibless | Knowledge Sharing Inside the Team | Set of Acceptance Tests | Avoiding Complexity | Usability Testing |
| History of All Changes | Risks Tracking | Regression Tests | Metrics | Design Patterns |
| The Only Base For All Issues | No Early Optimization | Separate Testing Team | What Could Be Done to Prevent Risk? | Nightly Builds |
Присылайте свои вопросы через форму — http://dou.wufoo.com/forms/nnnnn-/. Ответы — каждый понедельник.