摘要： 1.评审会(Review Meeting) a.小组向产品经理展示迭代成果。 b.产品经理给出产品的评价和反馈。 c.以用户故事是否能成功交付来评价任务完成情况。 怎样展开评审会？ 答：敏捷开发采用时间盒(Time Boxing)的方法，即限定时间而不限定范围。所以迭代不会延期，因为在迭代终点将放弃未完成的故事。 评审标准是什么？ 答：整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事"差一点就完成了"，这种情况属于未完成。 分析说明: 常常发生很多故事都已经开始开发了，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。 ... 阅读全文

摘要： 1.办公环境开放办公环境是敏捷开发的一个符号。与传统的开发中"背对背"地躲在格子里不同的是敏捷开发提倡沟通与互动，除了每天的站立会议外，随时随地发生的沟通也是不可缺少的。而在旁边放置一个随时可以涂鸦的白板，则是团队的最爱。2.每日立会(Standup Meeting) a.队员认领任务(或由组长协商分发)，对立或与别人一起完成任务。 b.团队内部利用【每日立会】来沟通进度。 c.开发团队利用【燃尽图】来展示整体进度。 d.如果没有特殊的原因，原则上迭代期内无任何变更。什么是每日''立"会？答：由于每次的会议时间为10~15分钟，人们习惯于在座位的附 阅读全文

摘要： １.迭代计划会在每个迭代的第一天召开，目的是选择和评估本次迭代的工作项。２.产品负责人逐条讲解最重要的产品功能。３．开发团队共同估算故事所需的工作量。直到本次迭代的工作量达到饱和。４.产品负责人参与讨论并回答与需求相关的问题，但不干涉估算结果。产品负责人准备什么？讲什么？准备工作：条目化需求(用户故事)、优先级排序、最近1~2个迭代最想看到的功能。会前的准备工作十分重要，可以帮助产品负责人清理头绪，不至于在迭代期内频繁提出变更、增加、修改故事。会议讲解：难以用文字描述的内容。在讲解的过程中，团队可以随时提问，产品负责人要给予解答。若产品负责人感觉暂时无法讲解清楚，可以推迟此故事的开发，或将故事 阅读全文

摘要： 1，产品待开发项：又称"产品功能列表"，是一组条目化的需求。2.产品待开发项必须从客户价值角度描述，并按优先级排序。3.典型的描述方法就是极限编程中提到的"用户故事(User Story)"。如何填写"产品待开发项"？1.产品负责人创建和维护产品功能列表。2.需求必须进行条目化管理，才能进行分配、开发、跟踪，才能清楚的看到什么做完了，什么没做完。3."客户价值角度"就是描述用户如何使用，而不是技术角度上的如何实现。比如："实现手写输入"，"实现游戏排行榜"，而不是" 阅读全文

摘要： 1.产品负责人(Product Owner)：负责产品需求的提炼、条目化、优先级排序。 现实世界的产品负责人： a.，部门经理，产品经理策划人员等都可能作为产品负责人。 b.产品负责人是产品的指路人，必须对产品有深入了解和长远的规划。因此，不能单纯的选择客户或销售人员作为产品的负责人。 c.大型的产品如嵌入式产品或游戏产品，常常采用有等级的产品负责人团队，来解决广度与深度的矛盾。 例如：产品总监->产品经理->主策划->策划团队2.Scrum Master(Scrum 大师)：负责Scrum的执行和指导，并协助解决非技术问题。 现实世界的Scrum Master... 阅读全文

摘要： 1.产品待开发项(Product Backlog)：从客户的价值角度理解产品的功能列表。 a.功能点、缺陷等都可以是Product Backlog。 b.Product Backlog一般以条目化的方式描述。 c.Product Backlog 的名称一般以白话来描述，方便客户和用户的理解。 d.整体上，Product Backlog是从客户的价值上排列顺序的。 e.总开发量一般在0.5~10人天。 f.Product Backlog的名称必须言简意赅，而且要唯一。优先级高的描述要清晰、详细，低的暂时可以不用太详细。2.冲刺待开发项(Sprint Backlog)：是从开发技术角度... 阅读全文

摘要： 1.产品负责人：根据客户需求、市场，以实现功能为目的，发挥的创意，建立条目化的产品待开发项Product Backlog，并进行优先级的排序。2.在【迭代计划会】上，产品负责人讲解迭代要开发的条目，团队进行Importance值的估算并商谈决定是否放入到本迭代中。3.迭代任务确认后，进行为期2~6个周的迭代开发，团队在迭代内完成所有需求，每天都开"站立会"，以沟通进度和解决疑难问题。4.在迭代终点的【迭代评审会】上，团队向产品负责人等展示开发成果。5.团队进行【反思会】，总结本次迭代开发，成功/失败的经验。 阅读全文

摘要： 在Sprint计划会议之前，要确保Product Backlog井然有序。(迭代开始的第一天，召开迭代会议即Sprint Meeting)我们可以从以下角度理解：1.Product Backlog必须已经整理完毕2.对于一个产品而言，只能有且只有一个Product Backlog和一个产品负责人3.所有的Product Backlog都必须评过分，而且不同重要度的Importance的值不同。附：Importance值解释说明如下： a.重要度比较低的"故事"的Importance值相同也没关系，因为在这次Sprint计划会上可能根本不会被提出来。 b.无论任何事，只要产品 阅读全文

摘要： Product Backlog 是Scrum的核心。它就是一个需求、或故事、或特性等做成的列表，按照重要性的级别进行排序。里面包含客户想要的东西，并用客户术语描述出来。我们称作"故事"(Story)，有时也称作"Backlog 条目"。"故事"包括如下字段：ID：统一标示符，自增字段。防止"故事"重复。Name(名称)：简短的、描述性的故事名称。它必须要含义明确，这样产品负责人和开发人员才能通过字面意思明白"故事"的含义。一般2~10个字。比如："查看个人交易明细"。Impo 阅读全文

摘要： 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：(We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:)1.个体和互动 高于 流程和工具 Individuals and interactions over processes and tools2.工作的软件 高于 详尽的文档 Working software over comprehensiv 阅读全文