w1100n
This site is best viewed in Google Chrome
wiloon, 7/20/2013 16:17

http://blog.csdn.net/KerryZhu/article/details/5366574  敏捷方法在软件开发中受到青睐,特别是在互联网应用服务系统的开发中,越来越多的公司采用敏捷方法,包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别,但基本思想是一致的,如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中,流程相对灵活,强调沟通,通过充分的沟通来及时解决问题,由于沟通充分,文档不是很重要,而且有可能不采用Word等独立的文件格式,而是采用Wiki、空间等web内容方式。在敏捷方法中,需求变化比较快、产品开发周期很短(一、两周),给软件测试带来很大的挑战!例如,功能测试的自动化实现就比较困难,没有足够时间开发自动化测试脚本,要花大量时间讨论产品特性,及时进行产品的验收测试。自动化测试,更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践,开发人员能发挥更大的作用,而测试人员难以很好地发挥作用。在敏捷方法中,开发人员的主导作用更明显,讨论需求、实现需求,再修改需求、再实现、再重构,不断完善产品,测试人员容易边缘化。甚至在Crystal方法中,可以不需要测试人员,开发人员能承担所有技术性的工作。   在敏捷方法中,测试人员的价值又如何体现? 首先在需求讨论上,测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。 在开发过程中,测试人员不仅扮演“用户代表”角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。 测试人员还是可以参与单元测试。即使单元测试由开发人员做,测试人员可以推进开发人员进行单元测,检查单元测试状态,如确保单元测试达到80%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。 即使在敏捷方法中,集成测试、端到端(end-to-end)测试、性能测试等是不可少的。因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。测试人员在功能测试上工作量会降低,但在这些测试上发挥更大的作用。 随着迭代的不断深入,回归测试的工作量很大,这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本,这也是一种持续的努力,使回归测试自动化。 测试人员对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。 而且: 在敏捷方法中,我们也要采用敏捷测试,不要再写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点列出来。 在敏捷测试中,可能不需要测试用例,而是针对use case 或user story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。 所以: 敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试)  + 原有功能的自动化测试 (回归测试)   理想情况下,测试人员具有很好的编程能力,可以和开发人员进行角色互换。在当前版本开发(/迭代周期)中担任测试人员角色,在下一个版本开发(/迭代周期)中担任开发人员角色,而开发人员则担任测试人员角色,让开发人员深刻地理解用户的需求角度来考虑系统功能的设计,这样会更好地保证产品的质量,沟通的障碍也会消除,开发的效率会有很大的提高。这也是对测试人员的一个挑战。   敏捷测试也是一个持续测试的过程,而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。测试人员在自动化测试框架构建上、测试工具开发或第3方测试工具前期研究、试用等方面可以发挥主导作用。   项目采用敏捷方法,要获得成功,项目组中每个人都有很强的质量意识,具有质量的主人翁精神,特别是开发人员,每时每刻提醒自己——“质量是构建出来的”,与客户或产品设计人员进行充分沟通,遵守高度一致的质量标准。测试人员将是促进质量文化不断提升的中坚力量。   [案例补充] 来HW一段时间了,所在项目是其一个全新重点项目,由于采用敏捷模式开发,包括PM在内大家都是在摸索中进行的。撇开CMM改用敏捷,文档不再全面了,连缺陷库都改用轻量级的了,领导们说敏捷中测试做的好不好不是看找到多少BUG,而是看转测试时有没有BUG,要在开发交流中解决全部问题。三轮迭代下来,交流占据了大多数时间,感觉工作做好很多,但却不知道如何体现,这个真是问题,希望大家给点建议。

wiloon, 7/20/2013 10:40

