敏捷实践思考1--需求颗粒度该如何与业务沟通

目前部门内推行敏捷迭代的思想及工作模式有一段时间了。部门内各开发团队，对该模式的理解和运用也比较清晰和熟练。

但是整个敏捷工作模式，不仅仅需要技术部门内部达成一致，还需要与业务部门达成一致才能更好的发挥敏捷的价值。

典型的问题有两个：一是需求颗粒度的问题；二是测试与上线频率。

首先：对于需求颗粒度的问题，按照敏捷的要求，最好一个需求控制在2周一个迭代，稍微长一点的也要控制在1个月以内；

但是根据历史经验，除了优化类或者问题类的小需求，稍微大一点的需求，例如一个系统开发一个全新的模块，大的迁移改造等都无法控制在1个月以内。

业务部门也不会为了这个颗粒度去把一份完整的需求拆分成若干份需求，也不便于项目的统一管理。所以对于需求颗粒度的处理，我的建议是：

1、对于业务部门提交的需求，通过需求澄清环节，保证需求内部的相关性，要求业务部门将需求中关联性不强的部分分开提交需求流程；

2、对于整体性较大的需求，通过需求澄清后，在部落内按照项目集管理，按照功能模块将需求拆分成颗粒度更小的子项目进行管理；

3、子项目的管理可以按照敏捷迭代的方式来管理和实现。

第二：对于测试与上线

由于一个需求被拆分成了若干的小需求或者小功能点进行迭代开发，那么就会涉及到功能的UAT测试和上线。如果频繁的UAT测试需求和上线，必然就会涉及到业务部门的

配合测试和提交上线流程，上线验证等。但是业务部门实际上是没有足够的人员来满足如此高频的测试和上线及验证工作的。那么我们该如何为业务部门减负呢？

我认为可以从下面三个方面来努力：

1、加强需求分析环节的需求澄清和确认，保证需求质量；

2、加强开发自测、SIT测试的质量，避免问题都传递到UAT测试环节，增加UAT测试工作量和周期；

3、针对需求进行分类，针对不停颗粒度和重要程度的需求制定不同的上线审批流程，目前我行的上线流程比较冗长且形式化较多。简化常规普通需求的上线流程。

HTML5在近两年里可算是出尽了风头，无论是去年10月底的规范定稿，还是今年年初惊爆业内的微信开放JS SDK，亦或是腾讯、百度、360、搜狐等互联网巨头之间的布局争夺。这一切的一切似乎都在预示着HTML5将要给移动互联网界带来颠覆性变革。

也许以后，HTML5真的会重新定义移动互联网的黄金时代。但在此之前，当你准备开发一款应用时，切不可只一味的追寻别人所尊崇的技术，最重要的还是要搞清楚自己的整体需求。其中最为关键的问题包括“应用的受众是哪些？”、“用户想要获得的是什么？”，以及“吸引客户最好的策略是什么？”。其实，总的来说也就是两点：移动用户体验，劳动和资本投资需求。

既然有如此多的顾虑，那么总要选择最适合自己的开发方式。关于这个问题其实早就有各种分析，而这次我们再整体性的探索Web、原生以及混合应用开发之间的历史渊源。

Web应用：最小化成本，更新敏捷性

别看现在的HTML5风光无限，其实它的发展道路也是让人不胜唏嘘。自出生到去年规范的尘埃落定，长达8年的长跑真心不容易。其中最大的惨败要数2012年的Facebook事件，当时Facebook CEO扎克伯格怒言“押注HTML5是Facebook最大失误”，进而转战原生应用，这让支持HTML5的人受到了不小的打击。

还好，HTML5依然挺了过来，相继也出现了各种HTML5开发框架和游戏开发引擎。再加上，前段时间YouTube替换Flash，正式默认使用HTML5视频播放器，着实让HTML5好好的扬眉吐气了。一件事物能受欢迎，总归有受欢迎的理由。那么，HTML5又有那些优势？

“一次编写，随处运行”。大多数浏览器都有着相同的运行方式，一个应用几乎可以在所有浏览器上运行，不像限定于只能在某一系统下运行的原生应用。对于用户来说，“一次编写，随处运行”的HTML5应用意味着应用的连续性，即不管是哪个 *** 作系统都可以运行使用应用程序。

允许应用不断更新。HTML5还允许不断更新，开发者不需要再将新应用提交给应用商店等待批准。每次用户登录到该web应用时，都将获得应用最新版本。

以上两点都是众所周知的，其实最主要的原因还是应用开发的成本问题。相较原生应用，能够随处运行的HTML5，单在移植方面就省下了不少银子。而且，面对新平台，无需高价聘请专业人士或培养现有的人员去重新学习，先前的Web技术人员就可以直接使用。

原生应用：最大化性能和用户体验

原生应用的历史要比Web应用悠久的多，如地址簿、日历和计算器等默认自带的应用程序及可用的Web连接在很早以前就出现在移动设备上，1998年风靡全球的诺基亚经典游戏贪吃蛇就是典型之一。就平均而言，如今开发者采用最广泛的开发方法仍是原生应用开发。虽然HTML5风头正胜，但拥有强大性能及高品质用户体验的原生应用能占据大头也不足为奇。

相对Web应用，原生应用最大的优势就是可以访问设备中的所有功能，运行的速度更快、性能更高，而且可以启用优秀的离线处理和存储能力。不过，别只关注它的优势，若想要维持原生开发绝对是个不小的挑战。它的最大问题就是支持的设备非常有限，想要移植到其他平台就得准备好更多的预算。此外，还有审核过程的不一导致上线时间不确定，以及获得新版本时还需重新下载应用更新。

如果，你做应用之前的预算是没有太多限制的话，只采用原生方法的团队所开发的应用质量，绝对要比其他团队高质的多。不过现实就是现实，很少有开发商的资金是源源不断的。

混合应用填补空白

所谓混合应用，顾名思义，就是原生和Web应用的结合体，自然也就继承了两者的优缺点。换句话说，相当于利用Web开发技术编写的原生应用，如HTML5、CSS、JavaScript都是进入原生容器（Native Container）的比较常用的语言，原生应用包含了一个链接到HTML文件的WebView隐藏浏览器。

总的来说，混合应用也是蛮有魅力的，开发者可以自由调配其中原生和Web的比例。它的好处也很多：

跨平台优势，既省钱又省时间，同时还是创意付诸实践的最佳捷径。

Web开发者不论水平如何，只需经过短期培训就能成为合格的混合应用开发者。

以上的两点都表明了混合应用对成本的节省，也算是它继承Web的一大优点。不过，混合应用的性能终究还是比不过原生应用，如果其中掺入了太多的Web技术，还是会减缓应用的运行速度。但随着技术的不断提升，混合应用开发也在水涨船高，在不断的寻找在获得优秀用户体验的同时，尽力降低开发成本。

ACP敏捷认证考试条件具体说明：

1、教育背景：中等学历(高中文凭，大专学历，全球同等学历及以上)。

2、普通项目经验：需在申请之日起前五年里在项目团队工作2000小时(12个月)。

3、敏捷项目经验：需在申请之日起前三年里在项目团队运用敏捷方法工作1500小时(8个月)，这些工作时长是在普通项目经验要求的2000小时以外的。

4、敏捷实践培训：必须在敏捷实践中获得21小时的培训课时。

免费领取ACP学习资料、知识地图：https://wangxiao.xisaiwang.com/acp/xxzl/n165.html

---