1.行为准则

2.敏捷开发2.1.软件开发应该有计划和与之相应的跟踪2.1.1.你的队友想知道你在做什么，这样他们就能与你有效地配合2.2.敏捷开发是一种软件开发模型，被广泛采用于快速交付优质软件的场景2.3.要理解敏捷开发实践，你必须要首先理解敏捷哲学2.4.敏捷开发诞生于2001年，是由以前的开发过程（如极限编程、Scrum、特征驱动开发和实用主义编程）的领导者合作完成的3.敏捷宣言3.1.个人和互动高于流程和工具3.2.工作的软件高于详尽的文档3.3.客户合作高于合同谈判3.4.响应变化高于遵循计划3.5.尽管右项有其价值，我们更重视左项的价值3.6.敏捷实践的重点是与团队成员和客户的合作3.7.认识、接受并消化变更3.8.注重迭代改进而不是大爆炸式的开发发布3.8.1.敏捷开发模型通常与瀑布流模型形成对比，瀑布流模型是指在项目开始时就进行详尽的计划，这是一种过时的做法4.敏捷计划的框架4.1.Scrum4.2.看板5.看板5.1.不像Scrum那样使用固定周期冲刺5.2.看板定义了工作流程中的各个阶段，所有的工作条目都要经历这些阶段5.3.看板相当于为每个工作流程阶段设置了垂直列的仪表盘，由标题框代表的任务，随着状态的变化在各列之间移动6.Scrum6.1.所有的计划通常都是从前期工作开始的6.2.冲刺的周期各不相同，最常见的是两个星期6.3.在每个冲刺阶段结束后，团队会进行一次回顾总结，回顾已经完成的工作、讨论新的发现、查看关键指标，并对执行过程进行微调6.4.用户故事6.4.1.一种特殊的任务票，它从用户的角度定义了特性的需求，格式是“作为一名＜用户＞，我＜想＞＜这样＞”6.4.2.一种常见的用户故事的误用是把常规的任务描述塞进用户故事中6.4.3.用户故事通常在其标题和描述旁边设有属性6.4.4.最常见的两个属性是预估工数和验收标准6.4.4.1.用户故事的预估工数是对实现该用户故事所需努力的猜测6.4.4.2.验收标准则定义了该用户故事何时完成6.4.5.小型的用户故事往往就是工作票6.4.6.大型的用户故事则关联实施票或子任务6.4.7.尖峰是一种有时间限制的调查，它使其他故事得以完成6.5.任务分解6.5.1.单一的用户故事可能需要被分解成更小的任务，以预估它需要多长时间才能完成，用来给多名开发人员分配工作，并跟踪实施进度6.6.故事点6.6.1.团队的工作能力是以故事点来衡量的，这是一个约定好的尺度单位（以小时、天或“复杂性”来度量）6.6.2.一次冲刺迭代的能力是以开发人员的数量乘每名开发人员的故事点来计算的6.6.3.用户故事的估计时间也是以故事点来定义的，一次冲刺迭代中所有故事点的总和不应该大于冲刺迭代能力的最大值6.6.4.一个故事点相当于一个工作日6.6.4.1.基于工作日的估计通常需要考虑到非任务工作——会议、中断、代码评审等，请将一个工作日定义为4个小时6.6.5.预估故事点是主观的，人们往往是糟糕的预估者6.6.6.提高预估准确性的方法之一是使用相对大小来得出数值6.7.消化积压6.7.1.积压分流或梳理（从修剪树木的意义上讲）通常在计划会议之前进行6.7.2.积压是指候选的用户故事列表，分流是为了保持它的新鲜度、相关性和优先级6.7.3.最流行的是Scrum，它鼓励短期迭代，并经常设有检查点来调整计划6.8.冲刺计划6.8.1.一旦前期工作完成，就会召开冲刺计划会议6.8.2.计划会议是协作性的，工程团队与产品经理一起决定要做什么6.8.3.冲刺迭代的能力是通过查看以前的冲刺中完成了多少任务来确定的6.8.4.冲刺最重要的特点是周期短，通常为两周6.9.站会6.9.1.在冲刺计划完成后，工作就开始了，团队举行站会，也被称为Scrum会议或huddle会6.9.2.站会通常是在每天早上安排15分钟的会议（快到可以站着完成，不过实际上可以选择是否一定要站着）6.9.3.站会是一种定期的系统检查6.9.3.1.如果你的团队举行同步站会，应该尽你所能准时参加6.9.3.2.当出现日程安排冲突时，跳过站会是可以接受的6.9.4.Scrumban是Scrum和看板的混合体6.10.评审机制6.10.1.演示是会议的重点6.10.2.有些团队只关注项目状态的评审6.10.3.标准的做法是，每个冲刺周的评审时间不应超过一小时6.10.3.1.两周的冲刺迭代将有两小时的冲刺评审6.10.4.不要为冲刺评审做过度的准备6.10.5.评审是为了庆祝团队的胜利、创造团结、提供反馈的机会，并使团队对进展保持诚实6.10.6.项目状态评审也可以帮助团队就什么是真正的“完成”以及他们如何朝着目标前进达成一致，发现的问题可以在冲刺回顾会上讨论6.10.7.评审会的重点是在某个冲刺阶段完成的工作6.11.回顾会6.11.1.领导者（或敏捷专家）将通过要求每个人分享上个冲刺阶段的成功案例和失败经验来召开回顾会6.11.2.回顾会的重点是流程和工具6.11.3.回顾会也是造成敏捷实践有如此众多的风格的原因之一6.12.路线图6.12.1.以两周为周期的冲刺迭代是完成中小型工作的好方法，但更庞大的项目需要更先进的规划6.12.2.路线图应该鼓励每个人对团队正在构建的东西进行长期思考6.12.2.1.更远的地方应该更模糊，而更近的地方应该更准确6.12.2.2.不要自欺欺人地认为任何一个季度都是百分之百准确的6.12.3.与被锁定的冲刺迭代不同，路线图是要不断发展的6.12.4.许多公司都要经历年度计划周期，管理者们在每年的最后一个季度试图为下一年的4个季度的工作进行规划6.12.4.1.年度规划几乎都是一个充斥着讨价还价的交易场