1. Create a wiki topic on what you are planning to do and explain these steps to someone before starting writing the code
2. Have a buddy spend at least a part of the day pair-programming with you, return the favor the next day.
3. Make sure to do a code-review daily and explain how the features work
4. Test your buddy's code and have them test yours. Use the wiki list as the start
5. Post screenshots on wiki early on and have client read thru them, make sure you get feedback (so you know they have read it)
6. Update the test list for the project
7. Assume that UAT testing is NOT for developers but for the CLIENT, there should be no surprises or code changes but then.
This list came up from the our experience and feedback from my developers (thanks to Phil W. for your thoughts)...
In the past development cycle I cave in to the fact that we had a large number of tasks and a limited, geo-dispersed team so I abandoned the practice of pair programming. The result was a prolonged period of
"bug fixes" and late, stressful build.
With the pair programing, we sometimes had a few of issues, but we never spent so much time on fixing bugs. It was almost a deja vu of the previous projects, of which many have failed.
As a project manager I have to take a full responsibility for this failure, and correct the problems.
Pair programming fosters:
- better understanding of the "big picture" by the whole team
- essential questions asked early on in the development cycle
- lack of procrastination with development
- more time spent actually developing vs. browsing the web, or daydreaming
Single developer programming leads to:
- lack of team work
- developers working on hard issues burn out and loose motivation
- developers "sand bag", or inflate the time required to accomplish the task
- developers take it "personally" and get hurt emotionally when client criticize their work
- when the developers finally quits, no one knows how things work
No comments:
Post a Comment