敏捷开发之三:关于“用户故事(User Story, Issue)”

敏捷开发中的User Story,用户故事几乎是Scrum的基础,几乎所有的流程都围绕User Story而来。

为什么要拆分Issue

这是一个内部争论的话题,为什么要把一个需求拆分成Issue。在瀑布模式中我们叫它Issue或者Ticket,中文我以前喜欢叫特性。在2000-2008年的开发生涯中,我都使用一种称之为“特性列表法”的方法来管理开发项目,因为项目组的人员不多,一般是3个人到10个人以内,包括我自己业余做的一个人的项目。拆分特性的好处主要有以下这些:

  • 更加明确需求。因为需求书和原型设计中有时候会对某些功能描述过于简单,而技术分析的角度和需求又完全不同,如果不能对需求有很好的细分,是有可能带来无用功的。颗粒度来说,最好是拆分到一个按钮点击、一次用户交互等,以前从代码来说20行-50行,现在随着各类编程语言的进步,代码量不再做强求了。从时间上来说,一般一个特性是不超过一天的,一天2-3个都是合适的。在拆分需求的时候,产品经理和项目经理是会对需求有一个再认识的,为了避免浪费时间,这里并行就很重要。通常在Sprint 1开发的时候,可以开始Sprint 2的拆分需求了,并行思想是敏捷开发中的要旨,我也会反复强调这一点。
  • 容易控制和跟踪。从2011-2013年,我参与的开发开始人数更多,流程更长。而细分特性则更有价值了。不会所有的特性都是关于需求的,比如一些纯粹技术的,但是所有的需求都是特性,甚至和开发无关的,比如用户手册。只要有开发的特性,还会涉及到code review、测试等很多环节,因此特性的控制和跟踪非常重要,只是照着需求文档去做设计,不能从根本上防止遗漏。像Jira这样的工具对于每一个Issue都提供了像简单论坛一样的回复评论、附件上传等功能,来使一个项目组的成员对于信息的共享是一致的,并且可以通过Jira的流程设置来保证Issue在不同角色中的流转。我用过的开发管理工具不多,Jira是这方面最灵活和可自定义最强的。比如一个特性开发的同事完成后,可以自动成为代码检查者的任务,然后再自动转到测试同事等,并且这个流程是可以往前和分支的。有了这样的基础,敏捷Scrum中的看板就很有用了,可以看到每一个User Story分别在什么阶段,是谁在处理。
  • 知识保存。有了上面的介绍,这点就很容易理解了。在一个项目由产品经理完成后到最后上线,总是会有各种原因的修改或者微调,在敏捷开发中这个问题更加突出,虽然传统的变更文档还是不可少的,但是多了一个基于web的记录还是不错的,对于临时加入到项目中的或者新来的同事,都是一个较好的辅助手段,来知道一些事情的来龙去脉。
  • 时间控制。这也就不用再说多了,传统的项目分析或者敏捷的燃尽图因为有了这些特性,而每个特性都有计划完成时间和实际完成时间(通过log work,也就是时间记录功能),我们可以知道项目的进度,来安排加班或者增加人手,也有可能是可以稍微放缓一点。
  • 并行控制。加快开发项目不能只是依靠加班的投入资源或者减少需求,加班太累,投入资源即便从管理成本上来说也是昂贵的,减少需求是不太可能的。所以准时上线最好的办法之一是并行控制,多核CPU当然比单核的要快,为此要做的调度也是值得的。有了拆分的特性,假设有两个网页设计、五个程序员、四个测试等,每个人的工作分配会变得相对容易。人员不可能随意安排,因为特性虽然分拆了,但是还是有一定的连续性。只是拆分特性、网页设计、开发、测试、生产验收这些能够在时间上平行,已经可以比传统的瀑布方式至少快一倍(个人经验)。

这里再补充一下,我们用的基本都是Scrum方法,因此我提到的敏捷开发、Scrum开发等是一个概念。在我们使用的Jira系统中,User Stroy用户故事(这个是敏捷特有的)、Issue特性、Defect影响、Bug错误这些在逻辑层面上都是Issue,只是Issue的不同呈现。它们都具备Issue的共性,比如内容描述、责任人、下一步责任人、计划完成时间、计划耗用时间等。

