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

  • 时间:
  • 浏览:1

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

项目并回会真实所处的事物,好多好多 并有的是思维模型。亲戚亲戚大伙发明家 项目你这种 词,来谈论有些模糊的工作,把它们当做有一五个 时间和工作量的整体。项目从不所处,所处的必须产品。关键在于多样化。按照一系列可不能否 交付可衡量价值的功能来组织项目,因此再进行小规模、可衡量的改进“浪潮”。

通用的“最佳”实践从不所处。适用于有一五个 团队的最好的最好的办法 肯能从不适用于原来团队,哪怕在同一公司,甚至是同一项目。亲戚亲戚大伙建造的所有东西回会基于独一无二的设计和条件,每个团队拥有的个性、技能和环境也回会独一无二的。看一看别人实在 有效的实践最好的最好的办法 ,肯能可行,就试用一下,因此从不肯能有些权威人士说什么最好的最好的办法 是“最好的”,就自动套用。别人的“最好的”最好的最好的办法 我说会成为你的团队的负担。

肯能你很关心功能的交付时间——有一五个 想法从概念到生产完成需要的时间——毁掉你这种 切的最好最好的最好的办法 好多好多 列个长长的任务清单。不幸的是,好多好多 公司仍旧按照大模块来计划、授权和执行软件开发项目,原来一现在结速回会一大堆待办事项,因此会保证排在上方的功能的交付时间绝对长得吓人。

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

结对编程一帮人爱一帮人恨。兄弟们,它好多好多 个工具,并回会个信仰。它应该用在适合的地方,因此没错,有些日后它时不时适合的。

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

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

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

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

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

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

Scrum 是并有的是过程管理最好的最好的办法 ,而回会软件开发最好的最好的办法 。Kanban 也一样。Scrum 和 Kanban 肯能缺少强硬的敏捷原则,最终只会回到瀑布模型。好多好多 企业开发环境中的几瓶待办事项(使用瀑布模型,而回会渐进发展模型)和“标准化”敏捷实践更会恶化你这种 大问题。

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

把机器当做牲畜,而回会宠物,使用 Ansible、Chef、Puppet 等工具实现基础架构自动化。启动测试,实施软件自动化,肯能离米 打开开关。补救基础架构大问题,把它作为代码库的一每段合并进去,并使用同类于 AWS 原来的自助服务平台。生产周期——从补救代码变更到产品发布所需时间——会被自动地大幅度缩短,肯能反馈周期变短,相应的理解时间也会缩短。理解时间加快会带来更频繁、更优质的软件交付。

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

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

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

本文转自 OneAPM 官方博客

假设我需要去寻找此前听说过的有一五个 隐秘湖泊。因此你带上拥有的所有物品,还是只带上你需要的东西,以便快速前行呢?几瓶的待办事项跟你这种 情况报告很像,你希望能尽快发现或验证功能价值,却在一现在结速就负担过重。

因此肯能你需要补救有一五个 很糙难的大问题,那就想尽一切最好的最好的办法 来补救。低保真度的模型或设计需要在故事的测试用例中通过大脑进行测试,因此不同的设计需要太快了 了 完成探索。你肯能回会想基于故事规模来规定你这种 活动的完成时间:举个例子,5分钟用于审查有一五个 一分值故事的基本流程和接触点,15分钟用于查看有一五个 两分值故事否有隐饱含多样化大问题,等等。

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

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