随笔分类 -  敏捷(火星人开发手册) 随笔

摘要：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.团队进行【反思会】，总结本次迭代开发，成功/失败的经验。 阅读全文

摘要：1.带球过人需要计划！ 在球场上：在比赛每段的开始，双方都要摆开阵势，并计划本段的迕攻/防守路线和策略，教练和队长都可以参不计划。 在软件开収公司：在每丧迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。2.带球过人需要灵活应变！ 在球场上：当哨声响起，尽管队员们劤力按照既定计划推迕，然而场上瞬息万发，队员丌可能实时按照教练戒队长的指令亦步亦趋地行亊，而是靠平时讦练丨形成的素养见机行亊，达成目标。 在软件开収公司：在每丧迭代开始后，团队领导丌可能也丌需要亊必亲恭地者介入每件亊情，而是应该由具体执行的人选择如何去做。团队领导.. 阅读全文

摘要：敏捷，来源于橄榄球中的“带球过人”。在橄榄球的比赛中，每次的冲刺前，都有一个计划安排的过程，但是在冲刺的过程中，队员都会根据当时的形势，在原计划的基础上随机应变。瀑布模型的开发过程：需求、设计、编码、测试等阶段。Scrum的开发过程：多次的迭代(又称为Sprint，冲刺)，周期一般为2~4周。在日常的工作中，【产品负责人】会维护一个按优先级排序的＂产品待开发项＂(Product Backlog) 。"产品待开发项"就是根据客户的需求，得出产品的功能点。在每次迭代的第一天，都会召开【迭代计划会】(Sprint Planning Meeting)。产品负责人先总体讲解产品，按优 阅读全文