下午和新同事们一起做了个好玩的游戏-“航海项目”，通过一个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 (2 members)
. team one: Xiao ping, Qi he
. team A : Xiao song, Qin qin
roles identification
. 6 min
roles presentation
. 2 * 2 = 4 min
persona (fill in roles' info)
. 10 min
persona presentation
. 2.5 * 2 = 5 min
Biz workflow identification
. 10 min
Biz workflow presentation
. 2 * 5 = 10 min
story/AC/Low-Fi prototype writing
. 25 min
story presentation
. 10 min
estimation & review
. 10 min
release plan & presentation
. 5 + 5 = 10 min