小谈Scrum敏捷开发流程

一晃眼，有两年没有写博客了，回顾前两年，各类奔波，各类忙碌，也有很多的收获。从今天开始，我要把这些收获都分享在这里。

其实这两年，对我影响最大的是开发流程。总所周知，一个好的开发流程，对于项目的进行，更新和维护都起着相当重要的做用。Scrum适用于一些开发周期长，需求不明确，或者随时间渐进明确，频繁更新的项目。然而，如今国内的一些公司，甚至一些大公司，都对这块不过重视，或者作得不够透彻。从而程序猿们每天加班，苦不堪言。

咱们先来看张我经过实际经验画的图流程图，红色圈圈出来的是我认为比较容易忽略的部分，接下来一一说明。

1/二、项目决定启动后，第一步就是产品组准备需求，整理出需求文档。这个需求文档是须要屡次会议协商总结出的。在需求前期，产品组能够自由发挥，把对产品的任何要求尽可能详细地列出来，细节方面列不完整也不要紧，可是对于产品的最终呈现出的效果，大的方向，要有一个完全明确的说明，由于这个可能直接关系到产品架构的设计；而后进入需求中期，这个时候必定要引入技术经理以及技术主力，须要从技术角度去评估需求的可行性以及性价比，这让技术部门可以基本了解大的架构方向，（我曾经就有碰到过一个项目，因为产品组在美国，开发组在国内，产品组在没有和开发组完全沟通的状况下，就把需求和客户达成共识，这以后使得咱们技术部门十分被动，结果就是没法在规定时间上线，损失是小，在客户面前失信是大！）；最后在需求后期，就能够出具项目需求初稿，这个初稿须要产品组根据时间要求以及客户要求，进行优先级划分，并将其划分为多个模块，分配给各个开发经理，制定Story或者backlog，再让开发经理细分task，分配给各个程序猿，从时间的角度，须要设定Sprint，并将各个story分配到各个Sprint中，一个Sprint的周期通常是2个星期（10个工做日），遇特殊状况可延长到3个星期。这个过程当中，最关键的是怎么规划Sprint，这个时候，对story时间的估算是很是关键的。咱们之前都是程序猿们和产品经理坐在一块儿，为每一个story一一估算时间。好比说一个story由2我的完成，2我的固然须要在事先了解需求，而后在对方不知道的状况下，分别估算对这个2我的完成的story须要花费多少天/人次，若是两我的时间接近，就去较大的那个天数做为估算的时间，好比一我的估3天，一我的估2天，那么这个story估算的总时间就是3天/人*2人=6天；若是两我的的差距至关大，好比一我的估了2天，另外我的估了10天，那就有须要让两我的说明缘由，在排除了干扰因素后，再次估算，最后得出一个合理的时间。项目经理须要根据估算的总时间来安排Sprint里的story。

这些都准备完成后，就能够进行项目开发阶段了。

三、由于我是微软平台的苦B程序猿，因此我接下来用到的都是微软的工具。首先要有一个代码版本控制软件，我要在这里说的是TFS。微软的TFS有两个版本，一个叫Team Foundation Server，一个叫Team Foundation Service，小弟都用过，因此来讲明下二者的区别：Server版须要公司用本身的服务器部署，比较适合局域网内开发的项目，固然也能够部署在公网，优势是能够最大程度的customize；Service版是部署在微软云上，由微软托管的，比较适合跨区域中小型公司（缺乏硬件支持的），优势是方便，和office365帐号绑定，公网也能够访问，缺点是没法自定义流程模板。其余功能都是同样的。其实不管那个版本的TFS，功能都是很是强大的，彻底能够知足敏捷开发项目须要。我曾听有人抱怨TFS只能给程序猿用，项目组又不装VS，不用用它来开task啊，开bug什么的，而后又去买了JIRA什么的专门给项目组用的流程控制工具，其实不必，TFS有个service portal，相似于sharepoint的站点，能够用它来给项目组用，两个版本都有，很是好用。固然JIRA也是很是不错的，咱们当时也是两个一块儿用，JIRA在自定义流程上面仍是至关不错的，咱们用JIRA来作部署流程控制以及运维流程控制等与代码自己关联不深的流程控制。

TFS在对代码版本及质量管理方面是颇有优点的，咱们会把sprint，story，task等等通通在开发阶段开始前录入TFS，这些都是TFS默认的模板，咱们也能够本身更换或者修改模板，遗憾的是service版无法改。具体怎么修改能够参考MSDN。

 

