读书笔记3

第十五章 稳定和发布阶段

15.1 从代码完成到发布

 

第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。开发者必须向与会者报告的是：

• Bug是什么
• 危害是什么，如果不修复，有何后果
• 用户会有什么变通办法
• 是否经过代码复审，是否经过伙伴测试

第二步：会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。

• Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过
• More Info——需要更多的信息
• No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
• Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“Like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“Must”，那么处于待命状态的“Like”修复就可以一起集成到代码库中。如果没有“Must”级别的修复，那么“Like”级别的修复就只能处于“待命”状态，直到以后出现了“Must”级别的修复为止

第十六章 IT行业的创新

影响产品竞争的各种因素

• 产品行业的因素
  这是影响产品发展的最重要的因素，2012年流传着一句俗话——“站在风口上，连猪都可以飞起来”，就是说明产业发展的成长期（竞争产品少，市场空间大，用户容忍度强）能给产品提供巨大的助力。相反，如果是在一个产业的衰落期进入这个产业（例如，在2008年做小灵通手机业务，在2013年进军网络团购市场，等等），那么就会面临巨大的发展阻力。
• 公司和市场因素
  公司在目前目标用户中的品牌号召力如何？公司的现有市场能力如何？现有的市场能力能帮助打开新的领域么？从传统的产品开发角度来看，“市场”总是在产品之后才出现，而且和“产品开发”似乎没有直接的联系。但是从长期来看，产品的质量就是最有效的市场能力，产品经理往往就是市场经理。
• 团队执行因素
  根据产品特性的不同（基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等），商业模式不同，团队的战略也会不一样。在正确的时间，有正确的产品，却执行了错误的策略，或者不能做出决定，那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价，力争要弄清所有情况再动手，最后的结果是动不了手。这是“分析麻痹”（Analysis Paralysis）。
• 产品的价值因素
  产品给用户带来什么价值，这是和“软件工程”最相关的内容。考虑新产品或产品的新功能时，团队要问：我们给用户带来了什么价值，这个产品是提供了独家的价值，还是“人有我也有”的价值？这个价值足以让本产品和目前市场上已有的产品区分开么？我们怎么能进一步放大产品差异性？让我们越来越领先，或者让用户觉得我们很领先？我们是否在非差异化功能上花费了太多时间和资源？

第十七章 人、绩效和职业道德

①RASCI模型

R：Responsible，负责把具体事情做好

A：Accountable，对任务负全责，有批准的权利

S：Support，对任务提供支持，辅助任务的完成

C：Consulted，咨询，拥有完成项目所需的信息或能力的角色

I：Informed，知会者，应该事后及时通知结果的角色

②团队合作的阶段：

（1）萌芽阶段，就像小苗破土而出，柔弱但充满希望

（2）磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突

（3）规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战

（4）创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西

③不管从事哪一个职业，不管你是属于哪个岗位上的，都必须具有职业道德，软件工程师同样也需要

 

 

最后，《构建之法》的正文以及练习与讨论中有大量有价值的引用，这些内容可以让我们了解更多更广的知识，练习中大量的习题如果都能够独立思考并想办法解决的话，对我们的实际动手能力会有很大提升。