从客户那儿回来，顺路去了博库书城，晃了一圈，本只想随便看看，不经意拿到一本《敏捷软件开发：原则、模式与实践》。前些天刚好听过相关的讲座，而且一直以来都很有兴趣，更何况我是个喜欢藏书（却未必能读完）的人。所以当即买下，59元，开了发票。在路上翻看起来。本来我打算报销，不过发现果然是本好书，于是我不打算报销了 — 好书必须自己拥有。
回来之后花了点时间仔细阅读，看了前四章，30 页。觉得好酷。记下若干心得。
首先，搞清楚了一些概念，敏捷，也就是 Agile ，是一种思想，用来指导软件的开发实施过程。而 XP 只是符合敏捷思想的一种具体的软件过程，除此之外还有许多其他类似而有效的软件过程（诸如 SCRUM，Crystal，FDD, ADP 等等）。原来听讲座的时候没有深刻领会它们之间的关系，模糊的混为一谈。
在看书的过程中，我意识到，其实除了软件开发应该做到敏捷之外，其实我们的其他活动也应当是敏捷的。比如我正在看这本书，也应当快速的，有详有略地理解和消化文字和要点。敏捷说到底是一种切乎实际的做事风格和态度 — 用最简单的方法快速的实现最重要的目标，其余的交给下一阶段的迭代。
书中提到了一些观点。
“即使到了开发的后期，也欢迎改变需求”– 通常我总是会抱怨客户的需求不断变化，虽然可以通过技术上的一些措施可以快速响应客户一定范围内的需求变化，但我仍然十分不乐意。不过“他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。”确实如此，站得更高便是这样。当然，这并不是说所有客户的需求都一味地接受，实践告诉我，我们应该去引导客户，和客户讨论并最终讨论得出应该的合理的实施方案。我需要坦然地接受并努力做到这样。
“人被认为是项目取得成功的最重要的因素” — 这在之前的演讲中，就是“以人为本”所要表达的意思。在这个原则下，所以需要宽敞无阻碍的办公环境以及随意性较大的白板等。人决定项目过程，而非项目流程决定人的工作角色和职责。此外，形式上的结对编程，目的是扩大知识的广泛传播，提高代码质量，降低开发人员的疲劳带来的负面影响。
“可持续的开发速度” – 这点很重要，就像长跑，一开始就疯跑的最后多半不是第一。XP 不鼓励甚至于不允许加班。为了把明天的一点工作提前到今天完成，带来的是更疲劳的今天和状态不佳效率低下的明天，这势必会产生恶性循环。所以上班时间高效并兴奋的工作，下班好好休息。不过有一个例外，在最终完成项目前的一周是可以加班的。看起来有些矛盾，其实都是符合同一个原则：最短时间内有效的持续的达成目标。
“总是尽可能寻找能实现目标的最简单的设计” — 什么时候用 SOAP 做接口，什么时候用数据库，什么时候实现 I18N ，都首先需要评估时间成本。成本最少的，我们就用它，直到不能满足要求的时候再换。这通常和程序员追求完美的心态相悖，所以到具体的时候很难把握和取舍。而这却是一定程度上决定是否足够敏捷的关键部分。
回想起来，原先作消安项目的时候，不经意间正是应用了一些 XP 的方法和原则，包括后来的 member.perlchina.org 站点的开发，也是在“最简化，能 run 就行”的指导原则下快速实现的。所以现在看来很有些共鸣。由此想来，敏捷软件开发的出现决不是偶然，这是客观要求（市场引导下）所产生的必然的结果，很简单，因为它更务实的符合软件开发的特点和需求。达尔文进化论的又一佐证。
Read More
:-)
呵呵，我最近也买了这本书。确实是好~
“简单——使未完成的工作最大化的艺术——是根本”；
而且“我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意”。
嘻嘻，我也不想报了
这本书已经出了好长时间，你买得晚了。^_^
这本书最好看的部分在于他对设计的讲解，事实上这本书正是Uncle Bob前一本书的改版。至于前面关于敏捷的部分倒像是为了与当时的敏捷思潮搭边增加卖点而已。
RSS feed for comments on this post. / TrackBack URI