Agile

点数估算 敏捷开发点数估算 为什么用点数比用小时和天数更好？ 故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式，在有大量样本数据的情况下，比独立估算每个用户故事要准确得多。 举个例子，我们可以很容易的说出，从大连到长春的距离是从大连到沈阳的两倍，而不是大连到长春的距离是676.1千米， 大连到沈阳的距离是378.9千米。 (数据来自百度地图) 这样，团队不用花太多的时间来估算每个用户故事所要花费的准确时间和天数，就可以快速完成所有用户故事的估算。 不同的开发团队，是否可以使用统一的故事点数基准？ 不同的开发团队，对于故事点数有不同的度量基准，取决于各个团队所要估计的用户故事。除非他们是在开发相同的系统，否则团队A开发1个点的工作量和团队B在不同系统中开发1个点的工作量是不同的。这种差异将会影响团队的迭代交付速率。 如果有一个很大的项目，需要分成多个小团队来共同开发，人们很可能想去尝试定义一种点数标准应用到所有小团队。这有悖于估算用户故事点数的目的，每个小团队都会有自己的主观衡量标准。 我们如何估算试探性研究(Spike)的用户故事？ 为了弄明白如何实现一个特定的功能，或者验证某种概念，我们需要试探性研究故事 (Spike) 。由于很难知道到底总共需要多少工作量，通常我们要提前在团队中达成共识，对这种研究做出一定时间限制。这些用户故事可是通过观察交付速率趋势图，转换成大致的点数。 例如，如果需要计划一周的时间来完成一个试探性研究，而交付速率是16个点 (迭代周期为两周) ，那么就可以估算这个故事为8个点。 用户点数是否和业务价值有关？ 用户故事点数是对实现用户故事所需要工作量的团队内部度量。无论如何，与用户故事所能提供多少业务价值没有关系。 很可能在同一个系统中，1个点数的用户故事会比4个点的故事有更大的业务价值。业务价值最好是留给产品经理和相关的业务决策者来衡量。 在介绍敏捷估算的方法之前，我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值，单位是人天或者人时。 比如: David喝完一小杯热咖啡花费1.2个小时 (工作量 1.2人时) David喝完一大杯热咖啡花费2.4个小时 (工作量 2.4人时) 由于人的能力是有差异的，所以David的工作量对于Tom来讲可能就不适用，Tom喝完一小杯热咖啡可能需要1.5小时。这样一来，工作量、参与人以及完成这些工作的时间周期就是强相关的，因为强相关会带来如下挑战: 做计划时必须把人和周期关联到具体的任务上，会让计划很复杂。 团队成员的分工发生变化时对计划的影响比较大，管理和维护计划成本高。 (这是甘特图的价值所在 ) 由于第二条的原因，这种工作量的估算方式不利于团队协作。 接下来，我们来看看敏捷估算的思路。 在探讨具体的思路之前，我们先思考一下做估算的目的什么，通常有两个目的: 核算成本和周期，我们要了解这这个项目或产品的投资回报。 做计划，根据项目的需要，我们要知道什么时间点应该交付什么内容才可以满足市场、用户或客户的期望。 做敏捷估算时，请先忘掉人天或人时，敏捷估算关注的是工作量的规模 (大小) ，而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位——故事点，故事点是一个相对值，是一个相对倍数，和人天，人时没有关系，它和公里、吨、摄氏度类似，只是一个计量单位而已。我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍， 是 2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。 敏捷估算的步骤: 找一个参考基准，作为一个故事点。比如: 把开发一个简单的查询页面工作量作为基准，定义为一个故事点。 拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如: 查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。 3 . 累计产品backlog中的所有故事，得到所有故事总的故事点数。 得到了总的故事点规模，我们还要知道团队速度。团队速度是指: 1个敏捷团队在一个迭代中完成的故事点总数。比如: 某Scrum团队1个迭代可以完成 80个故事点，那么80个点就是他们的速度。 有了总的规模，我们也知道了团队一个迭代的速度，我们就可以很容易推算多少个迭代可以做完。 如下图所示，总的规模是1600个点，团队总共8个人，每个迭代完成80个点，我们就可以推算20个迭代完成。 每个迭代2周，所以40周可以完成，8个人40周的成本投入也可以很容易得出。 敏捷估算要点小结: 相对估算，使用故事点作为单位，故事点是一个相对倍数。 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。 敏捷估算关注团队的速度，不关注单个人的速度。 通过总规模和团队速度，推算周期 http://www.yugusoft.com/article/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E7%82%B9%E6%95%B0%E4%BC%B0%E7%AE%97.htm?f=blog_page https://cloud.tencent.com/developer/article/1104793

