CT2 Development Process v2
From UG
! This is UNDER CONSTRUCTION (NOT COMPLETED YET). Old version of this article here: CT2 Development Process
Intro
This article defines what methodology, roles, workflow, etc we use in CT2 Web Software Development.
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.
CT2 Team
CT2 Acceptance Board (The Board)(Committee)(Demo Meeting) Group of people who:
- initiated the CT2 project
- oversees general progress
- looks at new component and system releases
- 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
Each CT2 Supercomponent Team consists of 2 groups of people:
- Business Team (Client/Sponsor)
- (Software) Development Team (Vendor)
CT2 Supercomponent Business Team
Business Analyst
- logistics/transportation expert/manager
- invents, initiates features, components, formulates business needs and requirements
- communicates/transfers these requirements to 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
- 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
- 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
- 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
CT2 Task and Bug Management System
We use Mantis software as a main CT2 Tasks and Bugs Management System.
Read Mantis and CT2 article!
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
CT2 Workflow for Changes
Initiation
- BA comes up with new idea and in some cases documents it
- mantis: do nothing
- PPlan: do nothing
Transfer to SA
- 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
- 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
- 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
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 (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)
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.
