《微软开发快速秘籍》读书笔记1-典型错误

1快速软件开发的策略

最佳可能性工作进程：
1)避免典型错误：避免典型毛病，节省修改缺陷的时间和成本
2)开发的基础：设计好的开发基础，避免中途改变产品观念时，重新架构。
3)危机管理：考虑各种危机，制定预案。
4)工作进程导向实作方式
4个支柱都要坚固！    

快速软体开发的四种面向：
人员，过程，产品，技术

人员因素是首位（是会萎缩或激发其它生产力的因素）
以专案团队方式作人员选择考虑。

过程包含管理和技术方法学。（避免重做，确保品质，开发基础，危机管理，资源目标，生命周期计划，顾客导向）

产品规模(80,20规则)和产品特色(执行速度，内存是用，稳定性等 把这些核时程比，哪个更重要)能提供缩短开发时间的机会。

技术（高效的语言和工具）

2典型错误

列出一张属于你自己的错误实做方式表
在执行专案检讨时从你的或其它团队中学习并列入表中，在于同事交换彼此的经验时学习并列入表中，把错误表放在醒目位置让别人学到并不再犯同样的错，在和网友交流时把自己的经验写在下面的评论中和其他人分享：）。

人力方面的典型错误	过程方面的典型错误	产品方面的典型错误	技术方面的典型错误
逐渐失去动机 素质不佳的成员(快速加入应<顺利完成) 无法掌握问题成员 夸大的言谈 在一个延迟的专案中增加人员 吵闹拥挤的办公室 开发人员和顾客间的摩擦 不切实际的期待 缺乏有力资助的专案 取法相关人员的参与感 缺乏使用者的参与 政治因素取代主旨 充满希望的想法	过度乐观的工作时程 危机管理的缺乏 外包人员未能如期覆约 计划不周 在压力下放弃计划 在前置作业上浪费时间 未扎根的先导作业（比如省略设计直接编码） 不当的设计 不当的品质确认（如省略设计审查和代码审查，） 过早或过度经常的整合 不当的管理控制 在预估时程中忽略了必须的任务 稍后赶上进度(不当回应) 拼命三郎式的程序开发	要求完美 功能改变 要求完美的开发人员 讨价还价的谈判（同意延长工作时程时增加新工作） 研究导向的开发（软件开发不是软件研究，不是试验室）	神奇子弹并发症(对未使用过的新技术，方法，技术的期待) 高估新工具或方法 专案进行中更换开发工具 缺乏自动原始码控制

部分注解:
前置作业: 专案开始前，花在争取预算的时间
必须的任务: 没有持续性的保留先前专案的纪录，忘记较不明显的工作
在启动时缩短一天的QA=在后期增加3~10天的时间
如果你无法在一开始找5小时好好做先导作业，则有可能在后来花50个小时做弥补。