什么是自组织团队？作者 Sigi Kaltenecker and Peter Hundermark ，译者 夏雪 发布于 2014年11月14日 | 1 讨论。“最好的架构、需求和设计出自自组织团队”，敏捷宣言如是说。组织行为发展顾问Sigi Ka

敏捷开发是快速迭代，快速交付的开发模式。这也就要求迭代周期内任务量不宜过大，以保证在预期内能够按时完成开发计划。需求变更之所以可怕，主要是因为变更影响的范围无法预估。需求确认后就进入为需求分解任务阶段。我们常用的管理软件禅道中这个过程就表现为“为需求分解任

目前公司的产品或项目的研发/开发既不是传统意义上的瀑布式开发流程，可以说是增量迭代类型的，但是却有没有什么大或小的一些计划，只是步步的向前推，以项目驱动产品发展。敏捷只是一种思想，一种软件开发的方法学，有很多种分类。可以说Scrum是敏捷思想落地的一个参考

Scrum是一种用于开发创新产品和服务的敏捷方式；一个用于开发和维护复杂产品的框架，增加、迭代的过程。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Spri

它是一种开发方式，开发的流程，主要核心驱动是人，采用的方式是迭代。只写必要的文档，开发注重的是人与人之间，面与面之间的交流。橄榄球专业术语，表示“争球”的动作，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它。Scrum就是这样的一个开发流程，运

经常听到有人提到敏捷开发与“本能反应”非常近似，比如凡事都需“看着办”，比如“不拘泥于形式”，比如“直击代码，不写无用的文档”等等。简单地说，敏捷开发就是无我状态的本能反应。按理说，本能反应是最接近最佳路径的，一线人员，工作现场，当下的问题，一定能在事先预

不写，怎么不写？先把话说绝点，敏捷就是不写文档。敏捷认为所有中间产品，需求，计划，设计，测试用例……长期文档适合详细描述，用语应完整，甚至可以动用图形和建模工具。短期文档适合粗略描述，典型的就是用纸或Word凌乱地写一些关键内容，无需长期保存，月末一般就无

在般若敏捷系列中已经提过，包括不住于法，不住于空。就是不停留在一种固定的方法上。如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？如果把“敏捷”理解成一个形容词，也就是“敏捷的开发方法”，大致能找到敏捷新的定义：敏捷是一种轻量级的开发方法。如果把

公元21世界，软件业江湖动荡，人才辈出，各大门派林立，白道黑帮，都欲靠各自门派的武功称霸武林。在那些外家功门派和非正统教当道之际，一股新势力正在崛起——以敏捷方法为总成的一批内家功门派。

代码Review：不管是否采用了结对编程，现阶段建议还是要安排代码Review人员，包括测试代码也要安排Review，以弥补结对编程的经验不足。Review的方式不限，可以采用交叉Review的方式，但至少要有一个人能够通读代码，从整体上把握代码架构和质量

重新讨论、确定本次迭代需要实现的Story，达成共同理解；若有必要的话，则继续细化Story；开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由SE或项目PL安排工作量。任务和问题都可作为

在Scrum的实施过程中，我发现并不像最初想象的简单。我认为Scrum中的Sprint计划会议是最重要的事件，这确定了每次迭代的目标。

后者要求评审，集成与测试基本同步于开发完成。

很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。至于设