微信客服
微信公众号敏捷开发（敏捷开发流程）
大家好，如果您还对敏捷开发不太了解，没有关系，今天就由本站为大家分享敏捷开发的知识，包括敏捷开发流程的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！
1本文目录一览
2敏捷开发的敏捷开发团队原则
敏捷型方法发源于20世纪90年代的 IT 软件开发行业。
2001年，软件开发业的17位领导者在美国犹他州聚会，发布了《软件开发敏捷宣言》，进而从《敏捷宣言》派生出了12条敏捷原则，他们分别是：
（1) 我们的最高目标是，通过尽早地、持续地交付有价值的软件来使客户满意。
（2) 即使是在项目开发后期，也欢迎对需求提出变更。敏捷过程利用适应变化来帮助客户创造竞争优势。
（3) 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
（4) 项目过程中，业务人员与开发人员必须在一起工作。
（5) 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
（6) 无论是团队内还是团队间，最有效的沟通方法是面对面的交流。
（7) 可用的软件是衡量进度的主要指标。
（8) 敏捷过程提倡可持续的平稳开发。项目方、开发人员和用户应该能够保持恒久稳定的开发速度。
（9) 对技术的精益求精以及对设计的不断完善将提升敏捷性。
（10) 简单——尽最大可能减少不必要的工作。这是一门艺术，是根本。
（11) 最佳的架构、需求和设计出自于自组织的团队。
（12) 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
以上就是敏捷开发的十二原则，希望可以解答您的问题。
3瀑布开发、敏捷开发的优缺点是什么
（一）瀑布开发
优点：
阶段清晰：从计划到开发最后到上线运行，三个阶段非常清晰。
时间顺序：每个阶段顺序必须是从上到下，严格按照时间先后进行。
环环相扣：在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
黑盒模式：每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
缺点：
需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
（二）敏捷开发
优点：
更快交付价值
更低的风险
拥抱变化
更好的质量
持续改进
更高的客户满意度
更高的团队满意度
缺点：
很难进行准确的资源规划
很难准确的定义“轻量的“或必要的文档
很难把握整体产品的一致性
很难预测有限的终点
很难有效地进行度量
4敏捷开发过程中的一点感受
在利用敏捷开发过程中，用户（业务）也是作为相关人员参与到项目与之中，用户可以对每个周期完成的软件产品进行使用和评估，根据操作体检对功能、界面等各方面提出改进意见，并且可以激发用户对进步功能点的思考，有利于促进项目特性的快速积累，迅速到达完整的软件产品。
敏捷的三个要素是迭代开发、坦诚合作和自适应性。
迭代开发：把功能进行小粒度的分割，采用迭代和增量式的开发方法，时间段是按周而不是按月进行度量。频每交付使用，而不是等待项目开发完成一次性提交。这样也就能有比较明显的阶段性成果，可以按周交付新功能。这对于Web应用程序尤其适合。持续性的更新，可使用户有新鲜感，提高其访问频度和使用次数。也有助于开发人员根据用户的反馈数据，应对需求的变更，及时做出响应与改进。
坦诚合作：以我来说，做为开发人员，合作应该主要是有两类：一类是与开发人员的合作，另一类是与业务人员。与业务人员的合作很容易理解，能做到一起紧密工作，可使得产品更能切合实际的需求。而不是作完需求分析后，就将他们一脚踢开，直至产品交付。以往所做项目都不算大，几个人而已，合作也是分模块分别开发再整合。所以与开发人员的合作体会还不是很深，没看出敏捷开发有什么明显的改善。
自适应性：现实不断发展与变化，需求也在不断改变，未来状态难以预测，也就很难提前用一个文档来规范所有的开发行为。自适应方法就是不断变化的现实情况，来及时作出改变。这也就需要信任开发人员的能力，给其更多的活动空间。相信对于一个合格的开发人员，这也会有助于调动其主观能动性，以更加积极的态度来参与开发。
1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7 工作的软件是首要的进度度量标准。
8 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9 不断地关注优秀的技能和好的设计会增强敏捷能力。
10 简单——使未完成的工作最大化的艺术——是根本的。
11 最好的构架、需求和设计出自于自组织的团队。
12 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。把人的能动性调动起来，给动力而不是给压力。要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。没有绝对的权威，每个人都有可取之处。
5敏捷开发估算与计划
敏捷计划的目的是以迭代的方式为产品开发的综合问题，在那段时间内使用那些资源来得到哪些功能，去寻找到最佳解决方案。敏捷估算和计划方法可以成功找到这样的解决方案的原因包括：计划是在不同层次上作出的，并且频繁的重新计划；计划是根据特性而不是根据任务作出的；首先估算大小，然后根据大小的估算值推算出持续时间；小故事保持工作的流动，而且每次迭代结束时会消除未完成的工作；在团队层次而不是个人层次对进度进行度量；承认不确定性并为之做计划。
无论软件开发项目的规模如何，估算和计划对于项目的成功都是至关重要的。估算与计划并不仅仅是决定一个恰当的最终期限和进度表，而是对价值的探求.
1.减少风险
2.降低不确定性
3.提供更好的决策支持
4.建立客户信任
5.传递信息
1.基于活动而不是基于特性进行计划：基于活动的计划常导致项目实际开发超出计划表，有些团队会试图通过不恰当地降低质量来节省时间，有些团队会制定变更控制策略来限制产品变更。主要因素包含：活动不会提前完成；延误随进度表传递；活动不是互相独立的。
2.多任务处理导致更多的延迟：同时处理多个任务，多任务会对生产效率产生可怕的影响。当项目中开始有些活动被延期的时候，多任务处理往往变成了问题。
3.不按优先级开发特性：不按照特性的优先级顺序进行开发，因此某些被放弃的特性可能反而比所交付的特性更具有价值。
4.忽视了不确定性：忽视了与产品相关的不确定性，比如我们不能指望一开始就确定项目进程中需要的所有活动，但我们制定的计划中往往无法意识到这一点。应对不确定性的最佳方法是迭代。
5.把估算当作承诺：如果项目团队或者利益干系人把估算当作了承诺，传统的计划方法就会出现问题。在做出这样的承诺之前，团队需要对大量的商业因素和风险进行评估，并且不要把所有的估算都当成是隐性的承诺。
两种度量大小的方法：故事点和理想时间。
故事点：故事点是对用户故事大小的相对度量，将要进行的工作大小进行估算，项目的持续时间通过求取项目的总故事点数，再除以小组的速度而推算出来的.
理想时间：理想时间不是耗用时间，使用理想人天估算，就只需考虑完成这个用户故事所需要的时间，最好只为每个用户故事分配单一的估算值。应该把所有需要的时间加在一起，说某个用户故事需要九个理想人天，而不是说他需要四个程序员人天、两个测试人员人天和三个产品负责者人天。
故事点的优势是可以帮助促进团队的跨功能行为。此外，由于故事点是更为纯粹的对大小的估算，因此即使团队在技术上或是领域知识上取得了进步，也并不需要重估他们。如果一个团队成员认为某件事情需要4个理想人天，而另一个成员认为只需要1个理想人天，也许他们都是对的，但是他们缺乏讨论的共同基础，无法建立一个单一的估算值。
理想人天的优势在于更容易向团队之外的人进行解释，以及更容易开始。
我的倾向是使用故事点。使用故事点进行估算的优点更有说服力。如果团队对单纯的大小进行估算存在困难，可以让他们用一下人天开始估算，然后再让他们转化到故事点上。更多的问“这个功能的大小与我们刚才估算的那个相比怎么样？”而不是去问“它会需要多少个零小人天？”大部分团队几乎不会注意到这种渐进式的转变，而当他们意识到的时候，他们已经是在用故事点而不是理想人天进行思考了。
四种最常用的估算方法是：
专家意见：如果你想知道一件事需要多长时间，去问问专家。在基于专家意见的估算方法中，专家根据他自己的直觉给出估算。根据专家意见进行评估的一个好处在于他通常不需要太长时间。根据专家意见进行评估的一个好处在于他通常不需要太长时间。
类比：当用这种方式估算时，你不必把所有用户故事都按一个基线或是通用的参照物进行比较，而是把每个新的用户故事与那些已经估算过的用户故事进行比较。这称为三角测量。
分解：分解是指将一个用户故事或者特性分解为更小、更容易估算的部分。不过当分解太过时，不仅忘记某项任务的可能性会增加，而且对于大量小任务都估算值求和也会出现问题。
计划扑克：要得到一个估算值，我们除了可以依赖专家意见、类比和分解，还可以依赖计划扑克。计划扑克是一个有趣而有效的方法，它结合了上述三种方法。在计划扑克中，每个估算者有一叠写着有效估算值的卡片。每讨论一个功能，每个估算者就选择一张代表他的估算值的卡片。所有的卡片都会同时展示出来。团队对估算值进行讨论，重复这个过程直到团队的估算达成一致。
大多数项目都包含大量的不确定性。项目团队建立的进度表和最后期限中往往没有完全反映这种不确定性。有些时候，如果这种不确定性非常大或者非常显著，就需要在估算项目持续时间的时候采取一些额外的步骤。这些情况可能包括：提前很早就进行项目计划、项目必须绝对满足最后期限（同时交付一组相当严格的功能集）、项目是外包的、需求人员处于非常表面的层次、或者在日期出错时会产生严重的影响（经济或其他方面）等。
特性缓冲区和进度缓冲区是两类最常见的缓冲区。当团队确定了项目中所有需求的优先级，而且发现可能无法交付所有功能的时候，就需要建立一个特性缓冲区。另一方面，团队可以在进度表中包含一定量的时间来建立进度缓冲区，这个时间的量反映了蕴含在项目规模中的不确定性。团队可以通过同时估算每个用户故事具有50%的概率的大小和具有90%的概率的大小来构造进度缓冲区。通过对每队50%和90%估算值采用平方和和平方根的公式，可以估算出合适的进度缓冲区大小。
项目应该用特性缓冲区来预防特性不确定性，用进度缓冲区来预防进度不确定性。可以把特性缓冲区和进度缓冲区结合起来。实际上，这常常是个好方法，因为它可以让每个缓冲区的规模都更小。
敏捷开发项目倾向于在开发大型项目时避免使用大型开发团队，而是使用多个团队。当有多个团队工作与一个项目时，他们就需要相互协调。
首先，团队应该为他们的估算建立一个共同的基准。所有战队都应该同意按照相同的单位进行估算：要么是故事的，要么是理想人天。
其次，当多个团队需要一起工作的时候，尽早给他们的用户故事增加细节常常很有帮助。进行这一工作的最佳办法是确认产品负责人对于用户故事的满意条件。满意条件就是一旦故事完全实现了，就可以进行演示的那些细节。
第三，在发布计划过程中结合一个滚动性前瞻计划，可以让多个团队受益。滚动性前瞻计划简单地向前看几次迭代（典型的是2～3次），通过共享在不久的将来每个团队分别会处理那些工作的信息，让团队之间可以协调工作。
第四，在具有很多团队间依赖性的高度复杂项目中，把馈送缓冲区结合到计划中是很有意义的。馈送缓冲区是一段时间，可以避免由于一个团队推迟交付而导致另一个团队推迟启动。
任务板：常常是一张白板、软木板或者只是墙上特定的一片区域，可以帮助开发团队组织他们的工作，并把它们可视化。任务版的各列都带有标题，团队成员根据工作进展把任务卡在个列间移动。
迭代燃尽图：只是用来跟踪当前迭代中的工作，它的纵轴是剩余工作的小时数，而横轴是迭代中的天数。
团队不应该计算或跟踪个人速度。
关于本次敏捷开发和敏捷开发流程的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。