《构建之法》 读后感 —— there is no silver bullet

        接触到《构建之法》是因为我在找两个答案，怎么规范一个软件开发的流程，以及怎么去管理一个技术团队完成软件开发中的一环。带着这两个问题，我开始拜读邹老师的构建之法。（开始 2017.2.16  16：40）

        带着问题看书，代入情景去思考文中的知识点。构建嘛，从团队的构建，软件的的构建两个方面阐述：

        团队的构建：这和我想找的怎么去管理一个技术团队完成软件开发中的一环殊途同归，文中注重IC（individual contributor）。作为一个团队的贡献者，对你是一定要求的。

        1.交流

        2.说到做到

        3.接受团队赋予的角色并按照角色要求工作 

        4.投入团队

        5.流程  

        6.准备

        7.理性

        选对人是构建一个团队的开始，也是一个难点。PSP是组成TSP的单位。组件有了，选一个什么布局，选一个什么属性去组合他们。我们公司暂时可能是几个模式的结合体，一部分官僚模式，老板驱动；一部分交响乐团模式；更多的是功能团队模式，某一时间，某些具备不同的能力的人为解决一个共同的功能暂时联合，完成后解散重新组织或者重叠。模式没有对错，都是特定情况时间与经验的产物。

        软件的的构建：也就是规范一个软件开发的流程，文中也说了许许多多的流程，几乎每个流程都会推崇，交付增量。

        什么是交付增量，通俗的来说就是渐进。

        我们团队做的产品是一个敏感，善变的产品。我们更多的采用了写了再改的模式 code and fix。加上老板驱动流程。没有传统的瀑布，变化太快拖不起。没有采用敏捷开发，因为没人比老板更懂市场与竞争，加上团队的不成熟。我反倒觉得当下的流程没什么不好。

        但是不管是什么流程。必须强调几点：

        1.流程的每一步必须有结果  

        2.个体请使用成熟的技术

        3.珍惜数据，市场，反馈

        4.执行者出计划

        5.自我管理

        敏捷在我看来不是一种开发模式，更多的是一种态度。有需求随便提，哈哈，拥抱变化。产品，请不要把我们技术拥抱变化来掩盖你设计需求的不完善。

        文中也提供了成形的框架MSF。我总结他的原则应该就是多沟通，定目标，互相帮助而不是互相监督，责任，渐进，预期可变期望不变，长期的效率，踩坑，用户分析。

（p142 2017.2.17  17：00）