读书人

迅捷日记2011-08-03

发布时间: 2012-07-18 12:05:38 作者: rapoo

敏捷日记2011-08-03

下午和新同事们一起做了个好玩的游戏-“航海项目”,通过一个tiny project,大家一起吧完成了从最初的用户选择到最终的release plan制定流程,获益很多。

麻雀虽小五脏俱全,这个过程大体是这样的:

首先是根据PO的需求描述,大家一起把使用这个project的角色进行划分,方式是每个人做brain storm然后进行合并,发现自己的思维还有过于发散了,没有和项目保持一致,分解出的角色后来被证明大部分都不会使用这个tiny系统,。

角色划分完成以后,是制定persona,根据划分好的角色举出一个典型的用户,丰富他的资料,比如人名啊,头像啊,年龄啊,上网经验啊,网购爱好等信息,这个环节比较有意思,特别是制作persona的头像,很欢乐。

然后是业务流程的梳理,这个地方我也犯了一个错误,主持人要求梳理用户操作流程与分支,而我想当然的以为是提取

用户的use case,T_T,后来补上了一条关键路径。这个环节我的感觉,应该就自己不清楚的地方多与Po进行沟通,我们组这方面

做得不够。

梳理完流程以后,进入下一个环节,story相关的工作,首先是根据前一步我们梳理的用户流程进行story的分解,然后对story完成ac的评估,这里需要强调的是两个三范式,一个是use story的格式,这个比较熟需,作为一个XX,我希望XX,以便于XX,另一个是ac的范式,given一个条件,when发生什么,then什么结果,在写user story的时候有个地方要特别注意,在以便于这个范式里不要有“等”出现,因为会让RD无法获取正确的信息,必须明确。

story完成以后是UI设计,大家一起用最简单的a4纸干起了ux的工作,这个地方主要体会到了界面设计的不易,这个次方主要是需要注意UI设计需要和story保持联系。

story的相关工作完成以后是由RD来评估(evaluation)story的度量,这里又犯晕了,说的是使用菲波纳切数列评估时间,我又把以前评估story用到的序列弄上了,悲剧,被人鄙视没学过数学,哈哈。

RD的评估完成以后是challenge环节,PO拿到写好story、ac、evaluation的卡片之后对我(我模拟RD)进行challenge,主要工作有两点:一个是对8(包含8)以上的e进行可行性拆分,尽量减少到最小;第二是对某些相关的story进行比较,得到一个合理时间。

以上工作完成以后,我们已经拿到了每个story的evaluation,这个时候需要由PO来选择story们的优先级制定release plan,这个地方PO需要考虑的是velocity与ac的制衡关系,因为时间问题,大家弄的都不太好,呵呵最后只安排了两个sprint plan,一次release完成。

?

大体流程就是这样,中间我犯了不少错误,不过还是获益匪浅的,这个tiny project的流程是一个很正规的scrum流程,相对于我们之前项目的scrum实践,多了几个环节,特别是前期部分是第一次接触,有些交叉环节的实践也不太一样,学到不少东西。

最后感谢下一起做游戏的同学,特别是主持人马波同学哈。

?

附上时间表:

Scrum DOJO:Baidu Publishing On-line

?

two groups (2members)

. team one: Xiaoping, Qi he?

. team A ?:Xiao song, Qin qin

?

rolesidentification

. 6 min

?

rolespresentation

. 2 * 2 = 4 min

?

persona (fill inroles' info)?

. 10 min

?

personapresentation

. 2.5 * 2 = 5min

?

Biz workflowidentification

. 10 min

?

Biz workflowpresentation

. 2 * 5 = 10 min

?

story/AC/Low-Fiprototype writing

. 25 min?

?

storypresentation

. 10 min

?

estimation &review

. 10 min

?

release plan& presentation

. 5 + 5 = 10 min

读书人网 >软件开发

热点推荐