这是一个卡片, 背面还会记录下针对需求的讨论和验收标准。
用户故事主要彰显的是: 谁做了什么事, 带来什么商业价值。
2. 怎么决定每个小开发周期(我们称之为迭代吧)要开发的东西?
用户故事得有估算, 得有大小, 太大了一个迭代开发不完 , 还得拆分一下。
我们需要对需求按照优先级进行排序, 按照优先级从高到低的原则来开发。
3. 不要架构设计了吗?
一上来就按优先级选择需求, 直接进入迭代开发, 把架构师撂在一边,合适吗?
架构工作肯定还是需要的,在正式的迭代周期开始之前需要架构设计, 但是和设计出面面俱到的架构设计不同, 我们更需要演进式的架构, 随着迭代的推进而进化。
4. 那详细设计怎么办?
在每个迭代开始的时候,团队在一起把这些用户故事给拆分成一个个小的任务, 这个拆分的过程就相当于详细设计了。 对于一些特别复杂的,例如算法, 当然可以写文档,帮助大家理解。
5. 由于是迭代式开发, 这个迭代周期修改上一个迭代周期的代码在所难免, 怎么保证不破坏原有的功能? 总不能每次都手工重测一遍吧?
这个绝对是一大难点, 答案就是自动化的回归测试, 包括单元测试和功能测试。
开发人员写代码的同时,也要写下自动化的单元测试, 测试人员需要开发自动化的功能测试, 这样一旦有了代码的修改,就可以运行它们, 检查现有功能有没有被破坏。
像持续集成这样的基础设施是必不可少的, 每天,每小时,甚至每次代码提交都会触发编译,打包、部署、测试这样的过程。
6. 这么短的开发周期, 测试人员怎么测试啊?
开发和测试需要同步进行, 当开发在澄清需求的时候, 测试需要参与, 当开发在编码的时候, 测试人员在编写测试用例,等到一个用户故事开发完,马上就可以投入测试。
7. 看来开发、测试之间需要紧密的协作, 它们之间怎么沟通?
肯定是面对面的沟通, 有问题就跑到对方的座位那里去问,大家的座位最好在一起, 扭头就可以讨论, 尽可能减少效率不高的电话、QQ/微信等工具的使用。
开发团队每天都开一个15分钟左右的站会, 展示自己的进展和计划, 让进度保持透明, 及时暴露问题,解决问题。
8. 客户什么时候可以做验收测试?
随时欢迎, 但是我们更倾向于迭代结束以后, 这时候功能会稳定下来, 我们会给客户做一个演示, 告诉他这个迭代完成的工作, 邀请他也测试一下软件, 给我们反馈。
当然客户可能会发现问题, 甚至提出新的需求, 我们表示欢迎, 我们要和客户合作,而不是对抗。
除了给客户演示之外,我们自己还会反思一下,看看有那些地方做的好,要继续保持; 那些地方做的不好, 要持续改进。
估计你也明白了,这种看起来很美的迭代化开发方法实施起来挺不容易的, 如果我们给它起个名字的话, 可以叫做:敏捷软件开发。