2011-04-14 20:17:00 cheny_com 阅读数 2037
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。

“作为一个……,可以……,以(以便)……”不同于一般专注于功能的需求条目描述方法,三个……把角色、功能、价值跃然纸上。然而使用不当,却有可能形似而神不似。

下面就三个部分分别举出一个例子。

 

网络游戏的排行榜功能:“作为一个玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可。”

这个功能可以激发玩家的“斗志”,鼓励购买道具,是个不错的想法,但实现起来却有技术问题:服务器中的玩家太多了,实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心,即使关心,也不会为了提升排名去购买道具,只有一批(也有上百个)顶级大佬才会真正受此蛊惑。

这个故事后来被改为:每周重新排名一次,而且只显示TopXXX(很像csdn的“排名两万以外”)。所以如果写成故事,就变成:

“作为一个排名靠前的付费玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可(以刺激消费)。”

当然,对小虾米们也有刺激消费的方法,比如打怪掉落了一个很棒的道具,却要花钱买打孔材料和镶嵌宝石,即使用保健因素而非激励因素让他们消费,那是另外一个故事了。笔者曾经体验过的一个游戏中有帮派战争,大号会争当“连斩狂客”,小号则有“寻宝冠军”可得,且人人均有积分,因此各层人物都争相参加。

这个故事让我们理解到:“用户”这个词太笼统了,如果他们的“价值观”差别很大,就要分别为他们写故事,才能吸引他们使用功能,达成价值观。

 

权限查询功能:“作为管理员,可以查询所有用户的权限,以了解所有用户的权限”。

一种很常见的写之无味不写不行的故事,因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的,多半有其目的:有人反映自己访问不了某个文件,有个项目死活加不上新用户,有人刚刚离职,有三个外包团队的人需要在最近三个月在项目中作为成员一起工作……

知道这些就好多了,当点击“权限”这个tab后,多半不会出现“所有用户的权限”(倘若想想有10000人的企业),而是继续出现几个子链接:查询个人权限,项目成员,人员离职,限时权限(外包人员管理)……

当然,这需要一大堆故事了,但如果一个给客户带来明确价值操作友好的产品正是我们所追求的,我们极有可能选择开发其中最高价值的几个,然后再留下之前那个“万能”但又什么都干不太好的。

这个故事让我们理解到:功能不等于价值,要理解用户操作功能的业务目的,不要随意抛出万能的功能。

 

杀毒软件的防打扰功能:“作为一个用户,可以选择‘认可所有相似操作’,以便同意或禁止连续的相似操作。”

这看起来也是个很不错的功能,但笔者曾经在安装软件的时候用到这个功能,尽管选择了“认可所有相似操作”,窗口仍然跳个不停,直到后来仔细查看弹出的信息,原来在软件安装过程中要进行很多“不相似”的操作:修改注册表,创建C盘目录,向system32中拷贝dll……而这个杀毒软件在处理的时候,连注册表不同位置的修改都认为是“不同的操作”。

要改好这个故事,就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程,就可以写一个这样的故事:

“作为一个用户,可以在安装软件时选择‘认可本次安装操作’,以便一键完成正常的安装操作。”当然何为“正常”的操作需要额外说明,但整体客户价值却更精准地表达出来了。

这个故事让我们理解到:“客户价值”是要从客户的角度来理解的,否则极可能跑偏。

插播一段技术变革带来的软件体验变革。在传统exe软件的时代,构造一个“界面”是很累的事情,所以仔细想想Word/Excel,无论你是编辑它、观看它、评审它、审批它、使用(Excel)它,看到的都是一个界面。而且由于这些产品都是被设计为单个用户使用的

 

       最后留下几个思考题让大家费费脑筋:

在手机上输入“我”的时候,经常(接近80%)被识别为“舟义”等罕见文字,怎么办?(假设我们是汉王)

       Visio中画图的时候经常发现图形之间有细微的未对齐,需要放大到400%之后才能调整好,怎么办?(假设我们是微软,其实这个问题不久前我才知道被一个叫做“SmartDraw”的软件解决了,但估计微软是放弃了。)

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2011-09-16 23:04:51 cheny_com 阅读数 8260
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

