Healthcare is extremely complicated, and, consequently, the applications that we've built over the past 8 years are extremely complicated. There are so many buttons and dials and knobs that it's really easy to forget important, but arguably obscure, steps as we enhance and maintain the software.
It doesn't take too long to recognize the need to consolidate those obscure requirements into a single document (or, in our case, three separate documents), so that they can easily be reviewed during the development lifecycle.
It doesn't take too long to recognize the need to consolidate those obscure requirements into a single document (or, in our case, three separate documents), so that they can easily be reviewed during the development lifecycle.
We decided to create those documents as "checklists" that a developer can pass through at various points to ensure that, for example, user-level security and auditing requirements have been taken into account. Each checklist is limited to a single page, and applies to one of the following stages of development:
Analysis and Design: Since we're using SCRUM, most of the analysis and design for new features takes place during and shortly after a sprint planning meeting. It is generally at this point that the team is putting together screenshots and/or prototypes and thinking about what the database schema might look like (assuming that they are doing UI-first development).
Coding: These items help ensure that the developer is thinking about indexes and unique constraints on new database tables, commenting code, "leaving a trail of goodness", etc.
Finalization: At this point, the team is integration testing the feature, dotting the i's and crossing the t's, and communicating changes to IT and other teams.
Checklists can help developers to remember the details and avoid obscure bugs...as long as they remember to look at the checklists. We encourage our developers to keep the checklists mounted prominently in their workspaces so that they can be reminded of them, at least during code reviews and pair programming.
Analysis and Design: Since we're using SCRUM, most of the analysis and design for new features takes place during and shortly after a sprint planning meeting. It is generally at this point that the team is putting together screenshots and/or prototypes and thinking about what the database schema might look like (assuming that they are doing UI-first development).
Coding: These items help ensure that the developer is thinking about indexes and unique constraints on new database tables, commenting code, "leaving a trail of goodness", etc.
Finalization: At this point, the team is integration testing the feature, dotting the i's and crossing the t's, and communicating changes to IT and other teams.
Checklists can help developers to remember the details and avoid obscure bugs...as long as they remember to look at the checklists. We encourage our developers to keep the checklists mounted prominently in their workspaces so that they can be reminded of them, at least during code reviews and pair programming.
No comments:
Post a Comment