CT2 Development Process v2

From UG

(Difference between revisions)
Jump to: navigation, search
(Created page with ' <span style="color:orange; font-size:14pt">! This is UNDER CONSTRUCTION (NOT COMPLETED YET). Old version of this article here: CT2 Development Process v2 </span> This art…')
 
(83 intermediate revisions not shown)
Line 1: Line 1:
-
+
[[Category:Software Development Processes]]
-
<span style="color:orange; font-size:14pt">! This is UNDER CONSTRUCTION (NOT COMPLETED YET). Old version of this article here: [[CT2 Development Process v2]]
+
<span style="color:red; font-size:14pt">! This is OUTDATED! Old version of this article here: [[CT2 Development Process]]
</span>
</span>
-
This article defines what methodology, roles, workflow, etc we use.
 
-
== Overview ==
+
== Intro ==
 +
This article defines what methodology, roles, workflow, etc we use in CT2 Web Software Development.
-
CT2 System consists of CT2 components (Client App, Ops, OpsReps, Acc. etc).
+
== CT2 Supercomponents ==
-
We develop each component separately. It has its own team, project plan, etc.
+
CT2 System is large and can be divided into the following supercomponents (supertasks):
-
== Methodology ==
+
* Acc
 +
* Client App
 +
* OpsReps
-
We use our own methodology that is influenced by Scrum, Agile, Waterfall, Mantis, Outsourcing.
+
* Ops
 +
* OpsPdfs
 +
* Admin
 +
* Misc
-
== Examples In This Doc ==
+
Each supercomponent has its own Development team, project plan, etc.
-
'''Note:''' Text in ''italic'' represents values for [[Client Application]] Supercomponent Team
+
-
== Users ==
+
Some coordination between teams is needed because supercomponents are interrelated to a certain degree.
-
'''Future users of CT2''' - operators, management, etc. (''non jag operators and management'')
+
== CT2 Team ==
-
== Business (Client/Sponsor) Team ==
+
'''CT2 Acceptance Board (The Board)(Committee)(Demo Meeting)'''
 +
Group of people who:
 +
* initiated the CT2 project
 +
* oversees general progress
 +
* demo meeting is conducted for The Board
 +
* makes final decision about acceptance, tweaks, course of the project
-
'''Acceptance Board (The Board)(Committee)(Demo Meeting)''' - group of people who makes final decision about acceptance, tweaks, course of the project. (''sometimes Simon alone, sometimes Simon, Marc, Alex, Tira together'')
+
'''Chairman of Acceptance Board'''  
 +
* person who makes final decision in case there is a conflict
-
'''Chairman of Acceptance Board''' (''Simon'')
 
-
'''Biz analyst/architect''' - biz expert (''Simon'')
+
'''CT2 Systems Architect'''
-
* invents detailed '''biz requirements''' for the component
+
* Technical leadership of CT2 project
-
* transfers these requirements to Sys Analyst
+
-
'''Sys analyst/Architect''' - IT expert (''Tira'')
+
'''CT2 Project Manager'''
-
* translates detailed biz requirements into '''specs'''
+
* time/scope leadership of CT2 project
-
* transfers specs to development team
+
-
'''Project manager''' - time/scope management expert (''Tira'')
+
== CT2 Supercomponent Team ==
-
* accountable for reaching the stated project objectives
+
-
* managing '''high level''' of proj plan: start/end dates of development, specing dates, weekly demo dates, release dates
+
-
== Software Development (Vendor) team ==
+
Each CT2 Supercomponent Team consists of 2 groups of people:
 +
* Business Team (Client/Sponsor)
 +
* (Software) Development Team (Vendor)
-
'''Development Manager (Lead)''' - leader of the development team (''Slava'')
+
== CT2 Supercomponent Business Team ==
 +
 
 +
 
 +
 
 +
'''[[Business Analyst]]'''
 +
 
 +
 
 +
'''[[Systems Analyst]]'''
 +
 
 +
 
 +
'''Project manager'''
 +
* time/scope management expert
 +
* accountable for delivering component on time and on budget
 +
* managing/coordinating '''business phases''' of '''CT2 Software Development Worflow''' (see below)
 +
 
 +
== CT2 Supercomponent Development Team ==
 +
 
 +
