History
In the early eighties MoD UK produced a
procedure for software development DEF STAN 00-16/1, whilst in the states the
Defence Supply Agency Manual 8200.1, dated August 1976 outlined
a software lifecycle. It is widely accepted the first
document to define a practical approach to software
development is the Military Standard Defence, System Software
Development Standard DOD-STD-2167 dated 4th June 1985.
This superseded DOD-STD-1679A dated 22 Oct 1983 and was issued
along with MIL-STD-1512 also 4th June 1985 to
identify the process for Technical Review and Software Audits.
Document 2167A was replaced by Software Development and
Documentation MIL-STD-498 dated December 1994. This
standard was supported by
sixteen Data Item Sheets (DID). MIL-STD-498 was adopted by software managers whilst leaving outsiders a little bemused. CMMi came along early in the nineties to identify a much
broader range of goals necessary to achieve best practice
supporting software development. IEEE/EIA 12207
was produced in 1995 by a consortium made up from industry and
supported by US Government with the aim of replacing
MIL-STD-498.
Unlike defined software development
processes, Agile is much more of a culture method of
working. Differing organisations adopt a
slightly different approach. What Agile does is to
document and record a number of best working practices, many
are not new and would have been learnt by an
apprentice in previous years. The focus has to be on
delivering working code in short timeframes, no need to
produce perfect UML models or always produce complex
requirements documents. It is however vital that the
customer requirements are fully understood and agreed, the
green boxes on the diagram provide supporting documents that
will need to be addressed. The following identifies how
Agile has
been adopted by CMMI Ltd.
An MS Project Schedule has been used to
capture a number of Agile Methods From the diagram below click
on a coloured box to obtain more detail. See also
Agile
Practices. The Schedule button will return you back to
the schedule overview.
Product Backlog
It is necessary to have a backlog of work. This
shall be a prioritised list of requirements and may be made up
of system software components making up a user or customer
requirement. Without the need to schedule a backlog of
work, Agile will add little or no value. These will
be made up of
-
ID - An unique identification. This
can be generated from the requirements capture tool.
-
Name - Short description which the team
and customer will refer to.
-
Priority - The order in which the
artefacts will be addressed.
-
P1 For Next Release (First Fix)
-
P2 Second fix for next release
-
P3 Desirable for release.
These will be moved to a P2 for a subsequent
release if they have not been implemented.
-
P4 will be fixed at a subsequent release as per schedule
and revaluated.
-
P5 will be undertaken when all other tasks are completed.
-
Initial Estimate - Produced by the team
based on Analogy. Project Manager has the
responsibility to get this correct.
-
Notes - A description or other
information about the component.
Initiation Meeting
This is a meeting involving all of the team which may be made
up of three to twenty people, and may involve the customer.
The initial meeting is held at the start of a new product
release and can be based
on a Project Approach and Risk Review detail check lists. Allow an hour
for the approach and an hour for risk reviews. If a customer is present
for the approach meeting subsequently obtain their feedback
information.
Risk reviews will be much more open if the customer is not
present but needs to be judged based on commercial sensitivity. The room
needs to hold the relevant number in the team, a
white board, flip chart and projector made available.
Sprint Planning
Have available a product backlog identifying the requirements
and priority. Understand the velocity and resources
availability. CMMI Ltd used a tailored FogBugs tool to
identify requirement backlogs and to track bugs.
This identified unique ID's and task could be assigned to
individual owners. BugZilla provides a free and open
source software tool that will do a similar job. Excel
can be used to produce a locally modified tracking tool.
Other tools available are VersionOne, XPlanner and ScrumWorks.
In the first instance use a white board to discuss the
relationship of stories and get an overall picture from the
team based on salient points. Post-it notes can be used
to produce the Work Break Down (WBS) key
items in one colour supported by components or tasks in
another, this way everyone is involved. The use
of a projector to show each of the backlog items for review
and update information as it is discussed is good for
bug tracking. Both approaches require a
subsequent update of the WBS and Schedule by the Scrum Master
or Project Manager to finalise resources and priorities.
A story is deliverable and made up of a number of tasks.
By breaking the work down at this time will provide a more
accurate estimate and realistic sprint plan.
The whole team involved in the sprint need to be present.
The responsibility for the products success rests with the
Project Manager who may be considered as the representative of
the sponsor. The Project manager needs to identify Product
Owners from the team who may in turn seek support from other
developers. It is important to take on board each persons
diverse opinions and obtain estimates and buy-in and an
understanding of the aims from the whole team. Try not
to have team members influenced by others and widely differing estimates.
Where large discrepancies exist then it will be necessary to
go over
the story again. One team member may provide an initial
estimate which can then be debated by the rest of the team. What goes
into a sprint is normally what the sponsor sees as important,
however it is necessary in some instances to incorporate other
features due to the
future dependencies or match available skills.
Developers identify development time then add to this half as
much again for testing and contingency.
The Sprint Planning Meeting should ideally be no more than two
hours. To achieve this the Project Manager may have had to
have undertaken previous leg work. If more time is
required i.e. half a day, it may be beneficial to hold the meeting away from the normal
place of work so as to focus concentration. Decide on
the stories to be included in the sprint based on priorities. Trade offs
of P2 and P3's may be necessary. There should never be a lack of quality
assurance or squeezing testing. Instead scope has to be the
option for compromise, if not additional time scale or
resources will be required. Sprint lengths depend on the
task in hand but four to six weeks is comfortable.
Identify how quality will be ensured, this may be by peer
programming, code walkthroughs and independent QA testing.
Ensure this the necessary time for QA is recorded and planned.
The story has sufficient detail when the independent tester
feels they have the necessary information.
Scrum
This is from the UK rugby term where part of the team get
their heads down in a huddle to sort things out. CMMI
Ltd
tend to use the term scrum meeting to address a single issue
such as progress or a components design. This can be
held as a Ten Minute Stand-up (Daily Scrum)
each morning or as necessary by team members. It is important
to have drop out rooms with a white board and flip chart to
take away information.
Burndown Chart
This can be successfully managed in Excel, however MS
Project or Project Open Source is the correct tool for the
job. So as not waste valuable development resources this
is owned and maintained independently to development by the
Project Manager. The Project Manager will also be
tracking critical paths and potential bottle necks. This
should be updated and printed out on a plotter at salient
times. Each developer will update the requirements/bug
tracking tool by sending the feature to test and identify
progress on the printed out schedule when a
task is completed. They will also see from the schedule the
next task allocated to them. This will align to the
information in the requirements/bug tracking tool.
Treat bugs just like any other task, estimate time to fix and
keep an actual record of time taken to aid evaluation of
velocity.
An effective way to report progress is
to produce a WBS at the start of the project about three
levels down. This needs to go on the wall with the
schedule. It also acts as a visual progress report for a
sponsor. Each box shows the name of the component or
task, under each box mark the owner and the planned start and
end date. The main product and sub system boxes are
light grey. Task boxes are red until work has been
started when after 50% progress they turn from red to red and
yellow and yellow and green when they are presented to test.
Boxes go all green when successfully tested and bug free.
No boxes are removed unless a feature is no longer required by
the system. This WBS/PBS can be saved by date to show
progress over the life of the project.
Iterative Development
Deliver working software early and often. Iterations can
be one to eight weeks. Allow one third of the effort for
testing and bug fixing. That would equate to a delivery
every three months. This is sometimes too often for a
customer and it may be more convenient for a software update
being released every six months. In this case still plan
on a one to eight week Iteration.
Demo
A presentation that portrays the customers agreed
requirements. Template available in Power Point.
This may be captured in a Requirements Specification.
This demo is also used to develop the test requirements.
Velocity
It is important to understand velocity as without this
planning delivery dates will be a guesses. It is not just
the velocity of the team that is important but the velocity of
individual developers. Some developers deliver code
fast but then rely on rework to address issues, likewise a
slower developer may produce fault free code. Velocity
also has to take into effect holiday periods and the
introduction of new staff in the team requiring training from
existing staff, it is necessary for the Project Manager to
schedule accordingly. See also "Estimating".
|
