Agile Collaboration

Regularly scheduled meeting time

Perhaps you personally hate meetings, but communication is the key to the success of the project. Not only do we keep talking to customers, but also should be good communication with other developers.

Legislative Council (standing open conference) is to bring together a team, and a good way to let everyone understand the current state of progress. As the name suggests, participants are not allowed to do in the legislature, which guarantees quick conference. After a person to sit down, due to feel comfortable and make last longer meetings.

To ensure meeting agenda will not diverge, everyone should just answer the following three questions:

Yesterday, what's the catch?
Today plan what needs to be done?
What are the obstacles faced?

Each participant can only give very little speaking time (about 2 minutes). Maybe use a timer to help some Shoubu Zhu Buddist people. If you want to discuss certain issues in detail, it may be after the end of the legislature, to convene the relevant personnel.

Typically, the legislature are, and we are held at work earlier every weekday. But do not put it arranged the first thing to go to work. Let everyone have a chance to reply from the chaotic traffic situation in the state just for coffee, delete some junk mail or something. To ensure sufficient time after the end of the meeting, so that we do a lot of work before lunch, but do not start too early, let everyone anxious to hasten the end of the meeting, go have a drink. In general, to be held in less than an hour we half an hour later to the company, is a good choice.

People participating in the conference to follow some rules to ensure that no distracted each other, and the conference will not be beside the point. These rules are:

Only team members can speak. They must answer three questions above, but not in-depth discussion.
Management can be solved the problem down, but will not attempt to distract from the meeting three questions for each person to be answered.

Daily stand will be many benefits:

As soon as possible so that we put into the day's work in the past.
If a developer at some point there is a problem, he can take this opportunity to issue publicly and actively seek help.
Help team leader or management understand which areas need more help, and reassign staff.
Let team members know the progress of the rest of the project.
Help teams identify whether there is something in the duplication of effort and energy spent, or is not a problem someone has a ready solution.
By promoting the sharing of code and ideas to enhance the development speed.
Encourage power forward: people see the progress report are in progress, will encourage the formation of one another.

Specific skills

Meeting will take time to develop, so try to ensure that the investment of time greater output. Standing time will not be longer than 30 minutes, 10 to 15 minutes is ideal.
If you want to be booked in advance of the meeting room, put the predetermined time is set to 1 hour. So have the opportunity at the end of 15 minutes legislature, immediately convened a smaller scale.
While most teams are required to meet every day, but for a small team, doing so may be a bit overdone. You may wish to hold two days, once or twice a week, which is enough for a small team.
Pay attention to the details of the report. During the meeting to give a specific schedule, but do not fall into the details.
Quick start can ensure the meeting short. Do not waste time waiting for the beginning of the meeting.
If you think the legislature is a waste of time, it may be we have not formed a true sense of team. This is not a bad thing, in favor of improvements for the problem.

Architects must write code

Architects should be responsible for the design and guidance. As an architect, I should not just paint something that looks very beautiful design, cant say something like the same vocabulary, using a lot of design patterns - this design is not usually effective.

Designed to solve a particular problem is before us, with the implementation of the design, understanding of the issues change will occur. Want to achieve before you start, you make a very valid detailed design is very difficult. Because there is not enough context to get feedback page little or nothing. Design and evolution over time, if you ignore the status of the application, in order to design a new feature or function of a complete upgrade is not possible.

As a designer, if the system does not understand the details, it is impossible to make effective design. Only through a number of wide high altitude, rough design can not be well understood system.

Reversibility

The so-called final decision does not exist. After making the decision which is not nailed down. In fact, it is the timing point of view, may wish to every important decision-making, are seen as a pre-planned before the change made.

Good designer must be able to roll up their sleeves, join the development team, did not hesitate to participate in the actual programming.

To encourage programmers involved in the design. The main programmer should try to assume the role of an architect, but also engage in a variety of different roles. It will be responsible for solving design problems, but also will not give up the coding work. Programmers at the same time rejected the design, it will give up thinking.

Specific skills

If there is a chief architect, he might not have enough time to participate in coding. Or let him participate, but do not let him develop on the critical path of the project, the workload of the largest code.
Do not allow anyone to design alone, especially yourself.

Code-collective ownership

Any application of a certain size, they need more than cooperation for development. In this situation, it should not be like claiming ownership of the territory of the country as a statement of personal ownership of the code. Any team member, once you understand the ins and outs of a piece of code, you should be able to process it. If a piece of code can handle only one developer, the project will virtually risk increases.

Compared to find out who's the best idea, who sucks in terms of code implementation, solve problems, and let the application to meet the expectations of users to be more important.

When people at the same time developing the code will be checked frequently, reconstruction and maintenance. If you need to fix the bug, any one developer can get the job done. At the same time there are two or more people, it can handle different parts of the code in the application, allowing the schedule of projects easier.