这是敏捷开发用户故事系列的第二篇。(栏目目录

敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。

“作为一个……,可以……,以(以便)……”不同于一般专注于功能的需求条目描述方法,三个……把角色、功能、价值跃然纸上。然而使用不当,却有可能形似而神不似。

下面就三个部分分别举出一个例子。

网络游戏的排行榜功能

“作为一个玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可。”

这个功能可以激发玩家的“斗志”,鼓励购买道具,是个不错的想法,但实现起来却有技术问题:服务器中的玩家太多了,实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心,即使关心,也不会为了提升排名去购买道具,只有一批(也有上百个)顶级大佬才会真正受此蛊惑。

这个故事后来被改为:每周重新排名一次,而且只显示TopXXX(很像csdn的“排名两万以外”)。所以如果写成故事,就变成:

“作为一个排名靠前的付费玩家,可以通过显示排名,以便让自己在服务器中的地位获得认可(以刺激消费)。”

当然,对小虾米们也有刺激消费的方法,比如打怪掉落了一个很棒的道具,却要花钱买打孔材料和镶嵌宝石,即使用保健因素而非激励因素让他们消费,那是另外一个故事了。笔者曾经体验过的一个游戏中有帮派战争,大号会争当“连斩狂客”,小号则有“寻宝冠军”可得,且人人均有积分,因此各层人物都争相参加。

这个故事让我们理解到:“用户”这个词太笼统了,如果他们的“价值观”差别很大,就要分别为他们写故事,才能吸引他们使用功能,达成价值观。

权限查询功能

“作为管理员,可以查询所有用户的权限,以了解所有用户的权限”。

一种很常见的写之无味不写不行的故事,因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的,多半有其目的:有人反映自己访问不了某个文件,有个项目死活加不上新用户,有人刚刚离职,有三个外包团队的人需要在最近三个月在项目中作为成员一起工作……

知道这些就好多了,当点击“权限”这个tab后,多半不会出现“所有用户的权限”(倘若想想有10000人的企业),而是继续出现几个子链接:查询个人权限,项目成员,人员离职,限时权限(外包人员管理)……

当然,这需要一大堆故事了,但如果一个给客户带来明确价值操作友好的产品正是我们所追求的,我们极有可能选择开发其中最高价值的几个,然后再留下之前那个“万能”但又什么都干不太好的。

这个故事让我们理解到:功能不等于价值,要理解用户操作功能的业务目的,不要随意抛出万能的功能。

杀毒软件的防打扰功能

“作为一个用户,可以选择‘认可所有相似操作’,以便同意或禁止连续的相似操作。”

这看起来也是个很不错的功能,但笔者曾经在安装软件的时候用到这个功能,尽管选择了“认可所有相似操作”,窗口仍然跳个不停,直到后来仔细查看弹出的信息,原来在软件安装过程中要进行很多“不相似”的操作:修改注册表,创建C盘目录,向system32中拷贝dll……而这个杀毒软件在处理的时候,连注册表不同位置的修改都认为是“不同的操作”。

要改好这个故事,就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程,就可以写一个这样的故事:

“作为一个用户,可以在安装软件时选择‘认可本次安装操作’,以便一键完成正常的安装操作。”当然何为“正常”的操作需要额外说明,但整体客户价值却更精准地表达出来了。

这个故事让我们理解到:“客户价值”是要从客户的角度来理解的,否则极可能跑偏。

 

 

编者注:本博客是以前的旧文,因符合本系列内容,稍加修改穿插于此。

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2017-04-04 21:44:38 kenneth_h_liu 阅读数 3550
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

最近又一个项目用瀑布方式做砸了(由于本文会多次提到本项目,我们就叫她项目X吧)。项目X刚开始的时候,我们部门的敏捷转型还没有起步,所有项目依然用瀑布方式。这个项目我一开始就想采用敏捷,毕竟这才是我拿手的,和客户那边也沟通过,他们也不反对尝试。而且项目的自主开发部分是用Java写的,有一定的JUnit测试覆盖和持续集成(CI)基础。但是由于我一直没有想好这个项目可以如何拆分进而迭代,所以项目的敏捷转型一直被搁置,其实际开发过程依然是瀑布方式,也遭遇了所有瀑布方式会遇到的问题。


传统需求难以描述用户的真实想法,传统瀑布开发没有快速反馈机制


瀑布不行,向敏捷转型已经是共识,但是具体怎么做呢?通过对项目X的复盘以及对其他项目的思考,以下是我的一些心得。


把项目拆分成用户故事才是硬本领


我也算是个“老敏捷”,但像前面说的,在面对一个具体项目,不会把项目拆分成用户故事,就无法敏捷起来!真正的敏捷开发必须是基于用户故事的开发过程


所谓用户故事就是含有一定业务价值的端到端交付。瀑布开发是把项目按照不同生命周期阶段横向拆分的过程。而敏捷开发是把项目或产品或业务目标竖向拆分成若干可体验、可交付的用户故事的过程。一个用户故事,应该是用一两个月甚至几个星期或更短时间就能做出来的东西,我们可以通过它更早地获取用户反馈,从而确定产品的正确性。这也符合敏捷倡导的“小步推进,频繁验证”的原则,是降低项目风险最有效的方法。



瀑布和敏捷的不同拆分过程


只有基于用户故事开发才能快速交付和持续交付


正如前面所说,我们用一两个月甚至几个星期把第一个用户故事做出来并给用户体验和反馈,而不是大半年甚至一两年后在项目后期才把产品给用户体验,我们更早、更快地交付并获取反馈,而不断重复这样的过程,就是持续交付的过程。在整个过程中,我们都在交付业务价值,而不是战战兢兢地拿着一堆半成品面对那个死亡日期的逼近。


项目X最终呈现给用户的是不同类型的基金报表,其实每一类报表就是一个用户故事。如果我们一开始就以最重要的一类报表,作为首个用户故事进行开发,只需要两、三个月的时间,我们就可以把这个用户故事完成并交付给客户进行测试和反馈,有任何的反馈我们都可以及时进行修正。得到客户认可后,我们就可以如法完成其他报表。更重要的是,从第一个用户故事,也就是最早可测试产品获得的用户反馈将确保其他用户故事的开发也在正确的方向上。而在瀑布方式下,两个月后我们才刚刚收到需求文档,什么开发都没有开始。



尽早定义和交付最早可测试产品可及时获取用户反馈,确保产品正确


因此,定义好用户故事是实施敏捷的基础,没有这个基础,其他敏捷实践的实施其实只是局部改善,依然是战术上的改良,而不是战略上的改变,长远来看,收效有限并容易倒退。敏捷开发是一个有机体系,各种具体的方法论和实践需要打组合拳才能发挥出其应有的效力,基于用户故事开发是一切的基础:


1.    如果不是基于用户故事开发,简单地把项目的长周期拆分成短周期并不是真正的迭代,因为每个周期都没有可体验、可交付的东西,依然像瀑布一样在不断堆积半成品,这也不是真的Scrum

2.    如果不是基于用户故事开发,测试驱动开发(TDD)和行为驱动开发(BDD)很难开展,因为缺乏具体用户场景的描述,很难写出具体、简明的测试用例,因而很难累积足够的自动化测试提高系统的可改性,内部质量、重构、持续优化便无从谈起;

3.    如果不是基于用户故事开发,持续集成(CI)也意义不大,因为提交的代码并没有构成可交付的产品,其实并没有真的在集成。


既然用户故事是敏捷开发的重中之重,那么如何定义好用户故事呢?诚然,这是敏捷转型的难点。业界有关具体定义用户故事的说法并不多,这也是为什么用户故事一直被忽视,因为还没有标准答案,大家无从下手。《用户故事地图》是为数不多的较具体地阐述用户故事定义方法的书籍。所谓用户故事地图就是从左至右按时间顺序罗列用户行为(也就是流程的每一步),在每个用户行为下从上至下罗列相应的细节,包括所需要的开发点,构成一个二维的“地图”。基于这个地图,还可以对每个开发点的业务价值进行审视,找出最小可用产品(MVP并制定发布计划。但是直接从整个项目或产品入手编制用户故事地图其实非常困难。



《用户故事地图》是为数不多的较具体地阐述用户故事定义方法的书籍


具体用户场景+用户故事地图则是我认为比较可行的方法


所谓具体用户场景,就是设想一个用户在使用某个功能的具体过程。比如我们使用共享单车,具体的场景是用户找到一辆单车、用手机扫码和开锁、骑行、到达目标地、锁车、支付费用。这个场景的每一步,按照时间顺序从左到右罗列出来,然后再分解每一步所需要的系统或模块,在每个系统或模块下从上到下罗列所需要的细节,包括所需要开发点,便形成一个用户故事地图。如果这个场景依赖于其他场景,比如注册,那么就设想注册的场景及其用户故事地图。如果注册就是所有其他场景的前置条件,就优先开发它。



场景+地图是一对好基友


再举一个传统金融项目的例子。比如银行开户,其中一个典型场景就是具体某类客户通过某个渠道开某类账户的过程。在这个例子里,可以想象它会有很多个不同的场景,而每个场景都是一个交付。有了一个具体场景,我们就可以分析要实现这个场景,背后需要哪些系统来支撑,每个系统需要开发什么,形成一个用户故事地图。


当然,以开户为例,开发首选场景的过程会相对较长,因为软件从无到有有打地基的过程,业务实现也需要各个系统的统筹配合,但它并没有看起来那么困难和漫长,因为:


1.    由于一个具体场景相对于整个项目要简单得多,相比传统方式下各个系统各顾各围绕所有功能进行开发,开发内容相对简单很多,集成的难度也相对低;

2.    首选场景的开发其实为其他开户场景打下了大量基础,其他场景的开发会相对快和容易很多,交付会加速;

3.    可以采用微服务架构、云服务、容器和像SpringBoot这样的快速开发框架在技术上大大缩短了从搭地基到业务逻辑开发的前置时间。


项目X中,开发第一个用户故事确实会是开发周期最长的一个用户故事,但是由于它为其他用户故事打下了大量基础,它们的开发会大量重用第一个用户故事的代码,开发与交付会大大加快。


基于场景更易理解和测试


因为场景具体和相对简单明了,不像传统需求的功能描述那么抽象和割裂,它更容易解释、理解和测试,也是测试驱动开发(TDD)和行为驱动开发(BDD)的基础。


基于场景考虑用户体验


设想场景也是考虑用户体验的过程,前面提到的更早和频繁获取的用户反馈也包含用户体验。

用户体验并不是互联网产品的专有名词,在传统的业务开发中,用户体验同等重要,只是它一直在瀑布开发中被忽视。


在项目X后期,离原定交付日期只有一个月了,客户提出在测试过程中发现,由于一个请求需要在不同系统中处理,很难追踪,建议增加一个统一的请求ID作为识别。这时我们有两个选项:


1.    我们的目标是按照计划把原定的所有报表按时交付,因此这是新的需求或需求变更,不应该在这个时候考虑;

2.    我们的目标是实现业务价值,客户在测试中发现的这个问题在上线后必然会被无限放大,不解决这个问题,用户体验和可用性极差,我们应该优先解决这个问题。由于时间有限,我们要和客户沟通能否先集中精力测试某类报表,确保操作的用户体验和可用性,把一个月后的发布目标改为先上线这类报表,实现部分业务价值,其余报表在这次发布后再测试和上线。


前者是瀑布的思维,后者是敏捷的思维。而按照瀑布思维交付,就像我们新装修完一间会议室,电视机、视频会议主机、电话都有,每个设备单独都能通电开启,但是电视机不能连接视频会议主机进行视频会议,也不能连接电脑进行演示,电话也没有设置好不能进行通话,也就是所有设备对用户来说其实都是不可用的。这样的交付有何意义?这几个需求哪怕只有一个能被满足,都比现在这种情况要好。


其实每个项目的需求或产品的设计,都是由一个个具体的场景构成的


如果我们和客户能从一开始就以场景作为切入点,我们的眼里就不再是一个个孤立的功能,而是一个个有具体业务价值、可交付的用户故事,开发的过程便是这一个个业务价值的持续交付过程,这也是一个产品长期演进的过程,项目只是产品演进的一个个小插曲,软件开发中最不可控的因素——时间对于客户来说也变得不那么敏感。在此基础上,再结合其他敏捷方法论和实践,锦上添花。


总  


传统瀑布开发是半成品堆积而且缺乏快速反馈的过程,传统需求只考虑功能而不考虑场景和用户体验。敏捷开发是基于用户故事的业务价值的持续交付过程。把项目拆分成用户故事是实施敏捷的基础。具体用户场景+用户故事地图是定义好用户故事的一个具体方法。



关于作者


o       早期敏捷践行者

o       起步于极限编程

o       熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发


关注公众号


2018-02-27 12:40:46 aofengdaxia 阅读数 682
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

《C#敏捷开发实践》是一本相当不错的良心之作。本书分为两个部分:

第一部分:讲了敏捷开发的一些原则,书中列举了一些很不错的实现例子。本书主要使用的是Scrum的敏捷开发流程 
第二部分:通过一个具体开发过程中的实践,讲了如何应用这些模式。

对于本书的理解

本书讲解了C#敏捷开发,首先我们承认没办法做出一个大而全的软件,没办法一次性的完成用户的需求。所以我们需要去拥抱变化,采用迭代的方式逐步去适应客户提出的需求。而适应市场,拥抱变化需要做几方面的改变,首先我们需要采用更加敏捷的开发流程,其次在开发中我们需要一些技术手段,去实现自适应的系统

关于敏捷开发的理解

首先本书中介绍了Scrum敏捷开发的一般流程。个人理解的Scrum是把一个产品通过迭代演化的方式分为若干个阶段(冲刺)来开发,在每个开发中,完成一个最小可以演示的单元。把要开发的内容,从用户的角度去讲几个故事,然后把这些故事去分成开发任务,去一一实现。因为我们承认我们开发的软件是不完整的,需求会不断的变化,所以我们采用了迭代开发的方式进行开发,而迭代开发就需要我们去拥抱变化,同时快速的相应市场。

Scrum开发中的角色

  1. 项目负责人 主要是负责和客户进行沟通,把客户的需求转化为故事,同时组织团队进行评估、开发和验收
  2. scrum负责人,负责组织敏捷开发的流程,对开发中的问题,反馈进行记录
  3. 开发团队,负责实现故事点的开发,同时完成自己的单元测试
  4. 测试团队,负责测试开发人员完成的开发工作。

scrum的一些基本的流程

  • 首先要进行开发大会,对开发进行评审。
  • 把用户对产品的需求进行拆分,按照阶段进行迭代。从最小的可演示单元到最小可市场化的产品,再到逐步丰满,完善的产品。
  • 然后把若干个可形成第一次的可以演示的故事挑选出来。同时对故事的开发难易程度进行评估,评估的结果以故事点的形式进行呈现出来。
  • 然后挑选可以在1-2周可以实现的故事,分解成开发任务。
  • 开发人员进行开发,在开发的过程中努力的分析可能存在的变化,去开发一个可以拥抱变化的自适应系统。
  • 开发人员在开发过程中,需要测试驱动开发,测试说明了功能意图和实现的边界,能满足测试需求的功能点,才可以满足需求
  • 在开发过程中,要逐步优化和重构。
  • 开发完成后,交付测试人员,完成测试
  • 组织演示,让利益相关人员进行参与,提出需求和意见,行程挤压工作。
  • 开敏捷总结大会,找出什么是做的好的,什么是做的不好的,那些需要改进,那些需要坚持,那些实出乎意外的。
  • 然后再次进入这个循环,同时敏捷开发的负责人需要把进度记录到scrum板上。

    scrum的一些名词

  • 猪:全身心参与开发的人
  • 鸡: 参与开发,但是非全身心
  • Scrum板:记录scrum的一些开发过程
  • 冲刺:把若干故事点进行罗列,进行一个阶段的开发,完成一个最小的可演示产品
  • 挤压工作: 待开发完成的故事点
  • 每日站立会议:需要在每天,站立说明自己做过的工作和将要计划的工作,以及遇到的问题

    自适应系统的一些概念

    软件工程的SOLID原则

    1. 单一职责原则
    2. 开闭原则
    3. Liskv置换原则
    4. 接口分离原则
    5. 依赖注入原则

原则自适应的一个特征

应该尽量减少软件的依赖,同时避免无需的依赖,软件应该依赖于抽象,而不是依赖于实现。所以在软件开发中,尽可能的灵活使用接口,隔离变化是做好自适应系统的主要难点。
而多种设计模式都是为了更好的做出自适应系统。

依赖接口而非依赖实现的好处

  1. 方便隔离变化,软件的实现和细节无关
  2. 方便单元测试
  3. 有利于软件的重构和优化
  4. 可能会降低软件的可读性

书中讲到的集中常用的设计模式

  1. 括谓语修饰器
  2. 分支修饰器
  3. 延迟修饰器
  4. 日志记录修饰器
  5. 性能修饰器
  6. 异步修饰器
  7. 属性和事件修
  8. 空对象模式
  9. 策略模式

学会的几个新的词语和方法

  1. 代码味道
  2. 模式和反模式
  3. scrum开发
  4. 修饰器的详细模式
  5. 逆变和协变
  6. 空对象模式
  7. 阶梯模式和随从反模式
  8. 纵切关注点

下一步如何深入学习和研究

  1. 把修饰器模式的代码,认证的自己敲打一遍,增加印象
  2. 把书中第二部分的代码从Github上下载下来,自己研究一遍,同时敲打一遍
  3. 买几本Scum的书,认真的学习,并且在实践中去贯彻。
  4. 抽点时间搜索和研究学习下逆变和协变。
  5. 抽点时间,再认真的下载几个开源项目学习下。
没有更多推荐了,返回首页