敏捷实践――“钱掌柜”分流发布模式（通用5篇）由网友“不吃饺子皮”投稿提供，今天小编在这给大家整理过的敏捷实践――“钱掌柜”分流发布模式，我们一起来阅读吧!
篇1：敏捷实践――“钱掌柜”分流发布模式
“分流发布”脱胎自“灰度发布”，是一种发布范围逐步放量的过程，放量范围从公司内部，到种子用户，再到大量用户，那如何理解“灰度发布”中的“灰度”二字呢？我们首先从哲学的角度分析，自然界万物并不是非黑即白，在由白到黑或者由黑到白的过程中还存在着一种非黑非白的状态。分流发布（灰度发布）类似上述概念，对于互联网产品而言：从前，所有的用户只能使用同一个版本，版本一经发布，所有用户都得切换到最新版本；但现在，通过筛选策略和技术手段，不同的用户可以使用不同的版本。
一、为什么要分流发布？
也即分流发布有什么意义价值？其实业界早有类似的做法，比如Microsoft在推出Windows或Framework之前一般先出预览版，GMail正式发布前的测试账号在eBay上叫拍200美元，Napster放出2W音乐下载beta测试账号引来300W用户注册疯抢。那我们冷静分析之后发现，分流发布可以带来多方面的好处：
1、缩小可能风险的波及范围，比如新推产品或功能，容易出现用户体验不爽或者性能低下等不足；
2、尽早吸收用户的反馈，产品不必100%完美才推出，可以先让部分用户试用，分析用户行为或汲取用户反馈后，再采取快速步骤改进产品；
3、提高产品的最终质量，分流发布等于除了QA测试外再扩大测试人群的范围，我们让更多的忠实用户直接参与测试，让更多双眼睛来发现隐藏的缺陷；
4、程序升级更加有序和自动化，以往如果升级涉及复杂的数据变动，很有可能需要停机处理，但如果是以分流发布的方式，逐批更新升级，或由用户触发，就可以实现不停机处理；
二、哪些场景适合分流发布？
1、新产品或大项目初次发布时；
2、业务策略不明确拿不准时；
3、面向特定用户群体时；
4、大范围升级时；
……
三、分流发布包含哪些环节？
分流发布一般包含5大环节，它们是：
1、定义策略：确定分流的目的、放量的规模、递增的频率、回滚的策略等；
2、筛选用户：确定分流访问的用户特征，定义规则或导入名单；
3、访问分流：技术支撑，通过DRE（分流发布引擎）重定向用户请求；
4、部署应用：打包部署单独的分流环境；
5、体验反馈：收集分流用户试用后的建议反馈，修正产品设计；
四、分流发布在“钱掌柜”的应用，
目前在线财务开发部已实现DRE（分流发布引擎），支持根据租户特征（IP/地区）或者预设分流名单两种方式。其中计划在12月底发布的Portal、Dashboard、Flowmap改版项目中面向杭州IP用户定向分流发布，成为Alisoft WEB产品开发中应用分流发布的第一个吃螃蟹的团队。
附：DRE（分流发布引擎）架构设计图
篇2：敏捷测试实践
1、什么是敏捷模式：
敏捷模式是一种应对快速变化的需求的一种软件开发模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用，敏捷的模式并不是一个方法论，而是一个世界观。
甚至敏捷不是一个方法论，顶多也是一种世界观。当在做一件事而又不确定哪种方法正确时，就可以参考一下原则，看看是否与原则相违背；
2、敏捷模式的实现方法
采用敏捷的开发模式不是说前期的需求什么的都不需要讨论，系统设计不需要了。在项目的前期，PD需要完成PRD，召开PRD评审会议，或者出原型之类的，务必使项目的成员都了解项目的需求。
对于没有使用过敏捷模式的团队，还需要召开Scrum计划会议，介绍项目的整体管理（流程，方法，工具和团队组建）等。
另外在流程开始之前，我们需要介绍一个名词，UserStory。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：角色——谁要使用这个功能；活动——需要完成什么样的功能；商业价值——为什么需要这个功能，这个功能带来什么样的价值。指定UserStory并没有统一的标准，项目组N个人可能有N种粒度的UserStory；从测试的角度来讲，我们需要保证没有遗漏。
迭代计划：迭代的划分
设定UserStroy
任务的分解
工作量的评估和认领
对整个迭代的整体计划进行确认；
任务执行：开发和测试按照迭代计划执行
每日站立会议：沟通已经完成的进度，当前计划和当前问题
提前进行部分功能交付测试
全部功能测试
团队回顾：评审会议
产品交付验收
3、敏捷模式和非敏捷模式的区别：
使用敏捷的模式开发项目，更多的是要求项目成员之间能够彼此信任，互相协作，同心协作，相互沟通，
使用需要项目组的成员发挥自己的主观能动性。
对比瀑布模型：
个体和交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
对比迭代模型：
迭代模型是以模块为最小划分单位，每个迭代采用的可能是小规模的瀑布模型；而敏捷模式，是以一段时间为止，我们尽可能多的实现UserStory，；
4、敏捷的适用范围
敏捷的是在充分了解项目的基础上进行的一种类似于手工作坊的开发模式。因此在所有的项目中都可以使用敏捷的思想，但是如果完全使用敏捷的开发模式，个人觉得以下类型的项目比较适用：
对实践型需求变更较频繁的项目比较适用：对于那些需要严格按照PRD进行开发的项目不合适，比如微软需要开发一个win9的系统是不可能采用这种敏捷模式的。
对逻辑简单的项目比较适用：对项目逻辑复杂，关键性高，可靠性安全性等方面有较高的要求的项目需要在开发的每个过程中，都需要多方认证，适用敏捷模式不合适。比如需要淘宝的登陆系统，就不可能使用敏捷的模式。
对团队成员少而精的项目比较适用：如果一个项目中，人数越多，面对面的沟通的代价就呈几何级往上增加。
对模块独立的项目比较适用：如果项目中，模块和模块之间的耦合度较高，相互之间依赖严重，整个项目只有很少的UserStory，使用敏捷模式会造成项目敏而不捷。
5、敏捷实践的经验和教训
避免无计划性：在以往的开发模式中，测试计划是绝对时间，而敏捷模式中，测试计划是相对时间。以往的开发模式在某段时间中，任务比较明确，而在敏捷模式中，容易造成无计划没目标。对于这种情况，除了有任务计划之外，能够自己指定一份计划，给任务计划确定具体的完成时间点。
避免无纪律性：敏捷的模式是支持需求变更的，但是我们不能够无谓的变更。所有的开发和测试同学都不希望自己的项目中存在不确定因素，但是使用敏捷模式，我们需要接受这种变更；
任务划分思考不足：从下面的图中（最开始并行上升段）我们可以看到，预计的总的开发时间（蓝色的线）是上升的，表示项目的考虑不够充分！在实际开发的过程中发现了不足之处，然后进行改进，导致整个工作量的增加，例如我们项目使用的是WEBX3，结果hecla不支持webx3，目前仅支持从webx2升级到webx3的兼容模式。
任务填写不准确：不是项目组中的每个同学都能坚持每天都在XPLANNER中填写时间的，如果时间填写不准确，则无法准确表达当前的项目情况（资源投入情况，项目质量等）。
篇3：敏捷结对编程实践
本文主要从提升项目质量、促进知识传递及减少项目风险等角度出发，讲述作者所在团队在结对编程实践中的一些经历，以及如何避免或减少其所带来的负面影响，
你了解结对编程吗？你尝试过结对编程实践吗？也许你还未曾尝试甚至还不曾了解，那么我们一起来学习和了解敏捷结对编程实践，相信对敏捷感兴趣的你会有收获。
什么是结对编程
结对编程（Pair Programming）是一种敏捷软件开发实践，指两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘和鼠标一起工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）， 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试（Integration Test）、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作（如图1所示）。
图1 共用一台电脑进行结对编程
上面是极限编程（eXtreme Programming，XP）对结对编程的描述，它有如下主要的优点：
有利于提升项目质量，减少Bug；
有利于知识传递，降低学习成本；
多人熟悉同一段代码，减少项目风险；
与别人一起工作会增加责任和纪律性等。
尽管结对编程有诸多诱人的优点，但实行结对编程实践的却为数不多，其主要原因可能有：
结对编程需要投入更多的资源；
结对双方需同时注意力集中，否则效率更低；
结对人员能力要求相适，否则起不到观察者的作用，甚至产生依赖；
不成功的配对，经常引发争吵，产生内耗，导致团队不和谐等。
结对编程是颇具争议的敏捷实践之一，除上述一些优缺点外，可能大家还有更多不同的看法，但分析利弊不是本文所要讨论的重点。
实践经验
就我所在的项目团队而言，6人左右的开发团队需要支持多个中小型独立产品的需求开发，在繁重的业务压力下，用户价值的快速交付是首要的，所以想尝试共用一台电脑进行结对开发的实践只能是一种奢望。让团队开发人员尽可能熟悉相互间的产品代码，提升项目开发效率以及保证良好的项目质量，是我们在项目开发过程中需要重点解决的问题。
我们试图通过集体Code Review和设计交流分享等活动，来提升代码质量以及相互间业务代码的熟悉度，但一直收效甚微。问题主要在于这种集中式活动时间较难安排，人多交流效果不佳，性价比不高。后来，得益于公司的导师机制，在一对新人和导师身上，找到了敏捷结对的原型。由于他们的紧密合作，遇到问题及时沟通，新人在项目进度和质量都有不错表现，很好地融入了团队，
在后续的项目过程中，我们不断地尝试和优化这种结对形式，逐渐形成相对固定的工作方法。
与XP结对编程相比，敏捷结对编程最为显著的差异是结对进行需求分析、系统设计和问题讨论，但分别编码实现，通过过程中频繁的Review来实现结对的效果。开发人员两两结对，共同认领开发任务，一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论，然后分工各自编码实现，并通过Code Review以确保实现与设计一致。对结对过程中发现的问题，随时沟通和讨论。由于产品业务逻辑相对不是特别复杂，所以通过这种小范围、高效的沟通，可以解决项目中的绝大部分问题，实现更高的开发效率并确保代码质量。目前，在开发流程中的主要结对活动如图2所示。
图2 敏捷结对的主要活动
结对活动（如图3所示）给我们带来了哪些好处？
提升项目质量。结对开发人员在需求理解、设计思路上进行了充分的沟通和讨论，能尽早地发现和解决问题，避免前期因需求理解偏差、设计缺陷问题造成返工。
知识传递。对于新员工或经验略逊的开发人员，通过经常性的沟通和讨论，能迅速地进入角色和积累经验，发挥了传帮带的作用。
backup，规避项目风险。结对人员之间互为backup，有利于团队成员之间熟悉业务代码，若有人员异动时有利于项目风险控制。
图3 结对人员充分讨论设计细节及问题
无论新老结对还是强弱结对，都要尽力避免一方对另一方产生依赖，要给新人足够的成长和锻炼空间，让其独立思考和解决问题，并允许在可控范围内尝试失败，以获取宝贵经验得到成长。否则，团队只会多一个执行者，结对难以达到预想的效果。同时，一定程度的独立活动，可以让大家保留自己的工作习惯，而且形式更为自由和灵活。当然，大家可能会有疑问，如何保证结对人选中资深工程师工作的正确性，因为新人和弱者很有可能无法提出想要的Review帮助。这个问题在我们的结对中不可避免，有选择地邀请其他资深专家Review，也许会是个不错的解决方案，特别是对于一些重要的复杂业务逻辑。
参加结对的工程师应具备独立思考和解决问题的能力，并且具备较好的团队协作意识。否则，不仅不能有好的结对效果，反而会带来一些新问题。此外，结对也不仅限在研发工程师之间，研发和测试工程师之间或同产品经理之间的结对（如图4所示），同样可以带来不错的效果。
图4 研发、前端工程师测试之间结对解决问题
引入敏捷实践，贵在充分理解、结合实际，能扬长避短，且是一个适应、发展的过程，而按部就班绝对不是个好主意。有选择地结对对我们来说也许是上策，在结对的人选、场合、结对的环节等方面进行选择性的实施。
作者金建法，阿里巴巴B2B公司技术主管，具有多年互联网开发和项目管理经验，对J2EE和敏捷项目管理有着浓厚兴趣。
篇4：敏捷测试的方法和实践
文 / 朱少民
有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改，这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！
什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：
究竟什么是敏捷测试？
敏捷测试有哪些流程改进？
测试人员如何面对敏捷测试的挑战？
在敏捷测试中如何制定相应的自动化测试策略？
什么是敏捷测试
假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。
图1 敏捷测试定义的形象描述
敏捷测试流程的优化
在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。
在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。
图2 敏捷测试流程简要图
在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：
测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。
新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：
不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。
基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：
通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小，
基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。
自动化测试策略
由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。
图3 自动化测试的策略
构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试
集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。
单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
功能测试自动化：ThoughtWorks Twist。
Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
Web service测试工具（backend）：soapUI。
性能测试：JMeter+BadBoy。
验收测试框架：Fitnesse、Tellurium。
敏捷测试过程管理工具：微软的Visual Studio ，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。
测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。
产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。
理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。
总结
根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：
敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试） + 原有功能的自动化测试 （回归测试）。
敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。
作者朱少民，网迅（中国）软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员，中国软件测试认证委员会（CSTQB）资深专家。在软件工程 领域颇有建树，先后获得多项科技进步奖、出版十多部著作和高校精品教材，如《全程软件测试》、《软件测试方法和技术》等。
本文选自《程序员》杂志10期，更多精彩内容敬请关注10期杂志
篇5：敏捷项目管理工具ScrumWorks Pro 3.0发布
Danube科技近日发布了ScrumWorks Pro 3.0版本，这一版本是在2007年8月的时候提出的，ScrumWorks Pro是一个敏捷项目管理工具，它能够帮助团队跟踪每次迭代与整个版本发布的过程。本次版本的变化集中在两个方面：可用性的改进以及使用MySQL作为 后端数据库。
根据Danube的CTOVictor Szalvay所说，这一版本关注的一个方面是对界面美观性和可用性方面的改进。对UI作出的多个改进包括：
新的产品创建向导——指导用户根据决策（团队、角色和权限以及产品的属性）创建一个新产品。
Docking框架——与Eclipse相似，用户能够使窗口停靠（dock）在其父控件的任何一侧，以便于能够同时浏览多个编辑器。
标签方式编辑——与Firefox相似，用户能够在自己的标签（tab）中，整齐地显示针对不同故事或任务的编辑器。
拆分（Split）特性——在创建一批故事（或者任务）时，用户通常认为一个单独的故事会拥有多个条目。拆分特性简化了将它转换到一个单独故事的步骤。
Sprint详细信息视图——增强了树型视图的支持，该视图能够将任务与它们的故事关联起来，
此外，Sprint视图还支持根据“认领人”、“任务状态”或其他任一列对内容进行筛选。
根据Victor的观点，或许最重要的改变是对MySQL的支持，企业用户希望工具能够支持更大的部署需求规模，而不是使用一个内嵌的数据库。新的标签页方式的编辑器
Sprint详细信息视图
ScrumWorks Pro提供了桌面客户端和Web客户端——桌面客户端具有全部特性，而Web客户端则提供了Spring的一个视图，用于更新任务状态和任务估算。服务器 组件可以运行在Windows XP/Vista/2003 Server，Mac OS X 10.4.2+以及Linux上，而桌面客户端则支持：Windows XP/Vista，Mac OS X 10.4.2+和Linux KDE。
查看英文原文：Agile Project Management ScrumWorks Pro 3.0 released
来自：www.infoq.com/cn/news/2008/03/ScrumWorksPro_3
★ 高中小论文范文
【敏捷实践――“钱掌柜”分流发布模式（通用5篇）】相关文章：
盐业公司年终工作总结2023-01-03
营销心得2022-07-30
银行调研报告范文2023-05-21
数字城管明年个人工作计划2023-05-28
营销心得读后感2023-02-28
项目管理工程硕士开题报告2023-10-23
消防网格化工作职责2023-10-12
三农论文2022-10-08
法院上半年工作总结报告2023-05-12
浅谈检察机关办公办案信息管理系统的基本功能/刘仕杰法律论文网2023-08-04