CT2 Development Process
From UG
This article defines what methodology, roles, workflow, etc we use.
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.
Methodology
We use our own methodology that is influenced by Scrum, Agile, Waterfall, Mantis, Outsourcing.
Examples In This Doc
Note: Text in italic represents values for Client Application Supercomponent Team
Users
Future users of CT2 - operators, management, etc. (non jag operators and management)
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. (sometimes Simon alone, sometimes Simon, Marc, Alex, Tira together)
Chairman of Acceptance Board (Simon)
Biz analyst/architect - biz expert (Simon)
- invents detailed biz requirements for the component
- transfers these requirements to Sys Analyst
Sys analyst/Architect - IT expert (Tira)
- translates detailed biz requirements into specs
- transfers specs to development team
Project manager - time/scope management expert (Tira)
- 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
Development Lead - leader of the development team (Slava)
- 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) (Andrei)
- 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 immedialy notify Development Lead if his ETA can slip
Developer (Sasha)
- 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 immedialy notify Development Lead if his ETA can slip
Graphic designer (Slava)
- 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 immedialy notify Development Lead if his ETA can slip
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.
Decomposing Super Component into Components and Tasks
At some point it will be clear how to split specific component (and its development) into a number of large subcomponents.
At this point Sys Analyst creates "mantis parent records" for each component under Mantis project=[SuperCompName]. For example under Mantis Project=>>(Client) for Client Application
So 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]
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
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
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
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
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
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
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 Dev Team Lead together with QA and Developer must create Task List for next Sprint.
- If Sprints are say weekly the this Task List consists of all tasks that will be ready for Demo after next Sprint
- 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)
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.
