First week of LA work experience

Working with a group of foreign Dev teams is an experience I have never had before. In a strange country, a strange team, a strange customer, and a strange project, for me, everything is new. Here, we still adopt typical agile approaches: story walls, websites, user stories, Pair programming, continuous integration, TDD, and even BDD ...... We use almost all agile practices. When I joined this project, I had already performed 7th iterations, and the entire project framework was quite mature. Our task is to get familiar with the business and the entire technical framework as soon as possible and make full preparations for the new project. In nearly three weeks, we will conduct Pair with our customers and our colleagues in Thoughtworks to familiarize ourselves with and understand the business and technology through actual development. Then, we will launch an Inception for the new project in the remaining two weeks.

The project is developed based on. NET Framework 4.0. The technologies used include C #, VB. NET, Ext Js, and SQL Server 2008. The IoC container is Structure Map, NUnit is used as the unit test framework, and Moq is used as the Mock test framework. We use Jenkins (Hudson) as a continuous integration tool, Thoughtworks's Twist as a regression and integration testing tool, and Powershell as a build script, git is used as the source code control tool.

The first week of LA. In addition to taking part in the Meeting several times on the first day and understanding the overall project situation, especially the business logic, the next day, I quickly entered the team and started Pair programming. Throughout the first week, I completed two Bug fixes, fixed the problems in Regression Test, and participated in the development of a Story. In this week, I have not switched Pair. I have been working with a Dev (Andrew) on the client side.

Looking back at my work this week, I feel as follows:

1) understanding of business logic is more important than Technology

As a Dev, I may first think about the technologies used by the project. Do I know about these technologies? In short, we will first focus on everything related to technology. Before entering the project, I paid special attention to this content and made every effort to reserve these technologies. Of course, we also want to understand the business logic, but due to the lack of such conditions in preparation, we can understand that the project is related to Healthcare, and the project content is somewhat close to CMS. However, after the project, we discovered that technology is not the key to deciding whether you can quickly enter the team and start development and implementation. If you do not understand the business logic or define domain terms, it will be difficult for us to communicate and communicate. Especially for the current project, because the project has been made part. Understanding the field is even more important. For a Dev with many years of experience, technology will not become the main bottleneck restricting your project development. In this project, there are a lot of technologies that I don't know, but we can still quickly enter the development activities. This is because Pair Programming can well complete knowledge sharing and delivery, and my Pair can quickly bring me into the status like a Mentor.

2) communication is the foundation of project development

Communication in domestic projects may also become an obstacle. However, due to the same language, we often ignore communication activities. It seems that this is a natural thing. During my work this week, I seem to have entered another world where my ears are filled with languages that I cannot understand. Although I have a certain degree of Basic English, I found that the English words and syntaxes I have mastered were not enough only when I was working with Dev whose mother tongue is English. My tongue seems knotted too. It's hard for me to understand what Pair is trying to say, and it's hard for me to express my opinion to Pair. This results in a great impact on the development efficiency. Even if the task has been completed, the entire implementation still seems to be false to me. You need to take a look at the description of Story and the source code. For example, we have implemented a better Validation mechanism in our project, but in order to implement a relatively small Story, our implementation is severely hindered due to communication problems.

In addition, our project is fully qualified for field customers, so communication is a top priority. Our BA team has both TW and customer teams. They all wrote a good User Story. If we do not understand the implementation of these User Story, we need to consult BA as soon as possible to eliminate ambiguity through communication. After implementation, we must perform Show Case with BA to get feedback as soon as possible. This is very important and is also the embodiment of agile core values.

3) good habits are very important.

In week 1, Andrew from Pair and I were an intern from a customer. He just graduated from college and entered the project for about three months. During his college career, he only learned C ++ and was not familiar with. NET, Javascript, and CI. In other words, all the technologies he has mastered are learned by the project. Although it is such an Intern, I found that he already has a very good coding quality. When starting a Story, he first writes Regrssion Test Sceinario in Twist. While implementing the code, we will also try to implement it through the Unit Test driver. The Git command will be used properly when code is submitted. For example, before development, check the current Status through Git Status to see if there is any change. In Commit, if the submitted content is found to be in conflict, he will handle Merge very carefully. When writing code, we strictly follow the coding rules we have developed. Although his development experience is still lacking, there is no doubt a good start. I think that with the help of Thoughtworkers, if he is willing to continue to work hard, there should be a good development prospect.

At the same time, for the team, such a good coding habit is like the so-called "Boy Scouts military rules" that generally affect everyone in this team. We will have fewer Technical Debt owed, this will be of great help for later maintenance, modification, and future development.

4) Learn to seek help

Everyone has limited knowledge. Maybe you are capable enough to solve any problem, but considering the cost, if you can seek help as appropriate, you can quickly complete the task and also learn what you want to learn. Even if you don't get the expected results after asking for help, at least we can deny some options, which can also save time costs. The most important thing to remember is that we are a Team.

In the first week of Story development, both Andrew and I were not familiar with the Validation mechanism. We tried a variety of methods to solve the problem, but they didn't work, so repeated attempts have been delayed for about a day. Later, we took the initiative to find another Thoughtworker-Eric who had been in the project for a long time. After learning about our problem, Eric solved the problem in less than 10 minutes. In fact, the solution to this problem requires a small trick. In the Label, you can set the CSSClass we specified in advance to display those Validation messages.

5) knowledge sharing

There is no doubt that only full knowledge sharing can effectively play the role of the team. In particular, if the new team members do not have enough knowledge to share, or the old team members do not have the awareness to pass their own knowledge to the new team members, it is difficult for new members to integrate into the team and to quickly contribute their own Effort. In the process of knowledge sharing, it is effective to use Meeting, Session, or document reading. But in fact, even if you participate in a one-day Session or read a one-day document, it is better to make a Story with your Pair and share your knowledge. Based on my own experience, the so-called Session or document method is more suitable for introducing some background knowledge in the field or macro system architecture. Detailed knowledge must be obtained in practice. In this case, Pair Programming is very important.

When selecting your own Pair, you also need to make adjustments based on the actual situation. For example, Pair must be a relatively experienced Dev (of course, it can be paired with QA or BA ). In addition, you also need to Switch Pair appropriately. In this project, I realized the importance of this point. In the three days of the first week, both my Pair and I were Andrew. Although he has been in the project for more than three months, he still lacks some experience. As a newcomer to the project, I do not know much about it. This Pair combination can be imagined. In this process, we should have switched, but because of the Story relationship, other Pair also has their own tasks, this Switch activity was postponed to the second week. In fact, on the first day of the second week, Eric and I worked very well. The whole Velocity has been greatly improved.