用户故事, user story 故事story是粗略的勾勒的需求，它是信！号！卡！，指向真正的需求或者叫故事详情，怎么说都好。 而需求就是需求。 这里隐含了敏捷的一个要素，就是，延！迟！决！策！ 当需求不是被细化的摆放着，而是粗略的STORY的时候，才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前，我们才去细化STORY故事，把他变成需求。或者，开发前，我们扔掉STORY，因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的，而且保证我们不会遗漏。所以这里，就是为什么敏捷要用STORY而不是需求去进行需求的管理。 作者: 马菲菲 链接: https://www.zhihu.com/question/26996772/answer/35078718 来源: 知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 用户故事 https://www.tapd.cn/forum/view/43571 https://www.cnblogs.com/jetlian/p/3946359.html http://www.scrumcn.com/agile/scrum/4823.html http://www.scrumcn.com/agile/scrum/20026.html https://blog.csdn.net/GitChat/article/details/78410016 用户故事 (User Story) 和验收标准 (Acceptance Criteria) 那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求 (requirement) ，被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。最常见使用的标准格式的用户故事如下: 作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。 什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。格式如下: 在我做某些动作 (action) 之前请赐给一些先决条件，然后期望结果发生。举个栗子: 1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如"摄像头无法打开"…，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了"完成标准的定义"。作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。 https://www.jianshu.com/p/bde45187a78f

敏捷 Agile 敏捷宣言 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值。 # Kent Beck， James Grenning， Robert C. Martin # Mike Beedle, Jim Highsmith, Steve Mellor # Arie van Bennekum, Andrew Hunt, Ken Schwaber # Alistair Cockburn, Ron Jeffries, Jeff Sutherland # Ward Cunningham, Jon Kern, Dave Thomas # Martin Fowler, Brian Marick 著作权为上述作者所有，2001年 ,此宣言可以任何形式自由地复制， 但其全文必须包含上述申明在内。 Agile 12 Principle Our Highest Priority Is To Satisfy Customer through Early and Continuous Delivery Welcome-Changing Requirements Even Late In Development. Agile Processes Harnesses Change for Customer Competitive Advantage Deliver Working Software Frequently (Weekly or Monthly) With Focus on Shorter Timescale Business People and Developers Should Work Together Daily Build Projects around Motivated Individual. Provide Them the Environment and Support They Need and Trust Them The Most Efficient Way to Convey Information to Your Development Team is Face To Face Conversation Working Software Is a Primary Measure of Success Agile Process Promotes Sustainable Development. Sponsors, Developers and Users Should Maintain a Constant Pace Continuous Attention to Technical Excellence and Good Design Boosts Agility Simplicity—The Art of Maximizing The Amount of Work Not Done but Is Essential The Best Requirements, Architecture, and Design Emerge From Self Organizing Teams At Regular Interval, Team Reflects on How to Become More Effective and Tweak Behavior Accordingly 敏捷开发十二原则 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好 项目过程中，业务人员与开发人员必须在一起工作。 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 对技术的精益求精以及对设计的不断完善将提升敏捷性。 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 最佳的架构、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 敏捷的核心可以归纳成四个字: “渐进增强”。 ...

敏捷心态 http://www.infoq.com/cn/articles/what-agile-mindset?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global 敏捷心态是支持敏捷工作环境的态度。这些包括尊重、协作、改进和学习周期、为所有权自豪、专注于交付价值,以及有能力适应改变。这种心态是培养高性能团队所必需的,他们进而能为客户交付令人惊讶的价值。 尊重——大多数团队工作需要从尊重与你共事的伙伴开始。在组织层面,尊重组织各级同事、客户以及产品本身也是维系恰当工作环境的关键。 协作——随着待建系统越来越复杂,待处理的问题也随之更为复杂,没有一个人能在完成一项任务时掌握所有所需的信息。此外,与组织其他部分的同事以协作的方式一起工作将降低"手递手"交付的需求。通过工具、办公空间和行为规范对协作的促进,能提升协作讨论的质量和数量。 改进环——没有刻在石头上一成不变的过程,总有改进的空间。一个支持这种行为的组织将迎着这束光不断向前。 学习环——允许个人去尝试新鲜事物,成功也好,失败也罢,贵在为员工提供了学习和自我提升的机会。不应总向个人碎碎念失败,而应支持他们冒险,从而增长组织的知识水平。 为所有权自豪——即使没人为特定代码块负责,也应为预期交付高品质工作的增量交付物而自豪。 专注于交付价值——敏捷团队的主要目的是为客户交付价值。团队应该能够随时关注什么是最大的价值,并把这些传递给组织中的其他人 (例如管理人员和scrum master) ,这有助于消除任何障碍。 有能力适应改变——如果客户在会后两个小时给你打电话,说想要改改,组织随之而动。任何应对这种变化的处理过程都不应该成为这种变化的障碍。

