Use a Wiki-蒲公英云

Use a Wiki

Adrian Wible
New York, New York, U.S.
WIKIS ARE A gREAT MEChAnISM to centralize access to your project infor- mation. Hopefully, the wiki will be updated multiple times daily and will always be open in a window on team members’ desktops.
To prevent you from wasting any precious brain cells that may be needed for the actual project work, I’ve provided some suggestions for pages you might include on your wiki. While creating these, you are sure to have ideas about customizing the site for your own software project:
• Stakeholders. Have space for topics such as up-to-the-minute project sta- tus, short-term issues, long-term issues, risk, budget tracking, and mile- stone achievements.
• Developers. Add information such as the connection string to connect to the QA database. Fellow programmers won’t wasting time trying to locate the code from other random sources. Team members can share informa- tion on topics like coding standards, build and deployment procedures, common pitfalls, and use of advanced coding techniques such as depen- dency injection.
• General information. The software project manager should add the help desk phone number, team roles and responsibilities, and individual team member contact information here.
• Team calendars. Use this site to post team calendars. One great trick is to use an embedded iFrame pointing to a Google calendar.
• Meeting minutes. Archive meeting minutes so the team can easily refresh its memory on the details covered in past meetings. Also, team members can quickly reference the minutes to research or prepare for future meetings.

• Meeting agenda. Set up a process for stakeholders to suggest future agenda items online. Subject, of course, to the approval of the software project manager, the necessity for the item to be presented to the entire team, and the time limitations of the next meeting.

• Business analyst. Often this person is not colocated in the developer work- space. This is a perfect space to centralize access to working documents and domain artifacts that can be accessed from multiple locations.
• Testers. The organizational structure may separate testing responsibility from the programmer. This site can provide a clearinghouse between the two teams. Post topics like how to use testing tools such as Selenium, QTP, and Quality Center. Bug-tracking procedures can be developed and dis- cussed online, and the final decisions posted here.
Some tips:
• Don’t duplicate information. If the information lies elsewhere, link to that information instead of copying it into the wiki.
• Keep an eye on the volume of changes to make sure the information is not getting stale. If it does, people will stop using the wiki.
• Try to make your information real-time-data–driven if possible. Look for project management tools that include a wiki interface to enable creation of charts and status that is driven from the actual project data. This gives real-time status for the work in progress.
Any time you send project information via email, particularly with file attach- ments (documents, project plans, budget information, etc.), you should con- sider whether the team wiki would be a more appropriate place to exchange and archive that information.