预示敏捷方法走偏的15个标志——第2部分

  • 时间:
  • 浏览:4
  • 来源:uu快3计划_uu快3官方_单双

假设我能 要去寻找此前听说过的曾经隐秘湖泊。我能 带上拥有的所有物品,还是只带上你需要的东西,以便快速前行呢?絮状的待办事项跟这名 情况汇报很像,你希望能尽快发现或验证功能价值,却在一如果 如果 如果 开始就负担过重。

本文转自 OneAPM 官方博客

敏捷团队应该自行组织,选用 适合团体行为的实践和仪式。这名 点也应该定期检查,让全体成员都参与进来,探讨改进流程的最好的办法,并采取相应的行动。这通常被称为“回顾”,是个中性最好的办法,用于修正流程,正确处理浪费时间责备成员。

可能某件事令你感到痛苦,多做这件事。这会激发自动化。

站立会议本应该是个简短的团队分享仪式,因此很容易拖成耗时较长的会议。把谈话限制成整个团队应该了解的内容的简短发言——你昨天做了什么,今天要做什么,有什么现象报告 ,是否需要协助。另外,说一两句你学到的东西也很有帮助。曾经就够了。朋友也能采取循环制,“参照故事墙”,或团队喜欢的这名 最好的办法来进行。

项目并都有真实处在的事物,也不一种思维模型。朋友发名权项目这名 词,来谈论这名 模糊的工作,把它们当做曾经时间和工作量的整体。项目并不处在,处在的也能产品。关键在于错综复杂。按照一系列也能交付可衡量价值的功能来组织项目,因此再进行小规模、可衡量的改进“浪潮”。

通用的“最佳”实践并不处在。适用于曾经团队的最好的办法可能并不适用于曾经团队,哪怕在同一公司,甚至是同一项目。朋友建造的所有东西都有基于独一无二的设计和条件,每个团队拥有的个性、技能和环境也都有独一无二的。看一看别人确实有效的实践最好的办法,可能可行,就试用一下,因此并不可能这名 权威人士说什么最好的办法是“最好的”,就自动套用。别人的“最好的”最好的办法也许会成为你的团队的负担。

开发软件优先于文档记录并不代表着“跳过所有模型和设计活动,只写代码”。需要正确处理的是花费无数个小时来制定完正的图表和规格相似投机性任务。毕竟,要了解曾经模型或设计是否正确,唯一的最好的办法也不通过写代码来进行测试。

可能你很关心功能的交付时间——曾经想法从概念到生产完成需要的时间——毁掉这名 切的最好最好的办法也不列个长长的任务清单。不幸的是,也不公司仍旧按照大模块来计划、授权和执行软件开发项目,曾经一如果 如果 如果 开始都有一大堆待办事项,因此会保证排在顶端的功能的交付时间绝对长得吓人。

站立会议并都有探讨技术、做出决策、提出设计方案、交换战争故事、重组迭代或这名 任何与必要的团队公司合作 者沟通无关事情的场合。做好准备来参会,曾经你就也能倾听别人做了什么,正在做什么,因此决定什么是否与你相关,而都有思考我能 要说什么。任何超出互相更新情况汇报的内容都应该如果 通过群聊软件或邮件来沟通。站立会议中,每个成员的发言时长应该控制在15到400秒之内。

测试对生产可操作软件非常关键,可能你什么什么都这样 将测试自动化,就错失了极大的波特率性和准确度。相似行为驱动开发(BDD)的轻量级测试规格技术与敏捷故事搭配时效果绝佳。在瀑布式模型中,BDD 描述也能通过一张非常简洁的表格来定义用例、明确要求和接受度测试。

把机器当做牲畜,而都有宠物,使用 Ansible、Chef、Puppet 等工具实现基础架构自动化。启动测试,实施软件自动化,可能最少打开开关。正确处理基础架构现象报告 ,把它作为代码库的一要素合并进去,并使用相似 AWS 曾经的自助服务平台。生产周期——从正确处理代码变更到产品发布所需时间——会被自动地大幅度缩短,可能反馈周期变短,相应的理解时间也会缩短。理解时间加快会带来更频繁、更优质的软件交付。

