SA re defined part 2
From UG
(Difference between revisions)
(→About) |
|||
| Line 2: | Line 2: | ||
This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]] | This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]] | ||
| + | |||
| + | Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes: | ||
| + | |||
| + | * Alex will do SA for [[Project]] type tasks. All other tasks (tweaks) can be forwarded to Andrei for SA. | ||
| + | ** New SA will be hired to provide more m/h | ||
| + | * Kostya will play a role of Architect and must review all [[Project]] type specs and major tweaks. | ||
| + | ** He also must post Architect comments into "Architect Review" section (ideally) or mantis | ||
| + | * Spec will have the following structure: | ||
| + | |||
| + | 1 Info | ||
| + | 2 Business Analysis | ||
| + | 2.1 Requirements | ||
| + | 2.2 Possible solutions | ||
| + | 2.3 RFP | ||
| + | 3 Systems Analysis | ||
| + | 4 Architect Review | ||
| + | 5 Implementation Summary | ||
| + | 6 QA Plan | ||
| + | 7 History | ||
| + | |||
| + | * Since "Systems Analysis" section will not provide exact solution developer must fill in "Implementation Summary" so that QA and UAT know how to verify solution. | ||
| + | * SA must help BA to finalize her section. This means potentially re-writing it or writing it together. | ||
| + | * SA should avoid repeating info that was already presented in BA section. | ||
| + | * If Architect rejects solution then it must be returned to SA not BA | ||
== Examples == | == Examples == | ||
Revision as of 23:35, 12 December 2010
About
This is a continuation of an effort to streamline SA work. Fist article is here: SA re defined
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
- Alex will do SA for Project type tasks. All other tasks (tweaks) can be forwarded to Andrei for SA.
- New SA will be hired to provide more m/h
- Kostya will play a role of Architect and must review all Project type specs and major tweaks.
- He also must post Architect comments into "Architect Review" section (ideally) or mantis
- Spec will have the following structure:
1 Info 2 Business Analysis 2.1 Requirements 2.2 Possible solutions 2.3 RFP 3 Systems Analysis 4 Architect Review 5 Implementation Summary 6 QA Plan 7 History
- Since "Systems Analysis" section will not provide exact solution developer must fill in "Implementation Summary" so that QA and UAT know how to verify solution.
- SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
- SA should avoid repeating info that was already presented in BA section.
- If Architect rejects solution then it must be returned to SA not BA
Examples
Below are examples of spec that were built with new principles in mind:
