SA re defined part 2
From UG
(Difference between revisions)
(→Intro) |
|||
(19 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:News]] | ||
+ | |||
+ | == Intro == | ||
+ | |||
+ | See 1st part of the article here: [[SA re defined]] | ||
+ | |||
'''Subject:''' New directives to streamline SA (and BA) work | '''Subject:''' New directives to streamline SA (and BA) work | ||
Line 5: | Line 11: | ||
'''To''': CT2 Team | '''To''': CT2 Team | ||
- | + | Due to additional negative feedback about recently submitted designs/specifications I introduce the following additional directives: | |
- | + | == Directives == | |
+ | |||
+ | === We need to bring Systems Analysis on a new professional level === | ||
- | |||
** It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities | ** It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities | ||
** core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and [[Proposal]]) | ** core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and [[Proposal]]) | ||
- | ** existing staff must be re-trained | + | ** existing staff must be re-trained and new staff must be hired |
** For now: Alex will do SA for impact=ihigh type tasks; impact=ilow can be forwarded to Andrei for SA; impact=imed to Andrei or Alex. | ** For now: Alex will do SA for impact=ihigh type tasks; impact=ilow can be forwarded to Andrei for SA; impact=imed to Andrei or Alex. | ||
- | + | === We need to continue to improve BAs work === | |
** continue to train BAs to bring their skills and experience to acceptable level | ** continue to train BAs to bring their skills and experience to acceptable level | ||
** skills that are critical for BA role: writing, analytical thinking, interviewing | ** skills that are critical for BA role: writing, analytical thinking, interviewing | ||
** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc | ** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc | ||
- | + | === To improve BA to SA cooperation === | |
- | + | * BA is to post/manage her info in [[RFSA]] wiki and to forward this to SA | |
- | + | * SA is to post/manage his work in [[RFD]] wiki and to forward this to Developer (subject to review by Architect in some cases). | |
- | ** | + | * [[RFSA]] wikis are in: [[:Category:RFSA]] |
- | ** | + | ** example of naming convention: [[2211 rfsa]] |
+ | * [[RFD]] wikis are in: [[:Category:RFD]] | ||
+ | ** example of naming convention: [[2211 rfd]] | ||
+ | * [[RFSA]] wikis are for SAs only! Use special background color to make sure developers/architects do not get confused: | ||
+ | [div style="background-color:wheat"] .... [/div] | ||
+ | |||
+ | === I am adding impact mantis field === | ||
+ | * With values: {ihigh, imed, ilow} | ||
+ | * This value indicates a level of impact of particular task on entire system deign | ||
+ | * tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase | ||
+ | * tasks with impact = ilow could be assigned directly to Developer | ||
- | + | === Role of Architect to be introduced === | |
- | + | * tasks with impact = ihigh/imed must be reviewed by Architect (after BA and SA sections are completed) | |
- | + | * must post Architect comments into "Architect Review" section | |
- | ** | + | * If Architect rejects solution then it must be returned to SA (not BA) |
- | * | + | * If solution is accepted then developer must be assigned and task forwarded for estimation |
+ | * Kostya will play this role | ||
- | + | === Spec will have the following structure === | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | * | + | * template is here [[Spec Example]]) |
1 Info | 1 Info | ||
- | 2 | + | 2 Requirements and Solutions |
- | + | 3 Architect Review | |
- | + | 4 Implementation Notes | |
- | + | 5 QA Plan | |
- | 3 | + | 6 History |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
* I introduce Implementation Summary section | * I introduce Implementation Summary section | ||
- | ** needed | + | ** It is optional but needed IF "Requirements and Solutions" section does not provide exact solution, just direction |
** to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution. | ** to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution. | ||
+ | * <font color="red">SA must first to discuss solution/requirements with Architect/Developer if he feels that request is "not simple and could be translated into alternative non-standard solutions, etc </font> | ||
+ | ** Not discussing might result in: a) a very lengthy spec; b) rejection of solution later | ||
+ | ** Architect / Developer must always find time to talk to SA | ||
+ | === Keep spec simple and short === | ||
- | + | * keep it simple | |
+ | * keep it short | ||
+ | * do not say same thing twice | ||
+ | * if not sure about something then discuss it first (over mantis,email, Skype) before writing about it in spec | ||
+ | === Examples of specs that were built with new principles in mind === | ||
* [[0002525 PI redesign]] | * [[0002525 PI redesign]] | ||
* [[2157 dev]] | * [[2157 dev]] |
Current revision as of 17:29, 23 December 2010
[edit] Intro
See 1st part of the article here: SA re defined
Subject: New directives to streamline SA (and BA) work
From: CT2 Project Manager
To: CT2 Team
Due to additional negative feedback about recently submitted designs/specifications I introduce the following additional directives:
[edit] Directives
[edit] We need to bring Systems Analysis on a new professional level
- It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities
- core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and Proposal)
- existing staff must be re-trained and new staff must be hired
- For now: Alex will do SA for impact=ihigh type tasks; impact=ilow can be forwarded to Andrei for SA; impact=imed to Andrei or Alex.
[edit] We need to continue to improve BAs work
- continue to train BAs to bring their skills and experience to acceptable level
- skills that are critical for BA role: writing, analytical thinking, interviewing
- BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
[edit] To improve BA to SA cooperation
- BA is to post/manage her info in RFSA wiki and to forward this to SA
- SA is to post/manage his work in RFD wiki and to forward this to Developer (subject to review by Architect in some cases).
- RFSA wikis are in: Category:RFSA
- example of naming convention: 2211 rfsa
- RFD wikis are in: Category:RFD
- example of naming convention: 2211 rfd
- RFSA wikis are for SAs only! Use special background color to make sure developers/architects do not get confused:
[div style="background-color:wheat"] .... [/div]
[edit] I am adding impact mantis field
- With values: {ihigh, imed, ilow}
- This value indicates a level of impact of particular task on entire system deign
- tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
- tasks with impact = ilow could be assigned directly to Developer
[edit] Role of Architect to be introduced
- tasks with impact = ihigh/imed must be reviewed by Architect (after BA and SA sections are completed)
- must post Architect comments into "Architect Review" section
- If Architect rejects solution then it must be returned to SA (not BA)
- If solution is accepted then developer must be assigned and task forwarded for estimation
- Kostya will play this role
[edit] Spec will have the following structure
- template is here Spec Example)
1 Info 2 Requirements and Solutions 3 Architect Review 4 Implementation Notes 5 QA Plan 6 History
- I introduce Implementation Summary section
- It is optional but needed IF "Requirements and Solutions" section does not provide exact solution, just direction
- to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
- SA must first to discuss solution/requirements with Architect/Developer if he feels that request is "not simple and could be translated into alternative non-standard solutions, etc
- Not discussing might result in: a) a very lengthy spec; b) rejection of solution later
- Architect / Developer must always find time to talk to SA
[edit] Keep spec simple and short
- keep it simple
- keep it short
- do not say same thing twice
- if not sure about something then discuss it first (over mantis,email, Skype) before writing about it in spec