敏捷开发之二:名词解释

敏捷开发Scrum方法的常用名词解释

敏捷开发的管理其实很难,效果好,所以难。

这次开始,聊一下平时碰到的各类问题以及应对方法,抛砖引玉。

传统的开发一般是产品、开发、测试、QA、上线这些角色,敏捷就复杂一点了,角色很多,名词也不少。我们先来做名词解释。

ScrumSprint

Scrum是一种敏捷开发框架,是一个增量迭代的开发过程。在Scrum中包括了若干个小的迭代周期(有的也叫冲刺),称为Sprint。大的项目会有若干个Scrum,每个Scrum中我认为至少有2个Sprint。

Scrum强调迭代,简单的可以理解一个Sprint就是一次迭代或者一次升级发布。

从逻辑上大致可以这么理解:Project-Scrum-Sprint-Epic-User Story,Project就是项目,Epic和User Stroy后面再说。

User Story

Sprint是一个目标,所以下面的User Story可以认为是具体的需求点,一个Sprint可能有十几个到几十个User Story。敏捷开发被很多互联网公司使用,因为这些互联网产品都是面对用户,并且用户需求从产品角度是不断变化的,所以这里需求点叫做User Story。但是我们现在其实还是会涉及到一些并不直接和用户打交道的功能点,不过为了统一也叫User Story了。(Jira系统中User Story和非敏捷方式的Feature,以及测试的Defect、bug都是一个级别,也就是Issue,所以User Story等可以理解为是Feature套了一件外衣。)

User Story(aka Feature)到底拆到多细,在我们执行敏捷的时候一直有争论。比较简单的来说,这要根据不同项目的情况来区分,web项目可以是一个页面,但是一个页面上有很多按钮的话,那么User Story也可以到一个按钮的功能。同时兼顾时间,一般一个User Story在3小时左右。如果程序员素质很高的话,还可以到代码行数,比如50行代码。颗粒度太粗,不能控制项目进度,太细也没有必要。

测试一部分是根据User Story来进行,也就是说既然都说要实现的功能点,自然要测试一下,但测试还不光是测试功能点,还会有专门的案例测试、压力测试等。产品和需求方根据User Story来进行生产验收测试,是够的。

我们在敏捷中,因为把需求、Sprint拆成了很多User Story,所以测试是可以提前介入的,但是会增加很多回归测试的工作量,对于交付时间来说是划算的。但对测试本身的工作量和要求来说,也提高了,这也是为什么说敏捷对于人员要求高的另一个原因。

测试的结果会有Defect或者Bug,这个测试包括开发测试和生产验收测试,比如在Firefox下打开页面菜单栏有5个像素移位,这是Defect,比如在Firefox下打开登陆页面后登陆浏览器报错,这是Bug。Bug基本是一定要解决的。Defect不一定,特别是在敏捷中,是可以区分优先级后放到之后的Sprint中的,这个取决于产品经理、项目经理、开发、测试等共同商量。

一个User Story从建立到开发到测试完成,也就close了。我们就是根据这个来查看、判断进度,做需求和资源调整。

Epic

Epic类似于传统的里程碑,在一些大的项目中需要。如果Sprint周期在2-3周,Epic意义不大。

Issue

项目开发管理中Issue的状态有已经建立、在开发、在测试、完成。

每一个Issue都是有估计时间的,最小单位30分钟,最多一般不超过3小时,和建立User Story的原则一致。

Stand up

Scrum每天有一个Stand up站会的要求,我们目前把站会简化成review上一日存在问题和提出目前问题,同时因为考虑到有时候开发在晚上有工作量,因此站会有两个,分别为晨站会和暮站会(很有诗意的名字),站会后邮件给到大家。(Jira的敏捷插件做的非常好,包含了几乎所有敏捷管理需要的工具和功能,但是站会没有看到小结的电子化工具,因此这部分用邮件),站会邮件中的问题列表是有日期编号的,提醒产品经理、项目经理、Scrum Master关注多日未解决问题。并且这样的话,比起纯粹站会或者邮件多了一个可追朔。每个问题都会有提出人、解决人、解决时间等。