结对编程(Pair Programming)是一种敏捷软件开发实践,指两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘和鼠标一起工作。一个人输入代码,而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员,审查代码的人称作观察员(或导航员), 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试(Integration Test)、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作(如图1所示)。 有利于提升项目质量,减少Bug; 有利于知识传递,降低学习成本; 多人熟悉同一段代码,减少项目风险; 与别人一起工作会增加责任和纪律性等。 尽管结对编程有诸多诱人的优点,但实行结对编程实践的却为数不多,其主要原因可能有: 结对编程需要投入更多的资源; 结对双方需同时注意力集中,否则效率更低; 结对人员能力要求相适,否则起不到观察者的作用,甚至产生依赖; 不成功的配对,经常引发争吵,产生内耗,导致团队不和谐等。 结对编程是颇具争议的敏捷实践之一,除上述一些优缺点外,可能大家还有更多不同的看法,但分析利弊不是本文所要讨论的重点。 实践经验 就我所在的项目团队而言,6人左右的开发团队需要支持多个中小型独立产品的需求开发,在繁重的业务压力下,用户价值的快速交付是首要的,所以想尝试共用一台电脑进行结对开发的实践只能是一种奢望。让团队开发人员尽可能熟悉相互间的产品代码,提升项目开发效率以及保证良好的项目质量,是我们在项目开发过程中需要重点解决的问题。 我们试图通过集体Code Review和设计交流分享等活动,来提升代码质量以及相互间业务代码的熟悉度,但一直收效甚微。问题主要在于这种集中式活动时间较难安排,人多交流效果不佳,性价比不高。后来,得益于公司的导师机制,在一对新人和导师身上,找到了敏捷结对的原型。由于他们的紧密合作,遇到问题及时沟通,新人在项目进度和质量都有不错表现,很好地融入了团队。在后续的项目过程中,我们不断地尝试和优化这种结对形式,逐渐形成相对固定的工作方法。 与XP结对编程相比,敏捷结对编程最为显著的差异是结对进行需求分析、系统设计和问题讨论,但分别编码实现,通过过程中频繁的Review来实现结对的效果。开发人员两两结对,共同认领开发任务,一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论,然后分工各自编码实现,并通过Code Review以确保实现与设计一致。对结对过程中发现的问题,随时沟通和讨论。由于产品业务逻辑相对不是特别复杂,所以通过这种小范围、高效的沟通,可以解决项目中的绝大部分问题,实现更高的开发效率并确保代码质量。 给我们带来了哪些好处? 提升项目质量。结对开发人员在需求理解、设计思路上进行了充分的沟通和讨论,能尽早地发现和解决问题,避免前期因需求理解偏差、设计缺陷问题造成返工。 知识传递。对于新员工或经验略逊的开发人员,通过经常性的沟通和讨论,能迅速地进入角色和积累经验,发挥了传帮带的作用。 backup,规避项目风险。结对人员之间互为backup,有利于团队成员之间熟悉业务代码,若有人员异动时有利于项目风险控制。论新老结对还是强弱结对,都要尽力避免一方对另一方产生依赖,要给新人足够的成长和锻炼空间,让其独立思考和解决问题,并允许在可控范围内尝试失败,以获取宝贵经验得到成长。否则,团队只会多一个执行者,结对难以达到预想的效果。同时,一定程度的独立活动,可以让大家保留自己的工作习惯,而且形式更为自由和灵活。当然,大家可能会有疑问,如何保证结对人选中资深工程师工作的正确性,因为新人和弱者很有可能无法提出想要的Review帮助。这个问题在我们的结对中不可避免,有选择地邀请其他资深专家Review,也许会是个不错的解决方案,特别是对于一些重要的复杂业务逻辑。参加结对的工程师应具备独立思考和解决问题的能力,并且具备较好的团队协作意识。否则,不仅不能有好的结对效果,反而会带来一些新问题。此外,结对也不仅限在研发工程师之间,研发和测试工程师之间或同产品经理之间的结对,同样可以带来不错的效果。 结对编程(Pair Programming)是一个编程模式(Programming pattern)。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作。他们一起分析,一起设计,一起写测试例子,一起编码,一起单元测试,一起整合测试(Integration Test),一起写文档等。基本上所有的开发环节都一齐肩并肩地,平等地,互补地进行开发工作。 结对编程不是一个人简单地看着另一个在做什么——在卓有成效的配对工作里,这两个合作伙伴常常工作在不同抽象层次,一个人关注的是为实现眼前目标而编写的代码的细节,而另一个人考虑的是更大的前景和下一步要做的事情,这两个人的角色频繁进行更换。这是一项高强度的、严密的,且常常令人疲劳的活动,但是能够创造出经过深思熟虑的高质量代码。 ——Laurie Williams &Steve Hayes 本贴是关于敏捷开发-结对编程(Pair Programming) 的内容聚集的帖子。欢迎跟贴,提供: 1、结对编程相关的研究资料和资源   2、实施结对编程在国内或自己公司所遇到的阻力   … Continue reading

