Agile thinking there is a principle to guide our process improvement: At regular intervals, the team will reflect on how to work more effectively, and accordingly adjust their behavior. Because many uncertainties plan will lead to failure, such as project members increase or decrease the effect of technology, changing customer needs, the impact of our competitors so we will react differently. Agility is not based on a predefined way of working, but on empirical (Empirical) the way of these changes, agile team to maintain the agility teams through constant introspection adjustment. Agile provides us with process improvement related engineering practices, work processes and tools.
1. Agile process improvement practices
And heavyweight solutions offered by different CMMI, agile methods provide an improved process for many simple yet practical engineering practice for us, Here are four reference:
(1) Five Whys
5 Why is a more respected field of agile process improvement practices, the principle is very simple but really effective. Why so-called, that is, to a problem with five consecutive "why" from ask to pursue its root causes. Of course, knowledge. A virtual number number 5 here, only five times why the discussion is not limited to the use, mainly to be found until the root cause. Why five key solution to the problem is to encourage people to proceed from the results along the chain of causation, until the root cause of the original problem (as shown below).
(2) learning matrix
Learning matrix is relatively less, but in some scenes is what we can use to be an effective tool for brainstorming. Below the figure for distributed team development under the collaboration, we first summarize doing well and doing a good aspect, and then see if there are new ideas, if it is not, we can also look at whom to help, these procedural outcomes can be refined and clear through a similar learning matrix.
(3) Brainstorm
Brainstorming (Brain Storming) is active for triggering inspiration we often use, here is a simple UI interface between demand and matching team members brainstorm, through discussion we made an improvement to the workflow:
| Developers: Now that the relatively short development cycle, product manager needs to convene a review meeting in the absence of fully disentangled product demand, resulting in many problems late in the development process, rework the phenomenon is more serious. Technical manager: We can carry out the second review, that is to say before the formal needs assessment for all developers, you can find the first part of the technical representative of the first review, and then after the first issue of the existence of demand for revision by the First Review everyone called open a second review Product Manager: I am here that the technical director after the preliminary product out before and after the end of the first touch will find under Project Manager: Well, the next version we reviewed on the introduction of secondary flow |
(4) Affinity methods and
Affinity diagram (KJ method / Affinity Diagram), the large number of facts collected, comments or ideas language information, according to their mutual affinity collate data (proximity) induction, clear up the problem, and seek common understanding coordination, a way to facilitate problem solving. It is a form of affinity diagram in the figure below, the idea raised by members of the team from "remain", "stop" 'and "try" those three types are classified.
2. Agile process improvement tool
Agile various methods, there are some tools that can be used to help us implement process improvement:
(1) and the combustion FIG burndown
Burndown (Burndown Chart) and FIG combustion (Burnup Chart) from Scrum, a specialized tool for process monitoring execution Sprint. Burndown Chart (see figure a) Follow the remaining functions, and Burnup Chart (see figure b) Follow the function has been completed. FIG Burnup Chart we add the curve (lower curve lies below in FIG b) in an abnormal situation, is largely due to this abnormality can be seen that the use of Water-Scrum-Fall mode, the Sprint within the first half of the time, the team did not yield any deliverable resulting in insufficient force the second half.
(2) Value Stream
价值流图来源于TPS，TPS 的核心思想是，工作流中有以下三种制造约束的浪费必须要消除掉。你不得不做的事情中，有没有哪些是无用的或多余的？这类事情就属于徒劳，就是你不得不做，却不创造价值的事情。有没有一些时候，你只是闲坐着不能开工，焦急地等待某人给你答复？这就是不均衡，工作总是一阵多一阵少。是不是还有些时候，你不得不加班加点，因为你被要求完成比你所能承受的大得多的工作量？这就是超负荷，被要求做到不合理或不可能的事情。价值流图的作用就是通过可视化的效果让我们能够发现这些问题，从而通过拉动式系统等方式解决这些问题以达到持续改进的目的。关于价值流图的详细讨论可以参考《精益之识别和消除研发过程中浪费的思路和模式》一文中的内容。
（3）累积流量图
管道理论的一大话题是我们需要测量并管理管道中的流量，而在看板方法中，累积流量图（Cumulative Flow Diagram，CFD）为我们提供了这方面支持。下图就是一张累计流图示例，可以看到测试所对应的条带在变宽，这就告诉我们测试可能正在成为整个工作流中的一项瓶颈。图中还可以添加一些额外的线，用来表示平均到达速度（Arrival Rate，每天新增的工作项的数目）和平均工作存量（Inventory，工作流中工作项的总数），并展示平均交付时间（Lead Time，每个工作项在系统中存在的时间）。
使用CFD 管理系统流量的关键在于寻找那些能够表明存在问题的特征。看板可以告诉你今天你的工作流中哪里存在不均衡，并且帮助你通过添加在制品上限的方法来管理每一天的工作流。而CFD 的作用则是让你能够看到“在一个时间段内，你的整个流程的表现如何”，这样你就可以采取措施来找出并修复那些长期的问题。
结合上述限制在制品上限的方法，就可以通过CFD实验在制品上限的值并管理系统流量。一个软件开发的过程一开始可能处于不稳定的状态，通过对开发、测试等各个环节设置不同的在制品上限值，并观察对应的平均交付时间，找到基于现有资源的最合适的在制品上限值组合，确保开发过程的稳定性。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
