The fourth agile China conference

After all, the plane must fly high. Are you ready?

The effectiveness of agile, the fourth agile conference is extraordinary, the price of thousands of yuan can not withstand the huge expenditure, but also can not block people's curiosity and desire to learn. To be honest, I have heard too much new things, whether it's beautiful stories, miserable stories, or confused stories. But it does not hinder my interest. I have no intention of finding the answer to these stories. Although I have asked many questions, I have also been asked many questions. But for most of the questions, I know there is no answer. Although I made a struggle, my heart had long been defeated.

Didn't Brooks say it long ago? -- No silver bullet.

for example, how to measure performance? Agility makes it difficult to measure performance. Many people think this way, but what is the comparison between "comparing with what" (Kent Beck. Of course it is cmx! Then how is CMMS measured? Code ? Reliable? Test Coverage? Circle complexity? Can't I use it if I am agile? Is there a good way to measure developers' performance in this world? Yes? Is it easy to use CMMS? Ask yourself, if you are a Manager, do you want to score a score in your heart and then calculate the score of each person? If you are a developer, do you really think the number of lines of code can reflect a person's level? Or is your subjective judgment more reliable? If you are a tester, are you tired of measuring performance by discovering the number of bugs (by the way, express your solemn contempt for the leaders who use this performance evaluation ). Who should d be on this year's head, or the new guy? Don't tell me that you didn't get "D" when you were a new recruit. If your job is performance evaluation, are you struggling? What kind of indicators should you use? Are you confident that the indicators you define are fair enough? Are you sure that the data you see is not "made? By the way, which of the project managers have not "done" data? What tests are never used to test the coverage rate? In order to catch up with the Failover period, the test department should be warned to merge defects as easily as possible? Is it appropriate that the extraction function is not analyzed at the same time for the division of the circle complexity? Is it because I happen to have met these extreme examples? What should I do? Agile, isn't there a way? I don't know. Ask yourself, what am I doing? Why should I measure it? Can I do more in line with my goals? That's all. You can never be fair, especially in the software industry. In general, the software industry is still a craftsman-style industry, and development is still a craft. If you want any easy indicator to easily lead to "partial optimization", any truly valuable indicator is not that easy to quantify. In Agile development, the common indicator for measuring the development capability of a team is velocity. However, this indicator seems to be quantifiable and can only be used to measure the progress of a team. It does not have any significance for horizontal comparison. To improve velocity, the simplest way is to multiply the number of points in each story by 2. Do you want to convert the number of adult days? You will get a very interesting comparison, that is, the average workload of each person in Team A per week is 5 person-days, which happens to be equal to the average of Team B. (This is very similar to the total number of BITs in a World Cup and the total number of bits out of bits in a World Cup .)

Therefore, we suggest that these indicators can only be measured and cannot be managed, and they are for feedback rather than performance. In agile teams, we have many indicators and many measures. For example, check the number of lines of code, test coverage, and lap complexity. We use these indicators to help us analyze the status of our team. For example, if the test coverage rate drops, let's look at why unit testing cannot cover certain scenarios. Do we need to enhance integration testing and system testing to ensure system quality; for example, if the complexity of the circle increases, we will consider whether refactoring has not been done frequently recently. We do not need to set aside time for restructuring. When these indicators become a feedback method, we do not need to "do" any data. The red light and green light of Ci are our friends. (These ideas belong to the "trust-based" management method. For more information about the challenges and responses to these ideas, see the article by Guang Lei ).

= Randomly divided into segments, because the jump is too large =

In the TDD scenario in the afternoon, I came to a student who was doing SQA (I cannot remember) and pointed out that we were mistaken. Our method name does not comply with a Java "Specification", the test name does not comply with the "requirements" of the tool, and there is no comment. All in all-A mess. I can see his kindness, but there is really no chance to explain it to others, so I started to demonstrate his TDD. I tried to explain to him why the method is named like this, why the test class cannot correspond to the tested class, and why we "basically opposed the annotation. However, the final result is "fail ".

It is very important to be agile and open-minded. Today, we are looking at git.Source codeWe found that Linus is using the "Ruby naming convention" to name C functions (suchInt diff_tree_stdin (char * line)). I regret not being able to catch Linus and talk to that classmate :)

In the afternoon, I talked to my colleagues in a company about the test layering problem. Another student entered that their test was difficult to define the boundary value. I told him that this problem is orthogonal to the test hierarchy. That is to say, no matter what layering method is used, the problem always exists. Orthogonal is not strict here. We may solve this problem through some test layering scheme. For example, the boundary value may be easily determined in lower-layer tests. However, basically, the original problem still exists. However, this question is a test question, but it is another topic. Maybe it's a design issue-Kent Beck responsive design.

There are many problems in software development that can be solved without one practice, and there are still some problems that cannot be solved by every existing practice. At this time, the problems behind tracing are very important. I have met some teams. A single team cannot deliver any features, or even its own code compilation fails. It must work with other teams to compile and verify the code. What should I do if I encounter such a problem?

This may be an organizational or design issue. But from what perspective do we see many teams choose to solve it? Configuration Management, test framework, and process management. I will introduce them one by one:

Configuration Management: Since you must be with others to compile, otherwise you will be put on a branch to access each other's code.

Test Framework: Since you cannot compile it yourself, can I drop your dependency mock or stub? In this way, you can compile and verify a mock framework or some stub code.

Process Management: We can also specify the number of points that a team must submit before compiling.

Are these methods good? As an advocate of "responsive improvement" (to pay tribute to "responsive design"), I won't say yes or not. I just want you to ask yourself: does this kind of choice meet your "zhenbei principles" (refer to 7 Habits of successful people). Have you analyzed the cost and benefits of improvement from the perspective of design or organization? Is your choice a balance between long-term benefits and short-term benefits? If you still choose to use these "indirect methods" for improvement after analyzing all the reasons, then there is no problem with your choice.

"Do not consider solving the problem as the problem to be solved," he said.

Even if we chose the above method to solve our problems, we should always remember what problems we want to solve in our hearts, in addition, when we try to solve this problem again in the same way next time, we need to ask ourselves, "is the background the same as we did in the last decision ". Let's make another choice that conforms to the "zhenbei principle", rather than simply choosing the previous solution.

==== Split it again ====

I had the honor to have lunch with Kent Beck at noon yesterday. I asked him if the responsive design was a regression from the XP design. Or is responsive design a form or idea between traditional design and extreme programming style design (such as TDD? (Original statement: is responsive design a step back from XP style design? I mean on the road that we transform from traditional design to XP style design. Is responsive design somewhere between the two styles of design ?).

I didn't expect an amazing answer, because I do think traditional design is too conservative, eXtreme Programming is too radical, and responsive design is a compromise or regression of some form. But Kent Beck thought for a while and said, instead of turning back, he went further. Extreme Programming recommends that design decisions be postponed to the point where features are implemented, while responsive programming delays. You need to determine whether the context determines the design or design. (Based on my understanding, I don't know if it is Kent Beck's intention .)

=== I think of Dave's broken window theory. I will continue to write it tomorrow.