敏捷开发的实战经验

原创 2013年12月05日 20:59:49
1. 快速迭代 

相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年仅发布仅2~3个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。 

由一年发布2个版本转到一个月发布2个版本,这也不太可能。但是现在来看,快速迭代已经成为事实标准,关键是要比目前的版本发布速度更快一些。 

快速迭代,可以逼迫团队不断优化流程、提升工作效率,不要在无足轻重的事情上浪费时间。如果离deadline还有6个月,那么整个工作节奏必然悠哉。如果每月发布一个版本,那么较以前效率必然会更高。如果发布周期过长,导致无法尽快发现用户需求,进而无法及时改进产品。 

2. 让测试人员和开发者参与需求讨论 

需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。 

同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。 

确定需求时,不要过度盯在细节上。需求报告过于详细,就是一种不敏捷的习惯,还浪费大家的时间。当然,不能错过好点子,但就是不要太细,因为项目真正实施起来时需求将会产生很大的变动。 

3. 编写可测试的需求文档 

开始就要用“用户故事”(User Story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。 

规划业务需求,可以采用“3W模板”,也就是: 

  • 谁(Who)
  • 是什么(What)
  • 为什么(Why)
上面的3W实际上就是描述了相关利益者是谁,他们想要什么,他们为什么有这种需求。下面举一例子进行说明: 

谁(Who)
是什么(What)
为什么(Why)
用户 希望借助一个应用程序在不同服务器间传输文件 为了存储项目数据


为了更加接近“用户故事”,我们可以改写为: 

谁(Who)
是什么(What)
为什么(Why)
消费者/用户 想将归档过程数字化 为了增强沟通,提高分享效率


敏捷项目中编写用户故事有一个常用模板:作为一名[用户类型],我想要[需求],以便于[原因]。应用到这个例子,就是:作为一名用户,我想要将归档程序数字化,以便于增强沟通、提高分享效率。 

多数情况下,需求内容需要更加充实和详细,这一步要放到后面做,开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白:需求文档不是散文或诗歌,应该清晰、简明地描述用户需求;需求文档的重点也在于此,不要管形式多变或内容是否重复这样的问题。 

4. 多沟通,尽量减少文档 

任何项目中,沟通都是一个常见的问题。好的沟通,是敏捷开发的先决条件。在圈子里面混得越久,越会强调良好高效的沟通的重要性。 

团队要确保日常的交流,面对面沟通比邮件强得多。 

敏捷开发鼓励日常的协调会议和碰头会,5~7人参与的会议尽量控制在10分钟内。碰头时,要过一遍昨天完成了什么,今天要做什么,哪些问题仍待讨论。可以用Burndown Chart(燃尽图)来形象展示工作进度。每次迭代的时候也都要开一个计划会议和评审会议,一般需要的时间可能会长些,比如半天。这些会议的目的就是对工作查缺补漏。 

评审会议很重要,传统开发模式往往略过该环节,导致一些错误做法不断重复,好的做法无法推广。 

开会时,可以将原先的分组打散,让整个团队都参与到项目的需求讨论和测试中来,这样可以突出成员个人,让大家更乐意参与。 

5. 做好产品原型 

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档,但人人都会看图。 

一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题,可以模拟真实操作,改进模拟操作过程中难以理解和不清楚的操作行为。 

6. 及早考虑测试 

及早地考虑测试在敏捷开发中很重要。传统的软件开发,测试用例很晚才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。较早地开始编写测试用例,当需求完成时,可以接受的测试用例也基本一块完成了。

敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短,从开始到交付就是4周的时间,这样可以对迭代的设计、实现和底层测试一块进行回归测试。 

一系列迭代之后,可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中,可能会导致过少的测试文档。如果迭代周期为1个月左右,可以不必对测试文档过于要求,但要制定好测试策略。 

最后 

可能大多数公司或团队还没有开始尝试敏捷开发,不过可以开始从点滴做起,比如开碰头会、为项目管理采用一个更加高效的管理工具等等。最后,希望上面的建议能够为大家的软件开发管理带来帮助。 

相关文章推荐

产品项目里的九个敏捷开发实战经验

[摘要]   敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支...

敏捷开发的6个实战经验

在大型企业中经常是各种软件开发模式混用,一些采用敏捷开发,一些则是采用传统的瀑布式或RUP(统一软件开发过程)。敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优...

有道云笔记蒋炜航:敏捷开发的实战经验

网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用“敏捷开发”呢?我们的经验是需要两点:一、团队有三名或以上的研发工程师;二、团队内有一名合适的Scrum Master。   作者:蒋炜航,网...

PMI-ACP敏捷认证:敏捷开发的6个实战经验

敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优质软件。     1. 快速迭代     相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加...

有关EPPA项目开发的实战经验

  • 2010年10月22日 16:00
  • 1.3MB
  • 下载

工程师实战经验:Beacon与Wi-Fi定位技术的精度/成本/开发难度 EDN

关键字:Wi-Fi  Beacon  定位  很多尝试进入移动互联网行业的人,对室内定位系统很感兴趣,这项技术带来了很多创新的O2O商业模式,包括产品思路。 但对室内定位的技术商业化前景,用W...

Android 开发实战经验总结

以前一直想写一篇总结 Android 开发经验的文章,估计当时的我还达不到某种水平,所以思路跟不上,下笔又捉襟见肘。近日,思路较为明朗,于是重新操起键盘开始码字一番。先声明一下哈,本人不是大厂的程序猿...

iOS 开发实战经验(1)- 应用程序打包上传

工作两年多了,很少在CSDN上发表博文,今天开通博文,记载一下日常工作心得 今天将图文并茂讲解iOS应用打包上传 一.应用程序的打包 准备工作是,你写好的程序已测试过,现在开始进入开发者中心创建发布证...
  • yptzxx
  • yptzxx
  • 2015年12月02日 10:15
  • 243

python开发的项目学习 适合缺少python项目实战经验的人

我们在学习过程中最容易犯的一个错误就是:看的多动手的少,特别是对于一些项目的开发学习就更少了! 没有一个完整的项目开发过程,是不会对整个开发流程以及理论知识有牢固的认知的,对于怎样将所学的理...
  • ycl146
  • ycl146
  • 2017年05月04日 09:39
  • 325

我的 Android 开发实战经验总结

以前一直想写一篇总结 Android 开发经验的文章,估计当时的我还达不到某种水平,所以思路跟不上,下笔又捉襟见肘。近日,思路较为明朗,于是重新操起键盘开始码字一番。先声明一下哈,本人不是大厂的程序猿...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:敏捷开发的实战经验
举报原因:
原因补充:

(最多只允许输入30个字)