1.世上充满无数的选择和努力。但对于成功，选择大于努力。敏捷开发
是一种选择。
2.传统的开发方式有时候会阻碍产品的发展，甚至人的成功。
3.个体和交互重于过程和工具
敏捷方法认为人是软件开发中最重要的因素，开发团队成员之间有效的
交流、沟通与协作，比单纯的编程能力更重要。人与人之间面对面的交
流，是最有效、最迅速的交换信息方式。
4.可以工作的软件重于面面俱到的文档
最根本的文档就是源码。文档应当短小精悍、易于维护、主题突出
5.客户协作重于合同谈判
6.随时相应变化重于循规蹈矩，敏捷开发方法的核心思想是“适应变化
”和“以人为本”
（1）敏捷开发方法是面向人而非面向过程的
（2）敏捷开发方法是“主动适应的”而不是预先设定的
7.招聘启事是从些招聘启事开始的。而不仅仅是面试。敏捷开发的核心
是人，招到合适的人是所 有开发环节中最重要的。
8.极限编程（XP）
XP注重的核心是“沟通、简明、反馈和勇气”，用一句话来概括XP的
这4个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简
单明了；通过客户经常性的反馈，生产符合客户要求的软件产品，并且
有勇气迎接需求的改变。
XP的12个实践方法：
客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发
、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、
现场客户
9.统一过程（RUP）
RUP试图总结现代软件开发过程中所有好的实践经验，形成一种有
很强适应性的软件开发过程。
它包括了软件开发中的6大经验：迭代式开发、管理需求、可视化
建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。
RUP的9个核心工作流：商业建模、需求、分析与设计、实现
、测试、部署、配置与变更管理、项目管理、环境
10.（精益软件开发方法）Lean
消除浪费，将所有的时间花在能够增加客户价值的事情上；
延迟决策，在一个复杂多变的环境中进行软件开发，需要根绝实际
情况保持可选方案的开放性，但时间不能过长。
尽早交付，交付周期越快，用户需求越清晰，软件应对需求变化的
灵活性就越高，让客户的需求来推动工作的进展
加强学习，承认变化的存在及不可预见性。加强反馈和交流，在实
践中发现问题，解决问题，并最终形成解决方案。
授权给团队，正确的决策取决于准确的信息，让开发团队参与决策
，让团队成员充分发挥自己的潜力
11.SCRUM
SCRUM是一种灵活地敏捷软件开发管理过程，
在一个采用SCRUM的项目中，首先要将所育需要完成的工作列在一个
Product Backlog中，项目开发过程中的需求改变也要写进去。在每个
Sprint开始前，要召开一个Sprint计划会议。在Sprint计划会议中，产
品负责人为Product Backlog中的各项功能确定优先级。随后Scrum团队
按照优先级，从Product Baklog中挑选他们认为能在这个Sprint中完成
的任务，并把这些任务从Product Backlog中挪到Sprint Backlog中去。
sprint计划会议还要确定每个Sprint最后演示的时间和演示方式。
在Sprint的进行过程中，Sprint团队每天都举行一个简短的每日Scrum会
议，一边团队中的成员了解开发进度。在这个会议上每个Scrum成员要回
答三个问题，分别是从上一次会议到现在我完成了什么工作，这个会议
后我要完成什么工作，完成工作的过程中我遇到什么问题。一个Sprint
结束后，需要召开Sprint评审会议和Srpint回顾会议。开发团队要在
Sprint评审会议上把这个Sprint的开发成果展示给大家。在Sprint回顾
会议上，团队成员们会回顾刚刚过去的这个Sprint，从中总结经验和教
训。
12.在项目开始制定一个有效的沟通计划至关重要，对敏捷开发尤其如此。
13.如果真的遇到一个特别大的Story，应该适当地将Story分解
14.在混乱中建立秩序，是Scrum开始阶段的目标。
15.敏捷开发倡导面对面的沟通。可以工作的软件胜过面面俱到的文档。
16.敏捷和Scrum倡导团队的自我管理，在任务分配上提倡每个人按照兴趣和能力自主选择任务。
17.每日Scrum会议是Scrum的精髓，最简单又最复杂，如何更有效的召开，需要不断的改进和探索。
18.固定的时间和固定的地点也有助于团队把每日Scrum会议坚持下来，至于召开的时间则没有定论。大多数团队会选择早上一上班的时间，因为头脑清醒。
19.在很多组织中，敏捷开发都是从下到上推行的，尽可能多的得到上层支持是非常关键的。初期采用敏捷开发的团队对于迭代开发的实质（可以工作的软件而不是开发完成功能）要求很容易忽略或者难以达到，不妨循序渐进。
20.由于Scrum具有高度的可视性。所以团队中谁的状态都隐瞒不了。关于任务Done的标准是个非常重要的问题，在一开始总以为代码完成了就Done了，其实这离Scrum标准还很远。
21.发现问题不是坏事，Sprint评审可以帮助团队尽早的发现问题，尽早的使用反馈。
22.Sprint回顾会议通常是最容易被忽略的。然而，Sprint回顾会议其实是非常有用的，他是整个Scrum框架中第二重要的事件，因为他是让Scrum团队成长起来的最好机会。如果不开Scrum回顾会议，不久后你就会发现，你的团队在不断的犯着同样的错误。
23.不应该有理由和借口抛弃团队。
24.不要隐瞒团队的技术实力，否则很难做切合实际的计划和评估
25.wiki是个不错的敏捷项目文档管理工具
26.善于寻求帮助是个好习惯，不仅仅是针对敏捷开发项目
26.Prodect Backlog，User Story 和Task的区别。
产品要完成的功能清单叫做ProductBacklog，每一个Backlog项叫做Story，因为它是由User Story来描述的，一个Story是由一个完整的User Story来描述的，有时候，一个比较复杂的Story可以分解若干个更小的Story。Task是任务，在具体实现每个Story时候都要将其分解成具体的任务，比如编码、测试、调研、代码评审等，这些都是任务，而不能称为Story
27.扑克牌背后的敏捷思想是团队中没有绝对的权威，每个人都有可取之处，要避免少数服从多数。
28.类似升级机器这类杂七杂八的事情可以算在计划预留的缓冲时间里面。
29．机械地实施敏捷是一开始比较容易犯的错误。敏捷并不是一种过程。
30、燃烧曲线（burndown chart）是衡量团队进度的重要工具，但是不要过分依赖它作为监督和考核依据。否则就会变味。因为团队会把重点放在生成漂亮的曲线上，而不是项目本身。
31．Scrum Master要有敏锐的嗅觉，及时发现团队成员遇到的问题。
32.敏捷开发可以使项目具有高度的可视性，并能够及时发现问题。
33．Sprint评审会议实际上是非正式的会议，但是可以要求高层参加。会议的气氛可以活跃一点，避免变成严肃的报告会。Sprint评审会议上要避免过多的谈论技术细节，而是关注最后的成果。
34.敏捷强调面对面的沟通，创造一个有利于敏捷沟通的工作环境至关重要，有时候动动脑筋就会不大一样。
35.避免不必要的浪费是精益软件开发的思想，也同时是敏捷开发所倡导的。Sprint计划会议还要确定Sprint最后演示的时间和每个Story的演示方式。
36.Sprint Goal是个鼓舞士气的好工具。
37．Sprint计划会议的时间拖得再长也难有好的结果，应该果断结束。在Sprint计划会议之前应该有所准备。
38．在Scrum中，实际上要求Scrum团队是跨职能的。一个Scrum团队应该包括开发人员、测试人员、美工及文档人员。敏捷的开发流程迫切需要一个跨职能的团队。
39.结对编程的阻力在于人，没有尝试到结对编程的好处之前对其不理解也是正常的。
40．将投资和回报最大化，快速反应市场的风云变换，敏捷开发是应对未知的最好武器。
41.面对面的沟通是最有效的方式。在一个异地开发项目的初期，核心人员进行面对面的接触是非常必要的，尽管费用会增加一些。但是从长期效果来看，这样会节省很多沟通成本。
42.Scrum Master要能够排除开发人员和产品负责人之间的障碍，确保Scrum达成目标，实现投资最大化，确保团队进度、确保团队状态具有高度的可视性，激发团队创造力，提高团队的开发水平，采用各种优秀的工程实践，提高生产力等。
43.Scrum专家建议对Scrum团队整体进行考核，不过在现实操作中，还是会对每个人进行考核。
44.Scrum的可视性能够保证及时发现问题。不要隐瞒风险。要用非技术语言给客户提供足够的信息以便他们能够及时决策。
45.两个Sprint之间设置一定的缓冲时间，为两个Sprint起到承上启下的作用。
46.Team Pulse Survey的各项实际上告诉我们应该如何成为一个成熟的Scrum团队。
47．按照产品整合部门可以大大提高执行效率，开发和测试在行政上属于一个部门有利于是他们结合成一个真正的Scrum团队。
48.性能测试也是系统测试的一种。关于系统测试的介入时机，常见的作风是在第N+1个迭代测试第N个迭代的功能。
49．Scrum要求在一个Sprint中团队成员高度稳定。
50．无论以什么方式，尽早让客户参与到Sprint中来，无疑可以增加成功的砝码。
51.持续集成是敏捷开发中核心的工程实践，它是敏捷产出可以工作的软件的有力保障。
52. 当开始研发新产品或者已有产品的新模块时，由于各方面的原因，整个团队没有能力在Sprint的开始就做出一份非常详实的计划，因此，采用“照明弹”策略绝对不失为一个好办法。
53.对于每一个STORY，都要尽可能了解他的需求
54.在开发过程中，为了提高交流的效率，要尽量避免把精力浪费在不必要的文档上，取而代之的是要提倡团队之间面对面的直接交流。
55.在实际工作中，Scrum团队自我管理，在任务分配时每个人都可以按照自己的兴趣来选择任务。
56．团队成员的技能培训在做Sprint计划的时候就应该考虑在内的。
57. 经理应该充分信任开发团队，不要把每日的Scrum会议当成每日汇报。
58.在Scrum工具的使用上，一定要确保每天都进行准确的更新，只有这样才能让团队的其他成员及项目经理掌握及时、准确的项目进度信息。
59.通过Burndown Chart，Scrum将给项目带来更多的可视性。
60. 在每日Scrum会议上不要过多地讨论技术难题的细节，如果有团队成员遇到无法解决的困难时，Scrum Master应该将其记录下来，会后再调配资源去解决。
61．Scrum如何解决开发与测试工作同步的问题？
62.每个Sprint结束后，最基本的目标是应该得到一个可以工作的产品，Sprint结束时的Sprint评审会议和Sprint回顾会议都至关重要。
63.在Sprint计划会议中，ScrumMaster应该主动约Product Owner一起制定和讨论这个Sprint的工作。
64．在Sprint计划会议中，Scrum Master不应该抛弃团队成员，团队成员必须全体参与到计划的讨论中去，并且及时对不明白的地方以及用户需求等进行提问。
65．在Sprint计划会议中应该如何制定具体的计划？
66．在Sprint进行过程中，遇到临时员工变化，比如请假，该怎么办？
67. Scrum不鼓励加班。
68．对于不好演示的功能，可以用运行测试用例等其他方式在Sprint评审会议中进行演示。
69.创建一个敏捷的工作环境，让每个Scrum团队成员都坐在一起工作。
70. 敏捷开发的思想之一也包括避免不必要的浪费，在做Sprint计划时应该放弃实现一些不必要的功能。
71.尝试结对编程。
72. 在敏捷开发中，应该尽可能地寻找有效的工具提高效率。“工欲善其事，必先利其器。”
73．采用Scrum回顾模板“团队听诊工具”进行Scrum回顾。
74．利用演示工具有效地传递Sprint需求。
75．采用Scrum后的新部门组织结构。
76．如果测试人员不习惯自身的角色转换，应该鼓励他们转变思维方式，主动参与开发过程。
77. 测试新功能前要对老功能做回归测试，以保证新功能不会破坏老功能。
78. 关于自动化测试，应该尽力而为，但不能急于求成。
79．一个产品的成功与否需要市场来检验。在产品正式发布之前，如果能有客户尽早地参与到开发过程中进来，无疑会增加成功的砝码。
80. 如何管理素质较低的团队？
SCRUM中的工具：
1． 任务板
在一块白板上按一定规则张贴任务卡片。如下：
2.什么是ProductBacklog？什么是Sprint Backlog？
Product Backlog是根据初步需求分解出来的任务列表，包括功能性的和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
Product Backlog是产品所具备的所有功能的总纲，当一个项目刚刚开始的时候，没人能实现预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为之一个项目写下所有它应该具备的显著特征和功能。数量不必多，做好让团队的第一个Sprint有活可干。
随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人为ProductBacklog中的任务制定优先级，并向Scrum团队描述这项任务，Scrum团队随后根据团队的整体情况，确定他们能在这个即将来到的Sprint中要完成哪些功能，并把它们挪到Srpint Backlog中去。
3. Scrum中的角色。分别是产品负责人（Product owner）、Scurm Master和Scrum团队。
产品负责人（Product owner）
产品负责人需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场的需求确定产品功能的优先级。在每个Sprint开始之前，产品负责人可以修改功能需求和优先级。而且产品负责人有权决定是否接受各个Sprint的工作成果。
产品负责人的佳色通常由市场部的人员或开发部门内部主要使用该产品的人员来担任，主要工作是市场需求确定产品功能，将其列入Product Backlog中，并为这些工作确定优先级。
Scrum Master
Scrum Master的职责是：负责监督整改Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；保证开发团队不受外力的干扰和阻挠；掌握产品开发进度，参与每日的Scrum会议、Sprint计划会议和Sprint评审会议
Scrum Master通常由传统开发中的项目组长来担当。
Scrum团队
一般由5-10个能全职工作的成员组成较为理想。
团队成员横跨各个职能，通常包含开发、测试、文档设计人员等。
User Story
Sprint Backlog里的项目我们通常用User Story 来描述。User Story是从用户的角度对系统中的某个功能模块所做的简短描述。一个User Story描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。
UserStory要有stakeholder来编写。通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。而且，Stakeholder可以随时更改一个Story的优先级，那么此时开发人员就应该相应地调整Story的开发次序
一个User Story的大小和复杂度应该以能在一个Sprint中开发完毕为宜。如果User Story太大，可能会导致对它的开发横跨几个Sprint，这种情况是需要避免的，此时就应该将这个User Story 分解。
User Story有一个通用的公式格式： 作为《某个角色》，我可以《做什么》，以完成《什么目的》，例如：作为一个病人，我可以预约一个医生，让他给我看病。
为了能及时、高效地完成每个Story，Scrum团队会把每个Story分解成若干个Task，每个Task都是可以再明确的时间内完成的，而且时间是以小时为计量单位的。每个Task最好不要超过8小时，就是要保证一个工作日内完成。
4.Sprint计划会议
在每个Sprint开始之前，需要召开Sprint计划会议，会议时间一般为4-8小时。参加人员有产品负责人、ScrumMaster、Scrum团队和其他感兴趣的人，比如管理层和客户代表。Product Owener从Prduct Backlog中挑选高优先级的任务，并与Scrum团队一起讨论这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员相信讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
5.每日Sprint会议
即团队的每日例会，由ScrumMaster主持。条件允许的情况下，每天都应该在同样的时间和地点，组织所有成员站立举行，时间控制在15分钟左右。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣的话也可以参加，但是只能旁听，不能发言。
会议上所有成员轮流回答一下三个问题：
A． 昨天我完成了什么工作？
B． 今天我打算做什么？
C． 我遇到了什么障碍？
6.Sprint评审会议
Sprint评审会议在Sprint结束时召开，由开发团队展示这个Sprint中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的DEMO，而且客户、利益相关者、管理层、Product Owner以及其他开发人员都可以参加。
7.Sprint回顾会议
Sprint回顾会议由ProductOwner，Scrum团队和Scrum Master参加，会议中需要讨论有哪些好的建议或方法应该被采纳，在Sprint 中有什么做法不可取，有哪些做法效果和好，应该继续下去。宗旨是Scrum团队如何在下一个Sprint中做的更好。
Scrum Master首先给大家看SprintBacklog，总结这个Sprint。大家讨论这个Sprint中发生的一些比较重要的事件，与会人员轮流发言，每个人都有机会发表自己的意见。还要对比Sprint Backlog中各个Story的估计值与它们的时间发成时间，如果差距很大，就应该好好分析出现这种情况的原因。
8.Burndown Chart
Burn Down Chart是常用的衡量团队进度的可视化工具。敏捷开发可以给项目提供更多的可视性。
Burn Down Chart有Sprint BurndownChart和Release Burndown Chart之分。Sprint Burndown Chart的横轴表示整个Sprint的总时间，纵轴表示Sprint中所有任务。其单位可以是小时、人天等。Release Burndown Chart横轴表示这个项目的所有sprint，纵轴是指在各个Sprint开始前尚未完成的工作，她的单位可以是Story的数量，人天等。
9.计划扑克（Planning Porker）
所谓计划扑克是一种标有各种数字的扑克牌。参加游戏的人每人各拿一叠扑克牌，牌上有不同的数字。
客户或者产品负责人为大家挑选1个Story（Backlog），并简单解释其功能，以供大家讨论。
每个游戏参加者按照自己的理解来估计完成这个Story所需的时间，从自己手中的牌里选一张合适数字的牌，并发给大家看。游戏参加者各自解释选择这个数字的原因，尤其是数字最大和最小的人。
根据每个游戏参加者的解释，重新估计时间并在此出牌，直到大家的估计值比较平均为止。
这个游戏中需要注意的是：首先，这不像普通的扑克游戏，不是轮流出牌，而是大家考虑好了后同时出牌，这样就可以避免后出牌的人呗先出牌的人干扰；其次，要告诉团队成员，他们需要估计所有的Story，而不仅仅是他们要做到那些部分，不如测试人员不能只估计测试工作所需要的时间。
10．Sprint
Sprint代表Scrum的一次迭代，周期通常是30天，期间不能给Team增加额外的需求，以确保迭代结束时能够获得预期的结果
11. Stakeholders
利益相关者，是项目成败对他们影响不大的一类人，他们参与提出产品的需求并积极提出反馈意见。
4043
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
