How do you communicate effectively in a small development team? [closed]
开发者_JS百科
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this questionI work in a small team (4-5 developers) on a single project. Every member of our team is developing a different functionality from our project and they are highly independent. In fact, some members use technologies that other member doesn't know about. It's still a single project and there a lot of common business logic in it.
In addition, most of the members are completely unaware what and how the others are doing. Somehow, we manage to avoid code replication (credits for our team-leader, but even he is not completely aware what is happening). I wonder, what is a good practice to keep the whole team on the track what is going on. For example if some one from the team quits or is missing when an important fix should be made - it's difficult for the others to handle.
We have a policy, for conducting code-reviews, but only the team-leaders and one member of the team participates in it. The other "regular" members do not take part, there.
Also, we have a "newslist" for checkin-s committed in the source control by our members, but this seems too boring to deal with and it looks like nobody is taking time to read what others have just committed (and it's not effective, to be fair).
So, I wonder what is a good practice in this matter. What experience do you have? Is there a solution at all ?
EDIT: Let me clarify a bit. Our team is working for more than 2 years and the project is almost 5 years old. So, we can't start agile development, although we could you some agile practices (like stand-up meeting, I find it very useful indeed).
Also, our team is a part of a bigger company, so we have established a team-building practices. And we don't hate each other :) - we are friends, talking about social life and activities. The professional talks is what we are missing.
Standup meetings each day (keep them short) with everyone present help everyone understand what each other is doing. This also helps the manager get some management out of the way, helps prevents thrashing, and puts a little pressure on each individual without the manager having to do it. (You want to have something done so you'll look good in front of your peers tomorrow morning). Some methodologies like Scrum formalize this.
Have code review with different team members. Is one of the non-manager team members more experienced? Having this person do code review with others would be good; he/she would share their experience and be someone else (besides the manager) who knows most of what's going on. There's no law that says in a peer review one person must be more senior than the other and be the one who declares code right or wrong. I think though that if two "peers" are doing code review, they should just pair-program to begin with.
if your are trying to write some quality code, certain bits of code might lend themselves to pair-programming. XP people say you should do this all the time, but I believe it's more helpful sometimes and other times. For example, when one developer is more experienced than the other, this helps with mentoring. Also, when there is a specific area where you want knowledge to be spread. (Only one guy understands a part of the system; next time that needs revising, have that guy do it with the other person typing.) Also, sometimes a part of the system is really important, and having it crafted correctly is far more important than lines-of-code per minute. This is a great place to have two heads on the problem, and in the end two people have intimate knowledge of this key code instead of one.
Something like once a week, have someone present a short talk during lunch on something interesting they're doing. This can generate great discussion, promote confidence and mutual respect, but what we're interested in here is that it promotes awareness.
Value, support and believe in good code. Some shops (the managers mainly) don't really believe in good code, and this leads to people just busting out (crappy) code, even if the developers could make great code. Communication about code happens a lot easier if developers are happy with the code they're making, if you're implementing some new technology now and then, and if quality work helps your career.
And more about pair programming. The key part of pair programming for this discussion is that pair-progrmaming promotes shared code and cross-knowledge. The reason I mention the specific places where pair programming is particularly helpful is because the policy "we're going to do pair programming" succeeds about 10% of the time. The other 90%, the proponents of the practice can't give a good enough answer when a big manager asks, "why are all these people sitting at the same desks?" The advantages of pair programming have to be 200%+ than just one programmer doing it, because you're using two people. Done at the right time, pair programming can increase your solution/buck ratio; at the wrong time it can decrease it.
Agile techniques like pair programming and daily stand-up meetings are good formal ways to get communication happening.
But it sounds like what you really need to do is just get people talking to each other. Developers tend to be introverts, so you have to work at this. Have lunch together. Look over each other's shoulders. Ask for advice from one another (even when you don't need it). Ask each other about those weird technologies that not everyone understands. Gather for integration tests.
I am in a similar situation at my workplace. Some members of the team are, like you said, highly independent and do not share any insight or practices with other member of the team. I find this to be highly unprofessional and overall hurtful to the team.
Of course it's only inevitable to have some members more proficient than others, and, in the world of programming, some members will have trouble shoving their egos aside. The best thing to do is to have scheduled meetings and code reviews in which everyone is involved. Have a central documentation site where people can post certain techniques that they use. If you figure something out that you think can be useful to the rest of the team, upload it to the site and send an e-mail telling everyone. Communication is key.
What could help you are daily stand-ups (from agile development). It takes only couple of minutes and basicaly all the members present to the others status of their work, problems they deal with and plans for tomorrow.
I think stand-ups is a good start for you. You can find some more info e.g. at Martin Fowler - It's Not Just Standing Up: Patterns of Daily Stand-up Meetings
In our team, we have progress meetings every week. This allows to discover what others do and where each one is placed in the big picture.
Sometimes it is followed by a mini social event when we share a homemade cake. The name of the person who brings the cake next time is written in the minutes of progress meeeting.
Teambuilding
Go make BBQ together, play foosball, find some team activity besides work that everyone likes. That will teach people to trust each other as opposed to being "independent" and multiply by 10 the effect of every other useful team practice, like scrum-meeting or pair programming.
Here are some thoughts off the top of my head (small company, three programmers; used to work in a team of about 20).
- Some sort of progress reporting so that everybody can see what everybody else is working on. "What I've been working on" meetings work for some people, but I'm not a fan of them - they're too regimented, and a sit-down meeting for this purpose can often turn into a waste of time and/or be prone to disappearing down ratholes. At my current work we have a cron job that reminds us to send our weekly progress emails: in these we are expected to say what we've achieved, the next few items on our todo list (with estimates where appropriate), any problems we've encountered.
- Selective commit notifications. Very few people pay more than a cursory glance to company-wide commit mails (even in my small team) - but if you can empower each developer to monitor just the fields they're working in, they probably can keep track of it. (You shouldn't have too many people working on the same piece of code at once, anyway. Too many cooks and all that.)
- Some sort of ticketing system to provide a todo list can be helpful. You need to be very clear over how this is managed, though - particularly what your processes are for originating and closing tickets.
- Internal documentation. This is a hard problem; some developers hate it, some write far too much, and some write just enough. At least half the problem is in indexing and presentation; it's no good if the information you need is buried five layers deep in an impenetrable document entitled "Beware of the Leopard". I'm quite a fan of wikis for this purpose as they're so easy to use.
- Above a certain size of team you might find it becomes a full-time job for somebody to manage your documentation. At a previous workplace we spent the money on a search engine appliance, continually crawling our intranet sites, which was wonderful.
We are in a similar situation (a long project and are all friends), and had similar problems. The following practices allowed us to improve a lot:
- Daily standup meeting are a must. In my experience a well conducted daily standup is the best thing to encourage communication among the team. Everyone knows what all team members are doing, and can help out with any problem.
- A wiki is also essential. You can put up standard practices and technologies that are used within the team. To have everyone actively participate, the leader assigns all team members something to write about and maintain whithin the wiki. It is particuarly effective when each one writes about something that they particularly likes or is interested in.
- Try to have the whole team present, or all the members that are available, in meetings where requirements/features are analyzed, priorized, etc. It doesn't matter if some of members of the team are not specificaly working in that area of the project. This will give context to everybody and a broader vision of the project. It will allow (and encourage) them to participate in this discussions of the project as a whole, and not solely concentrate on the part that they are working on. This practice will motivate a lot of discussion, all of us when given a chance and knowledge (it only takes a very small amount) have an opinion and like to comment on all everything within the project.
- The final practice that motivates a lot of "shop" talk, is that every two week some member gives a small presentation about some technology or technique. Generaly it includes practical exercises, and time discuss and ask questions.
加载中,请稍侯......
精彩评论