腾讯敏捷之道,实施敏捷开发,看我就够了

简单的来讲,敏捷的意思就是反应迅速,为什么要反应迅速?看看腾讯、阿里就知道了,市场变化越来越快,客户要求越来越高,为了满足用户的需求, 人家一个星期发一个版本,我们仨月才能憋出一个...

简单的来讲,敏捷的意思就是反应迅速,为什么要反应迅速?看看腾讯、阿里就知道了,市场变化越来越快,客户要求越来越高,为了满足用户的需求, 人家一个星期发一个版本,我们仨月才能憋出一个来 , 那还不被打的满地找牙?

 

问题是如何才能反应迅速?  我们先来看一个场景:

 

一、残酷的现实

软件开发有一大难题就是客户脑子中的需求难于描述出来, 我们通常的应对方法是这样:

先花上几个月整理需求, 天天和客户座谈, 画出几百页的流程图, 写出上千页的文档, 最后把客户都快搞晕了。

 

项目经理:这是您要的软件需求吗?

客户:(看到这么多的文档) : 嗯, 应该是。

项目经理:那就请您在需求确认书上签字吧

客户:(心里犯嘀咕, 但是一想,反正是我先给你个首期款,怕啥? ) : 签就签!

项目经理:(非常高兴的宣布)需求分析阶段结束了, 项目成功进入下一个阶段: 概要设计!

 

然后是详细设计, 开发, 测试,  我们强悍的技术团队开始发动, 一切都严格按照计划进行, 一切看起来都很完美, 看来项目马上成功结束了!

 

但是客户的验收测试给了我们当头一棒: 这个界面怎么少了一个选项 ?    那个界面怎么不能跳转 , 那个功能需要给领导一个后门, 还有, 我的业务规则怎么不能改?  什么? 在代码中写死了?  唉,你们做的系统啊, 根本就不能用 !

 

每个人都很郁闷, 几个月的辛苦开发看来要付诸东流了。

从这个场景中能看出的是,  我们从客户那里得到的需求描述和需求文档, 其实离客户真正想要的软件还差的很远。 

 

在瀑布式的开发模式下,验收测试发现的问题,要想改正代价是非常高昂的。

 

二、改进

 

一个想法自然而然就浮现出来: 为了避免到最后习惯性崩盘,能不能让客户经常性的做验收测试? 

让他们经常性的去使用一个可以工作的软件, 从而告诉我们那些地方还有欠缺 ? 那些地方做错了?  这样我们可以迅速的修改, 这样我们就会轻松多了 !

 

我们可以把软件开发划分成一个个小的开发周期, 例如每个周期就两三周时间, 在这两周之内我们完成一个或几个功能, 然后就让用户去试用, 有问题立刻反馈,在下一个开发周期马上改掉。 这样就可以逐步逼近客户的最终目标。

 

这还带来了一个额外的好处, 不用花费巨长的时间来分析,整理冗长的需求文档了。

听起来很美是不是?  但是仔细想想这里边的问题很多。那么该如何实施敏捷开发呢?我们可以借用CORNERSTONE敏捷开发工具,来帮助我们高效规划任务,灵活调整计划,高质交付产品,快速迭代,响应需求。

 

1.  抛弃了冗长的需求文档, 但还是得描述需求啊

 

image.png

 

CORNERSTONE为需求生命周期搭建流程,可以自定义更改按收集、评审、排期、设计、开发、发布设立多个阶段,在不同阶段把任务分发给产品、设计或者开发人员,让需求完成无缝衔接。

 

2.  怎么决定每个小开发周期(我们称之为迭代)要开发的东西?

用户故事得有估算, 得有大小, 太大了一个迭代开发不完 , 还得拆分一下。

我们需要对需求按照优先级进行排序, 按照优先级从高到低的原则来开发。

 

image.png

 

CORNERSTONE透过增量迭代⽅法进⾏敏捷式开发,根据不同版本制定⽬标与评审计划,同步统计⾄天/周 /⽉视图、燃尽图以及完成度。迭代进度 清晰可追溯,助⼒企业敏捷迭代,⼩步快跑。

 

3. 不要架构设计了吗?

一上来就按优先级选择需求, 直接进入迭代开发, 把架构师撂在一边,合适吗?

架构工作肯定还是需要的,在正式的迭代周期开始之前需要架构设计, 但是和设计出面面俱到的架构设计不同, 我们更需要演进式的架构, 随着迭代的推进而进化。

 

4. 那详细设计怎么办?