'''Development Manager ''' - leader of the development team
* coordinates development effort
* coordinates development effort
* manages resources
* manages resources
-
* manages '''low level''' of proj plan: detailed development schedule that includes phases of development, bugfix, QA, graphics (for every '''sub-component/dev task''')
+
* manages '''dev phase''' of proj plan: detailed development schedule that includes phases of development, bugfix, QA, graphics (for every '''sub-component/dev task''')
-
* gets '''daily''' updates from developer, QA, graphic designer regarding deadlines
+
* collects updates from developer, QA, graphic designer regarding deadlines
-
* if there is a chance for ETA to be postponed then he immediately notifies Project Manager and they both decide what to do: move tasks around, add resources or push ETA forward or do something else
+
* if there is a chance for ETA to be postponed then he must notify Project Manager ASAP and they both decide what to do: move tasks around, add resources or push ETA forward or do something else
-
'''QA engineer (or manager)''' (''Andrei'')
+
'''QA Engineer '''
* makes sure that specs are complete
* makes sure that specs are complete
* creates test plans
* creates test plans
* runs test plans
* runs test plans
* forwards bugs to developer
* forwards bugs to developer
-
* provides ETA for his work to '''Development Lead'''
+
* provides ETA for his work to '''Development Manager'''
-
* must immediately notify '''Development Lead''' if his ETA can slip
+
* must immediately notify '''Development Manager''' if his ETA can slip
-
'''Developer''' (''Sasha'')
+
'''Developer'''
* makes sure specs are complete
* makes sure specs are complete
* implements new sub-components, changes, tweaks, bug fixes
* implements new sub-components, changes, tweaks, bug fixes
* deploy, forwards his work to QA
* deploy, forwards his work to QA
-
* provides ETA for his work to '''Development Lead'''
+
* provides ETA for his work to '''Development Manager'''
-
* must immediately notify '''Development Lead''' if his ETA can slip
+
* must immediately notify '''Development Manager''' if his ETA can slip
-
'''Graphic designer''' (''Slava'')
+
'''Graphic designer'''
* responsible for creating overall Look and Feel concept
* responsible for creating overall Look and Feel concept
* creates Style Guide
* creates Style Guide
* creates all graphics for application
* creates all graphics for application
-
* provides ETA for his work to '''Development Lead'''
+
* provides ETA for his work to '''Development Manager'''
-
* must immediately notify '''Development Lead''' if his ETA can slip
+
* must immediately notify '''Development Manager''' if his ETA can slip
-
== Project Workflow and Mantis ==
+
== CT2 Task and Bug Management System ==
 +
We use Mantis software as a main CT2 Tasks and Bugs Management System.
-
Note: All below is specific to Mantis soft we use.
+
Read this section as a separate article here: '''[[Mantis and CT2]]'''
-
It is explained using [[Client Application]] CT2 Super Component as an example.
+
== CT2 Task Types ==
 +
All tasks (ativities) we classify into:
 +
* major changes:
 +
** request for new components
 +
** request for new version of existing component
 +
* minor changes:
 +
** request for tweak (minor change of existing component)
 +
* bug
 +
* etc
-
=== Decomposing Super Component into Components and Tasks ===
+
== CT2 Workflows ==
-
At some point it will be clear how to split specific super component (and its development) into a number of large subcomponents.
+
-
At this point Sys Analyst creates "mantis parent records" for each super component under Mantis project=[SuperCompName]. ''For example under Mantis Project=>>(Client) for [[Client Application]]'' you will see:
+
For each task type as defined above there is a special workflow.
-
595 [Client.*Misc] =================== Client
+
Read this section as a separate article here: '''[[CT2 Workflows]]'''
-
924 [Client.CTdetails]
+
-
919 [Client.HomePage]
+
-
921 [Client.ListAll]
+
-
1015 [Client.LogInPanel]
+
-
685 [Client.LookAndFeel]
+
-
939 [Client.MAWBtracking]
+
-
922 [Client.MyProfile]
+
-
591 [Client.Reports]
+
-
920 [Client.WatchList]
+
-
925 [Client.WhereIs]
+
-
== Creating specific tasks for each component ==
+
== CT2 Project Method and Plan ==
-
Sys Analyst creates tasks for each component and links as ''child'' to ''parent record'' so it is easy to see any time what tasks are there for each component and in what state.
+
-
Main task would be "Implement ver x.xx". But some of these tasks are bugs, tweaks, etc. For example under parent component ''0001015: [Client.LogInPanel] '' we see:
+
Read this section as a separate article here: '''[[CT2 Project Method and Plan]]'''
-
parent of 0001016 started andrei 4.QAbasic [Client.LogInPanel] Implement ver1.0 
+
== Release Procedure ==
-
parent of 0001017 new slava 00.Graphics [Client.LogInPanel] Create Look and Feel for ver# 1.0 
+
All accumulated code in SVN Trunk (on /CyberTrax) released at once.
-
parent of 0001024 new dima 3b.Dev         [Client.LogInPanel] BUG: Login from another application hyperlink (MS Exel - hyperlink - Client)
+
-
Tasks are classified into:
+
In the future we will have bugfix releases
-
* '''changes''' (new features, new versions of existing features/components, tweaks/changes)
+
-
* '''bugs'''
+
-
 
