CT2 Development Process

From UG

(Difference between revisions)

Jump to: navigation, search

Current revision as of 19:30, 24 May 2010

! This is outdated version 1. See next version of this article here: CT2 Development Process v2

This article defines what methodology, roles, workflow, etc we use.

[edit] Overview

CT2 System consists of CT2 components (Client App, Ops, OpsReps, Acc. etc).

We develop each component separately. It has its own team, project plan, etc.

[edit] Methodology

We use our own methodology that is influenced by Scrum, Agile, Waterfall, Mantis, Outsourcing.

[edit] Examples In This Doc

Note: Text in italic represents values for Client Application Supercomponent Team

[edit] Users

Future users of CT2 - operators, management, etc. (non jag operators and management)

[edit] Business (Client/Sponsor) Team

Acceptance Board (The Board)(Committee)(Demo Meeting) - group of people who makes final decision about acceptance, tweaks, course of the project.

Chairman of Acceptance Board

Biz analyst/architect - biz expert

invents detailed biz requirements for the component
transfers these requirements to Sys Analyst

Sys analyst/Architect - IT expert

translates detailed biz requirements into specs
transfers specs to development team

Project manager - time/scope management expert

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

[edit] Software Development (Vendor) team

Development Manager (Lead) - leader of the development team

coordinates development effort
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)
gets daily 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

QA engineer (or manager)

makes sure that specs are complete
creates test plans
runs test plans
forwards bugs to developer
provides ETA for his work to Development Lead
must immediately notify Development Lead 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 Lead
must immediately notify Development Lead 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 Lead
must immediately notify Development Lead if his ETA can slip

[edit] Project Workflow and Mantis

Note: All below is specific to Mantis soft we use.

It is explained using Client Application CT2 Super Component as an example.

[edit] Decomposing Super Component into Components and Tasks

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:

595	[Client.*Misc] =================== Client			
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]

[edit] Creating specific tasks for each component

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:

parent of 	0001016	started	andrei 	4.QAbasic 	[Client.LogInPanel] Implement ver1.0  
parent of 	0001017	new	slava 	00.Graphics 	[Client.LogInPanel] Create Look and Feel for ver# 1.0  
parent of 	0001024	new	dima 	3b.Dev 	        [Client.LogInPanel] BUG: Login from another application hyperlink (MS Exel - hyperlink - Client)

Tasks are classified into:

changes (new features, new versions of existing features/components, tweaks/changes)
bugs

[edit] 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.

[edit] 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

[edit] Typical Workflow for Bugs

TBD

[edit] Communication

If there is a question regarding task then:

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

If there is a general question - use email. CC as required.

In addition there are:

Weekly Status Meetings
Communication Hours

Sys Analyst and Dev Team Lead must be able to reach each other during extended timeframe.

Note: To be always be available in Skype - chance for constant iteruption. 
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

[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

[edit] 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.

[edit] 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 --Alex 06:30, 23 July 2009 (UTC)

[edit] 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.

[edit] Timeboxing

[edit] Scoping