敏捷 vs 伪敏捷(3)

　　团队定期地反思如何能提高成效，并依此调整自身的举止表现。

　　敏捷伪敏捷有组织地回顾审视优势，劣势，机会和威胁，并采取行动。不是完全无组织学习经验教训，就是有了结论却没有相应的行动。每一个团队成员都集中注意力在提高冲刺(Sprint)，发布(Release)和项目上。回顾会议被视为敏捷的一个必需的标志，并没有被认真对待。团队审视所有流程，努力确保所有活动步骤是必要的，优化后的，并能带来价值。团队审视所有流程，努力确保没有流程。

　　混合体 - ScrAgileFall

　　敏捷，Scrum和瀑布方法论的混合

　　它的工作原理是这样的?用户故事积压在任务列表(Backlog)里并排上优先级，但特定的用户故事累积列表有一个目标发布日期，这意味着他们都将被一起发布， 而不是单独发布。采用冲刺(Sprint)管理开发过程中设计，编码和单元测试阶段， 另在发布之前安排一个集成系统测试，测试“在范围内的”用户故事所有已完成的功能。

　　(It works like this. User stories are prioritized into a backlog but there is a targeted released date for a cumulative list of specific user stories, meaning they'll all be released together instead of individually. Sprints are then employed for the design, code and unit test phases of development but an integrated system test is performed prior to the release of all the completed features for the "in-scope" user stories.)

　　瀑布地规划和发布时间表，敏捷 / Scrum地设计和开发。

　　(It's waterfall planning and release schedules with agile/scrum design and development.)

　　敏捷软件开发宣言

　　对流程、文档到底意味着什么?

　　敏捷并不反对的流程。它反对没有价值的流程，反对不能使团队更有效的流程。

　　敏捷并不反对的文档。它反对那些对交付的解决方案没有帮助的文档。

　　敏捷流程和文档应该限制在最快的时间内交付高质量产品的最低水平。

　　敏捷测试

　　框架里的“独立的(Independent)”测试角色

　　“独立”并不意味着孤立一人。“独立”是指测试团队在价值链中所扮演的角色。独立不孤立。

　　测试不能被视为“最后一关”，不能仅会在所有冲刺(Sprint)的最后进行测试。测试需要持续集成到冲刺(Sprint)的每一部分。

　　测试不能被视为我们开发和他们测试之间对抗。为了成功，必须有一个团队意识。

　　在真正的测试驱动开发过程中，“独立的”测试将更少地在执行测试上，而更多地在确认上。

　　敏捷工具

　　这些测试工具在敏捷开发过程中能有一席之地吗?

　　敏捷测试工具 - Agile Accelerator 5.x

　　敏捷模板是基于Scrum的实践(比如，冲刺(Sprint)，史诗级(Epic)的用户故事，用户故事等等)。

　　QC模块自动同步，以便更容易管理冲刺(Sprint)。

　　单独的维基接口，以便更容易管理用户故事和任务。

　　标准的开发环境集成

　　Eclipse

　　Visual Studio IDE

　　TeamForge

　　Tasktop task-focused interface

　　敏捷表象(Façade)

　　突破表象的策略

　　敏捷教练 - 当组织投向到敏捷时，确保有一个经验丰富的教练，然后让他指导你的团队!

　　风险管理 - 确保文档的请求是根据清晰的风险理解从而判断是否需要文档(Make sure requests for documentation are supported with a clear understanding of the risks associated with not producing them)。当风险成真后，确保领导能够接受影响。

　　突破职责的限制。参与到项目的每个方面。突出测试人员是解决方案的一部分，而不是问题的一部分。

　　故事复查(Review) - 主持正式和非正式用户故事的复查会议，以帮助确保每个人都有同样的理解。

　　结对测试 - 就像结对编程有助于提高开发的代码质量，结对测试能确保更好的测试覆盖率。一个开发人员搭配一个测试人员。

　　促进采用工具和方法论的“最佳实践”。促进利用之前那些离开的人的经验。

　　回顾会议 - 认真吸取经验教训。确保建立由PM或Scrum Master跟踪的并可操作的计划。

　　面对残酷的事实，但从不放弃希望。

　　度量，度量，度量 - 没有度量将一事无成(What get meatured gets done)。开始测量你的敏捷过程的有效性。

　　实现之后：事件与变更请求(Post Implementation: Incidents & Change Requests)

　　冲刺(Sprint)计划与实际情况

　　冲刺(Sprint)的测试计划与进度

　　不要成为受害者 - 控制你自己和你的团队。如果你需要，做好保卫它的准备，然后做好自己的事情，坚持不懈，以帮助你的项目成功。

　　译者注：

　　敏捷是一个热门、有争议的问题，文中观点仅为原文作者观点(当然不排除我的错误理解)。去年看到这篇好文，一直想翻译下，跟大家一起分享分享，由于种种原因，直到今天才搞定，虽然很晚了，也算了却一桩心愿。

　　此文来源一个PDF，格式自己用HTML实现，可能会有些问题。如果发现请大胆指出来。翻译得不好地方，也请指正。

　　原PDF上的时间: 10/2/2012

　　原文连接：http://www.softwaretestpro.com/Item/5727/Session-404-Agile-vs- Fragile-A-Disciplined-Approach-or-an-Excuse-for-Chaos---Brian-Copeland/Software-Test-Professionals-Conference

原文转自：http://blog.csdn.net/ocean1ee/article/details/8873688