《死亡之旅》 第2版
来源:互联网 发布:唯品社的域名 编辑:程序博客网 时间:2024/06/02 13:25
如果你把这本书当作《敏捷软件开发》这样的普适的软工书来读,希望从里面找到一些对日常项目有裨益的提议,就不会有什么收获。
因为这本书只教人如何采取保守主义,实用主义的策略,"挺过死亡之旅式的项目而没有损伤"。
这是个有趣的话题。
因为死亡之旅式的项目一般比较难看,所以很少书籍会从这里面去总结"最佳实践"。大家更愿意在正常项目的基础上展开论述,通过"最佳实践"指导大家避免跌入死亡之旅的尴尬田地。
可惜,死亡之旅式的项目依然充满我们周围,而每一个被挺过去的死亡之旅项目,都只作为经验存留于参加人员的记忆里。所以这本书会提醒你,总结正常项目的"最佳实践"让你更好的完成任务很重要,总结死亡之旅项目的"最佳实践"教你如何最大限度的挺过项目同样重要。
但是,人人的死法可能不同,一本求生指南救不了全世界,当你想起自己也该总结一下时,这本书50%的目的就达到了。
一、政治,政治,政治
政治,玩家,谈判。IT程序员,最不擅长的可能就是这些领域,但很多死亡之旅其实都是源于政治上,一场好的谈判可以扭转整个项目的态势,效果比N天N夜的加班顶用得多。所以,程序员也应该注意政治与谈判的基本技巧,有备而战。
书中美国式的政治与中国特色的当然很不同,但起了个头,大家就可以自己琢磨下去。
二、保守主义,实用主义放光芒
死亡之旅的项目,就是以挺过去的最高目标的,如果还带着平常项目里的技术狂热,英雄主义,就一定死得更惨。
团队组建:一定要使用即时可用的人选,不要想着可以在项目过程中对沙包进行转化。不合用的人员,首先是不能当可用兵员算入项目,如果被硬塞了,那就让他能做什么做什么,idle也好,去看复印机也好,不用费心机去不用培训,更不要安排高手去做陪练。
工具、技术、软件过程选用:
不试用任何新技术(除非合同里面要求),使用最舒适的开发环境,最简单的技术。
1.尽量不要选用团队里都没有经过培训的东西
2.尽量不要使用c/c++/smalltalk/LISP/人工智能
3.尽量呆在windows里,不要使用Unix等系统
4.尽量使用所见即所得的开发环境
三,需求管理
作者与XP, RUP里一样的强调,区分需求优先级,通过谈判延后或取消优先级低的需求。
而单独的OOAD方法论里,没有需求优先级和需求变更记录这些重要方面。
四,其他
太多,都在书里划了线,不记了。
看软工类的书,最重要还是自己的思考,否则很快看完,然后很快忘掉,特别是国外的情况和我们并不相同时。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=407730
- 《死亡之旅》 第2版
- 《死亡之旅》 第2版
- '死亡之组'结束'死亡之旅'
- 死亡之旅(二)
- 死亡谷之旅
- 死亡之旅(摘要)
- 死亡之旅——创业篇
- centos 7 一次死亡之旅
- 射击双人小游戏之死亡空间2
- 理论数学之死亡??
- 企业发展-死亡之路
- 微软之走向死亡
- 微软之走向死亡
- 微软之走向死亡
- 死亡之ping
- 死亡之ping
- 这不科学 —— 读《死亡之旅》
- 死亡之诗之四
- 在Spring+Hibernate框架下,用动态语言写业务类
- 我的最小项目管理工具集
- Antlr--看Hibernate3如何解释HQL语言
- MartinFowler的《Language WorkBench》笔记
- 在页面中使用WebWork的token标签解决表单重复提交问题
- 《死亡之旅》 第2版
- Groovy写业务类、框架类的那一吨好处
- 编码与字体
- MartinFowler: IOC, not IOC Container
- Groovy 笔记
- 用Groovy Template 生成代码 2nd
- 交互式的ant 调用与自写的Ant Task
- 线程对象的几个重要的方法
- 2005年阅读的网站RSS与schedule