The implementation of tasks in the team rotation system, so that each member can come into contact with different parts of the code, can enhance the overall team knowledge and expertise. When Joe took Sally code, he can be reconstructed, eliminate the problem to be treated. In trying to understand the code, he will ask some useful questions this morning began in-depth understanding of the problem areas.

On the other hand, we know that others will take over their own code, it means they have to be more unruly. When you know someone in attention, you will be more careful.

One might argue that, if a developer specifically address the task in a given field, he can be proficient in the field, and let the subsequent development tasks more efficient. This is true, but look long term, there are several pairs of eyes staring at a piece of code that will be able to bring benefits. This will improve the overall quality of the code, making it easier to maintain and understand and reduce the error rate.

Specific skills

Do not inadvertently lost among the team's expert skills. If a developer's machine proficient in a particular field, let him as a resident expert in this field, and the rest of the code system is also open to him, so that the project team and are very helpful.
In large projects, if everyone is free to change any code, the project will certainly be a mess. Collective ownership does not mean that the code can be arbitrary, destruction everywhere.
Developers do not have to understand every detail of each part of the project, but can not be processed because the code for a module and alarmed.
Some cases can not adopt the code of collective ownership. Perhaps the code requires some specific knowledge, knowledge of specific areas, such as real-time control system is a difficult. These times, more people, but easy to drop the ball.
Anyone can suffer sudden catastrophic events such as car accidents, etc., or are likely to be competitors to hire. If they do not share their knowledge to the entire team, but increased the risk of losing knowledge.

Become a mentor

Teaching and learning
Knowledge grows when given.

To work together with rest of the team is a good learning opportunity. Knowledge has some very unique property; suppose you give people money, your money will become less final, but their wealth will increase. But if it is to educate others, and that both sides can get more knowledge.

Detailed explanation of what they know, you can make more in-depth understanding of their own. When people ask questions, you can also find different angles. Maybe we can find some new tricks - heard a voice told himself: "I had no such thought about this issue."

Working with others, motivate them to become better, and can enhance the team's overall strength. When problems can not be answered, indicating knowledge in this field is still not perfect, needs to be further enhanced in this regard. Good mentor when advising others will take notes. If you experience problems take time for further observation and thinking, may wish to hastily recorded. After these notes will be added to the daily log.

Become a mentor, not meant to be taught the team how to do, does not mean to lecture in front of the whiteboard, or conduct quizzes noted, during the discussion may bring their own lunch time. Most of the time, become a mentor means to help enhance the level of team members but also to improve themselves.

This process does not have to be limited to their own team. Can set up their own blog, posted some code and technology on top. Not necessarily what a great project, and even a small piece of code interpretation, for others it may be helpful.

Become a mentor means sharing - rather than stick - their knowledge, experience and understanding. It means to learn and interested in the work of others, while willing to add value to the team. Everything is in order to improve his teammates and your ability level, not to destroy the team.

Specific skills

If you've been repeatedly explained to the people not by the same theme, you may wish to take notes, then write an essay on the subject, or even a book.
Become a mentor is an excellent way to invest in the team.
Pair programming is an efficient guidance of the natural environment.
If the number is always too lazy to bother people find their own answers.
Team members into a question of time before seeking help to set a time limit, one hour should be a good choice.

Allows everyone their own way

"Give a man a fish, three meals need; teach a man to fish, a lifetime of use." Way to tell team members to solve the problem, let them know page ideas how to solve the problem, which is to be part of a mentor.

Learn previous practice - mentors become - after, maybe some people will tend to answer directly to a colleague, to continue to complete the task. If only provide some guidance to them, let them try to find the answer, this is not what a troublesome thing. This has several benefits below:

You help them learn how to solve problems.
In addition to the answer, they can learn more.
They will not be repeated on a similar question to ask you.
In doing so, they can help when you can not answer the question for themselves.
They may not take into account that you come up with solutions or ideas. This is the most interesting - you can learn something new.

If anyone still had no clue it would give more tips (or even an answer). If someone put forward some ideas might help them analyze the strengths and weaknesses of each idea. If the answer or solution to give someone better, then learn from the experience, then share your experience of it. This is an excellent learning experience for both sides.

Specific skills

Answer questions with questions, you can ask questions to guide people on the right path.
If someone really fell into a stalemate, do not torment them. Tell them the answer, and then explain why this is so.

Ready to share code and then

Relative do not use version control system, what the situation is worse? The answer is: the incorrect use of the version control system. Use version control system mode, it will affect productivity, product stability, product quality and development agenda. In particular, the code such as the frequency of submission of such simple things will have a great impact.

After completing a task, you should immediately submit the code, should not be allowed to develop its code on more than one minute. If the code can not be integrated using others, then what use is it? It should be released quickly go out and start collecting feedback.

On the other hand, if the code is submitted before the task is completed, it will bring a lot of risk. These codes may also compile errors, or is not compatible with its code in other parts of certain changes made to the system. When other developers to get the latest version of the code, these codes will also be affected.