wiloon, 2/27/2013 23:08

日常站立会议(daily stand-up meeting)是每天早上举行的短期会议。该活动起源于敏捷开发方法,在Scrum开发中很常见。日常站立会议一般用时五到十五分钟,有时候指代站立的早晨点名或每日例会。   日常站立会议(daily stand-up meeting)的目的是让每个团队成员回答以下三个问题:   1)你昨天做了什么?   2)你今天要做什么?   3)你遇到什么困难了吗?   站立,而不是坐着,强化了该会议打算简短且避免浪费时间的想法。站立会议并不是一个解决问题的地方,而是让一个团队意识到现在的状态。如果需要讨论,适当部门可以安排另一个更长的会议。   在Scrum开发中,站立会议的目的是更新团队的状态,而不是管理,这一点必须得强调。在一些Scrum团队中,管理层会参加会议,但是只有团队成员讲话。

wiloon, 2/27/2013 22:56

迭代计划会议 重新讨论、确定本次迭代需要实现的Story,达成共同理解; 若有必要的话,则继续细化Story; 对Story进行优先级排序; 开发、测试、资料人员认领任务,估计工作量并做出承诺,这是敏捷的重要实践之一:开发团队决定承诺完成工作量的多少,而不是由SE或项目PL安排工作量。 共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划,开发、测试、资料是以Story为单位的,所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁?测试人员是谁?什么时候开始?什么结束?谁来Review?等等。 优秀实践: 明确任务责任人(包括开发、测试、资料)和任务完成时间点; 任务和问题都可作为跟踪项进行跟踪; 计划中根据Story优先级和依赖关系,严格按Story驱动制定计划,尽量减少Story并行开发;

wiloon, 2/27/2013 21:43

在ThoughtWorks一个典型的敏捷团队中,大致有四种不同角色:项目经理、业务分析师、开发工程师、测试工程师。同时,根据项目不同可能还需要:迭代经理,美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色,并担负相应的责任,但在ThoughtWorks内部,人与人之间是完全平等没有级别区分的。公司这种平等的文化,使得人与人之间的交流不会因为等级差距而丧失。同时,公司鼓励每个人向其感兴趣的其他领域发展,成为综合性人才。例如某个人现在是开发人员,但他也可以通过帮助项目经理做一些辅助工作,来学习项目管理方法,从而最终成为独当一面的项目经理。 以前公司同事写过一篇团队角色定义的文章:http://news.csdn.net/n/20060429/89961.html, 补完一些。 – Project Manager 作为团队的精神支柱存在。与团队的每个人进行必要的沟通以保障项目成员的士气和稳定性。 维持开发秩序,保障团队间交流的效率和效果,负责主持必要的活动 消除外部干扰,负责与客户进行协调和协作。管理来自与客户的scope变更 跟踪团队的开发效率,维持开发速率,进行适当调整以保证开发的顺利进行 管理项目风险,维护项目风险日志,识别风险并采取措施防治风险 负责最终的项目交付成功 – Business Aanlyst 需求获取与管理,与客户持续交流获取新的需求,并保持良好的客户关系。管理需求的优先级。 保障下一个迭代需要开发的需求能够预备到位。提前准备好需要的Story卡片,在Iteration Kickoff会议解释每个Story的具体需求给Developer 主持必要的会议,例如Iteration Kickoff和需求的评估活动 对需求进行初步的功能验收,保证功能的交付符合原始需求 – Developer/Architect: 了解系统业务和需求,设计和演进系统整体架构,能够做出适当的技术决策 编码,并对系统的每行代码负责,保持代码的干净,保持较高的测试覆盖率 维护项目基础设施如持续集成服务器、版本控制服务器等 评估需求,并在开发完成后演示开发的需求 – Quality Assurance 负责了解需求并编写需求验收条件,负责制定测试计划 负责测试开发人员完成的需求,并报告错误 负责对软件进行性能、压力、容量、负载测试等,负责项目的手工功能测试和发布测试 – Iteration Manager – 小团队多由项目经理或分析师兼任 负责项目过程的顺利进行,协调项目资源 主持各种迭代会议,如Standup和Retrospective … Continue reading

