Scrum方法在中国的应用
敏捷开发方法论的介绍和实践
敏捷开发方法论的介绍和实践敏捷开发（Agile Development）是一种先进的、适应性强的软件开发方法，其核心就是以人和互动为中心、注重软件工作而非文档工作、灵活地回应变化，从而更快地获取客户价值。
简单来说，敏捷开发就是一种敏捷、高效的软件开发方法。
敏捷开发方法论的发展历程敏捷开发的概念最早是在2001年被提出的，当时一群敏捷软件开发者聚集到了犹他州的蒙特娄（Snowbird）山庄，进行了一次探讨软件开发的会议。
这次会议被称为“敏捷联盟会议”，会议结束后他们发表了《敏捷宣言》。
在宣言中，他们强调了以下四个方面：1. 个体和互动胜过过程和工具。
2. 可以工作的软件胜过详尽的文档。
3. 客户合作胜过合同谈判。
4. 响应变化胜过遵循计划。
这些原则成为了敏捷开发方法的基础，而敏捷开发因此开始迅速发展壮大。
目前敏捷开发已经在全球范围内得到广泛应用，成为了软件开发领域里最具影响力的方法学之一。
敏捷开发方法的体系结构敏捷开发方法包含了多种实践和技术，旨在提高软件开发的效率和质量。
在敏捷开发中，软件开发是基于迭代和增量的，这意味着软件开发是分阶段完成的，每个阶段都需要生成可工作的软件产品。
在敏捷开发中，很少有预先确定的计划，因为这种计划很难应对变化。
而相比之下，敏捷开发更注重实践。
下面是敏捷开发方法论的核心实践：1. Scrum：Scrum是敏捷开发中广泛使用的一种开发过程框架。
在Scrum中，团队需要在每一个迭代周期中开发可工作的软件，并在固定的时间框架内完成。
Scrum强调了团队的自组织、交流和协作，使团队更容易应对变化。
2. XP：XP也是一种流行的敏捷开发框架。
它强调更高质量的编程技巧，比如测试驱动开发（TDD）、重构、持续集成等等。
这些实践可以帮助团队及时发现和修复问题，确保软件的质量。
3. Kanban：Kanban是一种可视化方法，通过制作诸如“工作流程图”之类的信息板，确保团队总能清晰地了解自己当前的工作状况。
敏捷项目scrum方法论
敏捷项目scrum方法论摘要：一、引言1.敏捷项目背景2.Scrum方法论简介二、Scrum核心理念与原则1.敏捷开发理念2.Scrum五大核心价值3.Scrum十二条原则三、Scrum角色与职责1.产品负责人（Product Owner）2.敏捷团队（Scrum Team）3.敏捷教练（Scrum Master）四、Scrum流程与机制1.迭代（Sprint）2.规划（Planning）3.评审（Review）4.回顾（Retrospective）五、Scrum实践与应用1.用户故事编写2.燃尽图与看板3.信息发射源与风险管理六、Scrum拓展与优化1.规模化Scrum应用2.混合型敏捷开发3.Scrum与其他敏捷方法的比较七、总结与展望1.Scrum在我国的应用现状2.Scrum的未来发展趋势正文：一、引言1.敏捷项目背景随着信息技术的高速发展，软件项目的复杂性和不确定性日益增加。
传统的瀑布模型已经无法满足快速变化的市场需求，敏捷项目开发方法应运而生。
敏捷开发注重团队协作、快速响应变更和持续交付价值，已逐渐成为现代软件开发的主流。
2.Scrum方法论简介Scrum是一种基于迭代的敏捷开发方法，它将复杂项目划分为多个短期迭代，从而实现快速适应变更、提高项目可控性。
Scrum方法论具有严格的流程和角色分工，适用于复杂、不确定的软件项目。
二、Scrum核心理念与原则1.敏捷开发理念敏捷开发注重个体与团队的协作，以人为核心，追求灵活性和适应性。
它强调持续交付、短周期迭代，让客户在项目过程中持续参与，以满足不断变化的需求。
2.Scrum五大核心价值（1）透明度：通过明确的流程和信息共享，让所有人了解项目状态和进展。
（2）变更响应：灵活应对变更，确保项目始终朝着正确的方向前进。
（3）敬业度：团队成员积极参与，自主承担责任，充分发挥个人潜能。
（4）协作：跨职能团队密切合作，共享知识和资源，实现共同目标。
（5）价值交付：以客户为中心，关注项目价值的实现，为客户创造最大价值。
敏捷开发在数字化转型中的应用与优势
敏捷开发在数字化转型中的应用与优势随着信息技术的快速发展，数字化转型已经成为如今企业发展的必由之路。
在数字化转型的过程中，敏捷开发方法成为许多企业所青睐的一种方式。
敏捷开发方法注重快速响应变化、迭代开发和持续创新，可以有效提升企业在数字化转型中的竞争力。
本文将探讨敏捷开发在数字化转型中的应用与优势。
首先，敏捷开发可以帮助企业快速响应市场变化。
在数字化转型中，市场需求和用户需求随时可能发生变化。
传统的开发方法往往需要长时间的规划和设计，无法适应快速变化的市场需求。
而敏捷开发方法则强调快速迭代和持续交付，可以根据市场需求的变化及时调整开发方向。
通过敏捷开发，企业能够更好地抓住市场机遇，提高产品的竞争力。
其次，敏捷开发可以实现持续创新。
在数字化转型中，创新是企业保持竞争力的关键。
敏捷开发方法鼓励团队成员积极参与产品开发和创新，提倡跨部门合作和持续反馈。
通过不断的试验和迭代，企业可以快速验证和调整创新想法，降低创新风险。
相比传统的开发方法，敏捷开发更注重用户需求和体验，可以更好地满足用户的期望，增强企业创新能力。
此外，敏捷开发可以提高团队的协作效率。
在数字化转型中，团队合作是实现项目成功的重要因素。
敏捷开发方法强调团队成员之间的沟通与协作，通过日常站会、迭代计划会议等方式促进信息的流动和问题的解决。
团队成员之间的密切合作可以提高工作效率，避免信息滞后和沟通不畅。
相比传统的开发方法，敏捷开发更注重团队协作和快速反应，能够更好地应对项目中的挑战。
此外，敏捷开发可以降低项目风险。
在数字化转型中，项目风险是无法避免的。
传统的开发方法往往需要长时间的规划和设计，容易因为市场变化而导致项目失败。
而敏捷开发方法基于迭代和持续交付，可以及早发现和解决问题，降低项目失败的风险。
敏捷开发注重项目的可视化和跟踪，可以帮助企业及时发现问题，快速调整和解决，确保项目的顺利进行。
综上所述，敏捷开发在数字化转型中具有广泛的应用与优势。
Scrum敏捷方法在快速开发中的实践及改进
Scrum敏捷方法在快速开发中的实践及改进作者：刘慧玲王申申陈晓军来源：《电脑知识与技术》2012年第21期摘要：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，是为了解决项目的复杂性，以最快最科学的方式实现需求的开发方式。
敏捷开发强调产品质量，更适合于开发进度不是很紧迫的环境。
但是国内的软件项目开发往往更注重于开发周期。
该文介绍了一种敏捷方法Scrum，通过在实际项目中的应用经验，针对快速开发环境，做出了一些改进。
关键词：敏捷开发；Scrum；快速开发中图分类号：TP312文献标识码：A文章编号：1009-3044(2012)21-5168-02在当前的软件项目开发中，敏捷方法被大量应用。
敏捷的优点不断的被发掘。
但是什么是真正的敏捷方法也在不断的争论中。
敏捷是一个思想，而不是过程。
敏捷宣言中只提到了四大主题思想和十二项原则。
由此引出的敏捷方法有很多，像极限编程，特征驱动开发，精益开发，水晶开发，动态系统开发方法，Scrum等，其中的Scrum方法在国内应用的最为广泛。
1 Scrum介绍Scrum不是一个技术或流程，而是一个开发框架。
Scrum将开发过程分为多个Sprint周期，每个Sprint代表一个2-4周的开发周期。
在项目开始前，将项目分成很多细小的任务。
所有开发者一起对这些任务评估。
每一项的任务的开发时间取所有人评估的中间值。
然后根据任务的优先级分配到不同的Sprint中。
每一个Sprint包含完整的设计，开发，测试，发布环节。
当一个Sprint的任务不能完成时，必须对剩下的任务重新规划。
在Sprint的开发过程中，每天开发团队都应举行一个简短的进度会议（Stand up meet ing）。
团队中的每个成员汇报当天的工作进展，以及遇到的问题。
这个会议应该尽可能简短，不能开成问题讨论会。
在每个Sprint结束后，需要对这个Sprint进行回顾。
主要总结4点：1）什么做的好？2）学到了什么？3）有哪些不足？4）下一次哪些要做的更好？在进行完所有环节后，进入下一个Sprint。
方法在中国的应用
Scrum在中国——企业实施情况调查实录最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。
从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。
尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。
正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。
出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：在交流中谈到的主要问题包括：1. 在项目中使用Scrum的原因是什么？2. 在实施Scrum时采用了怎样的路线，为什么这样做？3. 在实施时遇到的最大的困难是什么，你又是如何解决的？4. 实施Scrum以后，给项目、公司带来了哪些收益？5. Scrum实施为何遭遇失败？Q1. 在项目中使用Scrum的原因是什么？璎珞天色：需求变化太快；产品路线图不明；提高效率；增强交流；尽快让业务部门看到结果。
kaverjody：由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。
上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。
敏捷开发在产品研发中的应用价值是什么
敏捷开发在产品研发中的应用价值是什么在当今竞争激烈的市场环境中，产品研发的速度和质量对于企业的成功至关重要。
敏捷开发作为一种新兴的开发方法，正逐渐受到众多企业的青睐。
那么，敏捷开发在产品研发中究竟具有怎样的应用价值呢？敏捷开发最大的特点之一就是能够快速响应市场变化和用户需求。
在传统的开发模式中，往往需要进行长时间的规划和设计，一旦市场需求发生变化，调整起来十分困难，甚至可能导致项目的延误或失败。
而敏捷开发则强调灵活性和适应性，通过短周期的迭代开发，不断收集用户反馈，及时调整产品方向，确保产品始终符合市场和用户的需求。
比如说，一家互联网公司计划开发一款新的社交应用。
在传统开发模式下，可能会花费数月时间进行详细的需求分析和设计，然后才开始编码实现。
但在这个过程中，如果竞争对手推出了新的功能，或者用户的喜好发生了变化，那么之前的设计可能就不再适用。
而采用敏捷开发，团队可以先快速推出一个基础版本，然后根据用户的反馈和市场的动态，每周或每两周进行一次更新和优化，迅速加入新的功能或改进现有功能，从而在激烈的市场竞争中抢占先机。
敏捷开发有助于提高团队的协作效率。
在敏捷开发中，团队成员之间的沟通和协作更加紧密和频繁。
每天的站立会议、定期的回顾会议等机制，让团队成员能够及时分享工作进展、遇到的问题以及解决方案，避免了信息的不对称和误解。
以一个软件开发团队为例，在敏捷开发模式下，开发人员、测试人员、产品经理等每天都会进行站立会议，每个人只需要简要汇报自己昨天完成的工作、今天的计划以及遇到的障碍。
这样，团队成员能够清楚地了解整个项目的进展情况，及时发现并解决问题。
而且，由于大家经常交流，对于产品的理解也更加一致，能够更好地协同工作，提高开发效率。
敏捷开发能够降低项目风险。
通过短周期的迭代开发，每次迭代都能够产生一个可工作的产品增量，从而可以更早地发现问题和风险，并及时进行调整和解决。
假设一个企业正在开发一款新的智能硬件产品。
Scrum敏捷项目管理的应用研究
Research on the Application of Agile Project
Management with Scrum
作者： 党源源[1] 付晓琳[1] 徐立新[2]
作者机构： [1]长春工业大学计算机科学与工程学院,长春130012 [2]空军航空大学计算机教研室,长春130022
出版物刊名： 情报杂志
页码： 54-57页
主题词： Scrum 敏捷方法 Sprint 项目管理
摘要：软件开发是一项复杂行为，随着用户对软件要求的提高，需求的变化性和不确定性已成为软件行业的显著特点，传统软件开发方法不能很好地解决这些问题，而Scrum作为敏捷开发方法的一种，能够快速适应需求的变化，提高效率，增强交流，尽快让检查者看到结果，为这些问题的解决提供了一种可能方案。
介绍了被称为Scrum的灵活软件开发过程，简要分析了Scrum的骨架与核心，探究了Scrum的角色分配和Scrum流程，结合笔者所在大学实验室项目组的案例讨论了Scrum的具体应用，给出了Scrum团队组成及Scrum迭代过程，最后进行了展望。
基于Scrum的敏捷测试的研究及应用
基于Scrum的敏捷测试的研究及应用
信息技术的发展日新月异,市场的快速变化对软件产品的开发过程提出了更高的要求,既要快速发布又要能够迅速适应市场变化以便赢得市场并且不断在市场上处于有利地位。
测试作为产品开发中一个很重要的环节,面临新的挑战,要想解决面临的困难和问题,应该从几方面入手;一方面是高效的团队管理平台,一方面是正确的方法论来指导测试过程,还有一方面是选择合适测试设计的方法。
敏捷是近年来随着信息技术的进步发展起来的新的软件过程,敏捷过程的特点是容易适应变化并迅速做出自我调整。
Scrum是一种典型的敏捷软件方法,SCRUM开发过程中,通过迭代,预测和估计,及时调整计划,其中较为有特色的是它特别强调团队和管理层的交流协作。
对于测试人员面临的短时间、大量测试任务,测试覆盖的充分性与时间压力的矛盾的解决需要一种更为有效的测试方法。
正交矩阵测试方法是一种基于配对覆盖组合测试策略,是一种尽可能用最少的测试用例来达到最大的测试效率的方法。
本文首先阐述了传统的测试过程和方法,其次重点研究Scrum方法的特性,结合软件测试理论和方法,提出了一个基于Scrum开发方法的测试模型,另外本文研究了正交矩阵的测试的方法并且提出若干实用策略,两者结合以实现测试的敏捷过程和方法。
作者在公司新产品测试项目中应用此基于Scrum的敏捷测试模型,通过在测试项目中实践和结果的分析,验证方法是否实现测试的有效性和经济性,实现测试效益和对公司效益贡献的最大化。
作者的课题来源于工作中的要求,对实际工作有较好指导意义。
通过本课题的研究,将改进测试的敏捷性,使软件测试在整个产品开发周期中作出更加行之有效的贡献。
敏捷测试应该是所有成功软件开发的组织的目标。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Scrum在中国——企业实施情况调查实录最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。
从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。
尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。
正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。
出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：在交流中谈到的主要问题包括：1. 在项目中使用Scrum的原因是什么？2. 在实施Scrum时采用了怎样的路线，为什么这样做？3. 在实施时遇到的最大的困难是什么，你又是如何解决的？4. 实施Scrum以后，给项目、公司带来了哪些收益？5. Scrum实施为何遭遇失败？Q1. 在项目中使用Scrum的原因是什么？璎珞天色：需求变化太快；产品路线图不明；提高效率；增强交流；尽快让业务部门看到结果。
kaverjody：由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。
上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。
包括交付新的软件发布版本时间太长、软件维护效率低成本高，等等。
张汉东：我在07年10月份到NibiruTech的时候，初次接触敏捷。
当时团队内部普遍的敏捷做法是每天按时召开的例会。
当时我不太明白这个例会有什么作用？一直到11月底，强烈的好奇心让我想搞清楚这个问题。
于是我找到了Scrum。
因为创业团队嘛，刚开始项目管理方面只是用Trac 和我们公司自己写的管理系统。
Scrum先进的思想让我们当时的管理现状黯然失色。
于是我就决心在公司推广Scrum。
Q2. 在实施Scrum时采用了怎样的路线，为什么这样做？璎珞天色：我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进，从而趟出自己的一条路。
如果这个Sprint 我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review 机制。
这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。
我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进：06年3月——06年6月（1个团队，8人左右采用）06年6月——07年12月（3个团队，25人左右采用）07年12月——08年1月（一个部门，6个团队，50人左右采用）08年1月——至今（异地开发，原有团队的Scrum继续走下去。
异地的配合方式，工具，流程等建设中……）kaverjody：主要是自顶向下。
我们的组织太大，这样的决策权只有顶层管理人员具有。
张汉东：路线嘛，可以说是自顶向下和自底向上相结合。
我把资料拿给我们的CEO看了，同时也把资料分发给同事来看。
至于为什么用这种路线推广，我当时只是抱着一心想把好东西给大家分享的心态，其实也没想那么多路线。
随后笔者又向璎珞天色提问道，“在试点时是怎样的实施过程？是针对项目的具体问题，逐步采用各种敏捷实践来加以解决？还是先给团队做培训，介绍敏捷开发的理论实践，然后推行？”，她回答说：其实我们一开始并没有把Scrum这个说法拿出来。
就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。
于是就有了一月一个项目的进度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。
然后为了管理，我们开始开晨会。
然后为了改进，我们开始开项目总结会，把Product review和Team retrospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。
后来总结会上觉得质量不好，我们加入了单元测试和代码Review机制。
至于计划会议，一开始我们就采用的Scrum的方法。
项目小，MS Project太难调。
我们就更换了Scrum的Excel计划表，后来又换了Xplanner。
就这样走了几个月后，我们把大家叫到一起，开了一个Agile方法分享会。
把大家之前实践总结一下，然后告诉大家，我们的做法就叫做Scurm，而且它是很有名的哦。
然后再把XP、Agile 和Scrum都给大家系统讲一遍。
于是大家如梦初醒，原来我们是在走Scurm啊～～～～！！！同时这个项目组的成绩也得到了高层认可，高层也认为效率提高了。
于是让这个团队给周围的团队做分享。
并挑几个团队开始试行。
因为我们团队成员可能会有轮岗和互调，一个团队使用Project，一个团队使用Xplanner，有时员工也难以上手。
为了部门管理统一，方法统一，工具统一，最后高层下令全部实施Scrum。
Q3. 在实施时遇到的最大的困难是什么，你又是如何解决的？璎珞天色：首先应该解决领导的问题，解决方式就是拍晕他。
拍的方式，一言难尽啊。
至于接下来，说实话，我觉得推Scrum这种方式还是很容易推的，不过是一种管理理念。
比当年推CMMI那种东西好多了。
最困难的是你要不断解决暴露出来的问题。
比如说，以下这些呼声：1. “需求太模糊，造成后期开发沟通成本巨大，反复和产品经理沟通花了太多时间。
”2. “发布周期太长，一个Sprint要做3、4周才能上线，产品经理希望每周都能上两次线。
”3. “由于Scrum过程的特点，我们不能很系统地把握历史需求和整个产品的架构。
”4. “上线时间被业务拍死了，哪儿有时间做单元测试，连代码Review的时间都挤不出来。
”5. “目前的Backlog，人和人之间的协调，任务之间的瓶颈什么的都看不大清楚。
”6. “需求上线，至少1周才能分析数据看结果，没法在这个Sprint一做完就提出新的改进方案。
”7. “开发节奏太快，产品开发测试都没有时间停下来仔细考虑，历史需求没有善加利用。
”kaverjody：对于所遇到的最大困难，我认为是同事们对于敏捷开发的不了解甚至误解，以及只看到具体使用的工具和采用的开发实践等，而没有正确领悟到这些决定之后的那些考虑，即为什么要选择这些工具？为什么要采用这些开发实践？选择的标准是什么？选择的过程中才涉及到或者说真正体现出敏捷提倡的那些价值等。
而解决这些问题没有一蹴而就的办法，只能持续地进行教育工作。
一方面从理论上进行灌输，并通过长期的讨论来回答同事的问题，来消除大家的不安，另一方面，在遇到困难，或出现问题之后，及时地分析并解决难题，然后以此为案例向大家解释为什么要这样解决，以后再遇到这样的问题要怎么处理。
张汉东：顺利开展实施前的最大的困难有两个：1. 公司高层的支持。
我想这应该是个公共问题。
但是InfoQ前几天有篇文章（渐进式敏捷：由下而上的敏捷推行策略）也说了，如果高层并不支持Scrum，那么就屏蔽高层，在团队内部开展就行。
幸亏我们CEO和CTO都比较支持Scrum。
2. 公司员工的Scrum培训。
同事对Scrum都不太了解，于是我组织了一次Scrum培训，来给大家介绍Scrum里的规则，角色及Scrum的特点和它要解决的问题。
大家都把疑问拿出来集体讨论。
在讨论的过程中，让大家暂时了解什么是Scrum。
然后在实施的过程中，大家就慢慢地对Scrum的规则熟悉了。
当然前提是推广Scrum的这个人，要对Scrum比较理解。
以上两个问题在我这其实也不算是困难，因为我推广Scrum的过程中几乎很顺利，大家都很支持我的工作。
实施的时候基本也没有什么困难，很好上手。
可能和我们用来尝试Scrum的项目有关。
客户已经把backlog写成了Tickets发给我们，然后从接受那些Ticket算起，到客户要求的交工时间为一个迭代期，没有超过30天。
这些待办事项基本是优先级等同的，团队内部自己挑选能做的Ticket，然后每天例会大家都严格回答Scrum里的三个问题，保持团队的一致。
评审会议也是严格按照Scrum的规则来做。
所以暂时没有什么问题。
我想下一个Scrum尝试项目中可能会碰到细化需求制定backlog的问题，也许可以让客户把优先级排好，或者说帮助客户和客户一起把需求细分出来，排好优先级，然后在优先级的驱动下，漂亮地完成我们的每个迭代。
接着，笔者又请大家对某些具体困难的解决办法进行深入介绍，璎珞天色说：对应第一个需求模糊的问题，我们的做法是对需求文档统一模板，在计划会议前增加了需求讨论会，产品、测试和开发三方都参加；第二个发布周期长的问题，我们在项目发布之外，还增加了对日常维护需求的管理方法。
每周二和周四上班之前，产品经理会汇总所有维护性的小需求，例如页面修改，数据增删等。
周二和周四晨会上提交给负责发布的工程师。
周二和周四的下午，会集中发布这些小需求；第三、四个问题，无药可救，定期重构，业务第一，不做单元测试，只做代码Review。
张汉东说道：我们公司目前实施Scrum的状态可以说是比较顺畅。
所谓的顺畅，也许也包含我自己对Scrum 理解不太深入，只是抓着一些自己理解的皮毛来加以应用。
但我对敏捷的认知，对Scrum的认知就是那么一条，不断地迭代，不断地成功和失败，找到属于公司自己的Scrum。
在有一个项目里，因为需求不太明确，所以在sprint计划会议制定backlog时，粒度控制不是很好。
我们的做法是，根据已知的需求先把要实现这个迭代的总体技术步骤列出来，以实现次序做为优先级……我们的迭代期很短，这次是10天。
这样大概就可以在整体上把握项目的进度了。
然后在每天的每日例会上大家都会有计划地把今天要做的Item写到看板上。
这样有个好处，就是激发团队成员的自我管理意识，从而增进团队的自组织能力。
Q4. 采用Scrum后给项目、给公司带来了哪些收益？璎珞天色：说不上，很难去度量是Scrum给公司带来的收益。
说实话，我觉得Scrum所能带来的收益是没法度量的。
我们只能通过调查问卷的方式，去感性地得出它所带来的好处。