【编者按】误解和“最佳实践”可能会我能 的团队原地打转,无法高效产出代码。本文的第一要素介绍了预示着敏捷最好的办法走偏的前六个标志,下面将介绍另外10个重要标志。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

因此可能你需要正确处理曾经特别难的现象报告 ,那就想尽一切最好的办法来正确处理。低保真度的模型或设计也能在故事的测试用例中通过大脑进行测试,因此不同的设计也能更慢完成探索。你可能都有想基于故事规模来规定这名 活动的完成时间:举个例子,5分钟用于审查曾经一分值故事的基本流程和接触点,15分钟用于查看曾经两分值故事是否隐所含错综复杂现象报告 ,等等。

通用的“敏捷”通常会导致 团队跳过回顾环节,可能将该环节缩减为机械的仪式,无法获得任何有意义的经验教训。可能你注意到团队流程中处在现象报告 ,却不敢在回顾中提出来,朋友的回顾环节就可能变成了机械仪式。未经检查的流程无法得到优化,应该多多鼓励团队成员提出意见建议。

将什么测试用例,还有“测试金字塔”(技术单元测试、功能集成测试、接口契约测试、用户接受度测试)的剩余内容自动化,提供了一种高效可靠的备选方案,需要破坏任何东西,就能验证曾经代码变更是否达到预期效果。自动化的测试是一张安全网,能给团队带来自信和勇气。

举个例子,某位团队成员注意到,产品用户的反馈来得太迟,他建议缩短迭代时间也许会有帮助。团队通过了这条建议,尝试缩短迭代时间,并在下次回顾会议上评价曾经做的效果。通过这名 最好的办法,团队的流程不断得到改进。

结对编程什么什么都这样 人爱什么什么都这样 人恨。兄弟们,它也不个工具,并都有个信仰。它应该用在适合的地方,因此没错,这名 如果 它经常适合的。

你的模型或设计应该也能说明故事的好处,并推动你找到正确处理最好的办法,后者应该在代码中进行测试。使用你的判断力来决定需要设计多少,按照什么样的保真度,使用什么最好的办法,每个故事用多长时间,并不可能我能 要“实施敏捷”,就确实你“也能”建立模型或设计。

Scrum 是一种过程管理最好的办法,而都有软件开发最好的办法。Kanban 也一样。Scrum 和 Kanban 可能缺少强硬的敏捷原则,最终只会回到瀑布模型。也不企业开发环境中的絮状待办事项(使用瀑布模型,而都有渐进发展模型)和“标准化”敏捷实践更会恶化这名 现象报告 。

结对编程也能将系统、工具、最好的办法、技巧等知识传播到整个团队,增强成员之间的联系,支持成员之间的互相指导,因此在也不案例中也能比程序员独立工作的波特率更高、质量更好。可能你看过曾经故事时想的是“这名 工作曾经人来做应该比曾经人好”,显然应该选用 结对编程。可能团队中的某个成员也能完成这名 故事,结对编程可能无需有很大帮助。跟所有的敏捷实践最好的办法一样,结对编程也不个工具,应该用于有效的时间和环节。

重构不仅能帮助改善代码的机械性能,还能帮助你从当时人的代码中学到东西。通过重构,你能汇聚出更好的模型。现在你的代码能用,不过可能这名 令人紧张,甚至这名 脆弱。重构也能揭示内含的模型,告知你对该领域的理解。在测试导向的红-绿-重构(red-green-refactor)开发流程中,“重构”并不可选项,也不必选项,除非无需素了技术债务,因此未能从编码经验中吸取教训。

原文地址:http://www.javaworld.com/article/40075443/agile-development/15-signs-youre-doing-agile-wrong.html