微软项目：求生法则 读书笔记
书是在china-pub下载的。书的简介是这么介绍的：
书名: 微软项目：求生法则
英文原书名: Software project Survival Guide
作者: 史蒂夫.麦克康纳尔
译者: 余孟学
书号: 7-111-07732
页码: 346
定价: ￥25.00
会员价: ￥22.50
币值: 225
本书是特为每个关注项目开发成败的人，特别是寻些没有经过正式软件项目管理训练的
人而写的一本书。作者利用在研究与工作中获得的经验告 诉您项目开发过程中的规划、
设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简
可靠的框架来成功地管理项目。不论是新手还是老练的项目管理者教将从中获益匪浅。
本书将是每个项目人员案头不可或缺的指导书。
本书作者曾著有两本颇受好评的微软经典著作，通过他的亲身经历，现身说法，使您获
得“原汁原味”的微软经验与法则，助您攀着巨人肩膀步入巨入行列！
有一些感想记录下来
看这些书，感觉核心思想就是告诉人如何去控制（改进）软件开发的过程。
对照自己的开发经历来说，
大多数时候都是随心而为，虽然在大体方向上面随着代码写的越多，经验积累的越多，对程序整体走向的控制力越强，但还是在某些方面有比较大的不足。
也就说，以前靠经验，现在要靠理论来指导。
从没有过程控制到有目的的控制软件开发过程，到改进软件开发过程。说来容易，作起来难。
按章节来说说，
直接进入第二章
第二章 软件项目求生测验
中心要点
首先，开始一个项目的时候，最好作足准备工作，
这样项目存活下来的机率要大的多。
验证一个项目是否会成功，可以使用下面几个要点来检查
需求
>是否获取了明确的需求。
>是否跟最终的用户交换了意见
>是否有规范的文档
（文档不在于多和详细，而在是否描述了应该记录的信息）
>是否有接口雏形来描述软件功能
规划
>有否详细规划工程进度表
包括
人员的出勤时间
配置程序时间
沟通交流时间
整理资料时间
>有否架构设计和说明文件
>有否所有开发团队都认可的时间表和工作进度表
项目控制
>项目是否有一位决定权的主管并充分获得全力支持
>项目主管是否有能力兼股项目
>项目是否有明确的里程碑进行控制
>项目的所有变更是否能及时通达到项目相应的人员那里
>有否控制源代码版本，缺陷等软件支持
风险管理
>有否及时更新的风险控制表
>能够敏感的查觉到风险并标识出来
人事
>人力足够么
>有否一个能带领大家成功的技术主持人
>工作组的人具备项目开发的技术么？
>工作环境是否令人满意
本章节说的如何在产品出来之前就验证软件是否能够成功。
其实也就依据一些规律性的经验总结的规则，仔细一看，我也可以总结出来大多数。
只可惜大多数的人或公司都作不到。
因为我们嫌麻烦，所有我们只作到了一半，甚至没到一半，自然最后的结果可想而知了。
前两天，看了一个小故事，这里来引用一下。
Half-assed
刚到Stanford念书时，发现教室的设计很特别：剧场式阶梯、马蹄型桌子，坐下来，看到桌上有一条长长的细缝。
白蚁蛀的吗？怎么可能这么整齐！“这是插名牌的！”同学告诉我。注册时，教务处发给你一张横式长方形厚纸卡，上面写着“王文华”三个字。上课时你要把名牌插进细缝，好让老师看清楚你的名字，方便点你发言。阶梯式教室、马蹄型桌子，都是为了让老师同学看到彼此，讨论时容易产生火花。
学期中我把学校发给我的名牌搞掉了，自己做了一个，插进细缝中。下课后老师跟我说：“我看不清楚你的名字。”“为什么？”“因为你做的名牌，名字和纸张底部之间的留白不够，插进有深度的缝隙，一半名字都塞进缝隙里。”我拿出名牌，果然是这样，“你应该叫教务处帮你重做，他们做的名牌都是精密量过的，插进细缝中刚刚好。”老师临走前一语双关地说：“把你那张half-assed的名牌丢了吧，那张名牌只让我们看到一半的你。”
当时我听不懂“half-assed”（直译：半个屁股）是什么意思。去查字典，上面写着“凡事只做一半，不注细节”。
没错，在那之前，我一直是个大而化之、半个屁股的人。好的学校，连学生名牌上名字和页缘之间的距离都斤斤计较，而过去的我，只会嘲笑这样的人吹毛求疵。
Stanford第一年暑假，我和一位带着两岁小孩的朋友去拜访在苹果计算机工作的学长。在员工餐厅吃午餐，朋友抱着小孩，吃不到两口，学长走到角落，拿来一张儿童椅。“你们的员工餐厅还有儿童椅？”“当然啊！虽然很少员工会把小孩带到公司，但我们总要预防那种万一！”
毕业开始工作后，常常出差。有一次我坐新航的长程飞机。第一餐结束后，机舱的灯变暗。空服员问我要不要睡觉，我说要。于是她把一张贴纸贴在我的椅子上，上面写着客人要休息，下次餐饮不要打扰。大部分的航空公司会拍醒你，问你要不要用餐，你说不要，但被吵醒后再也睡不着。新航用一张贴纸，两全其美地解决问题。
工作这些年来，我发现成功的人和公司，屁股都很完整。不论大事小事，他们总能做到滴水不漏。他们不靠革命性的创意，因为革命性的创意可遇不可求。他们有耐心和能力把例行公事做到完美，和二流之间的差别就在细节。
我永远记得Stanford的细缝、苹果的儿童椅，和新航的贴纸。它们代表的，是一种细致和体贴，一种成本很小、容易做到，却是大家最不屑一顾的美德。所以，就叫我吹毛求疵吧！因为我终于醒悟到工作路上的颠簸，都是因为我行走时少了半边屁股。
第三章
使用了"开发程序"这个词组，
容易让人迷惑。应该叫"开发流程"
它提出上下游的关系，并认为在每个阶段应该堵截各自的错误。
它同时给出了错误产生的阶段以及在此阶段产生的错误需要的多大代价去修正
分别是
需求清理
架构设定
细节设计
构建过程
按此顺序，修改错误造成的代价越小。
未完待更新
