背景
之所以写这篇文章，是因为，最近身边发生了很多关于敏捷开发相关的事情，所以想全面的将我现在了解到的，进行一个阶段的回顾总结，以便量化，更好的成长
背景一： 从去年起就开始在担任公司的一些项目的开发负责人， 大大小小的项目过手的也有那么五六个了。有失败的，有成功的，有没有delay的，有delay的，每一个项目我都有召集大家一起Review， 然后把大家所有的意见整理成册。以便之后回顾， 一直在尝试敏捷的开发模式。 虽然实施了一段时间，但总感觉自己还是在某些方面没有领悟到精髓。所以也一直在社区踊跃的学习。
背景二：上周末去参加了 ThoughWorks 的敏捷工作坊。一共2天时间，费用300 RMB，整个Workshop, 以真实项目出发。模拟真实的敏捷流程，建立项目，大家一起拆分story, 实施迭代，每天总结。等等。把整个流程跑的挺顺畅。两天下来，和自己以前的工作方法找到了一些差异的地方，以前自己总认为做的不好的地方，在这次真实的实施过程中，也找到了满意的答案。
本文主要记录我在Workshop中感触比较深，且自己一直没有做好，没有注重的点。
第一个开场小游戏
规则: 25个人，每五人一组， 每组完成如图上的所有任务。最后看各个小组的表现情况。
我们组整个实时下来的结论：
- 在有限的时间。做一些事情，分工明确是第一，同时把分工详情和进度，能够友好的展示出来，也是很关键的，这点我们没有做好
- 一开始分配任务的时候，没有注意到任务的优先级，而是直接评估故事点，就按故事点的量平分了任务。
- 大家都在分工做，但是没有设立专门的人来验收。没有PO
重新思考用户故事
用户故事:
- 用户故事是简要的意向性描述,它描述系统需要为用户做的事情以及对用户的 价值。
- 作为<某类利益相关者>, 我想要<某个功能>, 以便<达到某个目的或获得某种价 值="">
用户故事三要素:
- 角色: 谁使用了这个功能
- 功能: 需要完成什么样的功能
- 价值: 为什么需要这个功能, 这个功能带来了什么价值
故事: 作为一个病人，我能够正常的注册账号，以便我能查看各个医生的预约信息。
问题：
1. 如何评估该story的范围，以及它的工作量?
2. 如何验收该Story是否通过?
结论:
Acceptance Criteria 很重要， AC明确了工作范围以及工作量，已经衡量标准，写story, AC是必不可少的。否则 story 是无法评估的。
验收条件: Acceptance Criteria
- 一系列的条件来明确事故的范围
- 作为测试设计的输输入
- 作为事故的完成标准
- 考虑故事实现的不同变量, 在不同上下文的处理
- 每个故事： 2 ~ 8 个验收条件
story 的特性，以及质量衡量标准
一个story 如果拆分成task, 我们应该注意哪些内容？
一次迭代有很多stroy, 如何把这些story有机的结合并展示出来？
这个时候 User Journey 就尤其的重要
在 sprint 中我们容易忽略的事情
- 其实每个sprint 都应该有一个自己的calendar
- 每个sprint 一定是可交付的
- 在每个sprint 结束后，一定要安排一个Demo 验收会议
一个有趣的面试题
一个讲师说，他在面试的时候，经常会问一个问题：当你在用一个工具或者产品或者技术框架的时候，遇到了问题，你首先的解决方案是什么？
结论：
他说很多人，都说的是Google
如果有人回答百度的话，这个人基本可以不用面了，直接不要了。
他期望的回答是：看官方文档
恩，还是值得体会的。
最后附上几点心得
- 重复是万恶之源
- 如果开发一个项目，出现了两个分支，会被人鄙视
- Martin Fowler 给当代年轻程序员的建议之一: 写代码的同时，尽量去理解业务
最后附上一个自己基于本文整理的一个脑图
(点击鼠标右键，在新的标签页查看该图片，可以查看高清大图)
《完》