对于Story Point,我个人认为意义不大,因为每一个Issue的Story Point的估计和时间估计是重复的,虽然说Story Point可以更加客观的评估,但是我认为项目管理是为了结果而不是为了评估,同时通过时间和一些后期设定也是可以完成项目评估的。要敏捷的话,该省的地方就一定要省。

敏捷开发中,对于项目开发的相关文档是另一个有争议的话题,我们这里一般瀑布管理的开发流程大约一个项目30-40个文档,那么敏捷是否可以减少文档的数量呢,在减少的同时怎么保证知识共享和知识传递呢?

敏捷开发之一:开篇简介

敏捷开发总论:IT开发项目中使用敏捷思想的Scrum开发方式。

从2005年开始研究如何可以让技术项目开发的更快更好,2011年前尝试过很多方法,我自己总结为这些是半敏捷的办法,有一定的敏捷思想,然后还不是很成体系,同时对于需求分析和测试、质量控制兼顾不够,当时的测试更多的是生产验收测试。2012年开始,一方面继续对半敏捷的方法进行实践,同时也开始试验基于敏捷框架实现的Scrum方法,通过连续的Sprint,来保证项目的迅速开发和迭代。

目前我们使用的是基于Scrum为主的敏捷开发方法,一次Scrum至少有2-3个Sprint,比较复杂的项目会有几个Scrum并行。

对于从需求提出、需求分析、技术分析、开发、测试、生产验收、生产配置等环节的主要流程基本支持的很好,新项目不算的话,一个Sprint基本可以在两周完成。并且在单元测试、案例测试、功能测试、生产验收测试上总结出一套行之有效的方法,达到敏捷开发的核心思想:快速+质量。

敏捷团队大约15个人左右,再多就不太好管理了,基本涵盖产品、UED、开发、测试等team,加上Scrum Master和QA等,20个人里面效率比较高。如果实在要超过20个人,建议分拆成不同的大team,单独配置Scrum Master和QA。

我们用的敏捷工具主要是Jira+GreenHopper,因为我们大部分的瀑布式项目还是基于Jira,所以用了Jira的敏捷插件后,对于Issue层面的管理没有什么问题,电子看板、燃尽图、Epic-User Story等Scrum特有的功能学习起来也很快。

我对敏捷开发的基本思想是兵无常势,水无常形,不拘泥于敏捷理论,通过对Scrum-Sprint-Epic-User Story/Defect/Bug的拆分,通过对每个Issue的时间控制,根据开发和项目发展的情况进行适度调整。

使用git管理develop分支心得之一

git的分支管理是最强大的,所以我们也尝试去用。当然一开始用的有点乱,并且我有一台work computer和一台home computer,我经常通过git在两台电脑之间保持连续性工作,最简单的办法是用master分支,不过那样太对不起git了,经过了很多尝试之后,发现我两台电脑的分支、tag已经不一致了,加上其他人使用的,所以服务端上也是另外一个样子。

这时,正好看得到这篇好文章,讲述了用master和develop两个分支,通过tag来管理版本等一些非常棒的git使用方法总结。

但是对于我这样git命令很不太懂的人,加上git本身一些比较奇怪的用户体验(我甚至觉得这就是linux的问题,所以现在用的人是越来越少了),折腾了很久,终于搞定了。

我的应用场景是所有这些介绍文章中没有提到的,就是我已经弄乱了分支,现在想用开发develop分支,发布时候合并到master,并且有好几台电脑(相当于好几个用户),同时我主要用的是tortoise git,因为几乎是图形化的操作,很容易。

