SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
(Intro)
 
(23 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
-
This is a continuation of an effort to streamline SA (and BA) work. Fist article is here: [[SA re defined]]
+
Due to additional negative feedback about recently submitted designs/specifications I introduce the following additional directives:
-
Due to additional negative feedback about recently submitted designs/specifications I introduce the following directives:
+
== Directives ==
 +
 
 +
=== We need to bring Systems Analysis on a new professional level ===
-
* 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 or/and new staff must be hired
+
** existing staff must be re-trained and new staff must be hired
-
** For now: Alex will do SA for [[Project]] type tasks; all other tasks (tweaks) can be forwarded to Andrei for SA
+
** 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:
+
=== 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:
+
=== To improve BA to SA cooperation ===
-
** BA is to post/manage her info in [[RFD]] type wiki
+
* BA is to post/manage her info in [[RFSA]] wiki and to forward this to SA
-
** SA is to post/manage his work in Dev type wiki
+
* SA is to post/manage his work in [[RFD]] wiki and to forward this to Developer (subject to review by Architect in some cases).
-
** See example here: [[:Category:Acc]]
+
* [[RFSA]] wikis are in: [[:Category:RFSA]]
-
** SA is to forward only dev type wiki to Architect/Developer
+
** 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]
-
** SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
+
=== I am adding impact mantis field ===
-
** SA should avoid repeating info that was already presented in BA section
+
* 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:
+
=== Role of Architect to be introduced ===
-
** must review all [[Project]] type specs and major tweaks (after BA and SA sections are completed)
+
* 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
+
* must post Architect comments into "Architect Review" section
-
** If Architect rejects solution then it must be returned to SA (not BA)
+
* 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
+
* If solution is accepted then developer must be assigned and task forwarded for estimation
-
** Kostya will play this role
+
* Kostya will play this role
-
* Spec will have the following structure: (template is here [[Spec Example]])
+
=== Spec will have the following structure ===
 +
 
 +
* template is here [[Spec Example]])
  1 Info
  1 Info
-
  2 Business Analysis
+
  2 Requirements and Solutions
-
  2.1 Requirements
+
  3 Architect Review
-
  2.2 Possible solutions
+
  4 Implementation Notes
-
  2.3 RFP
+
  5 QA Plan
-
  3 Systems Analysis
+
  6 History
-
4 Architect Review
+
-
  5 Implementation Summary
+
-
  6 QA Plan
+
-
  7 History
+
* I introduce Implementation Summary section
* I introduce Implementation Summary section
-
** needed since "Systems Analysis" section will not provide exact solution, just direction in many cases
+
** 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.
-
* I am adding "impact" mantis field. With values: {ihigh, imed, ilow}
+
* <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>
-
** This value indicates a level of impact of particular task on entire system deign
+
** Not discussing might result in: a) a very lengthy spec; b) rejection of solution later
-
** tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
+
** Architect / Developer must always find time to talk to SA
-
** tasks with impact = ilow could be assigned directly to Developer
+
 
-
* Below see examples of specs that were built with new principles in mind.
+
=== Keep spec simple and short ===
-
Examples:
+
* 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]]

Current revision as of 17:29, 23 December 2010


Contents

[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
  • 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

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

[edit] Examples of specs that were built with new principles in mind

Personal tools