+
-
== Mantis Projects ==
+
-
Mantis Project is a "top filter" (see top right corner). We use it to separate different phases/states of development: specing (sys. analysis), development, QA, demo, etc.
+
-
 
+
-
Each task can be only in one state at a time.
+
-
 
+
-
== Typical Workflow for Changes ==
+
-
 
+
-
* Sys Analyst and Biz Analyst discuss change/new ver of component
+
-
 
+
-
* At some point task is created, assigned to Sys An and moved to "Specs"
+
-
 
+
-
* Once specs are complited (added to wiki) they must be passed to Development Team - move to "Dev" and assign to one of the members on Dev Team
+
-
+
-
option A) pass it to QA who will analyze for completeness
+
-
option B) pass it to both developer and QA
+
-
option C) pass it Dev Team Lead who will decide how to organize spec transfer
+
-
 
+
-
* Once specs are accepted by dev team, developer and QA both give ETA for Scrum and Proj ''High'' Plan gets updated with ''Demo date for component''
+
-
 
+
-
option A) QA creates Test Plan ''before'' development starts (this would increase total time)
+
-
option B) QA creates Test Plan ''during'' development (best? two subtasks are done in parallel)
+
-
option C) QA creates Test Plan ''after'' development starts (this would increase total time)
+
-
 
+
-
* After development is complete developer must: commit, make sure all deployed,  move task into "QA" and assigns to QA
+
-
 
+
-
* QA tests and if any bugs found passes back the task to developer (move to "Dev")
+
-
 
+
-
* Bug free task will be moved to "Demo" and assigned to Sys Analyst
+
-
 
+
-
* Sys An will run top use cases to verify before showing it to '''the Board''' on '''Demo meeting'''
+
-
 
+
-
== Typical Workflow for Bugs ==
+
-
TBD
+
== Communication ==
== Communication ==
 +
=== Through Mantis ===
If there is a question regarding task then:
If there is a question regarding task then:
-
* post qustion into Mantis notes
+
* post question into Mantis notes
* set task to feedback
* set task to feedback
* assign to person you are asking
* assign to person you are asking
* if urgent contact that person in Skype
* if urgent contact that person in Skype
-
If there is a general question - use email. CC as required.
+
=== Through email ===
 +
* If there is a general question - use email. CC to your manager and others as required
 +
* Everyone must check email at least 2 times a day: at the beginning and at the end of workday
-
In addition there are:
+
=== Comm between Sys Analyst and Dev Manager ===
-
* Weekly Status Meetings
+
-
* Communication Hours
+
-
Sys Analyst and Dev Team Lead must be able to reach each other during extended timeframe.
+
They agree on how to reach each other during extended timeframe.
-
Note: To be always be available in Skype - chance for constant iteruption.
+
=== Urgent Communication ===
-
It is not clear how much of interruption to allow.
+
-
In some cases it could be very useful, in some cases very contr productive
+
-
(especially during tasks that require high concentration)
+
-
 
