 |
Home > Detail: Keeping a Project Journal
Viewing 1-10 of 4191 Collapse Descriptions
Sort by: Date Posted | Title | Content Type | Relevancy
 COLUMN: Keeping a Project Journal Author(s): Lee Copeland Summary: If you think that keeping a journal is only for adolescent girls, read this week's column by Lee Copeland. Among other things, he suggests that a project journal helps you stay organized; teaches you what not to do next time; and makes it easier to explain what went wrong in a troubled project when you have to defend yourself. He also gives tips on being a good recorder.
LINK: Visual Studio Project Management Journal Description: Visual Studio Project Management Journal (VSPMJ) was created to reduce the number of software project failures. VSPMJ has no "VB Tips or Tricks," our site is targeted to project managers, QA managers, programmers, and anyone who wants to go beyond the VB code. We have book reviews, discussion groups, and
articles to help you improve your VB project management skills. Link: http://www.vspmj.com Date Posted: Nov 30, 1999
CONFERENCE MATERIALS: Testing Dialogues: Technical Issues Author(s): Facilitated by Esther Derby and Johanna Rothman Summary: Test professionals face a myriad of issues with immature development technologies, changing systems environments, increasingly complex applications, and 24/7 reliability demands. We must choose the right methodology and best testing techniques to meet these challenges, all with a limited set of tools and not enough time. In this double-track session, you'll be able to ask for help from your peers, share you expertise with the group, and develop some new approaches to your biggest challenges. Johanna Rothman and Esther Derby facilitate this session, focusing on topics such as model based testing, security testing, testing without requirements, testing in the XP/Agile world, and configuration management. Discussions are structured in a framework so that participants will receive a summary or their work product after the conference. Conference: STARWEST 2003
CONFERENCE MATERIALS: Testing Dialogues: Management Issues Author(s): Facilitated by Esther Derby and Johanna Rothman Summary: Testing dialogues are a unique platform for you to share your ideas and learn from experienced testers from around the world. In this double session, test managers engage in in-depth, small group discussions with their peers. You'll share your expertise and experiences, learn from others’ challenges and successes, and generate new topics in real-time. Johanna Rothman and Esther Derby facilitate this session, focusing on management issues such as: release criteria; determining ROI of test; coaching and feedback; managing new employees; estimating test time and resources. Bring your BIG issue and start a new dialog with your management peers. Discussions are structured in a framework so that participants will receive a summary or their work product after the conference. Conference: STARWEST 2003
CONFERENCE MATERIALS: Bulletproof your Review Program! Author(s): Esther Derby, Esther Derby Associates Inc Summary: In this article, the author explains how to bulletproof your review program by avoiding traps that typically kill technical review programs. She also details four common reasons why review programs fail and what you can do to successfully implement one for your team. Conference: STAREAST 2003
CONFERENCE MATERIALS: Introduce and Sustain a Worldwide Software Inspection Process Author(s): Marc Rene, GTECH Corporation Summary: In this presentation you will discover how to: understand the benefits that come with implementing inspections, understand the steps to rollout an effective inspection process, how to anticipate the problems that can be
encountered during an inspection rollout, and learn the importance of monitoring to maintain effective inspections. This paper also details system inspection definitions. Conference: STAREAST 2003
CONFERENCE MATERIALS: Traps That Can Kill a Review Program (And How to Avoid Them) Author(s): Esther Derby, Esther Derby Associates Inc Summary: Technical reviews have been around for a long time, and they're generally recognized as a "good thing" for building quality software and reducing the cost of rework. Yet many software companies start to do reviews only to have the review program falter. So the question remains: How can you succeed with a review program? Management support and good training for review leaders is a good place to start. But it's the details of implementation that truly determine whether reviews will stick, or they'll fall by the wayside. Esther Derby offers her insights based on observations from both successful and failed review programs. Conference: STARWEST 2002
CONFERENCE MATERIALS: Automating Reusable Test Designs Author(s): Robin Goldsmith, Go Pro Management, Inc. Summary: Vendors and gurus agree that having a structured testing methodology is key to gaining maximum advantage from automated testing, but what this means in practice isn't always clear. One of the biggest potential paybacks comes from the ability to automate tests based on reusable test designs, which can be a key benefit of proactive structured testing. In this interactive session, Robin Goldsmith describes how to develop reusable test designs that can be automated to start testing sooner and run more tests in limited time. Conference: Test Automation Spring 2002
 ARTICLE: Passing the Buck Author(s): Allen I. Holub Summary: One way object-oriented systems address the maintenance problem is by using "implementation hiding." Clients of an object shouldn't be dependent on its inner workings--they should only have to know how to talk to it. Date Posted: Sep 30, 2008 |
