Week 2 《构建之法》读书笔记
关于敏捷开发的二三感想。
本周因课程原因，并未急于对书目进行大量的阅读。而集中精读了该书敏捷过程一章，先将该章主要内容和个人感悟总结如下。
首先的问题就是，什么是敏捷流程？就我个人粗浅的理解，该敏捷的说法是相对于传统开发模式的“笨重”而言的。众所周知，对于一个软件开发项目，需要在开发前有详尽的调研，再和客户要求反复商讨后得出详尽的计划书，后续所有的开发都需要严格的按照计划书来执行。虽说整个流程显得很严谨，但确实显得有那么一点点笨重。相反，敏捷流程则采取了与之完全相反的一条道路，简单来说有如下两条：
1. 尽早并且持续地交付软件。并非传统流程中的那样在详尽计划中的一步到位，而是有点类似于得过且过的想法？先尽可能早的拿出一个有一定功能的软件来，就像一个概念原型机一样，也许会在后续的使用中出现一些问题，但至少还是能一定程度上去使用他了。接下来，最重要的就是持续的发布可用的软件，简单来说就是查缺补漏。对于出现的问题，步步跟进，并去解决它。
2. 与客户的合作交流和新需求。传统的开发中，客户的需求在软件开始开发前便被确定下来了，就在那一份可能来来回回扯皮了不知道多少个版本的计划书中定好了。后期的一切工作都以计划书为准。而敏捷开发则不同，它的开发十分欢迎新需求的提出。这往往能够给开发人员带来新的灵感，同时一个新的Backlog也是一个新的开始，对于充满热情的开发人员来说，这不仅不会让他们恼怒，反而带来新的挑战和动力。
当详细到具体的敏捷开发流程上来时，书中以Scrum方法论为例来讲述。简单来说，这样一个流程就提出一个打得目标（Product Backlog），然后将其进一步细化，也就是拆分成更为详细的任务（Sprint Backlog），最后就是去完成这些拆分好的小任务。为了确保完成人物的效率，书中又提出了每日例会（Scrum Meeting）和燃尽图（Burn Down Chart），成员间每日去报告自己完成了什么，将要去完成什么，所剩的工作量也被标注在了燃尽图上。
看似来说很简单也很美好，但文中对其的几个至关重要的问题提出了疑虑。个人认为最为重要的，就是如何去生成一份合理的Backlog。对于客户需求来说，仅仅是一些简单的自然化语言描述。如何将其转化为一个合理的技术要求，再对其做出恰当合适的时间评估，这是个人认为在实际的敏捷开发中面临的重大问题。在我们自己的团队项目中，也暂定采取了敏捷开发流程，如何能够将调研所得到的结果一步步剖析，最终拿出一份令人满意的Burn Down Chart来，在我看来是小组所需面对的第一个难题，甚至对于没有开发经验的我们来说，要比后续的一些技术层面的问题还要难以去解决。
