|
Methodologies
Adaptive Project Framework
Agile Software Development
Crystal Methods
Dynamic Systems Development Model (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Information Technology Infrastructure Library
(ITIL)
Joint Application Development (JAD)
Lean Development (LD)
PRINCE2
Rapid Application Development (RAD)
Rational Unified Process (RUP)
Scrum
Spiral
Systems Development Life Cycle (SDLC)
TenStep Project Management Process
Waterfall (a.k.a. Traditional)
Scrum
Scrum
Methodology
Scrum is an agile method for project management
developed by Ken Schwaber. Its goal is to dramatically
improve productivity in teams previously paralysed
by heavier, process-laden methodologies. Its intended
use is for management of software development
projects as well as a wrapper to other software
development methodologies such as Extreme Programming.
Scrum
is characterised by:
A living backlog of prioritised work to be done.
Completion of a largely fixed set of backlog items
in a series of short iterations or sprints.
A brief daily meeting (called a scrum), at which
progress is explained, upcoming work is described,
and obstacles are raised.
A brief planning session in which the backlog
items for the sprint will be defined.
A brief heartbeat retrospective, at which all
team members reflect about the past sprint.
Scrum is facilitated by a scrum master, whose
primary job is to remove impediments to the ability
of the team to deliver the sprint goal. The scrum
master is not the leader of the team (as they
are self-organising) but acts as a productivity
buffer between the team and any destabilising
influences.
Scrum
enables the creation of self-organizing teams
by encouraging verbal communication across all
team members and across all disciplines that are
involved in the project. A key principle of scrum
is its recognition that fundamentally empirical
challenges cannot be addressed successfully in
a traditional "process control" manner.
As such, scrum adopts an empirical approach -
accepting that the problem cannot be fully understood
or defined, focusing instead on maximising the
team's ability to respond in an agile manner to
emerging challenges.
If
you're looking to hire a project manager with
a strong software development background, contact
me and I'd be happy to discuss your company's
project needs and how I can address them.
References
Jim Highsmith, Agile Software Development Ecosystems
Ken
Schwaber and Mike Beedle, Agile Software Development
with Scrum
--------------------------------------------------------------------------------
Waterfall
(a.k.a. Traditional) Methodology
The waterfall model is a popular version of the
systems development life cycle model for software
engineering. Often considered the classic approach
to the systems development life cycle, the waterfall
model describes a development method that is rigid
and linear. Waterfall development has distinct
goals for each phase of development where each
phase is completed for the next one is started
and there is no turning back.
The
perceived advantages of the waterfall process
is that it allows for departmentalization and
managerial control. A schedule is typically set
with deadlines for each stage of development and
a product can proceed through the development
process. In theory, this process leads to the
project being delivered on time because each phase
has been planned in detail.
In
practice, waterfall development often falls short
of expectations as it does not embrace the inevitable
changes and revisions that become necessary with
most projects. Once an application is in the testing
stage, it is very difficult to go back and change
something that was not thought of in the concept
stage. Alternatives to the waterfall model include
joint application development (JAD), rapid application
development (RAD), synch and stabilize, build
and fix, and the spiral model.
--------------------------------------------------------------------------------
Agile
software development
It
is a conceptual framework for undertaking software
engineering projects. There are a number of agile
software development methodologies e.g. Crystal
Methods, Dynamic Systems Development Model (DSDM),
and Scrum
Most
agile methods attempt to minimize risk by developing
software in short timeboxes, called iterations,
which typically last one to four weeks. Each iteration
is like a miniature software project of its own,
and includes all the tasks necessary to release
the mini-increment of new functionality: planning,
requirements analysis, design, coding, testing,
and documentation. While an iteration may not
add enough functionality to warrant releasing
the product, an agile software project intends
to be capable of releasing new software at the
end of every iteration. At the end of each iteration,
the team reevaluates project priorities.
Agile
methods emphasize realtime communication, preferably
face-to-face, over written documents. Most agile
teams are located in a bullpen and include all
the people necessary to finish the software. At
a minimum, this includes programmers and the people
who define the product such as product managers,
business analysts, or actual customers. The bullpen
may also include testers, interface designers,
technical writers, and management.
Agile
methods also emphasize working software as the
primary measure of progress. Combined with the
preference for face-to-face communication, agile
methods produce very little written documentation
relative to other methods.
References
Wikipedia, The Free Encyclopedia
--------------------------------------------------------------------------------.
Extreme
Programming (XP) Methodology
The main goal of XP is to lower the cost of change
in software requirements. With traditional system
development methodologies, like the Waterfall
Methodology, the requirements for the system are
determined and often "frozen" at the
beginning of the development project. This means
that the cost of changing the requirements at
a later stage in the project -- something that
is very common in the real-world -- can be very
high.
XP Core Practices
The
core practices of Extreme Programming, as described
in the first edition of Extreme programming Explained
can be grouped into four areas (12 practices)
as follows:
Fine scale feedback
Test
driven development
Planning game
Whole team
Pair programming
Continuous process rather than batch
Continuous
Integration
Design Improvement (a.k.a refactor)
Small Releases
Shared understanding
Simple
design
System metaphor
Collective code ownership
Coding standards or coding conventions
Programmer welfare
Sustainable
pace (i.e. forty hour week)
In the second edition of Extreme programming explained
a set of corollary practices are listed in addition
to the primary practices.
The
core practices are derived from generally accepted
best practices, and are taken to extremes:
Interaction
between developers and customers is good. Therefore,
an XP team is supposed to have a customer on site,
who specifies and prioritizes work for the team,
and who can answer questions as soon as they arise.
(In practice, this role is sometimes fulfilled
by a customer proxy.)
If learning is good, take it to extremes: Reduce
the length of development and feedback cycles.
Test early.
Simple code is more likely to work. Therefore,
extreme programmers only write code to meet actual
needs at the present time in a project, and go
to some lengths to reduce complexity and duplication
in their code.
If simple code is good, re-write code when it
becomes complex.
Code reviews are good. Therefore XP programmers
work in pairs, sharing one screen and keyboard
(which also improves communication) so that all
code is reviewed as it is written.
Testing code is good. Therefore, in XP, tests
are written before the code is written. The code
is considered complete when it passes the tests
(but then it needs refactoring to remove complexity).
The system is periodically, or immediately tested
using all pre-existing automated tests to assure
that it works. See test-driven development.
It used to be thought that Extreme Programming
could only work in small teams of fewer than 12
persons. However, XP has been used successfully
on teams of over a hundred developers. It is not
that XP doesn't scale, just that few people have
tried to scale it, and proponents of XP refuse
to speculate on this facet of the process.
XP
Controversy
Detailed specifications are not created or preserved.
Programmers are required to work in pairs - not
all software developers expect to be asked to
work this way.
There is no Big Design Up Front. Most of the design
activity takes place on the fly and incrementally,
starting with "the simplest thing that could
possibly work" and adding complexity only
when it's required by failing tests. This could
result in more re-design effort than only re-designing
when requirements change.
A customer representative is attached to the project.
This role can become a single-point-of-failure
for the project and some people have found it
to be a source of stress.
References
Wikipedia, The Free Encyclopedia
--------------------------------------------------------------------------------
|