MAGAZINE ARCHIVE: The Trouble with Derivation Author(s): Allen I. Holub Summary: This article discusses the dark underbelly of derivation: the fragile base class. It's possible to modify a base class in such a way that, even though you've improved its implementation and all your tests work just fine, you've nonetheless damaged the derived classes, perhaps fatally. Type of Article: Dept: Code Craft Better Software Issue: April 2009| Date Posted: Mar 30, 2009 |
|
 Viewing Item 1 of 4191


| A StickyMinds.com Original |
 |  |  |  Keeping a Project Journal A Key to Personal Growth
 By Lee Copeland

  
 Summary: If you think that keeping a journal is only for adolescent girls, read this week's column by Lee Copeland. Among other things, he suggests that a project journal helps you stay organized; teaches you what not to do next time; and makes it easier to explain what went wrong in a troubled project when you have to defend yourself. He also gives tips on being a good recorder. |  |  |

|
|
 | Yesterday I was helping my youngest son, Rajan, with a report on John Muir, one of the first environmentalists.
Remembering a journal of Muir’s I had read many years ago, I dug through dusty
boxes in my basement to find My First Summer in the Sierra. It is Muir’s
record of his experiences as he first explored the magnificent Yosemite Valley
in 1869. As I read passages to my son I remembered journals that I have kept—project
journals—that recorded my experiences as I worked on various projects. I’d
like to suggest that you too should keep project journals.
Why keep a project journal? I can suggest a number of reasons:
- Remembering.
By recording in my journal, I have all the information
in one place, nothing gets lost, and it is organized.
- Evaluating the project.
Often we will be called upon to evaluate some
part of the project’s activities or deliverables. Your project journal will
be filled with the details that make an accurate evaluation possible. Rather
than having to depend on anecdotal evidence (I call them "campfire
stories") we will have real data to use.
- Evaluating ourselves.
In order to grow we must change. In order to
change we must establish a new direction. Your project journal will be an
amazing source of data for your own self-evaluation and improvement.
- Protecting.
When involved in a troubled project, you may find yourself in
a round of "Place The Blame." At this point your journal may have
great value as a contemporaneous record of what transpired earlier. Many
people may be very interested in what you have written. It may save your skin
(and other important body parts).
Once you commit to keep a journal, the basic question is what to write. I use
an approach derived from Virginia Satir’s Interaction Model:
- First, I record what I saw and heard. I try to capture the event exactly—word
for word, scene for scene, with no embellishment or evaluation on my part.
As Joe Friday on Dragnet used to say, "Just the facts ma’am.
Just the facts."
- Second, I add my interpretation and understanding. If the meaning I
attach to the event is different from the exact words and actions I
observed, I write my interpretation in my journal. I also consider whether
this interpretation is mine alone or if others would have the same
interpretation.
- Third, I add my feelings about what has transpired. Yes techies, it is
okay to have feelings about things. I once worked for a man who said,
"Feelings are facts to those who have them." In my youth I
thought that bit of sloppy thinking was nonsense. Now that I am much older
and a little wiser it makes perfect sense. Our feelings influence us in the same way our facts do.
- Fourth, I record my response—what I said or did at the time. Again, I
note exactly what I said and did. If I meant to give a different response
I note that also.
- Fifth, I note my feelings about my response. Was my response appropriate?
Was it too sharp? Too judgmental? Too passive? Not only is it okay to have
feelings about our responses, it is vital to evaluate them. Our feelings
often give excellent guidance about the appropriateness of our responses.
Later, as I put Muir’s journal back in the box in the basement, I noticed a
project journal I had written a few years ago. As I thumbed through it, these
passages caught my eye:
10 Feb
Is there a use case model? (No)
Is there a list of actors? (No)
Can we meet with the developers to discuss some questions we have? (No)
15 Apr
Downloaded the latest build from the configuration management system.
It won’t even compile. A number of files are missing.
26 Apr
Development has announced that source code will not be turned over to
testing because it "previously appeared to have created some
confusion." What that means is that when we saw how bad it was and
said so publicly, it embarrassed development.
29 Apr
THE DATE SLIPPED A YEAR!!
What we all knew was finally admitted by management.
26 May
That’s it. I’m done. My three months of consulting are up. I’ll miss my
apartment on the beach. I can’t say the same about this project.
Remembering this project, its successes, its difficulties, and most of all the friends I made, I smiled, put the project journal back in its box, and walked back upstairs.
Reference
Satir Model: Family Therapy and Beyond. John Banmen, Jane Gerber (Contributor), Maria Gomori (Contributor), Virginia M. Satir. Science & Behavior Books; ISBN: 0831400781; (July 1991)
About the Author Lee Copeland has more than thirty years' experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. He has developed and taught a number of training courses focusing on software testing and development issues based on his experience. Contact Lee at lcopeland@sqe.com.
Back to Top
StickyMinds.com Weekly Column From 10/28/02
|