在敏捷中找到好的实践

今天在看架构相关的文章时突然看到一段，和敏捷有关。所以也就想起了自己现在参与的项目中的敏捷概念。

我们一直在强调敏捷，但怎么个敏捷法呢？项目周期不断的缩短，中间两次迭代，CR不定期的出现，即使在版本即将发布的最后几天，此前可是经过四轮的SDV啊。

 

另外还特别遵循了敏捷方法中的站立会议，但我不知道是否起到了敏捷的作用，原本是想将过去一天的工作与问题进行总结，并对新一天的工作做合适的安排，但到最后，这个会议却显得很无用，每天每人一句话，甚至一半人的那句话别人都听不清楚，不知道这样一个团队是在做着什么样的配合与协作。而领导者呢，对于整个项目的周期与计划并不很强调，导致大家心里根本没有一个对整个项目周期的清晰轮廓。

此前开发此项目时（此项目从南京转移到深圳开发，此前项目指的是在南京开发时的那一时期）对于敏捷中的一些方法比如结对编程使用的很好，代码质量得到一定保证，同时无论需求，测试用例，编码这些重要的过程组内除了结对人要要进行检视外，组内所有手中有时间的成员都要进行检视，并填写检视表单，然后组织大家开评审会议，争取把项目问题最早的暴露并把风险降到最低。但现在这些做到的很少。当然这一段时间属于项目交接期，所以会出现很多问题，但我在想是不是正是因为这样，管理者才应该将那些好的实践方法引用到项目中来，让整个项目更加高效的交接。

 

而更重要的一部分——持续集成也没有得很好的运用。华为对于持续集成工具已经做的很好，光版本从我看到的就换了三次。但对于现在这个项目却没有真正的运用起来，反而还不如以前。而现在项目的交付去责任更重，因为多了一个现网局点。

 

也进行了大半年的敏捷实践，现列出我认为的好的实践 ：

 

1、站立会议。 此会议不是例行，我个人认会不是每天都需要，如果没有确实的需要而举行，感觉真的很空洞。此会议多数应该由领导者以特定议题发起，且时间不需要固定。如果组内成员有想法需要与大家共同讨论同样也可以发起。

 

2、测试驱动开发。 此方法也是一个重要和很好的实践。在未进行代码开发之前将可能和必须出现的场景进行预料，写出测试用例，以方便代码完成后对基本的逻辑和特性进行有效验证。但我发现有很多人不愿意去执行此步，即使是在使用自动化测试工具的时代。

 

3、结对编程。 有一次和同事聊开发，他问我们是不是在搞敏捷，我说是，他说：敏捷就是耗尽一个人所有精力的开发方式。这句有点太过，人的精力是有限的，如果所有精力都用在今天了，那明天谁为我们来开发。但他这种说法和我以前自认为的敏捷实践中的结对编程有点像。既然是结对，那应该是这样的，两人对于从需求开始就要对要做的事以及对此前做的事都达成共识，然后一台电脑，两把椅子，一人执笔，一人紧跟。如果一人对于思路的实现遇到了问题则另一个人可以很快的接手过来，将此前已商讨过的实现方式进行下去，或修改前者错误，或直接走下去。两人都在一种编码的兴奋状态。这样才会高效的，真正的达到一种结对。当然这个实现过程并不需要两个人都进行编码，也可以只一人执笔，但对于遇到的问题（或者是在此兴奋过程中又想到什么此前没有考虑到的问题）两个人应该可以马上进行讨论然后修改和确定新的实现方案。

4、文档检视和评审。 这里的文档包括规格，需求，测试（方案）用例，以及代码，另外相关的VDD等。此检视所有成员都应该参与到其中，而领导者更应该是此中的重中之重，他对规格和现场（局方）需要的方案和特性应该最熟悉，所以他需要对规格，需求提出最有效的检视意见，对于代码则应该所有成员都去保证逻辑正确，结对人保证所有细小的地方都没有忽略检视。而检视完成后的重要一步对是组织评审，此评审必不可少，要让问题提出人与问题解决人都要明确提出的问题是否正确和必须，所以必须当堂对质。当然这些所有的问题不一定要等到评审上才解决，此前任何时刻都可以将发现的问题与问题负责人进行沟通，确定问题的存在性。这一过程包括对代码的一些特殊的问题检视，通常都会按统一要求进行checkstyle检查，还要进行findbugs的检查。

 

5、每日构建。 对于现在的敏捷开发来说，写个ant脚本加入到ICP中进行每日构建是必须的事，否则对于整个系统的完整和正确，还有项目的风险都无法预估。而项目的一些checkstyle与findbugs的问题将会遗留到第二天。这可不是一个好消息，因为它的存在意味着你们此前做的检视都被忽略了。而日后这些问题必将积重难返，你必将为当初的软弱而后悔。

6、总结会议。 这个会议必不可少，通常在一个版本快结束时进行。你会说我每天都在忙着开会，把我的文档编写的代码编写的时间都挤没了。你错了，在IT行业的会议中应该所有会议都简可能的简短和有效，如果你们的会议不是这样，那应该向组织者提出建议了。此前的会议都是必要的，现的会议是为了将来更好的将项目开发组织好，让项目中的每个人都参与到项目的管理中来。所以这个会议，与会者都要拿出一个自己对此版本开发中有需要改进的或是好的实践的例子来，当然，多多益善。这样整个团队才会有凝聚力，更重要的是这样才能不断的发现问题，现将这些问题规避在进入下一个版本之前。

 

目前，对于敏捷项目的心得就是这些，而如果你们开发的项目有一个好的系统架构，那会更加有利。因为敏捷本身就要求对所开发的代码要将各自设计模式运用起来，真正体会到代码之美丽。