+
-
In case of urgency (app is down, etc):
+
* we must define what can happen and how to reach someone we need to reach to solve urgency
* we must define what can happen and how to reach someone we need to reach to solve urgency
-
== Weekly Status Meetings ==
+
=== Weekly Status Meetings ===
* Why: These meetings are group chats in Skype with Agenda to update each other on progress
* Why: These meetings are group chats in Skype with Agenda to update each other on progress
Line 174: Line 154:
  Reports and Accounting Team (summer 2009 schedule): Tuesd, Thur: 9:15-10am NY time
  Reports and Accounting Team (summer 2009 schedule): Tuesd, Thur: 9:15-10am NY time
-
== Communication Hours ==
+
=== Communication Hours ===
*Who: Dev Team + Sys An
*Who: Dev Team + Sys An
Line 185: Line 165:
* If somebody can not attend he must notify Dev Team Lead and give alternative time frame that he is available same day
* If somebody can not attend he must notify Dev Team Lead and give alternative time frame that he is available same day
-
== Vacations and Days Off ==
+
=== Vacations and Days Off ===
* Must notify Dev Team Lead as much in advance as possible
* Must notify Dev Team Lead as much in advance as possible
* Dev Team Lead must post this info into Dev Calendar
* Dev Team Lead must post this info into Dev Calendar
-
 
-
== Scrum and Sprints ==
 
-
 
-
Scrum is an approach we use to scheduling components/tasks into development.
 
-
 
-
Planning is based on weekly or bi weekly or any regular time intervals that is called ''Sprint''.
 
-
 
-
Before the start of the Sprint team is looking at current tasks backlog (new components, bugs, tweaks, changes, etc) and select a number of tasks for next Sprint based on prioity, size of tasks, resources available, etc.
 
-
 
-
Note that conventional approach is to estimate each task and build a sequence (plan). One of the advantages of Scrum I guess is that it has always same distance between milestones.
 
-
 
-
So under Scrum if there is an ETA slip for given task then instead of re-scheduling milestone (demo date) we move delayed component to next demo and ideally work on and show something else instead for current milestone (demo).
 
-
 
-
If Release Date is fixed then all Sprints must be planned in advance so that they cover entire backlog.
 
-
 
-
== Project Plan Document with Mantis and Scrum ==
 
-
 
-
* Developer must set '''emh'''(estimated man hours) hor each task
 
-
* QA must indicate his '''QAemh'''
 
-
* Based on: Dev emh, QA emh, ds (priority) and other constraints (like other tasks, days off, etc) Dev Team Lead together with QA and Developer must create Task List for next Sprint.
 
-
* If Sprints are say weekly and start on Monday then this Task List consists of all tasks that will be ready for Demo on Friday
 
-
* For all these tasks Dev Team Lead must set '''due(ETA)''' field
 
-
* This Task List for next Sprint must be approved by all and presented to Sys Analyst and to the last Status Update Meeting of previous week.
 
-
* These ETA will be included into '''high''' level Proj Plan and be presented to '''the Board'''.
 
-
* Using Mantis sorting and filtering features these tasks could be easily extracted and migrated to xls or other format.
 
-
* I suggest incorporating into planning 1 day / week of developer time for tweaks and bugs --[[User:Alex|Alex]] 06:30, 23 July 2009 (UTC)
 
-
 
-
== Managing Time and Scope ==
 
-
It is very hard but if we want to fix '''Release Date''' then we all must:
 
-
 
-
1) be VERY serious about ETA
 
-
 
-
2) use techniques to avoid and solve this problem. See below.
 
-
 
-
=== Timeboxing ===
 
-
=== Scoping ===
 
-
 
-
 
-
[[Category:PM]]
 

Current revision as of 19:46, 24 May 2010


! This is OUTDATED! Old version of this article here: CT2 Development Process


Contents

[edit] Intro

This article defines what methodology, roles, workflow, etc we use in CT2 Web Software Development.

[edit] CT2 Supercomponents

CT2 System is large and can be divided into the following supercomponents (supertasks):

  • Acc
  • Client App
  • OpsReps
  • Ops
  • OpsPdfs
  • Admin
  • Misc

Each supercomponent has its own Development team, project plan, etc.

Some coordination between teams is needed because supercomponents are interrelated to a certain degree.

[edit] CT2 Team

