Agile Pyramid
The knowledge domain contained in agile can be summarized as a pyramid structure. The bottom of the pyramid, that is, the foundation of everything, is the core values of agile, which is the famous "Agile Manifesto". The middle supporting part is the 12 principles of agile. The top layer is the various practices and methods of agile. We are going to interpret the Agile Manifesto and 12 principles today.
Agile Manifesto
First of all, it needs to be explained that the agile manifesto is not the starting point of agile. Before the agile manifesto was drafted, various agile genres existed, and before the concept of “agile” appeared, methods like scrum and XP were called “lightweight” "Methods, we won’t go into details about the history of agile. In short, on February 11, 2001, 17 senior experts in the agile field gathered at Snowbird Ski Resort in Utah, USA. The guys are not sure whether this gathering will have a result, or they still hold the mentality of Huashan's sword, but the final result is that they jointly drafted an agile manifesto and the 12 principles behind it.
Speaking of the Agile Manifesto, many people are discussing the middle four sentences, and today we will start from the real first sentence, because if you only look at the middle four sentences, you may gradually come to a fork.
The true first sentence: "We have been exploring better software development methods in practice, and helping others while doing our best. From this we have established the following values: " This sentence can give us two messages. First, Agile is not A perfect methodology is not the bible of project management. We must maintain a mindset of exploration. We must continue to pursue a better state. The pursuit method is not to read more books and learn more about a few knowledge points, but to practice. , Only by practicing can you understand the essence of Agile and understand how various methods and practices interpret the spirit of Agile.
The second sentence: "Individuals and activities are higher than processes and tools." Are processes and tools important? The answer is definitely important. Processes and tools can help us do things faster and easier, and can bring us a lot of convenience, but processes and tools are only to assist us. Perhaps processes and tools can help us achieve a passing score. But if you want a high score, it's definitely not possible to rely on processes and tools alone. In the final analysis, it depends on people, each individual, and an excellent team. Therefore, the Agile Manifesto advocates focusing on the interaction between individuals and individuals and teams, face-to-face communication, continuous adjustment, respect and team co-creation.
The third sentence: "Working software is higher than detailed documentation." Is the documentation important? The necessary documents are of course important. Documents can help us record a lot of things. They are our knowledge base, but unnecessary documents are a waste of time and energy. For example, print out the requirements specifications that need to be packed in a small cart (the author personally Experience), does anyone really read such documents? Has anyone really finished it? If so, please contact me, I am curious about you. Therefore, the value of a product must be measured by the product itself. The so-called workability is not about being able to start and being free of bugs, but to help customers solve problems.
The fourth sentence: "Customer cooperation is higher than contract negotiation." Contract negotiation must be something we don't want to see, but what is real customer cooperation? Are we striving to meet customer requirements? Or do we find ways to get customers to pay? The author thinks that since cooperation is a win-win and win-win situation, a win-win situation is not a unilateral effort. It is everyone working together to achieve a common goal. Therefore, agility is not unilateral. In many cases, there is only the agility of the R&D team, and the customers and related parties Staying out of the way, and making agile fail to work.
The fifth sentence: "Responding to changes is higher than following the plan." Following the plan is a very distinctive feature in traditional project management. In the previous article, we also talked about that if you want to change in a traditional project, you need to follow the CCB, and there will be A large percentage of them are rejected in the end, so we return to the starting point. Why do customers change? Of course, we do not deny that there will be changes caused by the ability of customers or product owners, but more are caused by market changes and environmental changes, so changes mean that we are one step closer to the real goal, so we must Embracing change, embracing change is embracing opportunity, an opportunity to better cooperate with customers, and an opportunity to build better products.
note! There is another sentence: "That is to say, although the right item has its value, we pay more attention to the value of the left item." So agile has never denied the importance of processes, tools, documents, and plans. The content on the left is not a substitute The content on the right, in practice, many companies start to abandon plans, do not write documents, and change at will when they implement agile. In the final analysis, you are already wrong from the root, and your compass is not pointing to the south at all!
Agile 12 principles
Agile has 12 principles. If the core values of Agile are the roots of the tree, then the 12 principles are the branches of the tree!
1- Our highest goal is to satisfy customers by delivering valuable software as early as possible and continuously;
2- We welcome changes to requirements, even in the later stages of project development, we must be good at using demand changes to help customers gain a competitive advantage;
3- Required Continuously deliver available software, the cycle ranges from a few weeks to a few months, the shorter the better;
4- During the project process, business personnel and developers must be together;
5- Be good at motivating project personnel and give them what they need Environment and support, and believe that they can complete the task;
6- Whether it is within or between teams, the most effective method of communication is face-to-face conversation;
7- Available software is the main indicator for measuring progress;
8- Agile process advocates Continuous development, project parties, developers and users should be able to maintain a constant and stable rate of progress;
9- Refinement of technology and continuous improvement of design will improve agility;
10- To be concise and minimize unnecessary Work, this is an art;
11-The best structure, requirements and design come from a self-organizing team;
12-The team should regularly reflect on how to be more effective and adjust the team's behavior accordingly;
1- Our highest goal is to satisfy customers by delivering valuable software as early as possible and continuously; there was a statistic that for a software product, users always use only 7% of the functions and 13% of them are frequently used. Of course About 16% are occasionally used, but most of the functions are not used. This is also in line with the 80/20 principle. 20% of the product's functions have met 80% of customers' needs, so we must deliver as soon as possible This 20% function means that I want to sort out the MVP, put it into the market quickly, and the output of value must be continuous. From the perspective of the project, there will be an end point. From the perspective of the product, we hope to continue, as long as the product is still The work of continuous improvement will not stop.
2-欢迎对需求提出变更，即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；即使在项目开发后期，这句是很重要的，变更是要经过评估，也是要谨慎的，但是如果有必要，即使在开发后期，我们仍然期望发生改变，因为一直错下去，即使到了终点也没有意义。就像导弹发射，明知道目标错了，击中又有什么意义，而敏捷就是巡航导弹，永远跟随正确的目标前进。
3-要不断交付可用的软件，周期从几周到几个月不等，越短越好；敏捷期望交付周期是短的，在scrum中会推荐1-4周的迭代，足够短就可以足够快的获得反馈，研发过程是要遵循PDCA循环的，需要不断调整才能越来越好。
4-项目过程中，业务人员与开发人员必须在一起；很多企业的现状是，业务人员整理好需求，组织一个评审会，把需求简要澄清后，就算交接完工作了，接下来再想找到业务人员就很难了，不是在忙就是马上要忙，问多了会提醒你一句文档里不是都写了吗？你仔细看看。我们暂且不说文档到底能不能覆盖全部的需求，即使文档是正确的，研发人员能够做到100%理解吗？所以最有效的方式一定是面对面的沟通，哪怕吵一架，也比闭门造车来的痛快！
5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务；我们说过一切的基础是人和团队，敏捷推崇尊重的文化，我们要给团队提供环境同时也要相信每个人有能力做到自己承诺的事情，而每个人也应该有勇气对任务作出承诺，对困难发起挑战。
6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈；今年年初，因为疫情的原因，很多公司采用远程办公的模式，本来大家都觉得在家里办公应该是很爽的事情，但是结果却发现一言难尽。即使有各种远程协助工具的支持，大家依然期盼着早日能够回到公司上班，正所谓：“远程办公苦不苦，你自己心里最清楚 ！”。
7-可用的软件是衡量进度的主要指标；不知道大家有没有类似的经历，笔者在大学时期，喜欢用迅雷下载电影观赏，当时宿舍的网络是公用的，为了不影响别人下载是要限速的，或者是趁别人不用时抓紧下载，总之，下载个电影一波三折，有时当你马上下载好了，已经准备好好欣赏了，发现进度停在了99.9%的位置，用尽各种办法都无果，这时候笔者的情绪充满失望、愤怒和无奈，甚至会直接卸载掉软件（过后再重新安装回来），这种感觉就像研发花了几个月的时间交付给客户一个不能用的产品，研发觉得付出了很多努力，但是对客户来说什么都没有得到，0和99.9没有区别。
8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度； 关于这一条原则，后续介绍XP(ExtremeProgramming)极限编程的时候，也会有所体现，XP中提出40小时工作制，就是每周五天，每天8小时。敏捷是不提倡加班的，因为这个过程应该像长跑，要可持续，不是冲刺一两个迭代就结束了，但是很多人会说我们上了敏捷后加班更严重了，这个因素很多，后续也会聊这个话题，但是在这里我们应该知道敏捷提倡恒定的速度，加班解决不了根本的问题。
9-对技术的精益求精以及对设计的不断完善将提升敏捷性；敏捷是提倡拥抱变更的，如果想要变更除了产品和人员的适应性外，一定要有良好的技术支撑，大到企业级的架构设计，小到一个方法的设计模式都是对技术精益求精需要关注的内容，而在XP中，提倡频繁进行重构，重构本身也是对设计和技术的持续改进。总之，技术和设计的打磨是敏捷灵活性的基础保障。
10- It is an art to be concise and reduce unnecessary work as much as possible; this principle is very consistent with the elimination of waste advocated by lean theory. Lean production points out 7 kinds of waste in the production process. The same applies in development, such as: additional features, partially completed work, unnecessary steps, context switching, software defects, waiting, and work handover. These are all wastes that we should try to avoid.
11-The best architecture, requirements and design come from self-organizing teams; self-organization is a typical feature of agile teams, but self-organization is a very difficult state to achieve. To self-organize not only the team has a sense of responsibility, but also More arouse everyone’s interest, such as: grandpa and aunt who dance square dance, everyone likes to do the same thing, no one needs to hold a whip to draw, and start dancing spontaneously when the time is up. This is self-organization, wanting to self-organize , There is also a necessary prerequisite that the team must be stable enough. The Tuckerman model says that the team will go through multiple stages from formation to maturity and finally dissolution. If the team is unstable, it may only go back and forth between the shock and stability stages. How can it be possible to achieve a state of self-organization while pacing?
12-The team should regularly reflect on how it can be more effective and adjust the team’s behavior accordingly; the team’s self-examination and adjustment are very important agile practices. When we introduce scrum, we will focus on how the team passes the daily stand-up. Pursue continuous improvement with retrospective meetings; “learn from doubts and live by happiness”, reflection will always be rewarded. When many companies are doing agile transformation, scrum is implemented, but agile retrospectives have become a must. At the meeting, I think such a state, "pseudo-agile" is not counted, it can only be called "every 疌".
Stop here
In this article, we talked about the core values and 12 principles of agile. I believe that everyone has a basic knowledge and understanding of agile. Before I start to introduce agile practices, I hope to talk with you about the scope of agile. Agile is not a panacea. , Agile is not a silver bullet. In what environment is Agile most effective? Does agile only apply to software development? See you next article!
