In recent post I mentioned an engineering process. When most developers hear the word process they instinctively brace themselves for the overbearing, bureaucratic, time-wasting requirements that usually follow. This is not that kind of process. Every development team uses a process whether it is documented or not. A good process makes work more predictable and even enjoyable for all parties, inside and outside the engineering team.
This process allows developers to work more independently with less task-by-task direction than required in most organizations. This is a few years old and I’ll update it before I use it again, especially to add more testing requirements now that frameworks come with better testing features.
Here it is, as it was.
Work on tasks from Change Requests, highest priority requests first.
Do not multitask. Work on the highest priority CR until it is blocked or completed. Blocked means you have to wait on someone else (a customer, manager, vendor, etc.).
When a manager is available, discuss with manager before beginning a new CR so that most current company priorities are considered.
Each CR should go through the following phases in this order:
- Analyze
- Implement
- Code Review
- Test
- Publish
- Business Review
Analyze
Assign the CR to yourself at the beginning of this step.
Analyze means to understand the request fully. Interview the reporter, manager, customers, etc. as necessary. Seek direction from other business functions like Marketing and Operations.
Present the alternatives and a proposed high-level design to the team for the most complex requests. This is rarely required but do it at your discretion for large requests. Use story board, prototypes, or any tool you want.
Implement
Implement means to develop the solution in a development tree and using a development database. Some Do’s of implementation:
- Perform some unit testing for medium to complex changes, but not simple changes.
- Use comments liberally.
- Follow the coding style (indenting, naming convention, etc.) of the current code.
- Make sure any new database features can be managed from the admin interface.
- Make sure online documents are updated to match features. Add likely questions to FAQ, etc.
- Get all new copy written or reviewed by Marketing.
Code Review
Code Review before Test is not a mistake. It saves time to catch errors by review rather than by testing. Another engineer or manager reviews the changes line by line to identify errors. Count lines reviewed and number of errors found. Post this info as a bug note on the CR. Simple rework can be included in this step. Complex rework should be reviewed again.
Commit changes to source code control after Code Review is complete and advise all engineers that the tree cannot be published until testing is complete. Make sure any new files are added and committed to source code control.
Test
Test. A different specialist should test the new feature using a read-only tree. This phase includes any required rework.
Publish
Publish. Implement any database changes required on the production server. Publish the code and “touch test” on the production server to test the publish process. The CR should be changed to Resolved at the end of this step.
Business Review
Business Review. Implementer should demo user interface changes to Marketing and Support so the change can be communicated and supported effectively. This phase includes training internal users. Manager should change the CR to Closed at the end of this step.
