
闲话Agile
刚刚过去的周末参加了Scrum中文网的Scott Wang和Eric Liao两位老师的SAFe培训。
注:培训很赞,理论清晰/实践活泼
参加培训的8名学员中有4名是汽车行业的,分别来自整车厂、Tier 1、自动驾驶、ASPICE和汽车功能安全顾问(本文作者)。充分感受到汽车电子/软件领域,有越来越多的关于Agile的需要,并且已经有了很多的应用和实践。
这次培训引发的一些思考,零零散散的记录如下:
ASPICE和Agile的关系
上课期间,有学员问,如何看待ASPICE和Agile。
Scott Wang分享了如下的PPT,说明了处于“What层面的ASPICE”和“处于How层面的Agile方法”之间的关系。(注:Scott Wang老师具备ASPICE Assessor资质)
关于两者关系,可以参考如下文章:
Eric Liao看了这页PPT后,沉吟了一下之后说,这页PPT一定是ASPICE领域的人做的,虽然是对的,但看起来不太爽。
(可能是因为ASPICE被放在了上面,Agile被放在了下面,看起来Agile是为ASPICE来服务的)
Eric Liao认为,企业/项目在使用Agile方法时,可以把ASPICE看成需要Compliance的合规要求就好了。(这个观点也很赞)
关于Agile和ASPICE之间的关系,大家分享了各自的想法,虽然不完全一致,但普遍达成的共识是:二者不矛盾,可以互相拥抱。
项目活动,都是“人”在做,人不是机器,不是产线工人,人是知识工作者...
项目外部环境、客户需求等在持续变化...
…….
基于如上的这些因素,Agile宣言以及满足Agile宣言的Agile实践方法应运而生。
敏捷实践是方法层面的,采用这些方法的目的,是为了“效率、效果、价值”。
因此,笔者认为,可以把ASPICE与Agile之间的关系,调整成如下的图:
Agile宣言
SAFe是基于Lean和Agile的一个规模化敏捷框架,SAFe官网上有对Agile宣言的解读,摘录如下,供读者品味和参考。
原文网址:
https://community.scaledagile.com/apex/scormanywhere__SCORM_Player?courseId=a1a6T00000DNaWF
The final phrase of the manifesto is important and sometimes overlooked.
It is possible to misinterpret the value statements as a binary decision between two choices (for example, working software versus comprehensive documentation), but that’s not the intended meaning. Both items have value; however, the item on the left has more value (such as working software). The Agile Manifesto is not rigid or dogmatic. Instead, it embraces the need to balance the values based on the context.
笔者批注:左边和右边都有价值,需要根据上下文平衡价值的必要性。
Individuals and interactions over processes and tools
Agile processes in frameworks like Scrum, Kanban, and SAFe do matter, but a process is only a means to an end. When you’re captive to a process that isn’t working, it creates waste and delays. So, favor individuals and interactions, and then modify processes accordingly.
In a distributed environment, tools are critically important to assist with communication and collaboration (e.g., video conferencing, text messaging, and wikis). This is especially true at scale. However, tools should supplement, rather than replace, face-to-face communication.
笔者批注:为了提高过程/工具的效果,更要关注参与其中的,作为知识工作者的“人”。
Working software over comprehensive documentation
Documentation is important and has value. But creating documents for the sake of complying with outdated corporate governance has no value. As part of a change program, governance (often captured by documentation standards) must be updated to reflect the Lean-Agile way of working. Rather than create detailed documentation too early — especially the wrong kind — it’s more valuable to show Customers working software to get their feedback. Therefore, favor working software and document only what’s truly needed.
笔者批注:展示项目进展的最关键的是“Working的项目产品(软件)”,真正被需要的文档需要在恰当的时机被建立和维护。
Customer collaboration over contract negotiation
Customers are the ultimate deciders of value, so their close collaboration is essential in the development process. To convey the rights, responsibilities, and economic concerns of each party, contracts are often necessary — but recognize that contracts can over-regulate what to do and how to do it.
No matter how well they’re written, they don't replace regular communication, collaboration, and trust. Win–lose contracts usually result in poorer economic outcomes and distrust, creating short-term relationships instead of long-term business partnerships. Instead, contracts should be a win-win proposition that favor Customer collaboration.
笔者批注:了解客户,与客户进行协作,共同提高客户所使用的产品和服务的价值。
Responding to change over following a plan
Change is a reality that the development process has to reflect. The strength of Lean-Agile development is in how it embraces change. As the system evolves, so does the understanding of the problem and the Solution domain. Business stakeholder knowledge also improves over time, and Customer needs evolve as well. Indeed, those changes in understanding add value to our system.
笔者批注:变化是一定会存在的,接受变化,处理变化,提高“价值”。
文章转载自公众号:仨人谈起
