酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
从敏捷开发流程模型图当中可以看出，在敏捷实施过程当中，有四种会议，分别是计划会，每日站会，回顾会，评审会，其中数计划会最为重要。应该来说会议是有点多的，不是流传一种说法嘛，不开会的团队的一定不是一个好团队，好的团队一定经常开会。经常开会是需要时间的，因此有利有弊，如果会议时间和节奏控制的不好，就会占用掉团队很多的精力和工作时间，那就得不偿失了。在敏捷开发模式中，每种会议都有其特殊的职责和使命，不同的会议上所讨论的内容是不一致的，只要把握住会议的关键点，就可以为团队的敏捷模式服务。
关于开会，日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间，因此会议贵精不贵多，在最短的时间内达成最有效的决议，这才是一个有成果的好会议。产品团队必然也会面临这样的问题，在敏捷团队内部，除了必要的全员培训外，尽量保持在团队内部只有敏捷的这四个会议，其余的沟通和会议都可以由PO和SM去参加，然后回来传达给团队成员即可，这样可以减少团队整体的时间消耗，保证团队的工作效率。
Sprint Planning敏捷迭代计划会议
在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。
敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；
计划会议的目标：
1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；
2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；
阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。
会议时长：1-4小时
一般参考进程安排如下：
1、Scrum Master公开迭代时间表；
2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；
3、团队针对Sprint Backlog和优先级达成一致；
4、Scrum Master和团队成员共同确定Sprint Backlog；
阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加
会议时长：1-4小时
一般参考进程安排如下：
1、团队成员针对Sprint Backlog共同分解任务；
2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；
3、团队成员共同认领任务；
4、共同确定DoD，团队达成一致；
5、团队共同确认迭代目标和价值；
如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。
Daily Stand-up Meeting每日站会
团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：
1) 昨天我做了什么
2) 今天我计划要做什么
3) 我遇到了什么问题，妨碍了我尽可能有效地工作
Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。
Sprint Review敏捷迭代评审会议
在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog
参与人员：产品经理、Product Owner、Scrum Master、团队所有成员
会议时长：1-4小时，视演示内容而定
主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。
由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。
Sprint Retrospective敏捷迭代回顾会议
在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：
1) 本次迭代有哪些做得好；
2) 本次迭代我们在哪些方面还能做得更好；
3) 我们在下次迭代准备在哪些方面改进；
团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
参与人员：Scrum Master，Product Owner，团队成员。
会议时长：0.5-1.5小时
主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。
Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。
案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。
问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。
案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。
问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。
在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起来。
& 相关主题：
本文来源：小站会根据您的关注，为您发现更多，
看到喜欢的小站就马上关注吧！
下一站，你会遇见谁的梦想？
关注敏捷开发，学习、实践、感受
敏捷的本质是一种哲学思想，是一种做事情的方法论
敏捷不是灵丹妙药，不能包治百病。敏捷也不仅仅是一堆软件开发方法和开发流程，它的本质是一种哲学思想，是一种做事情的方法论。我的体会，敏捷之道就在两点，以价值为本，以人为本。价值为本，要时时刻刻想着客户，想办法创造真正对客户有价值的软件。当做到了能更快速地提供价值的时候，就是敏捷了。帮助客户成功，你也就赢了。以人为本，说到底，价值还是由人来创造。一家新公司或者一个新团队的关键是人才，有了人一切都好办，对人才要好好珍惜。当人的能动性超越了一切死的流程，就是敏捷了。记得有一句话是这么说的，&You&don&t do Agile, You are Agile !&
Scrum敏捷方法的清单列表
下面向大家推荐一个实施Scrum这种敏捷方法的清单列表。&首先是拥有一个具有优先级顺序的Product Backlog，每个Backlog用User&Story来进行描述，制定它的优先级和预估完成工作量。&其次是确定团队构成，确定团队是地理分布的还是在同一个位置，最好不要把地理位置不同的一群人算作一个团队。团队成员由开发、测试、文档人员组成，选出一个Scrum Master，每个团队人数最好是3～10人。&接下来，确定每个 Sprint 的周期。根据项目情况的不同，两周到两个月都是可以的，但最好不要超过两个月。&然后，召开Sprint计划会议，把每个Sprint的要做的工作从Product Backlog中按照优先级顺序排序，确定需求，将任务进一步分解，如人员分工等。&无论是否采用敏捷或者Scrum，从现在开始就可以尝试每日Scrum会议，每天选择固定的时间和固定的地点，15分钟就可以了。如果选在下班前开这个会，那么每个人陈述的3个问题就是：今天我做了什么？明天我打算做什么？我遇到了哪些困难？&应该从Sprint的第1天就开始准备测试用例。当Sprint结束时，不但功能完成，测试也将同时结束。在每个Sprint结束的时候召开Sprint评审会议和Sprint回顾会议。&根据团队情况，不断采用敏捷的工程实践，比如Unit Test、Code Review、结对编程、持续集成等。&多学习别人的经验。网上有很多资源，还有很多书籍。&Agile并不是银弹，它不可能解决你所有的问题。Agile本身并不是一种软件开发流程，而是一种理念，一组行为方法。只有真正理解了Agile的精髓，才能真正Agile。&You don& t do Agile, you are Agile。&
在任务计划不是太明确、详细情况下如何做Sprint计划、开Spint计划会议
团队最好有一个人能在 Sprint 开始前的几天就提前进行一些准备，这样整个团队就可以顺利地过渡到新的Sprint中。Sprint计划会议主要是为了制定Sprint Goal和Sprint计划，具体开多长时间，要以最终达成目标为准。但是如果事先大家谁都没有准备，那么这个会议开多长时间也是没有效果的，只能是浪费时间。任何会议都需要准备，更何况像Sprint计划会议这么重要的会议。在做计划的时候，任何需求不明确的任务都要及时向产品负责人提出来。如果不搞清楚，可能就会出大问题。在没有详细计划的情况下可不可以开始一个Sprint？当然可以，但是你不能没有任何计划。Scrum的价值观就是未来是不可详细预知的，也就是说你不可能做出详细的计划。不过只要有计划，并且这个计划足够支持团队开始有效且有序的工作的时候，就完全可以开始一个Sprint，然后再不断完善计划就可以了。&
计划扑克（Planning Poker）
所谓&计划扑克&（Planning Poker）是一种标有各种数字的扑克牌。参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。&客户或者产品责任人为大家挑选1个Story（Backlog），并简单解释其功能，以供大家讨论。&每个游戏参加者按自己的理解来估计完成这个Story所需的时间，从自己手中的牌里选1张合适数字的牌，并发给大家看。游戏参加者各自解释选择这个数字的原因，尤其是数字最大和最小的人。&根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。&在这个游戏中需要注意的是：首先，这不像普通的扑克游戏，不是轮流出牌，而是大家考虑好之后同时出牌，这样就可以避免后出牌的人被先出牌的人干扰；其次，要告诉团队成员，他们需要估计所有的 Story，而不仅仅是他们自己将要做的那些部分，比如测试人员不能只估计测试工作所需要的时间。&
Sprint回顾会议
Sprint回顾会议由产品责任人、Scrum团队和Scrum Master参加，会议中需要讨论有哪些好的建议或方法应该被采纳，在Sprint中有什么做法不可取，有哪些做法效果很好，应该继续下去。&Sprint结束后，Scrum团队回顾刚结束的Sprint，对其进行总结和反思，使整个团队能持续成长。&Sprint回顾会议的形式可以比较随意，主要做到以下这些方面就可以了。&Scrum Master 首先给大家看 Sprint Backlog，总结这个 Sprint，大家讨论在这个Sprint中发生的一些比较重要的事件。与会人员轮流发言，每个人都有机会发表自己的意见：他认为哪些方面做得好、哪些方面需要改进、如何改进等。还要对比Sprint Backlog中各个Story的估计值与它们的实际完成时间，如果差距太大，就应该好好分析出现这种情况的原因。&在会议即将结束之前，Scrum Master总结会上的讨论成果，即&团队如何才能在下个Sprint中做得更好&。&总之，Sprint回顾会议的宗旨就是：Scrum团队如何在下一个Sprint中做得更好！
每日Scrum会议（Daily Scrum）
每日Scrum会议（Daily Scrum），即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立举行，如图4-3所示。由于是以站立的状态开会，因此时间比较短，一般为 15 分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日 Scrum 会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。&会议由Scrum Master主持，Scrum团队的所有成员轮流回答以下3个问题。&（1）昨天我完成了什么工作？&（2）今天我打算做什么？&（3）我遇到了什么障碍？&通过每日 Scrum 会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master除了倾听团队成员的发言外，还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作顺利进行的障碍。即使有的问题Scrum Master没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的成员来帮助快速地解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，团队成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。每日Scrum会议是Scrum的精髓，最简单又最复杂，如何更有效地召开，需要不断地改进和摸索。
Sprint计划（Sprint Planning）
在每个Sprint开始之前，需要召开Sprint计划会议，会议时间一般为4～8小时，参加人员有产品责任人、Scrum Master、Scrum 团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
User Story
Sprint Backlog里的项目我们通常用User Story来描述，User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。&User Story要由Stakeholder来编写。User Story的形式很简单，人们可以很容易地掌握编写User Story的方法。这样就可以保证是由与项目相关的领域专家们来写User&Story，而不是开发人员。&我们通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定 Sprint Backlog。而且，Stakeholder可以随时更改一个Story的优先级，那么此时开发人员就应该相应地调整Story的开发次序。&一个User Story的大小和复杂度应该以能在一个Sprint中开发完毕为宜。如果User&Story 太大，可能会导致对它的开发横跨几个 Sprint，这种情况是需要避免的，此时就应该将这个User Story分解。&User Story有一个通用的公式格式，大家可以套用一下试试，很简单。&作为&某个角色&，我可以&做什么&，以完成&什么目的&。&例如：作为一个病人，我可以预约一个医生，让他给我看病。&这种表达方式清晰明了，提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story的Sprint开始之前确定下来，并补充到Sprint Backlog中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。&为了能及时、高效地完成每个Story，Scrum团队会把每个Story分解成若干个Task。每个Task都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。&特别提示：每个Task的时间最好不要超过8小时，就是要保证在1个工作日内完成，如果做计划时发现有些Task的时间超过了8小时，就说明Task的划分有问题，需要特别注意。
Scrum中3种角色
Scrum中有3种角色，分别是产品负责人（Product Owner）、Scrum&Master和Scrum团队，他们各自的职责如下。&1. 产品负责人（Product Owner）&Product Owner需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。在每个Sprint开始之前，Product Owner可以修改功能需求和优先级。而且，Product Owner有权决定接受或否决各个Sprint的工作成果。&Product Owner 的角色通常由市场部门的人员或开发部门内部主要使用该产品的人员来担任，主要工作是根据市场需求确定产品功能，将其列入Product Backlog中，并为这些功能确定优先级。&Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。 在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。&2. &Scrum Master&Scrum Master的职责是：负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；保证开发团队不受外力的干扰和阻挠；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。&Scrum Master通常由传统开发中的项目组长（Team Leader）来担当。&3. &Scrum团队&一般由5～10个能全职工作的成员组成较为理想。&团队成员横跨各个职能，通常包含开发、测试、文档设计人员等。
什么是产品Backlog？什么是Sprint Backlog？
& & &产品Backlog指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。&& & & 产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第1个Sprint有活可干。&& & &随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。&& & & 在Sprint计划会议上，产品负责人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中要完成哪些功能，并把它们挪到Sprint Backlog中去。&
任务板，说通俗点就是在一块白板上按一定规则张贴任务卡片。任务板的形式可以多种多样，不过通常的样子就像图3-7一样，有点麻烦哦。&
计划扑克（Planning Poker）
所谓&计划扑克&（Planning Poker）是一种标有各种数字的扑克牌。参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。&客户或者产品责任人为大家挑选1个Story（Backlog），并简单解释其功能，以供大家讨论。&每个游戏参加者按自己的理解来估计完成这个Story所需的时间，从自己手中的牌里选1张合适数字的牌，并发给大家看。游戏参加者各自解释选择这个数字的原因，尤其是数字最大和最小的人。&根据每个游戏参加者的解释，重新估计时间并再次出牌，直到大家的估计值比较平均为止。&在这个游戏中需要注意的是：首先，这不像普通的扑克游戏，不是轮流出牌，而是大家考虑好之后同时出牌，这样就可以避免后出牌的人被先出牌的人干扰；其次，要告诉团队成员，他们需要估计所有的 Story，而不仅仅是他们自己将要做的那些部分，比如测试人员不能只估计测试工作所需要的时间。&
Sprint评审会议
Sprint评审会议在Sprint结束时召开，由开发团队展示这个Sprint中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而且客户、管理层、Product Owner以及其他开发人员等都可以参加。&在每个 Sprint 结束时，应该组织一次 Sprint 评审会议。Scrum 开发团队将在会上展示他们在这个Sprint中所做的工作，一般采用向大家演示产品新功能的方式来展示。&相对来说，Sprint评审会议不必很正式。通常不需要用到PPT，而且长度最好控制在两个小时之内。也就是说，不要让Sprint评审会议成为Scrum团队的负担，不必让他们花太多时间来准备这个会议。Sprint评审会议的参与者包括所有对该产品感兴趣的人，可以是产品责任人、Scrum团队、利益相关者、管理层人员、客户，甚至是来自其他项目的开发人员等。&在Sprint评审会议上，Scrum团队用Demo的形式展示产品的新功能之后，与会人员依据在Sprint计划会议上确定的这个Sprint的目标来评审具备了这些新功能的产品。&为什么一定要用Demo的形式来展示产品的新功能呢？因为这种方式有很多好处。首先，参与会议的人都能直观地看到 Scrum 团队的工作成果；其次，利益相关者们可以据此提出更切合实际的反馈意见；第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在&已完成99%&的阶段。相比较起来，在有Demo的情况下，也许&已完成&的功能数量会相对少一些，但它们是确确实实完成了的。否则，那些&99%&的貌似完成的功能势必还要拖到下个Sprint来解决。假如有一个刚从传统的开发模式转而采用 Scrum 的团队，由于不习惯这种自我约束、自组织的方式，在Sprint中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板会因为看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的。但良药苦口，在下一个Sprint中，这个团队肯定会吸取教训。他们会明白，无论什么情况下都必须做Demo，那么他们必然会很好地完成这个Sprint并演示给大家看。&
Scrum辅助图示工具
我们来认识认识一些Scrum辅助图示工具。&
Burndown Chart&Burndown Chart的横轴表示整个Sprint的总时间，纵轴表示Sprint中所有的任务，其单位可以是小时、人天等。一般来说，Burndown Chat有Sprint Burndown Chat和Release Burndown Chat之分。Sprint Burndown Chart的示例如图4-4所示。&&
&从图4-4中可以看出，这是一个Spirnt Burndown Chart。&& 在8月31日Sprint刚开始时，这个Scrum团队预计这个Sprint的总任务量大概是400小时； 到了9月4日，这条曲线不降反升，这是正常的现象，说明在实际开发过程中，团队认为之前对某个 Story 的估计不够准确，他们根据实际情况调整了其中的任务和相应的估计时间值；曲线的中间有波动，但是总体趋势是随时间倾斜向下的，而且团队在 9 月 28日Sprint结束时完成了这个Sprint的任务。&Sprint Burndown Chart可以体现Sprint的进度。如果Sprint Burndown Chart一直是上升状态，或当Sprint进行一段时间之后，Sprint Burndown Chart上当前点的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的Story过多，要拿掉一些Story以保证这个Sprint能顺利完成。如果Sprint Burndown Chart下降得很快，例如Sprint刚过半时Y值已经接近零了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在Sprint计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。&Release Burndown Chart&Release Burndown Chart用于记录整个Scrum项目的进度，它的横轴是这个项目的所有 Sprint，纵轴是在各个 Sprint 开始前所有尚未完成的工作，它的单位可以是个（Story的数量）、人天等。&在如图4-5所示的Release Burndown Chart示例图中可以看出，这个Scrum项目预计需要用6个Sprint来完成，项目开始时，预计总共有300个Story，在有些Sprint点，这个Story数还稍有上升，就像在图4-4的Sprint Brundown Chart中我们看到的曲线波动一样，这是因为Scrum团队增加了一些Story，但曲线的总体趋势是平缓向下的。&
Team Pulse Survey调查表
在你们的开发中，你们使用利益相关者目标来描述你们开发的目标吗？
User stories and
你们是否使用User stories&或Use cases来定义需求
开发人员经常跑自动运行的unit test吗？
Stakeholder feedback
你们经常从利益攸关者那里拿到反馈信息吗？
Prioritized Backlog
你们会从一个具有优先级排序的功能列表中未下一个迭代选择工作任务吗？
Working software
你们是否重视高质量的软件，在迭代结束的时候只剩下少量不重要的bug
Time-Boxed iterations
你们是否遵守地带结束的日期，根据情况调整工作内容
Daily scrum
你们是否召开15分钟的每日会议，讨论今天做了什么，明天打算做什么和遇到了什么困难
Test early
测试是否很早就介入，测试人员是否参与迭代计划并在早期的迭代就开始测试；
Reflections
你们是否召开经验总结会来持续提高你们的流程
Continuous integration
你们是否经常构建，一天好几个build分数高，相反地，一周一个build分数就低
Self Directing Teams
团队是自我管理的吗？经理只相当于教练的作用
Sustainable Pace
团队进度是长期可持续的吗？
你们是否召开代码评审，结对编程等会议
备注：此表格的统计结果的各项实际上高速我们应该如何成为一个成熟的敏捷团队。
Scrum 与单元测试、TDD、XP 这些概念之间的关系
& &首先要理清Scrum与其他敏捷方法的着重点的不同之处。要知道，Scrum 看重的是敏捷项目管理上的实践，着重点在于管理，比如如何计划、如何迭代、怎样评估进度、在什么时候遵循怎样的规则开什么样的会等，它仅仅是一个框架，没有过多地关注具体的工程实践，也就是说，它与 XP 这样的具体的软件开发实践关注的重点不同。& &Scrum没有教我们怎样进行结对编程、怎样做TDD等，而XP在做这些工作。你可以简单地认为，Scrum的概念更宏观一些，而XP则更关注微观。&& &单元测试：单元测试在现代软件开发的流程中基本上属于不可缺少的一环，敏捷性质的软件开发更是如此。在 Scrum 管理的软件开发项目中，单元测试的使用与否与 Scrum 无关。但是从软件开发质量的角度和 Scrum 管理软件开发的成效来看，要多多使用单元测试，不要轻视它。&& & TDD：测试先行的做法主要是XP在提倡它。在一个Scrum管理的软件开发项目中，使不使用XP的实践方法，包括TDD，完全是由软件开发项目团队所决定的。
敏捷软件开发宣言
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动&高于 流程和工具
工作的软件&高于 详尽的文档
客户合作&高于 合同谈判
响应变化&高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
轻松Scrum之旅：敏捷开发故事 书籍推荐
读故事一样，很棒就了解了scrum敏捷开发的思想
大家好，欢迎来到我的小站！
站长在关注}