wiloon, 2/21/2013 23:05

http://www.scrumalliance.org/articles/439-story-points-versus-task-hours http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning

wiloon, 2/17/2013 10:37

http://space.itpub.net/13633641/viewspace-312630 很多教材上都有关于这个问题的解答。迭代长度通常建议为 2-6 周,这是一个经验数值。到底选择几周为一次迭代,这个问题其实不太难,因为你只有 1、2、3、4、5、6 这 6 个数字需要选择。 我们太极敏捷派的建议是这样的: 如何确定迭代长度,有这样几个关键点需要权衡。 第一,我们希望每次迭代开发,可以获得实质性的进展,完成足够的开发任务,所以对于普通项目 1 周的迭代长度就显得有点短,做不了几天的开发就要 close,不合算。 第二,迭代任务(包括模块集成、系统测试、评审等等)的完成,应该比较顺畅(streamlined)、从容或者适度紧张,没有非常紧迫、仓促的感觉。如果在某次迭代开发中,需要砍掉很多完成不了的任务,感到进度很紧张,那么很可能说明迭代的长度设置太短了,在下一轮的开发中应该增加迭代的长度。 第三,总体上我们希望迭代越短越好,它有个下限,短于这个下限就可能得不偿失。那么,迭代时间为什么不能过长?它的上限是多少呢?迭代的主要目的是为了及时获得各方面反馈,确认已开发的内容是正确和可靠的,从而减少风险,保证开发能够始终稳步地前进。显然迭代过长,很长时间不对已开发的系统部分进行验证、反馈,随之而累积的各种风险就可能增加。如果超过一个半月(6 周)以上,还都拿不出一些可以执行、验证和 demo 的软件程序,那么这样的项目开发显然不能说是高效的。 从 2 到 6 周,建议选择偶数 2、4、6 周作为迭代长度,排除奇数 3、5 周。执行周计划周总结和月计划月总结是国内很多企业比较普遍的做法,显然设置迭代长度为半个月、一个月或一个半月,就能与之相合拍,更自然和便于管理。设想,当您做月度总结的时候,只完成了 1 又 1/3 的迭代,会是什么感觉? 迭代长度通常还与整个项目的工期(或复杂度、规模)有关。如果项目的工期在 1 年以上,那么 1 个月或 1.5 个月的迭代长度就是比较合适的。假设 2 … Continue reading

wiloon, 2/17/2013 10:31

