CT2 Development Process v2

From UG

(Difference between revisions)
Jump to: navigation, search
 
(52 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]]
+
<span style="color:red; font-size:14pt">! This is OUTDATED! Old version of this article here: [[CT2 Development Process]]
</span>
</span>
Line 27: Line 27:
== CT2 Team ==
== CT2 Team ==
-
It consists of 2 groups of people:
+
'''CT2 Acceptance Board (The Board)(Committee)(Demo Meeting)'''
-
* Business Team (Client/Sponsor)
+
-
* (Software) Development Team (Vendor)
+
-
 
+
-
== Business Team ==
+
-
 
+
-
'''Acceptance Board (The Board)(Committee)(Demo Meeting)'''
+
Group of people who:
Group of people who:
* initiated the CT2 project
* initiated the CT2 project
* oversees general progress
* oversees general progress
-
* looks at new component and system releases
+
* demo meeting is conducted for The Board
* makes final decision about acceptance, tweaks, course of the project
* makes final decision about acceptance, tweaks, course of the project
Line 43: Line 37:
* person who makes final decision in case there is a conflict
* person who makes final decision in case there is a conflict
-
'''Business Analyst'''
 
-
* logistics/transportation expert/manager
 
-
* invents, initiates features, components, formulates business needs and requirements
 
-
* communicates/transfers these requirements to Systems Analyst
 
-
'''Systems Analyst'''
+
'''CT2 Systems Architect'''
-
* IT expert, core knowledge of logistics/transportation required
+
* Technical leadership of CT2 project
-
* interview Business Analyst
+
 
-
* creates wiki spec doc that describes detailed business requirements and specifications
+
'''CT2 Project Manager'''
-
* this wiki spec is all developer and QA need to fully implement feature/component
+
* time/scope leadership of CT2 project
-
* transfers specs to development team
+
 
 +
== CT2 Supercomponent Team ==
 +
 
 +
Each CT2 Supercomponent Team consists of 2 groups of people:
 +
* Business Team (Client/Sponsor)
 +
* (Software) Development Team (Vendor)
 +
 
 +
== CT2 Supercomponent Business Team ==
 +
 
 +
 
 +
 
 +
'''[[Business Analyst]]'''
 +
 
 +
 
 +
'''[[Systems Analyst]]'''
 +
 
'''Project manager'''
'''Project manager'''
Line 60: Line 65:
* managing/coordinating '''business phases''' of '''CT2 Software Development Worflow''' (see below)
* managing/coordinating '''business phases''' of '''CT2 Software Development Worflow''' (see below)
-
== Development Team ==
+
== CT2 Supercomponent Development Team ==
'''Development Manager ''' - leader of the 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 '''   
'''QA Engineer '''   
Line 74: Line 79:
* 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'''   
'''Developer'''   
Line 81: Line 86:
* 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'''   
'''Graphic designer'''   
Line 88: Line 93:
* 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
== CT2 Task and Bug Management System ==
== CT2 Task and Bug Management System ==
We use Mantis software as a main CT2 Tasks and Bugs Management System.
We use Mantis software as a main CT2 Tasks and Bugs Management System.
-
Read [[Mantis and CT2]] article!
+
Read this section as a separate article here:  '''[[Mantis and CT2]]'''
== CT2 Task Types ==
== CT2 Task Types ==
Line 106: Line 111:
* etc
* etc
 +
== CT2 Workflows ==
-
== CT2 Workflow for Changes ==
+
For each task type as defined above there is a special workflow.
-
== CT2 Workflow for Bugs ==
+
Read this section as a separate article here: '''[[CT2 Workflows]]'''
-
== CT2 Workflow for Etc ==
+
-
== (OLD) Typical Workflow for Changes ==
+
== CT2 Project Method and Plan ==
-
* Sys Analyst and Biz Analyst discuss change/new ver of component
+
Read this section as a separate article here: '''[[CT2 Project Method and Plan]]'''
-
* At some point task is created, assigned to Sys An and moved to "Specs"
+
== Release Procedure ==
 +
All accumulated code in SVN Trunk (on /CyberTrax) released at once.
-
* 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
+
In the future we will have bugfix releases
-
+
-
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
-
In addition there are:
+
* Everyone must check email at least 2 times a day: at the beginning and at the end of workday
-
* Weekly Status Meetings
+
-
* Communication Hours
+
-
Sys Analyst and Dev Team Lead must be able to reach each other during extended timeframe.
+
=== Comm between Sys Analyst and Dev Manager ===
-
Note: To be always be available in Skype - chance for constant iteruption.
+
They agree on how to reach each other during extended timeframe.
-
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):
+
=== Urgent Communication ===
* 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 173: 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 184: 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