迭代回顾, Sprint Retrospective Scrum - Sprint Retrospective 在Scrum中,每个Sprint结束的时候会有两个会议 (Sprint Review/Demo和Sprint Retrospective回顾) 。 这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是检查过去一个Sprint的产出 (What) ,主要是PO根据先前的计划来检查Team在过去一个Sprint的工作成果,包括一些Demo,以及未完成部分的总结和分析；而Retrospective则是回顾过去一个Sprint整个Team的运作模式,有什么好的和不好的实践,怎样在未来的Sprint做的更好,强调How。 Sprint Retrospective (回顾) Sprint Retrospective会议主要是整个Team讨论过去的一个Sprint的运作,如何改进使Team更良好的运作。讨论的内容可以是任何有关Team建设的问题,包括工作流程、团队实践、团队内部/外部沟通、团队气氛以及相关工具的使用等等。 Scrum并不是一种方法,而是给软件开发流程提供了一种框架,在整个框架下,不同的项目、团队需要根据具体条件,适时调整实践方法。而Retrospective会议正是一个Scrum团队自我调整的机会。 会议的参加者包括整个Scrum团队、Scrum Master和Product Owner。会议由Scrum Master主持,一般以下边两个问题开始: 过去的一个Sprint里,我们有哪些好的方面？ 过去一个Sprint存在哪些问题？ 整个Team就这两个问题进行公开讨论,方式也可以是多样的。可以大家一起讨论,Scrum Master在讨论过程中将大家的观点记录在白板上；也可以让Team每个成员在便签纸上写下自己的答案,可以要求每个问题至少写三点,然后每个人把自己的答案贴在白板上,并给出相关解释。 讨论完毕后,对讨论结果进行分类。对于好的方便,在下个Sprint继续保持并发扬；对于存在的问题,列出Action Point去解决问题。列出的Action Point也会在下个Sprint的backlog中体现出来,并且是高优先级的项目。 探索者 (E) 代表对这个会议的内容充满期待,很有兴趣听听看看大家都是怎么看待过去这段时间的工作的,想以此来分析我们为什么是这样工作的； 推销者 (S) 是带着想法过来的,他有一个idea想借这个会议推销给大家,比如一个新的工作方式的建议,给团队增加一个流程来改进某一个方面的问题,总之这个人看到了问题,也带来的解决办法； 度假者 (V) 把这个会议当做一个休闲的方式,他们觉得有个机会大家一起聊聊天,胡扯一通挺有意思的,可能比自己工作的时候更让他放松。度假者对会议的内容是没有期待的。 囚犯 (P) 是极不愿意来参加这个会议的,他们要么就是厌恶会议,要么就是忙得没时间参加会议,总之他们是被迫来的,他们期望着会议能马上结束就好,没有心思参与到会议的讨论中来。 http://blog.csdn.net/ljinddlj/article/details/5328404 https://www.jianshu.com/p/95a59fe7844c

角色互换, Swapping Roles Swapping Developer Roles,A Lesson in Empathy and Cross Disciplinary Work If you’ve ever found yourself in a code oriented meeting in which people are going over issues and you find yourself dozed off in the corner – you’ve got an empathy problem. It isn’t explicitly because you’re a jackass (which, you very well may be), but because you cannot relate to the issues. Maybe you’ve never coded a REST interface before, handled the scaling issues of a database, or written the markup for a responsive website. You don’t know what pitfalls exist, what complexities often arise, or what technical challenges are present — it’s all unfamiliar and unknown. To remedy this, a colleague — Willie Miller — and I engaged in what we call “dev swap.” ...

敏捷方法中测试人员的价值 http://blog.csdn.net/KerryZhu/article/details/5366574 ** 敏捷**方法在软件开发中受到青睐，特别是在互联网应用服务系统的开发中，越来越多的公司采用敏捷方法，包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别，但基本思想是一致的，如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中，流程相对灵活，强调沟通，通过充分的沟通来及时解决问题，由于沟通充分，文档不是很重要，而且有可能不采用Word等独立的文件格式，而是采用Wiki、空间等web内容方式。在敏捷方法中，需求变化比较快、产品开发周期很短 (一、两周) ，给软件测试带来很大的挑战！例如，功能测试的自动化实现就比较困难，没有足够时间开发自动化测试脚本，要花大量时间讨论产品特性，及时进行产品的验收测试。自动化测试，更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践，开发人员能发挥更大的作用，而测试人员难以很好地发挥作用。在敏捷方法中，开发人员的主导作用更明显，讨论需求、实现需求，再修改需求、再实现、再重构，不断完善产品，测试人员容易边缘化。甚至在Crystal方法中，可以不需要测试人员，开发人员能承担所有技术性的工作。 在敏捷方法中，测试人员的价值又如何体现？ 首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。 在开发过程中，测试人员不仅扮演"用户代表"角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审 (code review) ，将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。 测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。 即使在敏捷方法中，集成测试、端到端 (end-to-end) 测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统 (模块/组件) ，集成测试和端到端 (end-to-end) 测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。 随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。 测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。 而且: 在敏捷方法中，我们也要采用敏捷测试，不要再写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点列出来。 在敏捷测试中，可能不需要测试用例，而是针对use case 或user story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。 所以: 敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试) 理想情况下，测试人员具有很好的编程能力，可以和开发人员进行角色互换。在当前版本开发 (/迭代周期) 中担任测试人员角色，在下一个版本开发 (/迭代周期) 中担任开发人员角色，而开发人员则担任测试人员角色，让开发人员深刻地理解用户的需求角度来考虑系统功能的设计，这样会更好地保证产品的质量，沟通的障碍也会消除，开发的效率会有很大的提高。这也是对测试人员的一个挑战。 敏捷测试也是一个持续测试的过程，而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。测试人员在自动化测试框架构建上、测试工具开发或第3方测试工具前期研究、试用等方面可以发挥主导作用。 项目采用敏捷方法，要获得成功，项目组中每个人都有很强的质量意识，具有质量的主人翁精神，特别是开发人员，每时每刻提醒自己——“质量是构建出来的”，与客户或产品设计人员进行充分沟通，遵守高度一致的质量标准。测试人员将是促进质量文化不断提升的中坚力量。 [案例补充] 来HW一段时间了，所在项目是其一个全新重点项目，由于采用敏捷模式开发，包括PM在内大家都是在摸索中进行的。撇开CMM改用敏捷，文档不再全面了，连缺陷库都改用轻量级的了，领导们说敏捷中测试做的好不好不是看找到多少BUG，而是看转测试时有没有BUG，要在开发交流中解决全部问题。三轮迭代下来，交流占据了大多数时间，感觉工作做好很多，但却不知道如何体现，这个真是问题，希望大家给点建议。

