Li Wei: I asked Martin's first question: (Speak in english) I am a fans developed by agile software, especially extreme programming. I am also a hobby for interactive design and centered design. I think two ways to combine together can produce high quality software while very good to meet the needs of users. I have read an interview between Kent Beck and Alan Cooper in January 2002, there seems to have some conflicts between the two methodologia. I also read an article written by Thomas Technologies' Jeff Patton, who found some good ways to combine both methods. I told me some friends in THOUGHTWORKS that you are also trying to combine both. Can you introduce us this situation?
Martin: I can introduce this background situation in this regard. Since these years, I am interactive with many people with interaction design and centered design. They want to be able to capture the needs of the user and allow the system more attention to the user's use. Alan Cooper is an important member of this community (Community). One problem in this community is that they are in the work or in a submission, tend to assume that the process is placed in the most important position. This is unpredictable with agile ideas. This is also from Kent Beck and Alan Cooper's ideas, these two people mentioned in your questions, they have received an interview. It is worth mentioning that Jeff Patton has indeed made a lot of meaningful work in this regard, he is the employee of Thoughtworks US Company, and he makes interaction design to agile. However, Jeff is a very popular person, we arrange him with our customers, hoping that he can have good cooperation with our customers. But all ThoughWorks employees hope to give Jeff more time, let him complete his own work.
Guo Xiao: Jeff Patton mentioned by Li Wei was working in Thomas Technologies, and now I have worked in Thoughtworks.
Martin: He has worked for ThoughtWorks for a year or more. I can't talk about things here. But if you want to complain about why Jeff is not coming out, you can go to "blame" Markku (the Global Chief Executive Officer of Thoughtworks) and ask him. I think these are valuable. I think it is very important to interact design, we find it very worth trying, I hope knowledge spreads quickly. Unfortunately, writing a book requires a lot of hardships.
Li Wei: I just listened to Martin, just a core concept of agile development methods was to pay attention to people itself. I have a relatively deep understanding of this in the process of learning agile development methods in these years. I now want to ask Martin a question about people's own: No overtime every 8 hours, just a very ideal situation, but there is a lot of overtime in many companies. There is a nearest example is Hu Xinyu, Huaxin, who fell in his own job, because of excessive overtime. Many years ago, I am also an employee of Huawei. I feel very sad about this matter. I know that there is a class of overtime work in many companies in China. Overtime is a trick to achieve promotion, representing this employee The loyalty of the company, and in fact, in many companies, this overtime work is actually a semi-forced nature, and I also know that most developers hate this development. It is no problem in short-term overtime, but long-term problems will bring a lot. I want to ask Martin how to see this problem? How to control overtime in Thoughtworks?
Martin: This is indeed a very important issue. This issue makes me very troublesome when I participated in Netscape at the end of my century. I am involved in some work of the team. The time they started to work is 10 o'clock to 11 o'clock, this is not good forecast, but they work very late, sometimes they are two or three in the morning. Sometimes we need to open a meeting in the afternoon, starting to have a good job a day. Therefore, those work in the early hours of the early hours of work are usually more complex, making a lot of errors. This is not able to improve teamwork efficiency. Another situation is that they don't work in ways to tell them by Manager, but work with what they want, thus ignoring their factors that they make mistakes. Software is a complex project, which requires you to consider a lot, so when you don't have a lot of work, there will be many problems, often take a lot of time to solve these problems. So when you are tired, don't continue to work. Because this will have a negative impact on the entire team and the project. There is also a biggest problem, the project manager has not written code, or a very good developer, they don't realize this problem, think more of the work hours mean more effects. But this is the problem that should be realized. For example, when you take the plane, I was told that the pilot had worked for 12 hours, you should not be happy. The truth here is the same. Although there is no strict law stipulate that it cannot be timed, this rule should be connected. When working in fatigue, work productivity will drop. Working 10 hours or more is unfavorable to the project. Because you have created more trouble in your project. When you feel fatigue, you need to relax. Don't join the scribbled code in the code. I think so. Bear Day: There is another problem with additional agile methods. Can agile methods in a large-scale team, such as a team of hundreds of teams and distributed teams, is located in the projects such as different local development teams?
Martin: We use agility methods in hundreds of projects, and some distributed development, such as in different continents, is there an effect? This depends on how you define it for Work. Is everyone's own productivity or a team overall effect? I do not know. However, in the software field, the rule is that it is uneconomy, meaning your project, the greater the team, the lower your work efficiency, because there is a problem with communication here. So when your team expands twice, it does not mean that your work efficiency is twice. This may only have approximately 1.5 times. When you encounter some stress, you must improve efficiency, you may have to achieve it. When you need to end a two-year engineering in eight months, the only thing you can do is to increase the scale of the team, this is not an efficient method, nor is it what we are willing to see. But this is the only way. The same phenomenon appears in a distributed team. When you go to Thoughtworks Indian branch, they work in a distributed manner. They will tell you that this team's efficiency will greatly improve. But there is another problem, which is communication between the United States and India team. From another meaning, agility can be given to hundreds of people, distributed teams bring high production efficiency, bring valuable work, and I can answer. We have successful experience hundreds of success, these prove we can do it. Compared with the traditional Feature Driven, I think we have an advantage. There is another problem in the software, it is difficult to measure an output. We do have a lot of projects, and this is one of our agile ideas. So my answer is yes.