Under normal circumstances, the documents submitted should be relevant to a particular task or solve a bug. And it should submit the relevant documents, and marked with the log information, future modifications page to know what place and why to make changes. Once the rollback of the changes need to be taken, this "atomic" submission is also helpful.

To ensure that before submitting the code, all unit tests can all be passed. Continuous integration is to ensure that the source code control system of one embodiment of code good no problem.

Code does not choose to submit the implementation of other security operations

Use Remote Access

Carry: U disk

There are laptop with base extension: to solve the problem of continuity of development on multiple computers caused

Using the source control system characteristics: branching and merging. Code can be divided into the trunk and branches developers.

Specific skills

Some source code control system distinguishes between the "Submit" and two kinds of code permission "publicly accessible." At this point, you can temporarily commit operation. (VS TFS in the shelveset?)
Some people want the code can operate for review prior to submission. As long as not too long delay submit code there is no problem. If a part of the process of generating a delay, then the correction process it.
You should still frequently submit code. You can not use the "code has not been completed" as an excuse to avoid submitting code. (At least in the development branch is the case.)

Do code review

When the code has just been completed, it is the best time to find the problem. If left unchecked, it will not get better.

And removing defect code reviews

To find the hidden program bug, formally code review, the effect of any known form of test twice, and is the only known method of removing 80% of the defect.

Management is concerned the code review time spent. They do not want the team to stop coding, code review meetings to go to a long time. Developers feel worried for code review, allow others to see their code, make them feel threatened.

Through a rigorous code review process, you can submit a very high quality and stable code. When developers code and test complete a task, before checking in source code control system, there will be another developer to code to do a thorough review. This process fixes a lot of problems, code review not only the code for junior developers to write - code for each team of developers should be reviewed, regardless of its experienced or not.

Then how to perform code review it?

Overnight review: less agile, do not recommend this approach.
Pick-up game: When writing some code completion, compile, test complete and ready upon check in, other developers can start picking up the code review. It is a quick and informal way to ensure that the code before submission is accepted. In order to eliminate the inertia in behavior, in charge rotate among developers.
Pair programming: In Extreme Programming, the situation is not a person exists independent of encoding, programming is always in pairs.

What to see in the code review as well?

The code can be read and understood?
Are there any obvious mistakes?
Adversely affecting other parts of the code would be whether the application?
Whether there is a duplicate code?
Or whether there is some improvement can be reconstructed?

In addition, you can also consider using code analysis tool. If the static analysis results generated by these tools helpful for the project, put them in a continuous build integration into the go.

Specific skills

Not to think, similar to rubber stamp the same code review no value.
Code review need to actively evaluate the design and clarity of the code, not just consider the variable name and code format meets the standards organizations.
The same function, the code developers of different implementations may vary. The difference does not mean bad. Unless you can make a piece of code clearly getting better, do not free to criticize other people's code.
If you do not timely follow-up discussions to recommendations, code review does not have any real value. Follow-up session may be scheduled, or use the code marker system to identify needs to be done, the tracking portion has been processed.
To ensure that the code review feedback from participants to review each activity. As a result, to let everyone know that after the completion of the review of action taken.

Timely informed on the progress and problems

Take a task page it means to make a commitment to on-time delivery. However, experience various problems leading to delays, this situation is not uncommon. Deadline approaching, everyone is waiting to show you the results of the work in the demo session. If you go to will inform you after work is not yet complete, what will happen? In addition to embarrassment, which is not good for your career development.

If you wait until the deadline before the release of bad news, it would be tantamount to provide an opportunity for you to micro-manage manager and technical director. They worry that you let them down again, and began to repeatedly check your progress every day.

Suppose now that you have got one of the half of the task, due to technical problems, it seems not completed on time. If you then actively inform other interested parties, it will mean opportunities for them ahead of time to find solutions to the problem. Maybe they could seek another developer to help, maybe they can be reassigned to work more familiar with the technology of people, maybe they can provide more resources needed, or adjust the current scope of work to be done in this iteration. Customers will be willing to exchange this task with other equally important tasks.

Timely informed of progress and problems, when there happens, do not let other people feel suddenly, and they are willing to understand the current state of progress. They will know when to help, and you get their trust.

Send e-mail, transmit information using sticky notes, or quick phone call, this is the traditional way to inform everyone. You can also use "information radiator", similar to the poster on the wall, providing information changes, passers-by can easily understand the contents. To push way (posters, website, Wiki, blog or RSS Feed) transmission of information, they do not have to come to ask questions. As long as people can regularly view the required information, which it.

The entire team can use the information radiators to publish their status, code design and come up with good ideas and so on. Now just walk around the work area around the team, you can learn a lot of new things, but also the management can know how the current situation.

Specific skills

Daily legislature can make everyone a clear understanding of the latest developments and situation.
When showing progress status, level of detail to take care of the audience attention. For example, leadership is not concerned about some of the implementation details.
Do not spend too much time in progress and informed of the above problems, or should ensure the successful completion of development tasks.
Often look up at around instead of just immersed in their work.