结对编程 结对编程 (Pair Programming) 是一种敏捷软件开发实践,指两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘和鼠标一起工作。一个人输入代码,而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员,审查代码的人称作观察员 (或导航员) , 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试 (Integration Test) 、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作 (如图1所示) 。 有利于提升项目质量,减少Bug； 有利于知识传递,降低学习成本； 多人熟悉同一段代码,减少项目风险； 与别人一起工作会增加责任和纪律性等。 尽管结对编程有诸多诱人的优点,但实行结对编程实践的却为数不多,其主要原因可能有: 结对编程需要投入更多的资源； 结对双方需同时注意力集中,否则效率更低； 结对人员能力要求相适,否则起不到观察者的作用,甚至产生依赖； 不成功的配对,经常引发争吵,产生内耗,导致团队不和谐等。 结对编程是颇具争议的敏捷实践之一,除上述一些优缺点外,可能大家还有更多不同的看法,但分析利弊不是本文所要讨论的重点。 实践经验 就我所在的项目团队而言,6人左右的开发团队需要支持多个中小型独立产品的需求开发,在繁重的业务压力下,用户价值的快速交付是首要的,所以想尝试共用一台电脑进行结对开发的实践只能是一种奢望。让团队开发人员尽可能熟悉相互间的产品代码,提升项目开发效率以及保证良好的项目质量,是我们在项目开发过程中需要重点解决的问题。 我们试图通过集体Code Review和设计交流分享等活动,来提升代码质量以及相互间业务代码的熟悉度,但一直收效甚微。问题主要在于这种集中式活动时间较难安排,人多交流效果不佳,性价比不高。后来,得益于公司的导师机制,在一对新人和导师身上,找到了敏捷结对的原型。由于他们的紧密合作,遇到问题及时沟通,新人在项目进度和质量都有不错表现,很好地融入了团队。在后续的项目过程中,我们不断地尝试和优化这种结对形式,逐渐形成相对固定的工作方法。 与XP结对编程相比,敏捷结对编程最为显著的差异是结对进行需求分析、系统设计和问题讨论,但分别编码实现,通过过程中频繁的Review来实现结对的效果。开发人员两两结对,共同认领开发任务,一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论,然后分工各自编码实现,并通过Code Review以确保实现与设计一致。对结对过程中发现的问题,随时沟通和讨论。由于产品业务逻辑相对不是特别复杂,所以通过这种小范围、高效的沟通,可以解决项目中的绝大部分问题,实现更高的开发效率并确保代码质量。 给我们带来了哪些好处？ 提升项目质量。结对开发人员在需求理解、设计思路上进行了充分的沟通和讨论,能尽早地发现和解决问题,避免前期因需求理解偏差、设计缺陷问题造成返工。 知识传递。对于新员工或经验略逊的开发人员,通过经常性的沟通和讨论,能迅速地进入角色和积累经验,发挥了传帮带的作用。 backup,规避项目风险。结对人员之间互为backup,有利于团队成员之间熟悉业务代码,若有人员异动时有利于项目风险控制。论新老结对还是强弱结对,都要尽力避免一方对另一方产生依赖,要给新人足够的成长和锻炼空间,让其独立思考和解决问题,并允许在可控范围内尝试失败,以获取宝贵经验得到成长。否则,团队只会多一个执行者,结对难以达到预想的效果。同时,一定程度的独立活动,可以让大家保留自己的工作习惯,而且形式更为自由和灵活。当然,大家可能会有疑问,如何保证结对人选中资深工程师工作的正确性,因为新人和弱者很有可能无法提出想要的Review帮助。这个问题在我们的结对中不可避免,有选择地邀请其他资深专家Review,也许会是个不错的解决方案,特别是对于一些重要的复杂业务逻辑。参加结对的工程师应具备独立思考和解决问题的能力,并且具备较好的团队协作意识。否则,不仅不能有好的结对效果,反而会带来一些新问题。此外,结对也不仅限在研发工程师之间,研发和测试工程师之间或同产品经理之间的结对,同样可以带来不错的效果。 _结对编程(Pair Programming)是一个编程模式(Programming pattern)。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试例子,一起编码,一起单元测试,一起整合测试(Integration Test),一起写文档等。基本上所有的开发环节都一齐肩并肩地,平等地,互补地进行开发工作。 结对编程不是一个人简单地看着另一个在做什么——在卓有成效的配对工作里,这两个合作伙伴常常工作在不同抽象层次,一个人关注的是为实现眼前目标而编写的代码的细节,而另一个人考虑的是更大的前景和下一步要做的事情,这两个人的角色频繁进行更换。这是一项高强度的、严密的,且常常令人疲劳的活动,但是能够创造出经过深思熟虑的高质量代码。 ——Laurie Williams &Steve Hayes 本贴是关于敏捷开发－结对编程(Pair Programming) 的内容聚集的帖子。欢迎跟贴,提供: 结对编程相关的研究资料和资源 实施结对编程在国内或自己公司所遇到的阻力 实践结对编程时,遇到的具体问题 如何让我们的结对编程做得更好 对2和3问题的解决方案 说明: 描述问题时,最好能给出具体的例子,这样讨论不会太偏向于理论研究。 http://www.programmer.com.cn/10724/ https://www.jianshu.com/p/d79cef4296b8 结对编程是「极限编程 (eXtreme Programming) 」里的一个实践。 结对编程技术是指两位程序员坐在同一工作台前开发软件。 结对编程有三种形式: 键盘鼠标式 顾名思义,就是一个人操作键盘,一个人操作鼠标。当然,这种方式越来越不常用,因为程序员们以使用命令行和快捷键为荣,能用到鼠标的地方越来越少了。 Ping-Pong 式 这种是采用 TDD (测试驱动开发) 时常用的方式,A 写测试,B 实现和重构,然后 B 写下一个测试,A 来实现和重构。 ...