http://www.blogjava.net/josson/archive/2011/01/31/341341.html 1、什么是iteration和release? iteration和release是两个不同的概念,但在敏捷实践活动中,我们往往认识的比较模糊,一个Iteration就是一次release,其实不然。那么,具体有什么区别和联系呢? Iteration(迭代):在固定的周期内,经过需求分析、设计、实现、测试等活动,完成计划的的业务需求,迭代结束提供一个可工作的产品。计划的业务需求,可能是一个完整的User Story,也可能是一个Story中的若干task。 Release(发布):经过一个或若干个iteration后,完成计划中的所有User Story,经过测试后才release,最终真正交付给客户使用。 在我们的实践活动中,一个User Story所需的工作量超过我们的有效资源,无法安排在一个iteration内。我们就会想当然的会去延长迭代周期,增加有效资源以适应所需工作量。殊不知,这更象是形式上的迭代开发,无异于瀑布式项目开发过程。 2、建立固定的迭代周期,保持稳定的开发节奏 Scurm方法也非常强调稳定的迭代节奏,一个稳定的迭代节奏就如同项目的的心跳。Simon Baker描述说:”就像心脏有规律地跳动来保持身体运行,固定的迭代长度提供了一个恒量,有助于建立开发和交付的节奏。根据我的经验,节奏是帮助取得不变的步幅的重要因素”(2004)。对于敏捷开发的团队而言,稳定的迭代节奏可以让产品保持更稳定的交付。 3、如何保持稳定的开发节奏? 当一个迭代期内可提供的有效资源无法实现一个User Story时,我们如何按排呢? 在 谈迭代周期控制的困惑中已谈到,这里不在细述。 4、如何选择适合自己团队的迭代周期? 一般需要考虑以下因素: 1)、整个项目周期长度(完成计划的商业需求所需时间) 较短的迭代周期将会有以下一些好处:更频繁的向客户展示/交付可用的软件;更频繁的度量开发进度;更频繁的取得反馈并改进;一般大的项目最好有多次(3次或以上)获取反馈、修正的机会,根据项目周期调整迭代周期长度。 2)、不确定性的多少 不确定性有多种形式,客户到底想要的是什么?小组的工作效率,时间?技术门槛等都不存在不确定性,不确定性越多,迭代就应该越短。 3)、获得反馈的难易程度 指小组获取反馈数量、频度和及时性,视所处的环境不同,选择合适的迭代长度; 4)、优先级要以多久保持不变 开发小组承诺在一次迭代中完成一组特定的功能,重要的是不要改变他们的目标方向,优先级不会被改变的时间长度是选择迭代长度时需要考虑的因素。 5)、迭代的系统开销 每次迭代的成本(时间),如迭代中进行的完整回归测试。最佳迭代周期的目标之一就是减少或近似消除每次迭代的系统开销。如每次回归时间成本很高,那决定周期长度时更倾向于长一些。 6)、团队成员的紧迫感 Niels Malotaux指出:”只要项目的结束日期还在遥远的将来,我们就不会感到任何压力,并从容不迫的工作。当结束日期逼近时,我们才会开始更努力的工作”。意思指项目开始大家比较放松,而越临近结束,工作越忙压力越大。因此,选择一个合适的迭代周期长度,让团队成员在整个迭代过程中感受到的压力更平均,不是给团队更多的压力,而是压力总量平均分布在迭代过程中。 每个团队根据所在环境和条件确定一个合适的迭代长度,一般建议2~4周。在我们的实践中,以2周一次迭代的频率,保持相对稳定的开发和交付的节奏。

wiloon, 10/26/2012 13:27

install mysql create user agilefant update password in table users, md5 import example DB deply agilefant in tomcat fix utf8 encoding(tomcat server.xml, mysql character-set) EL: Effort left OE: Original estimate ES: Effort spent

wiloon, 10/24/2012 15:15

在世面上的自动化测试工具很多。有开源的,有商业化的,各有各得特色,各有各得优点!下面我就介绍几个我用过的开源自动化测试工具。 1 测试 WEB SELENIUM可以说是测试WEB最全面的开源自动化工具, 它可以在WINDOWS, LINUX, MAC 和 SOLARIS 上运行, 而且可以几乎用任何一种编程语言进行构建, 你可以用你熟悉的语言包括 JAVA, C#, PERL, PHP, PYTHON 和 RUBY。 它可以测试的浏览器有IE, FIREFOX, OPERA 和 SAFARI。 SELENIUM 家族成员有:SELENIUM, SELENIUM RC, SELENIUM IDE, SELENIUM CORE, SELENIUM GRID 和 SELENIUM ON RAILS。 GOOGLE 每天都要在他的TESTING FARM上跑几万个SELENIUM测试CASE,现在也些会更多,你如果想学习SELENIUM, … Continue reading

wiloon, 10/24/2012 11:04