CT2 Acceptance Board (The Board)(Committee)(Demo Meeting) Group of people who:

  • initiated the CT2 project
  • oversees general progress
  • demo meeting is conducted for The Board
  • makes final decision about acceptance, tweaks, course of the project

Chairman of Acceptance Board

  • person who makes final decision in case there is a conflict


CT2 Systems Architect

  • Technical leadership of CT2 project

CT2 Project Manager

  • time/scope leadership of CT2 project

[edit] CT2 Supercomponent Team

Each CT2 Supercomponent Team consists of 2 groups of people:

  • Business Team (Client/Sponsor)
  • (Software) Development Team (Vendor)

[edit] CT2 Supercomponent Business Team

Business Analyst


Systems Analyst


Project manager

  • time/scope management expert
  • accountable for delivering component on time and on budget
  • managing/coordinating business phases of CT2 Software Development Worflow (see below)

[edit] CT2 Supercomponent Development Team

Development Manager - leader of the development team

  • coordinates development effort
  • manages resources
  • manages dev phase of proj plan: detailed development schedule that includes phases of development, bugfix, QA, graphics (for every sub-component/dev task)
  • collects updates from developer, QA, graphic designer regarding deadlines
  • if there is a chance for ETA to be postponed then he must notify Project Manager ASAP and they both decide what to do: move tasks around, add resources or push ETA forward or do something else

QA Engineer

  • makes sure that specs are complete
  • creates test plans
  • runs test plans
  • forwards bugs to developer
  • provides ETA for his work to Development Manager
  • must immediately notify Development Manager if his ETA can slip

Developer

  • makes sure specs are complete
  • implements new sub-components, changes, tweaks, bug fixes
  • deploy, forwards his work to QA
  • provides ETA for his work to Development Manager
  • must immediately notify Development Manager if his ETA can slip

Graphic designer

  • responsible for creating overall Look and Feel concept
  • creates Style Guide
  • creates all graphics for application
  • provides ETA for his work to Development Manager
  • must immediately notify Development Manager if his ETA can slip

[edit] CT2 Task and Bug Management System

We use Mantis software as a main CT2 Tasks and Bugs Management System.

Read this section as a separate article here: Mantis and CT2

[edit] CT2 Task Types

All tasks (ativities) we classify into:

  • major changes:
    • request for new components
    • request for new version of existing component
  • minor changes:
    • request for tweak (minor change of existing component)
  • bug
  • etc

[edit] CT2 Workflows

For each task type as defined above there is a special workflow.

Read this section as a separate article here: CT2 Workflows

[edit] CT2 Project Method and Plan

Read this section as a separate article here: CT2 Project Method and Plan

[edit] Release Procedure

All accumulated code in SVN Trunk (on /CyberTrax) released at once.

In the future we will have bugfix releases

[edit] Communication

[edit] Through Mantis

If there is a question regarding task then:

  • post question into Mantis notes
  • set task to feedback
  • assign to person you are asking
  • if urgent contact that person in Skype

[edit] Through email

  • If there is a general question - use email. CC to your manager and others as required
  • Everyone must check email at least 2 times a day: at the beginning and at the end of workday

[edit] Comm between Sys Analyst and Dev Manager

They agree on how to reach each other during extended timeframe.

[edit] Urgent Communication

  • we must define what can happen and how to reach someone we need to reach to solve urgency

[edit] Weekly Status Meetings

  • Why: These meetings are group chats in Skype with Agenda to update each other on progress
  • Who: Dev Team + Sys Analyst 
Client App Team (summer 2009 schedule): Tuesd, Thur: 10-10:45am NY time
Reports and Accounting Team (summer 2009 schedule): Tuesd, Thur: 9:15-10am NY time

[edit] Communication Hours

  • Who: Dev Team + Sys An
  • What: All must be available in Skype
  • Why: In case somebody needs to discuss not through Mantis, but "live" through chat
  • When: 
For All Super Components: Mon, Tue, Wed, Thur, Fri: 9-11am NY time
  • If somebody can not attend he must notify Dev Team Lead and give alternative time frame that he is available same day

[edit] Vacations and Days Off

  • Must notify Dev Team Lead as much in advance as possible
  • Dev Team Lead must post this info into Dev Calendar
Retrieved from "https://wiki.jaguarfreight.com/CT2_Development_Process_v2"
Personal tools