‘Scrum,Sprint Review Meeting’

Daily Scrum, stand-up meeting, 站会 日常站立会议 (daily stand-up meeting) 是每天早上举行的短期会议。该活动起源于敏捷开发方法,在Scrum开发中很常见。日常站立会议一般用时五到十五分钟,有时候指代站立的早晨点名或每日例会。 日常站立会议 (daily stand-up meeting) 的目的是让每个团队成员回答以下三个问题: What did I do yesterday? 你昨天做了什么？ What will I work on today? 你今天要做什么？ What is in my way? 你遇到什么困难了吗？ 站立,而不是坐着,强化了该会议打算简短且避免浪费时间的想法。站立会议并不是一个解决问题的地方,而是让一个团队意识到现在的状态。如果需要讨论,适当部门可以安排另一个更长的会议。 在Scrum开发中,站立会议的目的是更新团队的状态,而不是管理,这一点必须得强调。在一些Scrum团队中,管理层会参加会议,但是只有团队成员讲话。https://less.works/less/framework/daily-scrum.html

迭代计划会议 迭代计划会议 重新讨论、确定本次迭代需要实现的Story，达成共同理解； 若有必要的话，则继续细化Story； 对Story进行优先级排序； 开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷的重要实践之一: 开发团队决定承诺完成工作量的多少，而不是由SE或项目PL安排工作量。 共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划，开发、测试、资料是以Story为单位的，所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁？测试人员是谁？什么时候开始？什么结束？谁来Review？等等。 优秀实践: 明确任务责任人 (包括开发、测试、资料) 和任务完成时间点； 任务和问题都可作为跟踪项进行跟踪； 计划中根据Story优先级和依赖关系，严格按Story驱动制定计划，尽量减少Story并行开发；