1 删除git服务器上所有不需要的分支,不管是bitbucket或者github都有这个功能,先把主控弄干净。
2 按照阮的blog中介绍的,在本地一台电脑上,创建develop分支:git checkout -b develop master
3 切换到这个develop分支,git checkout develop
的确在git gui中打命令比较快和方便,用图形化界面肯定可以,但是一些参数万一弄不好就麻烦了。
4 在这台电脑上开发,修改代码等等,全部弄好了之后,上传,就用右键的上传命令,肯定是 Git Commit… -> ‘develop’,也就是当前修改的会传到develop分支
5 换一台电脑,如果这个computer B之前也像我弄的分支很多,并且已经不怎么同步的了话,可以这样做,先 pull 最新的版本,在pull的窗口里,分支名称可以自己输入的,然后我碰到的奇怪问题就是拉下来之后在本地并不是develop分支,本地还没有建立过,用git命令切换也没用。
6 google了一下,这样子操作,先切换本地到master,然后把不用的分支全部删除,然后用git fetch命令,就拿到了服务器上最新的分支情况,现在是干干净净的master和develop了,然后用前面的git checkout develop就可以了。

说实话,没有好好去弄懂git的原理,也不太想懂那么多,只要实战会就可以了,愚人之见。

吾生有涯

好像还是小时候,从来是不计较时间的虚度,喜欢电脑和编程,兴趣爱好广泛,但是不知道有多少个晚上也就是闲逛瞎弄,很多东西学得不扎实。记得大三大四就开始看turbo pascal的面向对象oo编程,可是心里浮躁,静不下来,一直到毕业后十年多,才终于走出了oo的第一步,中间很多程序都用面向过程的方式写,加上规划不利,浪费了时间,辜负了梦想。

1999年写理财软件第一版,2001年写第二版,还是做成共享软件,彼时也有万多元的收入,可惜2002年有一段空闲时间没有抓紧,然后就松了气,后来2003年换工作,更忙碌,就荒废了。2009年年底又开始第三版,起初还是做的很好,后来对于到底客户端有没有前途始终判断不清楚,是否要做手机版也把握不定,还有一个重要的问题是虽然软件架构开始设计的不错,但后来随着功能增加,没有及时重构,导致包袱越来越重,要迭代更新的难度越来越大,2011年又换工作,于是坚持了半年左右,又没有精力做下去了。

以前以为我是一个很有毅力的人,可以单就这些事情来看,还是虎头蛇尾多。虽然我早就不是一个程序员的角色,其他工作方面比上不足,比下有余,可是这个梦想终究还是有些许遗憾。

以前没有这么强烈的感受,时间不是什么奢侈品,如今,突然发现,吾生肯定是有涯的,曾经的梦想,如果不是完全做不到,还是应该专注的去执行的。一些事情的确不是一蹴而就的,重写一个家庭理财软件,也的确谈何容易,或许从需求分析到成为作品,需要半年,只是如今开始,那么明年四月或许可以看得到,现在不做,永远看不到。

不知觉,便是错过十年,或者更多。

GameMaker Studio 1.2

这个真是懂得入了,记得好几年前,用game maker写了一个简单的赛车游戏,学着里面的demo修改,还雄心勃勃准备写一个类似雷电的游戏,可惜也没有坚持下去。想起来,此生放弃了不少事情,真是有点可惜,或许这也是命运。

现在gamemaker已经不是当年那个小工具了,支持windows、osx、ios、android、html5等十一个平台,很厉害。

game maker studio 1.2 下载

破解程序下载

以下为网络摘录,没有验证过:

安装注意事项:首先运行安装包,安装gamemakerstudio1.2.1130,直到弹出激活窗口,点击use free edition,打开gms后关闭,然后打开任务管理器结束gms update更新程序(如果你原来安装运行过任何一个版本的gms,注册表里有注册项了的,不会弹出激活窗口,会直接打开程序窗口,关闭即可)。然后运行补丁文件,把路径改成你的gms安装目录,安装即可(好多人都找不到gms的安装目录,快捷方法,在开始-程序里找到gms目录下的chm help帮助文件,右击该文件,选择属性,查找目标即可(xp),win7,8右击打开文件位置。) 。默认帮你创建快捷方式在桌面了。如果是win7,8,记得以管理员模式运行。

