in reply to Re: XSL/XML/Perl as a development process
in thread <strike>XSL/XML/Perl as a development process</strike>
The problem is not finding new ideas of devel proc but executing any old concept descently.
I rarely have such a "good manager." Examples of spec from the managers could be like:
1.Note that a single person could take multiple roles.
2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.
It is not usually a good idea for an business manager to tell programmers what to do directly. Two reasons:
One, doing so is like a patient (the biz mgr) telling a doc (the programmer) what drug and treatment he (the patient) should take.
Two, if one biz mgr can do it, any of them can. Hence, conflict of interests. Everyone wants their jobs done first. Besides, changes become intractable.
Normally, during Req Elicitation, a Client or Mgr would be like a patient, a Proj Mgr (or Sys Analyst) plays the role of clinical psychologist, literally. It really takes a skillset of a clinical psychologist to do Req Elicitation well. That's why (for me), a good personnel in that role is the most difficult to find.
Unfortunately, Req Elicitation is often the most poorly done. Thus, the tragedy--a bad and wrong biz idea perfectly implemented--which is still a bad and wrong biz idea.
I rarely have such a "good manager." Examples of spec from the managers could be like:
- "Make it look sexy"
- "Make it flexible"--euphemism for 'I duno what I'm doing'
- "Just turn the paper forms into webpages"--when building an employee performance evaluation application
- "Use a 3D spider web display"--for an org chart--2D info
- "This is exactly what the client wanted!"--no, it wasn't, since we redid the entire project afterwards.
Devel Phase |
||||
Role1. | Req Elicit./Analysis: What to Do |
Design: How to Do |
Coding: Do |
Testing: Done (hopefully) |
Mgr/Client | lead | verify | ||
Proj Mgr/Sys Analyst | lead | lead | buffer disturbance |
coordinate |
Artist/Programmer | (as needed) | lead | lead | fix |
QA | (as needed) | lead | lead | |
Artifacts: | flowcharts, screenshots, use cases... |
DB schema, class diagram, site map, (prelim) test script2.... |
(you know what...) |
results to the test matrix... |
1.Note that a single person could take multiple roles.
2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.
It is not usually a good idea for an business manager to tell programmers what to do directly. Two reasons:
One, doing so is like a patient (the biz mgr) telling a doc (the programmer) what drug and treatment he (the patient) should take.
Two, if one biz mgr can do it, any of them can. Hence, conflict of interests. Everyone wants their jobs done first. Besides, changes become intractable.
Normally, during Req Elicitation, a Client or Mgr would be like a patient, a Proj Mgr (or Sys Analyst) plays the role of clinical psychologist, literally. It really takes a skillset of a clinical psychologist to do Req Elicitation well. That's why (for me), a good personnel in that role is the most difficult to find.
Unfortunately, Req Elicitation is often the most poorly done. Thus, the tragedy--a bad and wrong biz idea perfectly implemented--which is still a bad and wrong biz idea.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Re: Re: XSL/XML/Perl as a development process
by chunlou (Curate) on Jun 16, 2003 at 23:04 UTC |
In Section
Meditations