2025年精益求精――敏捷宣言的第五项价值？（共3篇）.docx

该【2025年精益求精――敏捷宣言的第五项价值？（共3篇） 】是由【lajie】上传分享，文档一共【16】页，该文档可以免费在线阅读，需要了解更多关于【2025年精益求精――敏捷宣言的第五项价值？（共3篇） 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。2025年精益求精――敏捷宣言的第五项价值？（共3篇）
篇1：精益求精――敏捷宣言的第五项价值？
人称“Bob大叔”的Robert Martin再次掀起了讨论“编程的职业水准”的声浪，他提出“敏捷宣言”应该加入第五项价值：“精益求精胜过言听计从”，
“Bob大叔”在多伦多举行的Agile大会上发表了主题演讲，他提议敏捷宣言应加入第五项价值：“精益求精胜过敷衍了事（Craftsmanship over Crap）”。他解释说，这项价值表明：在开发软件特别是在编写代码时，有精益求精的态度非常重要，这远胜过仅仅开发出可用但是见不得人的丑陋代码。
一周之后，Bob大叔找机会澄清了他的想法，并修正了自己在多伦多提出来的新价值：
我的提议的额外难题在于，它不是一个平衡的价值表述。其他四句表述中，我们同样认为后者有价值，不过我们更重视前者的价值。可在我提出的建议中，敷衍了事对于我们来说没有任何价值。 原来的提议更注重戏剧效果，所以我要把它改成：
精益求精胜过言听计从（Craftsmanship over Execution）
大多数软件开发团队都是言听计从，按命令办事，但是他们并没有真正投入到工作中去。我们重视言听计从，但是精益求精的态度更为宝贵。
许多人都回应了Bob大叔的文章，提出了他们对于被贬低的原有说法“敷衍了事”的修订，其中包括：（精益求精胜过）个人英雄主义、可用代码、唯工程化、奇技淫巧、险中求胜、效率优先、数量第一、辛苦劳作、缴械投降，甚至还有东拼西凑，
不久之前，Brian Marick提出了类似的建议，他认为：敏捷团队应该重视技能、修炼、灵性和快乐，并以此作为当前敏捷宣言的补充。多年来，在提到软件开发时，Pete McBreen一直用“craftsmanship”一词强调个人技能的重要性。Sean Hanly在文章《禅与软件开发的艺术》中提出 “质量更胜数量”，并论证了敏捷如何能够支持“精益求精”。这几年里，很多人都已经提出了类似的观点，虽然形式不同，但其本质都是认同“将软件作为一门手艺”这样的说法。
简短截说，敏捷软件开发越来越重视“程序员的职业水准”，这并不是什么全新的观念了。极限编程提出一系列技术实践，就是为了达到这个目的。Scrum强调“技术卓越性”，还有很多其他的例子。问题在于：为什么有那么多团队都做不到这一点？是不是太过隐晦了？为敏捷宣言加入第五条价值能使之显现出来么？它会不会造成不良影响？欢迎读者分享对于此话题的想法和意见。
查看英文原文：Craftsmanship - the Fifth Agile Manifesto Value
英文站读者Mike Bria认为：
真奇怪，这似乎一直没有受到多少关注。……不过这就是现状。我是说，这么长时间以来，这本应该是我们这个行业最重要的一个话题（真不幸），可似乎总是没什么人关注（更不幸）。结果，它就继续成为“我们面临的最严重的问题”了。由是观之，是先有鸡，还是先有蛋呢？ 来自：-fifth-craftsmanship
篇2：从敏捷宣言理解敏捷交互设计
敏捷交互设计是敏捷方法论向交互设计领域的延伸，它提倡让所有相关人参与到设计过程中，迭代演进式地进行交互设计，从开始，已经有越来越的团队在不同程度上使用敏捷交互设计的方法，而放弃了流程化的传统产品设计过程。
事实上，敏捷交互设计方法在很多方面都充分体现了敏捷价值观，因此，理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。
个体和交互胜过流程和工具
一个传统交互设计的流程一般分成以下几个步骤进行：
任务分析：任务分析基于功能列表（一般来自于客户的功能说明书）──在功能性需求的基础上拆分出人物流程和场景；
页面流程：根据任务分析的结果，为每一个大任务下的子任务中覆盖的功能制作页面流程；
信息建模：根据页面流程的设计出一套完整的信息框架，满足用户所有功能性需求；
原型设计：基于信息建模，设计出低保真原型，交给美工进行页面美化；
视觉设计：基于原型设计，对页面进行美化，最终产出高保真原型，同时编写设计说明；
在传统流程中，我们可以看到非常细致的分工──产品经理负责功能的拆解和分类，以及页面流转；交互设计师设计信息架构和具体交互行为；视觉设计师负责美化页面；前端开发人员负责高保真原型。
你是否体看见了传统瀑布式开发的影子？弊端显而易见：
分工造成的局限性──每个人都用自己的视角进行工作，无法形成统一的产品视角（Vision）；
分工造成的“不可评价性”──你没权利对产品经理的功能拆解有异义，因为你不是这方面的专家；
需求在传递中产生了失真的风险──需要靠大量文档进行记录；
客户没法说不──当客户需要到整个流程的最后看到一个或者两个大而全的设计方案时，他无法提出任何有价值的反馈，这本身就是用一个贵重的半成品绑架客户；
跟软件交付中的敏捷实践一样，敏捷交互设计倡导全功能团队，避免过于明显的分工，和基于分工特有的流程。仅有的流程是基于产品逐步清晰化的过程，而非基于人员的技能，所有人都应该参与到这个过程中来。敏捷交互设计主要分以下几个步骤：
寻找产品方向(Inspire)：抛开需求列表，从目标人群的期待体验出发，寻找可能存在的产品方向；
定位产品需求(Identify)：定位本产品需要提供什么样的消费者体验；
设计产品体验(Ideate)：对决定的目标体验进行设计；
验证产品设计(Implement)：快速制作原型，并频繁进行用户测试，迭代式改进。
图1. 从体验中寻找交付范围，把功能列表放在一边
除了流程简化和分工融合，在工具的选择上，敏捷交互设计也与传统方式有所不同──对于交互的推崇高于对特定工具的选择。
所有在敏捷交互设计中使用的工具，都应该遵循一条原则：它必须推动设计团队成员间的交互，而不是简单提升单个成员的工作效率。
基于此，敏捷交互设计中推崇各种轻量级工具，而不是大型的第三方软件，例如纸质原型Paper Protityping而非Visio或Axure此类原型工具。过于精细的结果往往会增加协作和反馈的门槛，虽然可能提升单个成员工作效率，却达不到鼓励交互的目的。
图2. 使用轻量级的工具进行交互设计
可工作的软件胜过完备的文档
敏捷软件交付过程中，每个迭代的核心产出是不足够完美，但却满足一个完整业务场景的软件──端到端流程的可完成，而不需要面面俱到的完美。
而传统开发方式中在长时间内只是各个功能模块中功能的堆砌，无法在短时间内实现端到端场景，那么文档便成为串联各个功能保证有序开发的必需品。
传统交互设计也存在这个问题。往往一个标准交互设计阶段的文档分三个方面，它们是：
内容方面(Content)：内容的层次和整体信息架构设计；
视觉方面(Visual)：整站风格的视觉设计文档；
交互方面(Interaction)：整站高保真交互设计原型；
仔细分析这些文档的生产过程，我们不难发现以下特点：
它们都是以整站为目标，试图覆盖所有使用场景；
它们的生产过程是线性的，直到三者全部完成才能够指导开发；
正因为每个环节的过程是孤立的，无法形成统一的认识，文档传递经常发生失真；
一个完美的东西很难得到产品方向性的关键反馈；
敏捷交互设计试图在解决以上问题。
敏捷交付的核心在于尽早地交付出可进行端到端测试的代码，而非完备文档，而敏捷交互设计的核心则在于尽早地交付出可以进行端到端可测试的原型，同样亦非完备文档。
而这里说的“端到端可测试的原型”包含以下含义：
端到端：必须设计出符合合理使用场景的端到端流程，这个流程会覆盖一个典型用户最核心的使用场景，所有的交互设计应该第一时间收敛在这个端到端场景周围，而非“整站”功能的分割展示；
可测试原型：不需要完美的原型，只需要所设计端到端场景中涉及到的原型，同时，原型的完备性上必须达到内容、视觉、交互三者细致力度一致，在测试中，三者力度的不一致往往会隐藏问题，例如，如果测试的原型视觉上过于完美，就会减弱用户在交互上的关注；
假设我们把交互设计的四周拆分成每周一个迭代，每周交付一个覆盖端到端场景，且在内容、视觉和交互方面都相对完备的原型收集反馈或进行测试，和传统项目相比，我们是否可以更早地得到客户反馈，是否可以让设计过程更透明，是否毋须完备的过程文档？答案自然是肯定的。
图3 逐步细化的原型，不停进行用户测试
当然，这样的过程必然需要多模块（这里的模块指技能的差别）之间的融合，实现全团队的运作。
你会问我，这是否意味着我们的交互设计师需要学会使用IIlustrtor进行视觉设计？或者视觉设计师需要学会HTML+CSS+jQuery制作高保真原型？
是的，在很多情况下，敏捷交互设计团队中的设计师确实需要具备多种功能的T型人才──他们有专业的技能，也可以在其他方面有足够的贡献。
分工的结果只能导致能力的停滞不前、产品视角的缺失、职能不可替代的风险、协作软的低效、沟通的浪费等等，而唯一的好处在于，可以更快和“更不被抱怨（如德鲁克说过程文档的价值在于管理抱怨）”产生一堆堆相互分裂且无法让客户挑错的文档。
客户协作胜过合同谈判
让我们举例说明在传统交互设计阶段出现的场景：一份标书、一份功能列表、一份到处使用的所谓用户体验调查问卷，在交互设计的开始阶段，我们和客户在一起进行“需求调研”，其实这些不重要，我们只需要对比我们之前的产品都有哪些功能可能有重复，类似产品有哪些可以借鉴，调研往往只是形式，关键还是未来的二至四周；
然后最后一次见客户也许就是最终文档提交的那天，给客户看一套精美的PSD文档，一般我们会做出A和B方案，其中不乏我们臆想出来的需求，有时只为让那个区域看起来不那么空，客户高兴地选择了其中的一套方案后，交付正式开始，
这就是基于合同进行设计的典型场景，谁也不知道合同中的功能列表意味着什么，而对于客户来说，它确实是购物单，真正交付时已忘记为什么需要。
但这不妨碍交互设计师进行设计，大部分时候他们并没有仔细思考这个功能真正的使用场景，而是把它“画”出来，让它看起来很美，却不管它如何实现和如何被用户使用。
这是基于合同进行设计自然而然的结果，在每个功能上，设计师都希望当成对自己的挑战，他们绞尽脑汁收集类似产品类似功能，尽可能取悦客户，说服他们采用更炫更丰富的交互方式，而作为不对交付负责的人他们毋须承担责任。
而敏捷交互设计希望打破这种基于合同或者换言之，基于功能列表的设计模式。它希望在设计的全过程将客户参与进来，让客户了解某个标书上的功能也许没有意义，或者不是当下应该解决的问题──一个交付项目范围的最好确定时机就是在交互设计过程中客户的全程参与。客户参与的优势有以下几点：
过程的透明化提升客户的安全感，随时保持对设计进度的了解；
最好的反馈模式就是让客户亲身参与设计过程；
了解最终用户和业务模式的是客户，客户是不可多得的资源；
当设计结果是功能列表的重新确认，对于合同中的内容便达成了新的共识；
客户参与的过程是建立信任的最佳机会，良好的信任关系应该在最开始就建立；
在产品设计方向上和客户达成一致，而不是仅靠标书或者访谈结果的支言片语；
提升参与感有助于培养更负责的客户，在交付阶段，之前的努力将会获得巨大的回报；
有效控制设计的变化，当客户亲身参与设计决定过程时，很多盲目的设计变化会减少很多；
图4 和客户一起进行设计
拥抱变化胜过遵循计划
当你的设计不能和客户一起进行，你只是个标书需求列表的简单执行者，需求的变化便是理所当然的事情。
在有些传统交互设计流程里甚至出现“需求冻结”这样的流程──如果你已经对某个环节的文档进行进行签收，就不能在“需求冻结”后改变主意。这样的结果无非两个：一尽量不要签收那个环节的文档；二在需求没有冻结的时候抓紧机会改变主意。