Re: small team's knowledge/document management issue

sailor.gu@xxxxxxxxx wrote:

> Hi all,
>
> I am managing a small development team(2 senior engineers + 4
> junior engineers).
> We tend to documenting and weekly code-review.

Good to hear at least you are reviuewing something. How about ensuring that
every peice of project documentation is also thoroughly reviewed.

> We tend to knowledge sharing and brain-shock.
>
> But I can not manage those knowledge effectively, further more,
> After a period of time, the practice notes and ideas will be lost or
> be hard to find.

Sounds like you are in need of a simple formal process by which development
can be controlled. There will be a number of documents that ought to be
considered as part of the project documentation. This would include the
whole chain of documents from requirements specification, through analysis
reports, technical specifications, schematics, BOM, test reports, quality
reports and even the development records. Appointing a Document Registrar
to keep track and control the issue of the approved versions would
certainly help you out a great deal. Having a simple, memorable process
that all generated documents undergo will also assist you in keeping
control of the project. See the flow-chart on my HIDECS page for an idea of
how a simple process might look. It is based upon the use of four forms and
a register. The register keeps the record of what was created, what
problems it had to have fixed and when it was passed as OK for issue. The
four forms are:-

A Review Record Form (used as a front-*** for all reviewed items).
A Problem Report Form (a multi-*** report and response set)
A Change Proposal Form
A Work Instruction Form.

The process leaves a paper trail that is useable as evidence in a project
quality/systems safety audit. Of course, it can be implemented in
electronic form and is the way the the MKS software, that I mentioned,
operates together.

> 1. Is there some simple and effective softwares for my team?
> (it will be better if it can run in linux and it is free)

For that size of team it is not necessary to have a software package to
assist management but can be useful. There are plenty of packages
out there. You should probably look at keeping version management software
such as a CVS or RCS system. Add to that a problem tracking programme. If
you were running a Windows based system I would recommend MKS Source
Integrity and Track Integrity if you were willing to spend that sort of
money. As you expressed a preference for Linux based packages I am certain
that there will be a list of suitable items along shortly.

> 2. Is there any recommended resource or ideas for my situation?
>
> 3. Someone recommend Wiki, Is there someone ever use wiki in
> pratice?
> and how do you think of the wiki?

That may be OK for keeping the daily log of work accomplished. I would,
however, recommend that you use a more formalised means of creating the
specification and user documentation and ensure that these are very
thoroughly reviewed and controlled.

> 4. Can someone talk about code-review?
> we have unified code style and standard.
> but how to avoid that your member give you some special
> enhanced code?

I recommend the book "The Handbook of Walkthroughs, Inspections, and
Technical Reviews; Evaluating Programs, Projects, and Products" by Daniel
P. Freedman and Gerald M. Weinberg. Dorset House Publishing ISBN
0-9-32633-19-6.

You may also find "Configuration Management; The Changing Image" by Marion
kelly - McGraw Hill ISBN 0-07-707977-9 is also very useful.

> How to record the code's goods and shorts?

Establish a problem reporting system and ensure that this is also kept
under regular review. The record of problems arising and being fixed will
serve to highlight any weaknesses in your designs. It is worthwhile having
a review of what sort of problems are cropping up. If you stick to the rule
that one Problem Report Form will record only one problem it becomes much
easier to manage the problems (and eliminate them).

> How to avoid to make those mistakes that was already taken
> before?

Build up a manual of good practice and publish it on-line so that it is
easily referred to. This is probably where the wiki comes in very handy.
Don't forget that, like any other document in the project it does need
review from time to time.

--
********************************************************************
Paul E. Bennett ....................<email://peb@xxxxxxxxxxxxxxxxxx>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************
.