‘敏捷团队中的角色 agile role’ 在ThoughtWorks一个典型的敏捷团队中，大致有四种不同角色: 项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要: 迭代经理，美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在ThoughtWorks内部，人与人之间是完全平等没有级别区分的。公司这种平等的文化，使得人与人之间的交流不会因为等级差距而丧失。同时，公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。 以前公司同事写过一篇团队角色定义的文章: http://news.csdn.net/n/20060429/89961.html， 补完一些。 Project Manager 作为团队的精神支柱存在。与团队的每个人进行必要的沟通以保障项目成员的士气和稳定性。 维持开发秩序，保障团队间交流的效率和效果，负责主持必要的活动 消除外部干扰，负责与客户进行协调和协作。管理来自与客户的scope变更 跟踪团队的开发效率，维持开发速率，进行适当调整以保证开发的顺利进行 管理项目风险，维护项目风险日志，识别风险并采取措施防治风险 负责最终的项目交付成功 Business Aanlyst 需求获取与管理，与客户持续交流获取新的需求，并保持良好的客户关系。管理需求的优先级。 保障下一个迭代需要开发的需求能够预备到位。提前准备好需要的Story卡片，在Iteration Kickoff会议解释每个Story的具体需求给Developer 主持必要的会议，例如Iteration Kickoff和需求的评估活动 对需求进行初步的功能验收，保证功能的交付符合原始需求 Developer/Architect: 了解系统业务和需求，设计和演进系统整体架构，能够做出适当的技术决策 编码，并对系统的每行代码负责，保持代码的干净，保持较高的测试覆盖率 维护项目基础设施如持续集成服务器、版本控制服务器等 评估需求，并在开发完成后演示开发的需求 Quality Assurance 负责了解需求并编写需求验收条件，负责制定测试计划 负责测试开发人员完成的需求，并报告错误 负责对软件进行性能、压力、容量、负载测试等，负责项目的手工功能测试和发布测试 Iteration Manager - 小团队多由项目经理或分析师兼任 负责项目过程的顺利进行，协调项目资源 主持各种迭代会议，如Standup和Retrospective 负责跟踪需求的状态 负责项目的其他日常事务 User Interaction Designer -多和分析师为同一人 在项目初期参与前期需求的收集，提出可行的交互设计方案，保证软件的可用性 建立和维护Lo-fi prototype，负责指导项目的界面开发原则 进行用户测试，持续改进系统的可用性 Database Administrator 维护软件所需的数据库，定期进行数据备份 了解数据库重构和演化方法，负责维持数据库的每一条更新脚本 System Engineer/Webmaster 维护软件所需的各种硬件和网络系统 了解敏捷开发中的发布过程，保证每次迭代发布的实施 Art Designer - 一般团队最缺少优秀的Art Designer，了解敏捷的Art Designer更甚 了解项目的远景和规划，了解迭代方法，应用增量式美术设计方法 了解软件的交互设计，能够设计出可用性良好的系统 有一类角色，在敏捷团队中至关重要，不得不重视起来的，就是Customer。 Customer 理解迭代开发的过程，与团队进行频繁和和谐的交流，参与团队的各种必要的活动如Showcase 理解需求和排序需求的优先级 ...

