Modify the document and save it with a new name. (You should see the changes flagged in the document. If you don’t, go to the Review tab’s Tracking group and use the drop-down to select Final: Show Markup.)
d. On the Review tab’s Tracking group, click the Reviewing Pane button to display the reviewing pane. You should see your changes there.
e. In the Review tab’s Tracking group, open the Track Changes drop-down and select Change User Name. Change your user name and initials.
f. Make another change, save the file again, and see how Word indicates the changes.
3. Microsoft Word also provides a document comparison tool. If you followed the instructions in Exercise 2 carefully, you should have two versions of your sample document. In the Review tab’s Compare group, open the Compare drop-down and select Compare. (I guess Microsoft couldn’t think of synonyms for “compare.”) Select the two versions of the file and compare them. How similar is the result to the changes shown by change tracking? Why would you use this tool instead of change tracking?
4. Like Microsoft Word, Google Docs provides some simple change tracking tools. Go to http://www.google.com/docs/about/ to learn more and to sign up. Then create a document, save it, close it, reopen it, and make changes to it as you did in Exercise 2.
To view changes, open the File menu and select See revision history. Click the See more detailed revisions button to see your changes.
5. What does JBGE stand for and what does it mean?
▶ WHAT YOU LEARNED IN THIS CHAPTER
● Documentation is important at every step of the development process.
● Good documentation keeps team members on track, provides a clear direction for work, and prevents arguments over issues that were previously settled.
● Document management systems enable you to:
● Share documents with other team members.
● Fetch a document’s most recent version.
● Fetch an earlier version of a document.
● Search documents for keywords.
● Show changes made to a document.
● Compare two documents to show their differences.
● Edit a document while preventing someone else from editing the document at the same time.
● A simple way to store project history is to create an e-mail account named after the project and then send copies of all project correspondence to that account.
● You can use e-mail subject tags such as [CLASP.Rqts] to make finding different types of project e-mails easy.
● Types of documentation may include:
● Requirements
● Project e-mails and memos
● Meeting notes
● Phone call notes
● Use cases
● High-level design documents
● Low-level design documents
● Test plans
● Code documentation
● Code comments
● Extractable code comments
● User manuals
● Quick start guides
● Cheat sheets
● User interface maps
● Training materials
● Meta-training materials
● Marketing materials
● JBGE (Just Barely Good Enough) states that you should provide only the absolute minimum number of comments necessary to understand the code.
CHAPTER 3
Project Management
Effective leadership is putting first things first. Effective management is discipline, carrying it out.
WHAT YOU WILL LEARN IN THIS CHAPTER:
● What project management is and why you should care
● How to use PERT charts, critical path methods, and Gantt charts to create project schedules and estimate project duration
● How you can improve time estimates
● How risk management lets you respond quickly and effectively to problems
Part of the reason you implemented all the change tracking described in the preceding chapter is so that you have historical information when you’re writing your memoirs. It’s so you know what happened, when, and why.
In addition to this peek into the past, you also need to keep track of what’s going on in real time. Someone needs to track what’s happening, what should be happening, and why the two don’t match. That’s where project management comes in.
Many software developers view management with suspicion, if not downright fear or loathing. They feel that managers were created to set unrealistic goals, punish employees when those goals aren’t met, and take credit if something accidentally goes right. There are certainly managers like that, and Scott Adams has made a career out of making fun of them in his Dilbert comic strip, but some management is actually helpful for producing good software.
Management is necessary to ensure that goals are set, tracked, and eventually met. It’s necessary to keep team members on track and focused on the problems at hand, without becoming distracted by inconsequential side issues such as new unrelated technology, impending layoffs, and Angry Birds tournaments.
On smaller projects, a single person might play multiple management roles. For example, a single technical manager might also handle project management tasks. On a really small project, a single person might perform every role including those of managers, developers, testers, and end users. (Those are my favorite kinds of projects because the meetings and arguments are usually, but not always, short.)
No matter how big the project is, however, management tasks must be performed. The following sections describe some of the key management responsibilities that must be handled by someone for any successful software development project.
EXECUTIVE SUPPORT
Lack of executive management support is often cited as one of the top reasons why software projects fail. This is so important, it deserves its own note.
NOTE To be successful, a software project must have consistent executive management support.
The highest-ranking executive who supports
