CT2 Development Process v2

From UG

(Difference between revisions)
Jump to: navigation, search
 
(31 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 31: Line 31:
* 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 43:
'''CT2 Project Manager'''
'''CT2 Project Manager'''
* time/scope leadership of CT2 project
* time/scope leadership of CT2 project
 +
 +
== CT2 Supercomponent Team ==
Each CT2 Supercomponent Team consists of 2 groups of people:
Each CT2 Supercomponent Team consists of 2 groups of people:
Line 52: Line 54:
-
'''Business Analyst'''  
+
'''[[Business Analyst]]'''  
-
* logistics/transportation expert/manager
+
 
-
* invents, initiates features, components, formulates business needs and requirements
+
 
-
* communicates/transfers these requirements to Systems Analyst
+
'''[[Systems Analyst]]'''
-
'''Systems Analyst'''
 
-
* IT expert, core knowledge of logistics/transportation required
 
-
* interview Business Analyst
 
-
* creates wiki spec doc that describes detailed business requirements and specifications
 
-
* this wiki spec is all developer and QA need to fully implement feature/component
 
-
* transfers specs to development team
 
'''Project manager'''
'''Project manager'''
Line 74: Line 70:
* 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 83: 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 90: 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 97: 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 115: Line 111:
* etc
* etc
 +
== CT2 Workflows ==
-
== CT2 Workflow for Changes ==
+
For each task type as defined above there is a special workflow.
-
=== Initiation ===
+
-
* BA comes up with new idea and in some cases documents it
+
-
* '''mantis:''' do nothing
+
-
* '''PPlan:''' do nothing
+
-
=== Transfer to SA ===
+
Read this section as a separate article here: '''[[CT2 Workflows]]'''
-
* BA transfers business requirements to SA. This could take several sessions
+
-
* '''mantis:''' at this point or earlier mantis task must be created, assigned to SA and moved to "Specs" mantis folder
+
-
* '''PPlan:''' do nothing
+
-
=== Documenting Specs ===
+
== CT2 Project Method and Plan ==
-
* SA creates first detailed version of specs
+
-
* review and finalize with BA
+
-
* review with CT2 Systems Architect
+
-
* '''mantis:''' assign to Systems Architect, he returns task, set as completed
+
-
* '''PPlan:''' do nothing
+
-
=== Transfer of specs to development team ===
+
Read this section as a separate article here: '''[[CT2 Project Method and Plan]]'''
-
* SA transfer specs to development team
+
-
** '''mantis:''' assign task to Dev Manager
+
-
* Dev Manager invites QA, Graphic Designer and Developer to discuss specs
+
-
** meet in skype for initial discussion
+
-
** '''mantis:''' everyone post questions as Notes into task (or attach), set feedback, assign to Sys Analyst
+
-
** dev team must suggest alternatives in design and solutions with ''emh''
+
-
** graph designer starts working on design
+
-
** QA starts working on Test Plan
+
-
* In some cases SA must discuss questions from dev team with BA
+
-
* At some point dev team agree that spec is complete and accepts it
+
-
* QA creates Test Plan for it:
+
-
** '''mantis:''' attach QA plan to task
+
-
* Developer estimates:
+
-
** '''mantis:''' set "emh" field
+
-
* Graphic designer finalizes graphics
+
-
** '''mantis:''' attach approved graphics to mantis
+
-
* Dev Manager:
+
-
** '''mantis:''' after all above is completed set task as "complete" and leave assigned to yourself
+
-
** '''PPlan:''' do nothing
+
-
 
+
-
=== Scheduling the task ===
+
-
* At some point this task will be selected for a Sprint (See Proj Management sec below)
+
-
* '''mantis:''' set ETA, assign to developer, move to development
+
-
* '''PPlan:''' add task to project plan with ETA
+
-
 
+
-
=== Development ===
+
-
* after developer completed task:
+
-
** developer must deploy
+
-
** '''mantis:''' move to '''QA''' mantis folder; assign to QA
+
-
* QA must test
+
-
**  '''mantis:''' attach bug report
+
-
* if QA = passed:
+
-
** '''mantis:''' set "QApf"=pass; move to '''Demo''' mantis folder
+
-
* if QA = failed:
+
-
** '''mantis:''' set "QApf"=fail; move back to '''Dev''' mantis folder, assign to developer
+
-
* Dev Manager must monitor progress, if there is a chance for delay:
+
-
** notify SA immediately, discuss alternatives (cancel feature, postpone, minimize, drop other features for this Sprint, etc)
+
-
** '''PPlan:''' update plan if needed
+
-
 
+
-
=== Demo ===
+
-
* SA:
+
-
** test major use cases before demo
+
-
** demo to the CT2 Board
+
-
** collect tweaks
+
-
 
+
-
=== Tweaks ===
+
-
* SA:
+
-
** '''specs:''' add tweaks to wiki
+
-
** '''mantis:''' create task for twaeks; move it to "Specs"; assign to Dev Manager
+
-
** tweaks must be discussed with dev team and set aside to be included later into Sprint
+
-
 
+
-
=== Release into Production ===
+
-
* at this moment we do not release one component at a time, all changes accumulate and will be released together at the moment when release is scheduled
+
-
 
+
-
== CT2 Workflow for Bugs ==
+
-
== CT2 Workflow for Etc ==
+
-
 
+
-
=== 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 Planning 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)
+
== Release Procedure ==
== Release Procedure ==
-
TBD
+
All accumulated code in SVN Trunk (on /CyberTrax) released at once.
 +
In the future we will have bugfix releases
== 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
Line 268: Line 168:
* 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
-
 
-
 
-
 
-
== 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