Use Story Points, task hours [http://www.scrumalliance.org/articles/439-story-points-versus-task-hours]1 http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning

迭代长度 http://space.itpub.net/13633641/viewspace-312630 很多教材上都有关于这个问题的解答。迭代长度通常建议为 2-6 周，这是一个经验数值。到底选择几周为一次迭代，这个问题其实不太难，因为你只有 1、2、3、4、5、6 这 6 个数字需要选择。 我们太极敏捷派的建议是这样的: 如何确定迭代长度，有这样几个关键点需要权衡。 第一，我们希望每次迭代开发，可以获得实质性的进展，完成足够的开发任务，所以对于普通项目 1 周的迭代长度就显得有点短，做不了几天的开发就要 close，不合算。 第二，迭代任务 (包括模块集成、系统测试、评审等等) 的完成，应该比较顺畅 (streamlined) 、从容或者适度紧张，没有非常紧迫、仓促的感觉。如果在某次迭代开发中，需要砍掉很多完成不了的任务，感到进度很紧张，那么很可能说明迭代的长度设置太短了，在下一轮的开发中应该增加迭代的长度。 第三，总体上我们希望迭代越短越好，它有个下限，短于这个下限就可能得不偿失。那么，迭代时间为什么不能过长？它的上限是多少呢？迭代的主要目的是为了及时获得各方面反馈，确认已开发的内容是正确和可靠的，从而减少风险，保证开发能够始终稳步地前进。显然迭代过长，很长时间不对已开发的系统部分进行验证、反馈，随之而累积的各种风险就可能增加。如果超过一个半月 (6 周) 以上，还都拿不出一些可以执行、验证和 demo 的软件程序，那么这样的项目开发显然不能说是高效的。 从 2 到 6 周，建议选择偶数 2、4、6 周作为迭代长度，排除奇数 3、5 周。执行周计划周总结和月计划月总结是国内很多企业比较普遍的做法，显然设置迭代长度为半个月、一个月或一个半月，就能与之相合拍，更自然和便于管理。设想，当您做月度总结的时候，只完成了 1 又 1/3 的迭代，会是什么感觉？ 迭代长度通常还与整个项目的工期 (或复杂度、规模) 有关。如果项目的工期在 1 年以上，那么 1 个月或 1.5 个月的迭代长度就是比较合适的。假设 2 周就要完成一次迭代，持续干上一年，大家会不会感到太累、太频繁？如果整个项目工期小于 3 个月，那么 2 周迭代甚至 1 周迭代，就是非常合适的。对于进度这么紧的项目，可能每周都是非常宝贵的。 通常，张恂会向客户推荐采取 2 周或 4 周作为迭代长度的首选，3 周、5 周和 6 周作为备选，往往大项目、比较复杂的项目才会采用 6 周，6 周以上基本不考虑。2 周通常适合各方面很成熟的开发团队。如果一个传统瀑布团队，要尝试着转向迭代开发方式，从 4 周的迭代开始学习、积累经验，然后逐步缩短迭代长度，是比较稳妥的。 ...

敏捷开发之稳定迭代周期 http://www.blogjava.net/josson/archive/2011/01/31/341341.html **1、什么是iteration和release？ ** iteration和release是两个不同的概念，但在敏捷实践活动中，我们往往认识的比较模糊，一个Iteration就是一次release，其实不然。那么，具体有什么区别和联系呢？ **Iteration (迭代) **: 在固定的周期内，经过需求分析、设计、实现、测试等活动，完成计划的的业务需求，迭代结束提供一个可工作的产品。计划的业务需求，可能是一个完整的User Story，也可能是一个Story中的若干task。 Release(发布): 经过一个或若干个iteration后，完成计划中的所有User Story，经过测试后才release，最终真正交付给客户使用。 在我们的实践活动中，一个User Story所需的工作量超过我们的有效资源，无法安排在一个iteration内。我们就会想当然的会去延长迭代周期，增加有效资源以适应所需工作量。殊不知，这更象是形式上的迭代开发，无异于瀑布式项目开发过程。 2、建立固定的迭代周期，保持稳定的开发节奏 Scurm方法也非常强调稳定的迭代节奏，一个稳定的迭代节奏就如同项目的的心跳。Simon Baker描述说: “就像心脏有规律地跳动来保持身体运行，固定的迭代长度提供了一个恒量，有助于建立开发和交付的节奏。根据我的经验，节奏是帮助取得不变的步幅的重要因素” (2004) 。对于敏捷开发的团队而言，稳定的迭代节奏可以让产品保持更稳定的交付。 3、如何保持稳定的开发节奏？ 当一个迭代期内可提供的有效资源无法实现一个User Story时，我们如何按排呢？ 在 谈迭代周期控制的困惑中已谈到，这里不在细述。 4、如何选择适合自己团队的迭代周期？ 一般需要考虑以下因素: 、整个项目周期长度 (完成计划的商业需求所需时间) 较短的迭代周期将会有以下一些好处: 更频繁的向客户展示/交付可用的软件；更频繁的度量开发进度；更频繁的取得反馈并改进；一般大的项目最好有多次(3次或以上)获取反馈、修正的机会，根据项目周期调整迭代周期长度。 、不确定性的多少 不确定性有多种形式，客户到底想要的是什么？小组的工作效率，时间？技术门槛等都不存在不确定性，不确定性越多，迭代就应该越短。 、获得反馈的难易程度 指小组获取反馈数量、频度和及时性，视所处的环境不同，选择合适的迭代长度； 、优先级要以多久保持不变 开发小组承诺在一次迭代中完成一组特定的功能，重要的是不要改变他们的目标方向，优先级不会被改变的时间长度是选择迭代长度时需要考虑的因素。 、迭代的系统开销 每次迭代的成本 (时间) ，如迭代中进行的完整回归测试。最佳迭代周期的目标之一就是减少或近似消除每次迭代的系统开销。如每次回归时间成本很高，那决定周期长度时更倾向于长一些。 、团队成员的紧迫感 Niels Malotaux指出: “只要项目的结束日期还在遥远的将来，我们就不会感到任何压力，并从容不迫的工作。当结束日期逼近时，我们才会开始更努力的工作”。意思指项目开始大家比较放松，而越临近结束，工作越忙压力越大。因此，选择一个合适的迭代周期长度，让团队成员在整个迭代过程中感受到的压力更平均，不是给团队更多的压力，而是压力总量平均分布在迭代过程中。 每个团队根据所在环境和条件确定一个合适的迭代长度，一般建议2~4周。在我们的实践中，以2周一次迭代的频率，保持相对稳定的开发和交付的节奏。

automation test tools 在世面上的自动化测试工具很多。有开源的，有商业化的，各有各得特色，各有各得优点！下面我就介绍几个我用过的开源自动化测试工具。 1 测试 WEB SELENIUM可以说是测试WEB最全面的开源自动化工具， 它可以在WINDOWS， LINUX, MAC 和 SOLARIS 上运行， 而且可以几乎用任何一种编程语言进行构建， 你可以用你熟悉的语言包括 JAVA， C＃， PERL， PHP， PYTHON 和 RUBY。 它可以测试的浏览器有IE， FIREFOX， OPERA 和 SAFARI。 SELENIUM 家族成员有: SELENIUM， SELENIUM RC， SELENIUM IDE， SELENIUM CORE， SELENIUM GRID 和 SELENIUM ON RAILS。 GOOGLE 每天都要在他的TESTING FARM上跑几万个SELENIUM测试CASE,现在也些会更多，你如果想学习SELENIUM， 可以从这里开始 http://selenium.seleniumhq.org/ **tellurium ** 这个框架是从Selenium框架{#ex48}发展而来，但又具有不同的测试理念。大多数Web测试框架，比如Selenium，主要致力于单独的UI元素。而Tellurium恰好相反，它把多个UI元素看作一个Widget整体，并将其称作UI module。

agile scrum tools Trello wekan https://github.com/wekan/wekan podman run -d --name wekan-db -p 27017:27017 mongo:4.4 podman run -d --name wekan -e "WITH_API=true" -e "MONGO_URL=mongodb://192.168.50.13:27017/wekan" -e "ROOT_URL=http://192.168.50.13:2000" -p 2000:8080 wekanteam/wekan:v5.41 podman run -d --name wekan-db -p 27017:27017 mongo:5.0.9 podman run -d --name wekan -e "WITH_API=true" -e "MONGO_URL=mongodb://192.168.50.16:27017/wekan" -e "ROOT_URL=http://192.168.50.16:2000" -p 2000:8080 wekanteam/wekan:v6.30 Rally 商业软件用户使用率排名第二位！支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则 (notification rules) ，以及用于Eclipse和CruiseControl.NET的连接器。 有免费在线试用体验版本. VersionOne 商业化产品！没什么好说的，业界老大 从 功能上看，的确非常新颖，贯彻了敏捷中的User Story为先的原则，和VSTS类似，将Issues、Defect、Task合并概念成为Task(在VSTS中更加优雅，叫做WorkItem)， 并且必须挂在UserStory下，这个工具值得看看，有试用版可以下载，或者可以使用他们在线提供的试验平台 基于ASP.NET and IIS和 SQL。 团队可以使用"V1: 敏捷团队"来管理产品和sprint backlog，通过交互式的"任务板 (taskboards) “和"测试板 (testboards) " 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。 通过这些功能，“V1: 敏捷团队"的用户可以做到: ...

us, 用户故事 as a xxx, i would like to xxx so that xxx. As a “user”, I want to “do sth”, so that “sth” “user” - 就是我们抽象出来的persona (Definition refer to wiki http://en.wikipedia.org/wiki/Persona) “do sth” - 要实现的功能 最后so that后面的 “sth” - 价值 价值说起来很简单，也很容易理解，就是 实现这个story后对用户的价值所在。 可是再多问一个问题，为什么要有这个价值，为什么一定要写这个so that呢？ 如果你的目的是想买一条裙子，20年前，唯一的就是去商场买，但是今天我们还可以选择网上购物。 这也就是说，对于同一个story，不同的技术背景，不同的地域，不同的时代都会有不同的实现，这就是so that存在的价值。

迭代规划 团队会在Sprint开始之初召开Sprint计划会议并制定目标，团队成员会在Scrum每日例会上分享工作进展。当Sprint快结束时，团队会在评审会议中将进展展示给项目干系人。紧接着评审会议之后是回顾会，会上总结当前Sprint中团队的合作情况并为后续Sprint寻找可改进的地方。 计划会 Sprint开始时，团队与项目负责人共同制定下个Sprint的计划，这需要两个会议：Sprint优先级会议和Sprint计划会议。其中优先级会议需要准备产品Backlog、用户故事，并识别潜在的Sprint目标，而计划会议需要构建当前Sprint的Backlog，以确实际开发任务。 优先级会议 Sprint优先级会议的目的是挑出产品Backlog上优先级高的条目，并选择潜在的Sprint目标。我们在产品需求池通过属性来配置任务的优先级。 (图：任务的优先级设置） 在排序之后，PO和团队便可以挑选出高优先级的需求功能作为Sprint的目标。如果高优先级功能实在太多，无法在一个Sprint中完成，这些功能就要分解成更小、更适宜在同一Sprint中完成的小功能，然后放入已创建好的Sprint中。 (图：一个Sprint中的需求功能） 计划会议 在确定当前Sprint的目标需求后，团队从每个需求中分解出任务条目以构成Sprint的Backlog，这是在Sprint计划会议上面进行的，这个会议的参与者包括PO、Scrum Master以及团队中的每个人，和可以帮团队更好预估工作量的各领域专家。 (图：构建一个Sprint Backlog流程） 大家需要在会上讨论每个需求的设计与实现，最好的预估工作量的方法是检查团队过去Sprint中的工作完成情况，比如团队在近期的几个Sprint中完成了平均400小时的工作量，他们就有把握承诺在下个Sprint中完成同样多的工作量。除此之外，一个Sprint是否包括节假日、是否有重要员工离职以及其他影响 (比如是否在开发需要试错的新模块）等等因素也需要考虑进来，最终形成一个可按时交付的Sprint Backlog。 https://ones-ai.gitbooks.io/ones-ai/content/31-si-ge-gai-nian/43-gui-hua-die-dai.html