登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 专题 > 敏捷项目管理 > 如何做到敏捷的“形”“神”兼顾

如何做到敏捷的“形”“神”兼顾

返回>

2014年06月09日    作者:朱军华    来源:朱军华博客

A-A+

  近年来,敏捷开发越来越火热,但是要想在实际应用当中做到“形”“神”兼顾,还的确不是一件容易的事。在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者也提到,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。


  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。


  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:


  1. 敏捷开发最少需要维护哪些文档


  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。但文档宜少且精炼,一般情况下建议维护三份文档:


  《产品需求规格说明书》:PRD,定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;


  《系统设计说明书》:开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;


  《测试用例和测试报告》:由测试人员编写:记录所有功能点的测试计划、过程和测试结果;


  2. 敏捷开发是否需要系统设计


  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。


  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。


  3. 敏捷开发是否需要项目计划


  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。


  4. 敏捷开发的迭代周期大概多长


  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。


  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;


  5. 敏捷开发为何提倡小版本,小版本有哪些优势


  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:


  (1)总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;


  (2)需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;


  (3)测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;


  6. 敏捷开发与重构的关系如何


  敏捷开发以重构为基础,时时刻刻处于重构过程中;


  7. 敏捷开发为何强调团队人员的参与、用户的参与


  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。


  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:


  “这正是我想要的……”


  “这里需要修改一下……”


  “我的想法是这样的……”


  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!


  8. 怎么才能评估团队是否已经敏捷了


  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:


  · 团队有共同的愿景,并且对这个愿景充满信心


  · 团队有明确的阶段目标并且为每个成员所知晓


  · 团队知晓当前计划:做什么、何时完成、预期效果等


  · 团队任务是低耦合的,并且紧密协作


  · 发布过程是轻松愉快的,构建版本并不断测试是常态行为之一


  9. 敏捷开发能缩短项目时间并提高质量吗


  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:


  · 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;


  · 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;


  · 过程目标导向,使团队高度集中于项目目标,提高了生产力;


  · 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;

责任编辑:weiwei

标签:敏捷
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
官方新浪微博
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3
PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设