Originally this started with reading Martin Fowler's bliki entry, but I diverged topics when replying to it and I wrote up what I would like in a project.
Personally I do agree with what he says. Unfortunately, most people and processes are still "old school", and unless they get the concept of:
- no fixed end date for ALL requested features
- two people working on one thing together on the computer
- the decision making person actually working with the team
- you will get very little "paper" documentation with your product
they are not going to be paying you.
I would have to agree with what someone told me about methodologies. If you have good developers, any methodology would work anyway.
I also find that XP does not scale down to accomodate the occasional
bad seed that got his/her job by nepotism. Some of the more heavy process oriented ones have somewhat of a redundancy through excess documentation.
The best methodology by theory that I can muster is a combination of RUP + XP.
RUP for its 4 phases: Inception, Elaboration, Construction and Transition. The phases are useful because it can give a course grained view/estimate of the project. Also the phases can be rewound back in case there is a change in requirements.
In Inception #1-1:
I would do requirements gathering and put them into a tool like Excel or something more complicated, but simple to use. This includes all requirements even non-functional requirements.
In Inception #1-2:
Define change procedures to set expectations. Don't be to elaborate, just a simple one saying who will know and understand change impacts the schedule.
In Inception #2-1:
A course grained plan will be laid out here. Customer decides whether to actually go on with the project or not. If not, then you cut your losses early on.
In Inception #2-2:
A defect (JIRA)/version (SVN) control system is also put in place. The requirements are version controlled or put into the defect system (prefered). This phase should be reltively quick in theory, but not in practice. An organization should have one in place or ready to put in place. I suggested JIRA and SVN since they are the quickest to roll out.
**** DO NOT CONTINUE IF ANYTHING FAILS HERE, REWIND ****
In Elaboration #1-1: (parallel streams of elaboration or sequential depending on resource availability)
I would build the infrastructure that would solve most of what we would need (or buy it from someone):
- A model driven paradigm that can be used for code generation. Primarily for the back end development.
- Tapestry or similar for the front end pieces so you can use HTML developers more easily and adapt to change more readily.
- LDAP security configuration.
- Integration glue code to link the tiers together.
- A test harness
In Elaboration #1-2:
I would also get the HTML developers to build the HTML pages from the requirements and get them to "linked" state to show the flow of the application and possible states. These can be built using WYSIWYG tools and shown to the client very quickly.
This excerise would define the scope and behaviour of the UI at an early stage. Since its all HTML, it will do some of the Javascript driven client behavior.
UI will not create detailed use cases. But will define behavior and screen posibilities.
In Elaboration #1-3:
A data/process modeller would be developing the business domain object model. Not in terms of tables, but more Hibernate persisted objects. They would discuss this with the client as well. The client can be a different person who would know how things actually worked in the company rather than how they want things to work.
The process modeller will be responsible for breaking down the requirements into use cases.
**** DO NOT CONTINUE IF ANYTHING FAILS HERE, REWIND ****
In Elaboration #2-1: (after the first set of work is partially started)
The development groups have to ensure that they will all integrate together.
In Elaboration #2-2:
The development teams have to validate that the Non-Functional requirements (which tend to be the silent killer of projects) can be met.
Those that are not met are logged as Risks in Excel to put to the PM.
**** DO NOT CONTINUE IF ANYTHING FAILS HERE, REWIND ****
In Elaboration #3:
Write working code that fulfills a simple use case. (If there are no simple ones, break one down till it becomes a simple one). Ensure that the code is testable.
In Elaboration #4:
Update the estimates that were originally provided now that there is more understanding of things.
If it won't fit, decide on which requirements (preferably non-functional requirements) to remove from the build.
**** DO NOT CONTINUE IF ANYTHING FAILS HERE, REWIND ****
In Construction #1-1:
The development team on Elaboration will now be known as Leads.
The Leads are responsible to document guidelines and instructions on how to use the framework. They are also responsible to teach the construction staff.
DON'T WRITE A NOVEL. The documentation is meant as a starting point for people. You already have some working code to show them that it works. Just improve your documentation as things go on.
The Leads will also be responsible for performing reviews on things done by the individuals at the start.
Just because someone is a lead, doesn't mean they can't do the work, but its best that they don't have to do much otherwise you block the resource from helping out.
In Construction #1-2:
Leads will also be defining the metrics that they would go by. Useful ones are test coverage and automated code review results (all available through maven)
**** NOW IS A GOOD TIME FOR YOUR CONSTRUCTION TEAM KICKOFF ***
In Construction #2-1: (the actual work)
Construction staff just do their own work.
HTML developers may do
* i18n
* alternate page UIs (removing fields that are not supposed to be visible given a state).
Presentation tier developers:
* put in the rest of the Tapestry attributes
* tapestry XML pages for the rest of the HTML.
Backend developers:
* Flesh out diagrams to provide enough information for code generation.
* Convert the diagrams into actual code.
* Create unit tests to ensure coverage.
Test developers:
* work with leads to define a defect management procedure.
don't go overboard, but set at least what severity levels mean.
* define and build alternate scenario integration tests.
* Continutuously run either manually or with a tool. Sometimes getting a bunch of low level people to do test cases is cheaper than getting high level people to automate the entire thing. Compromise, don't get all low level people (you get bad tests) or all high level people (they will get bored)
In Construction #1-3:
Infrastructure Leads will automate as much of the builds as possible. This will reduce the amount of documentation needed.
In Construction #1-4:
The leads will
- Define interfaces between presentation tier and the backend in UML.
- Convert the rest of the use cases into sequence and interface diagrams in UML.
The UML diagrams are not detailed. They are meant to guide the actual developers. The class diagrams will be fleshed out by the developers. Sequence diagrams are meant as a guide and will not be fleshed out by the developers, but may be reverse engineered after the fact.
* Ensure test coverage for integration tests. (Unit tests are done already through JCoverage)
The Leads are also responsible to make as much construction staff personel turn into leads to facilitate turnover.
They should set an environment of "no fear" for the construction team.
The leads are also responsible to feedback to the clients/project manager on the progress of the work.
In Construction #2-1: (This section happens after ramp up -- about a week or two into the phase)
Everyone should have a feel for how things work and would be able to provide better estimates.
The Project/Requirements Manager will track the requirements and update the plan to see what the delta is then report to the client. Hopefully there isn't much delta, but if there is revisit the requirements to see if anything can be taken out (or added back in). This provides continuous feedback to the client.
In construction #2-2:
Execute integration test cases for completed use cases.
In construction #2-3:
Work to reduce the iteration and build cycle time. Start showing off to the client so they see things in action. Or introduce changes.
Changes will create a sub project (with inception, elaboration, construction, transition) on its own, but integrated with the main project.
In Transition #1-1: (this is when the performance/ivt/uat/stage/production environment is ready, this can happen during construction and should happen there, so there is development support).
Test deployment process on the new environments to make sure they work properly.
Infrastructure team develop install guides for the deployment teams on how to install the product.
In Transition #1-2:
Deployment team ensures instructions work.
They should do this on more than one iteration to ensure the upgrade process also works.
