Scrum之旅--敏捷开发

    最近把《轻松Scrum之旅--敏捷开发的故事》看了一遍。水平有限，只是囫囵吞枣。

   先来个Scrum扫盲

1. Product Backlog：根据初始需求分解出来的任务列表，包括功能性和非功能性的所有功能，由Product Owner指定任务的优先级，开发团队开始某个任务时，再精确定义和分解这个任务。
2. Stakeholder：利益相关者，是项目成败对他们影响不大的一类人，他们参与提出产品的需求并积极提出反馈意见。
3. Backlog：一项工作
4. Sprint Backlog：在某个Sprint中要完成的功能。
5. Sprint：代表Scrum的一次迭代。
6. User Story：用户故事，从用户的角度对系统的某个功能模块进行简短描述。
7. Task：从Story中分解成多个Task

   流程

1. 产品负责人确定产品的功能和完成时间，确定产品功能的优先级--》Product Backlog
2. Scrum团队按功能的优先级，将功能分配到各个Sprint中，形成Sprint Backlog
3. 做Sprint计划，参与人员有产品责任人、Scrum Master、Scrum团队等。产品责任人从产品Backlog中挑选优先级高的任务，与Scrum团队一起决定在这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何才能按需求完成这些功能模块，并估计完成每个功能模块的大概时间。--》Story
4. 完成一个Sprint，需要Sprint评审
5. Sprint回顾会议由产品责任人、Scrum团队和Scrum Master参加。总结和反思，持续成长。会议宗旨：如何在下一个Sprint中做得更好！

    再说说自己的理解

• 敏捷强调以人为本，注重团队成员的自我管理，管理层以指导的方式参与，忌在旁边发号施令
• Scrum团队成员的自主性比较强，可以自由选择自己擅长和感兴趣的Story，发挥各自的特长

    看的时候感触挺多的，怎么一想写下来就完全没思路的呢，看来有想法还是要即时记下来啊，好记性不如烂笔头，果然是真理。  

    自己是做测试的，我们现在也是用敏捷开发，但可能我们还是不够敏捷，至少我们还要那么一大篇幅的需求文档，在开发产品时，我们还可以看看需求、写写用例，还可以写得挺详细的。有点疑惑就是，书上说出于敏捷考虑，有些Bug可以不提到Bug管理系统中，直接跟开发说就可以了，除非是那些不能马上解决的问题，需要进行跟踪的才提到Bug管理系统上。跟我以前接受的思想出入挺大的，是我还没有转到敏捷的道路上来吗？