在每个迭代开始的时候,团队在一起把这些用户故事给拆分成一个个小的任务, 这个拆分的过程就相当于详细设计了。  对于一些特别复杂的,例如算法, 当然可以写文档,帮助大家理解。

 

image.png

 

CORNERSTONE里,可以同时并行管理多个项目。每个项目清晰明确可见责任⼈、任务状态、优先级、类别、时间等多维度信息,帮助企业快速⾼效的对项⽬进⾏全周期管理。

 

5. 由于是迭代式开发, 这个迭代周期修改上一个迭代周期的代码在所难免, 怎么保证不破坏原有的功能? 总不能每次都手工重测一遍吧?

对于敏捷开发来说,开发人员需要尽可能做到提早集成,频繁集成,一般每添加进一些新的代码时,最好都做一次集成,不要临到软件发布或者交付的当天才开始集成,也不要很久才集成一次,如此可尽早发现代码中的问题,保持软件的状态一直是可用的。

 

image.png

 

 

CORNERSTONE⽀持将持续集成等结果部署到对应的测试环境,所有部署版本在测试 环境中可随时访问,⽀持灰度发布到⽣产环境中。

 

6.  这么短的开发周期, 测试人员怎么测试啊?

 

开发和测试需要同步进行, 当开发在澄清需求的时候, 测试需要参与, 当开发在编码的时候,测试人员在编写测试用例,等到一个用户故事开发完,马上就可以投入测试。

 

CORNERSTONE执行测试计划,也是非常有亮点的哦!

 

亮点一:用例的执行情况一目了然,随着执行的进度即时更新测试结果

 

亮点二:执行用例不通过,有BUG,可以直接关联缺陷,新增缺陷指派责任人,完全不用退出页面,再去缺陷列表新增

 

亮点三:执行用例过程中,执行后,自动切换到下一条用例,减去很多点点的操作。

 

亮点四:测试用例批量执行的功能肯定少不了,你需要的它都有哦。

 

亮点五:用例执行页面执行操作简单明了,还可以记录下了执行过程中发现的缺陷,执行人员的操作记录,一目了然。

 

image.png

image.png

 

7. 看来开发、测试之间需要紧密的协作, 它们之间怎么沟通?

肯定是面对面的沟通, 有问题就跑到对方的座位那里去问,大家的座位最好在一起, 扭头就可以讨论,尽可能减少效率不高的电话、QQ/微信等工具的使用。

 

CORNERSTONE讨论功能也可供团队成员互相交流,共享信息,解决自己在工作中遇到的各种问题。

 

image.png

 

开发团队也可每天开一个15分钟左右的站会,展示自己的进展和计划,让进度保持透明,及时暴露问题,解决问题。

 

8. 客户什么时候可以做验收测试?

随时欢迎, 但是我们更倾向于迭代结束以后, 这时候功能会稳定下来, 我们会给客户做一个演示, 告诉他这个迭代完成的工作, 邀请他也测试一下软件, 给我们反馈。

 

当然客户可能会发现问题, 甚至提出新的需求, 我们表示欢迎, 我们要和客户合作,而不是对抗。

除了给客户演示之外,我们自己还会反思一下,看看有那些地方做的好,要继续保持;  那些地方做的不好, 要持续改进。

 

当我们完成了项目目标或可交付成果的时候,就可以对项目进行归档了,当然归档之前可以对项目行进中的一些问题进行复盘,给团队和个人提供一个反省和提高的机会。

 

 

image.png

 

总结:

 

CORNERSTONE作为新一代智能项目管理平台,专注于产品研发项目管理,致力于帮助企业全方位解决团队协作与研发痛点,内嵌精益/敏捷/DevOps方法论,让企业能快速响应市场变化和客户需求,同时还具备成熟的立体化智能数据分析系统,可自动生成报表,帮助企业科学量化团队表现,实时把控项目进展。CORNERSTONE适用于各行各业,产品体验链接(https://www.cornerstone365.cn/)。

aeef399ffa8046109e455da2e8c34dc4.png

  • 发表于 2019-10-10 14:46
  • 阅读 ( 1872 )
  • 分类:其他

0 条评论

请先 登录 后评论
CORNERSTONE
CORNERSTONE

72 篇文章

作家榜 »

  1. omicsgene 698 文章
  2. 安生水 347 文章
  3. Daitoue 167 文章
  4. 生物女学霸 120 文章
  5. xun 82 文章
  6. 红橙子 78 文章
  7. rzx 74 文章
  8. CORNERSTONE 72 文章