iOS 7, 革命或者是创新

从iphone 1代以及ios 1.1.4(这个版本印象比较深刻)到如今的iphone 5和ios 7,短短六年,这是一个伟大的公司,可以改变我们的生活。

诸如市场营销之类可以有很大作用,但是伟大的作品就是伟大,乔布斯以及无数apple工程师的精心杰作,这是事实。否则,再好的市场营销也只能带来一时的欢呼,如同很多粗糙的国内的电子化产品。

白天,作为一个管理软件开发项目的我来说,深深的感受到我们的方法论的确还有很大问题,和国外的严谨细致相比,差距不小;另外,我们的产品设计由于种种原因,急功近利,要想完美,真的很难。在手机、电脑领域,大概也只有魅族、小米等稍微好一些了。

耐心、认真,站在用户的角度考虑问题,何其难啊!要拒绝很多诱惑。所谓十年磨一剑!

ios7

基础编程习惯的问题

看到这里 http://blogs.embarcadero.com/nickhodges/2010/06/09/39453

虽然这些都是一些很小的技巧,但是很遗憾,我觉得很多程序员在具体编程的时候并不是很在意这些。

目前,像我们公司招聘初中高程序员有以下途径:

1 大学本科或者研究生的应届生
2 培训学校的毕业生,在去培训学校前有各类情况,应届生、工作过等
3 有经验的程序员

上面情况中的1和2中的绝大多数在具体编程方面,很多人缺乏足够的技巧和基本功,我们的大学教育、培训结构培养了大量的“技术工人”,但是他们中的大部分只是为了工作而编程,并没有太多兴趣,也不关心外面的世界到底怎么发展了。这基本上就是目前的现状,很难改变。

我们的开发流程中有code review这个环节,但是效果一般。

如果你是对编程有兴趣的话,不管年龄,还是注意一下这些基础的编程习惯吧,所谓大牛,最牛的是在这些小地方。

Apple开发者帐号被攻击?

史无前例的,从上周五开始,apple的开发者网站就不能登录了,本来以为也就几个小时日常维护,没想到,连续将近三天。期间也收到过有点奇怪的邮件,说续费之类的问题。今天早上,收到了apple的邮件,估计是被攻击了。

Last Thursday, an intruder attempted to secure personal information of our registered developers from our developer website. Sensitive personal information was encrypted and cannot be accessed, however, we have not been able to rule out the possibility that some developers’ names, mailing addresses, and/or email addresses may have been accessed. In the spirit of transparency, we want to inform you of the issue. We took the site down immediately on Thursday and have been working around the clock since then.

In order to prevent a security threat like this from happening again, we’re completely overhauling our developer systems, updating our server software, and rebuilding our entire database. We apologize for the significant inconvenience that our downtime has caused you and we expect to have the developer website up again soon.

关于那些下载软件的无法理解

我们绝大多数人用的都是盗版软件,以前有个原因是正版软件太贵了,现在可能是习惯了。

相当一部分iphone越狱的人就是为了安装各类盗版软件,和人品什么的没有关系,就是习惯了。

但是我奇怪的就是,为什么有很多网站针对下载盗版软件、破解软件还要变相的收费。你真的做一个义士,挑战很多软件公司,给大家下载破解版本,倒也认了,注入csdn,提供盗版软件下载,好要收费。如同我非常看不起的另外一个网站:虾米网。这是什么强盗逻辑啊。

当然不止这些网站。

法律的东西我也不太清楚,但是从道义来说,如果可能应该支持正版软件,如果支持不起,可以理解。而很多组织盗版软件下载的网站,实在无话可说。

如同很多美剧小组,至少都是号称自己是非盈利性组织,虽然他们给版权方是造成损害的,但是至少也有个理由。

(这也是我为什么始终看不起淘宝的原因之一,依靠大量的盗版水货起家,然后漂白赚到钱后再修改规则,这样的原罪难道是中国很多创业者绕不过去的坎么?)