Written Use Cases, until I saw and used them, thought they were a silly waste of time. Now I've used them and think they are indispensible for facilitating communication between the business and technical disciplines.
This is NOT UML!
Business Subject Matter Experts write the Cases, at the least the high-level ones, forcing them to really think out what they want and how it should work.
I recommend "Writing Effective Use Cases" by Alistair Cockburn. After looking at several resources, this is the only book I've found focusing exclusively on this area, and one I have found useful.
The one thing I've missed so far in this thread is what a Project Manager (PM) can bring to the table to help their technical staff.
Frequently, at least on smaller projects, the PM is the Team Lead. Realizing then PM's often do not have technical knowledge what can they do? Simply put: define a schedule of milestones with clearly defined short-term goals. By clearly defined I mean is either done or not-done; a 1 or 0 if you will. Track these goals. Revise the schedule and keep it visible to the team (put it in version control!).
Also, estimates while necessary are usually meaningless; at least I have seen very few accurate project estimates. Reason being that they are only based on experience (if lucky) or wild assed guesses. Until you have tracking in place for prior timelines on that project or other similar projects, where you can then use empirical data to make your estimates, making them good is black magic at best.
Tracking then is where a PM also adds the most value for a technical team. Many times I have seen the "schedule" issued as if it were the 10 Commandments given to Moses by God, only to see it abandoned because no tracking, or God forbid, revisions were done along the way.
So to recap for PMs out there to help their technical staff:
Create a schedule with clearly defined success criteria at each checkpoint - call them "inch pebbles".
Advice: Don't unless you enjoy it and can accept a high-level of frustration. That said, two places to go for some good information about parts, prices and how-to.
Generally speaking I try to buy the majority, if not all my parts from one or two vendors, because shipping can really make or break a deal.
Users and Interface
on
Version Fatigue
·
· Score: 3, Informative
*** Rant On ***
As a programmer I can speak to the software end of this conundrum involving "version fatigue." In the companies I've worked for, the programmers are the lifeblood of the enterprise, but often treated as little more than throwaways (albeit usually relatively well-paid). And, software projects/products rarely have a clear definition - so their development is a moving target. So programmers cannot define what they should build - because they lack any control (other than to drive from the backseat) - and no one else can definitively tell them.
What does this have to do with versions you say? Well, for software that actually gets out the door (the minority of projects to be honest), it's almost never *right*; in addition, it has a bevy of unnecessary features, which made it in due to an unclear vision of what the result should be. Therefore another version is needed to "get it right", of course the unclear vision remains so some improvement is made, maybe features are cut (a rarity), and some new unnecessary features are added, and others changed (but not for the better and sometimes for the worse).
A good book on this topic is Alan Cooper's "The Inmates are Running the Asylum" Amazon. It focuses on User Interface Design, which at the end of the day really means developing the disciplines and indentifying the user(s) to actually define what should be done before it's done!
At the code level, in CF at least, I agree with an earlier poster about Fusebox and more specifically their documentation standard Fusedoc. In short, you state what the file does and define what goes in and out in terms of variable names, types, and scope.
At a higher level of abstraction, I find Entity Relationship Diagrams (ERDs) are very useful because they force a group to use a similar vocabulary. Case in point, right now I am developing an accounting module for a larger project. Initial discussions gave the impression "Receipts" were the same thing as "Payments". Au contraire mon frere! They are simliar, but have key differences, that once we used an ERD became apparent.
Lastly I agree with using some sort of version control system for your documentation and definitely implement one if your source code is not there already. Makes a huge difference - as long as you remember to back up the archive too!
Slashdot Mirror
See http://xfml.org/.
Google Facet Classification for a more in depth study of the idea.
Written Use Cases, until I saw and used them, thought they were a silly waste of time. Now I've used them and think they are indispensible for facilitating communication between the business and technical disciplines.
This is NOT UML!
Business Subject Matter Experts write the Cases, at the least the high-level ones, forcing them to really think out what they want and how it should work.
I recommend "Writing Effective Use Cases" by Alistair Cockburn. After looking at several resources, this is the only book I've found focusing exclusively on this area, and one I have found useful.
The one thing I've missed so far in this thread is what a Project Manager (PM) can bring to the table to help their technical staff.
Frequently, at least on smaller projects, the PM is the Team Lead. Realizing then PM's often do not have technical knowledge what can they do? Simply put: define a schedule of milestones with clearly defined short-term goals. By clearly defined I mean is either done or not-done; a 1 or 0 if you will. Track these goals. Revise the schedule and keep it visible to the team (put it in version control!).
Also, estimates while necessary are usually meaningless; at least I have seen very few accurate project estimates. Reason being that they are only based on experience (if lucky) or wild assed guesses. Until you have tracking in place for prior timelines on that project or other similar projects, where you can then use empirical data to make your estimates, making them good is black magic at best.
Tracking then is where a PM also adds the most value for a technical team. Many times I have seen the "schedule" issued as if it were the 10 Commandments given to Moses by God, only to see it abandoned because no tracking, or God forbid, revisions were done along the way.
So to recap for PMs out there to help their technical staff:
Advice: Don't unless you enjoy it and can accept a high-level of frustration. That said, two places to go for some good information about parts, prices and how-to.
- Anandtech
- Tom's Hardware
In my experience the following online vendors are good for parts because of their service and prices:Generally speaking I try to buy the majority, if not all my parts from one or two vendors, because shipping can really make or break a deal.
*** Rant On ***
As a programmer I can speak to the software end of this conundrum involving "version fatigue." In the companies I've worked for, the programmers are the lifeblood of the enterprise, but often treated as little more than throwaways (albeit usually relatively well-paid). And, software projects/products rarely have a clear definition - so their development is a moving target. So programmers cannot define what they should build - because they lack any control (other than to drive from the backseat) - and no one else can definitively tell them.
What does this have to do with versions you say? Well, for software that actually gets out the door (the minority of projects to be honest), it's almost never *right*; in addition, it has a bevy of unnecessary features, which made it in due to an unclear vision of what the result should be. Therefore another version is needed to "get it right", of course the unclear vision remains so some improvement is made, maybe features are cut (a rarity), and some new unnecessary features are added, and others changed (but not for the better and sometimes for the worse).
A good book on this topic is Alan Cooper's "The Inmates are Running the Asylum" Amazon. It focuses on User Interface Design, which at the end of the day really means developing the disciplines and indentifying the user(s) to actually define what should be done before it's done!
*** Rant Off ***
At the code level, in CF at least, I agree with an earlier poster about Fusebox and more specifically their documentation standard Fusedoc. In short, you state what the file does and define what goes in and out in terms of variable names, types, and scope. At a higher level of abstraction, I find Entity Relationship Diagrams (ERDs) are very useful because they force a group to use a similar vocabulary. Case in point, right now I am developing an accounting module for a larger project. Initial discussions gave the impression "Receipts" were the same thing as "Payments". Au contraire mon frere! They are simliar, but have key differences, that once we used an ERD became apparent. Lastly I agree with using some sort of version control system for your documentation and definitely implement one if your source code is not there already. Makes a huge difference - as long as you remember to back up the archive too!