VersionOne 商业化产品!没什么好说的,业界老大! 从 功能上看,的确非常新颖,贯彻了敏捷中的User Story为先的原则,和VSTS类似,将Issues、Defect、Task合并概念成为Task(在VSTS中更加优雅,叫做WorkItem), 并且必须挂在UserStory下,这个工具值得看看,有试用版可以下载,或者可以使用他们在线提供的试验平台 基于ASP.NET and IIS和 SQL。 团队可以使用“V1:敏捷团队”来管理产品和sprint backlog,通过交互式的“任务板(taskboards)“和”测试板(testboards)” 进行每日开发活动,藉由报表和燃烧图查看进度,以及其他活动。 通过这些功能,“V1:敏捷团队”的用户可以做到: 从电子表格中快速导入故事与缺陷,管理合并后的产品backlog。 利用简单的多条目拖放操作,方便地完成计划制定、对故事划分优先级。 使用电子白板界面同时制定多个版本的发布计划,提高效率。 通过交互式的任务板(Taskboard)、测试板(Testboard)、每日Scrum dashboard来对版本和sprint进行可视化追踪。 针对版本和sprints的关键敏捷度量数据生成图表,如Burndown、Velocity、Estimate trends、Cumulative Flow Reports。 唯一的问题就是提供的选择过多,对于寻求简单明了工具的人,并不是一个好产品!. Rally 商业软件用户使用率排名第二位!支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则(notification rules),以及用于Eclipse和CruiseControl.NET的连接器。 有免费在线试用体验版本. Mingle Mingle在ThoughtWorks官方站点可以免费下载,且5个用户以下的可以永久免费使用。Mingle是用纯Ruby打造的且运行在JRuby上 的一个产品,由于ruby是一门脚本语言,所以其移植性就很好,用其编写的程序安装起来也甚是容易,在Windows、Mac和Unix多种主流平台上跑 都是没有问题的;但也正是由于采用ruby编写,Mingle对硬件的要求也甚高,在我这台512M内存的机器上跑是超慢的、让人闹心的,建议还是放到性 能好的、单独的服务器上,内存容量官方建议是2G。还遇到了好几次ie错误,只好放弃了。 Mingle后台存储采用数据库方式,目前仅支持mysql和Postgres两种数据库版本,这个比 较遗憾,我无法使用现成的Oracle数据库了。 简单用了一下,发现如下很好的Features: 支持建立”个性化”项目模板,便于复用; 附带项目wiki,便于”项目知识积累和管理”; 丰富的card properties,使需求驱动的管理流程更加清晰; … Continue reading

wiloon, 3/27/2012 11:05

scrumWorks Pro是一个敏捷项目管理工具,它能够帮助团队跟踪每次迭代与整个版本发布的过程。本次版本的变化集中在两个方面:可用性的改进以及使用MySQL作为后端数据库。 根据Danube的CTO Victor Szalvay所说,这一版本关注的一 个方面是对界面美观性和可用性方面的改进。对UI作出的多个改进包括: 新的产品创建向导——指导用户根据决策(团队、角色和权限以及产品的属性)创建一个新产品。 Docking框架——与Eclipse相似,用户能够使窗口停靠(dock)在其父控件的任何一侧,以便于能够同时浏览多个编辑器。 标签方式编辑——与Firefox相似,用户能够在自己的标签(tab)中,整齐地显示针对不同故事或任务的编辑器。 拆分(Split)特性——在创建一批故事(或者任务)时,用户通常认为一个单独的故事会拥有多个条目。拆分特性简化了将它转换到一个单独故事的步骤。 Sprint详细信息视图——增强了树型视图的支持,该视图能够将任务与它们的故事关联起来。此外,Sprint视图还支持根据“认领人”、“任务状态”或其他 任一列对内容进行筛选。 根据 Victor的观点,或许最重要的改变是对MySQL的支持,企业用户希望工具能够支持更大的部署需求规模,而不是使用一个内嵌的数据库。

us
wiloon, 3/19/2012 9:58

as a xxx, i would like to xxx so that xxx. As a “user”, I want to “do sth”, so that “sth” “user” — 就是我们抽象出来的persona(Definition refer to wiki http://en.wikipedia.org/wiki/Persona) “do sth” — 要实现的功能 最后so that后面的 “sth” — 价值 价值说起来很简单,也很容易理解,就是 实现这个story后对用户的价值所在。 … Continue reading

辽ICP备14012896