2012年8月13日

09-Scrum过程-评审会(Review Meeting) & 反思会(Retrospective Meeting)

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

posted @ 2012-08-13 08:01 恩泽²º¹² 阅读(5036) 评论(1) 推荐(1) 编辑

08-Scrum过程-办公环境 & 每日立会(Standup Meeting)

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

posted @ 2012-08-13 07:27 恩泽²º¹² 阅读(1032) 评论(0) 推荐(0) 编辑

07-Scrum过程-迭代计划会(Scrum Planning Meeting)

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

posted @ 2012-08-13 05:00 恩泽²º¹² 阅读(3809) 评论(0) 推荐(0) 编辑

2012年8月11日

06-Scrum过程-创建和维护产品待开发项Product Backlog

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

posted @ 2012-08-11 06:37 恩泽²º¹² 阅读(588) 评论(0) 推荐(0) 编辑

2012年8月10日

05-Scrum敏捷方法中的角色

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

posted @ 2012-08-10 18:31 恩泽²º¹² 阅读(415) 评论(0) 推荐(0) 编辑

04-Scrum敏捷方法中的工作产品

摘要: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):是从开发技术角度... 阅读全文

posted @ 2012-08-10 17:08 恩泽²º¹² 阅读(245) 评论(0) 推荐(0) 编辑

2012年8月9日

03-Scrum敏捷方法一分钟扫盲

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

posted @ 2012-08-09 22:45 恩泽²º¹² 阅读(388) 评论(0) 推荐(0) 编辑

04-怎样准备Sprint计划

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

posted @ 2012-08-09 21:17 恩泽²º¹² 阅读(349) 评论(0) 推荐(0) 编辑

03-我们怎样编写Product Backlog

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

posted @ 2012-08-09 13:22 恩泽²º¹² 阅读(2987) 评论(0) 推荐(0) 编辑

02.敏捷软件开发宣言(Manifesto for Agile Software Development)

摘要:我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:(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 阅读全文

posted @ 2012-08-09 09:08 恩泽²º¹² 阅读(214) 评论(0) 推荐(0) 编辑

导航