Креш - тест : бачення ефективного процесу розробки
Олександр запитує:
- Моє бачення ефективного процесу розробки. Чи має право на життя? Що поліпшити-додати-забрати?
Коли я бачу таку діаграму, я намагаюся сприймати її приблизно так:
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- / . Відповіді - кожен понеділок.
Опубліковано: 01/10/12 @ 06:58
Розділ Різне
Рекомендуємо:
Італійський керамограніт з російською душею .
Apple виплатить $ 86 тисяч Китайському видавничому дому за порушення Закону про захист авторських прав .
Схуднути не виходячи з дому тепер просто .
Успішні кейси просування в Яндексі . Частина 7 . Сітка під CPA .
27 жовтня, Київ - JavaDay 2012