而后咱们能够经过规则，强制在check in代码的时候绑定task/bug/issue，以及强制写comment以及check in notes，这些都至关重要。固然，代码不能随随便便就能check in啊，最好须要有我的review，这个时候，咱们能够先Shelve代码，而后能够指定一我的来给你review代码，review代码的人能够经过TFS自带的比较工具，比较shelve的代码和最新的代码间的区别，也能够给代码片断写comment，最后决定是否能够提交和须要打回去，从新shelve。有人会以为，这个好麻烦啊，不是会影响进度。我要说的是，若是没有这个环节，或许你能够很快速的完成开发，但别忘了，代码不是写完就算了的，代码的质量也是至关重要的，谁都不想，项目进入测试环节由于某个不应发生的问题而影响一轮测试，也不想在项目上线以后，由于性能问题，再来review全部代码，找到性能瓶颈......

顺便说下测试，测试不比开发轻松，通常测试分为smoke test，regression test，fuzz test，load test/performance test，security test。前两个很少说了，很熟悉了，后面三个很容易被忽视，可是却很是重要。有一句真理：任何一个软件，永远都存在bug，任何一种测试都没法把全部bug都找出来！所以，咱们须要在测试阶段尽量地将简单明显的bug通通找出来，这样剩下的只是在特定状况下才会特别发生的bug。smoke test和regression test是为了找简单明显的bug，而fuzz，load，security等等测试是用来找出特定状况下的bug。fuzz可以很好地验证软件的健壮成都，它经过随机无序的任意输入，测试系统的内部应对及输出；load可以让系统在某个压力下测试系统的稳定性能，从而评估该系统/软件能够给多少人用，须要多少服务器，以及找出性能瓶颈，从而优化代码；安全测试能够测试系统的安全性，关于安全微软还有一套完整的流程叫SDL，就不详述了。咱们之前公司一直想作自动化测试，fuzz和load是能够自动化的，可是功能性测试作自动化比较困难，VS自身有针对web服务的自动化测试项目模板，有兴趣能够了解下。但我的以为还不算理想中那种自动化。反正有大批测试妹子，全自动化了，公司里不就少了不少妹子，哈哈，扯远了。。。

再说下发布，在分布式的发布体系下，比较头疼的是，从QA到UAT，在到Staging和Production，各个环境可能须要不一样的配置参数，尤为是SOA的系统，在分布式部署的时候，服务地址的配置一般很是头疼，最简单的方法是用配置文件的自动转换功能，也有公司本身作配置管理工具的，也有把配置移到数据库的。我的以为，有条件的能够本身开发套适合本身的配置工具，可是我做为一个从简主义者，我针对SOA系统，个人方法是这样的：首先，在每一个环境的服务器集群之中，搞一台机器专门作内部的DNS服务器，咱们在dns服务器上为每个须要分布式部署的service定义一个内部域名，而后在配置文件中，都用这些预先定义好的内部域名，若是须要本地测试，能够修改本身机器的host文件，map到127.0.0.1或者具体的局域网IP地址，包括数据库地址也是能够这么作（这种方法对Azure SQL无效），而后发布到任何一个环境都不须要改跟地址有关的配置；对于一些跟环境相关的其余应用程序配置，本人建议存储到数据库或者作一个专门的配置服务。当在Staging上发布并测试完成后，Production就不要再发布了，经过交换绑定的IP地址来实现切换，具体如何实现是IT的事情，这里不说了。

四、终于一个阶段开发完成，能够顺利进入测试阶段了，这个时候，下个阶段的新需求就又来了，而后又是重复的步骤，估时间，sprint，story，写代码，测试，发布。

五、当产品上线后，确定会遇到很多特定状况出现的bug，为了发现bug，要有监控系统，这又是一个大话题，暂时略过，而后发现问题后，要可以重现，而后须要评估问题的严重程度，而后根据协商结果，决定是否须要立马修复，仍是进入下个发布周期修复，若是是须要立马修复的就要作hotfix，开maintainence window，走一边UAT-〉Staging-〉Production的过程，QA能够不走，由于有可能下个阶段的开发已经在QA上测试，若是下个阶段的开发已经在UAT上了，那么这么急的hotfix也没有意义了，若是下个阶段已在UAT，prod又出现没法运行的后果，那么把production再切会以前的在staging上的版本吧。关于数据库，staging和prod应该是须要工具来同步的。

先说那么多，不少细节仍是须要不一样的团队不一样的人员作一些调整。总结的不对之处，还望指正！