CM for Web Development Environments Series
CM Quick Wins - What is a "Quick Win"?
A "Quick Win" is a small process improvement, something
that is small in terms of size of effort required for implementation.
The idea behind Quick Wins is that few teams can swallow
large process changes, but almost everyone can adapt to
small changes that make their jobs easier.
When QA Labs begins a consulting stint at any organization,
we try to examine the current processes in place with the
idea of finding and implementing one or more Quick Wins
almost immediately. We find that because we are external
to the company and have worked in many different development
environments, we can often see potential Quick Wins that
team members who are close to the problem cannot.
The key points when looking for Quick Wins are:
- Don't try and solve all your problems at once. Start
with one or two improvements and review them at the
end of the project. When compiled together, these small
changes can effect huge improvements.
- Remember that Quick Wins should be easy to implement.
Small cost and time-effective changes are going to be
easier than large changes, such as requiring an entire
team to adopt a new methodology or new suite of tools.
- You want a Quick Win to be something that could be
done by a project resource as part of their regular
project work.
- Most Web Application projects are short in duration
(1-6 months), so Quick Wins need to be of the same time
frame so that you will be able to measure the effectiveness
of the Quick Win by the end of the project.
Identification Quick Wins
- Avoid using your project's name (or code name) as a part
of your file name for source code - it makes reuse and/or
reconfiguration a messy task. You can do this for project
documentation of course, but remember to be consistent.
- Documents should be given appropriate version numbers.
We suggest trying this scheme: "<version>.<revision>"
where version runs from 0 to n, and revision from 1 to m.
So a first draft of a document would be "0.1". All incremental
revisions of that draft document triggers an increment in
the revision number. Once a document is "accepted" or "signed
off" (no longer a draft or work in progress), it graduates
to a "1.0" version.
Documentation Quick Wins
- Create a Project Intranet. By linking project documents
all together via a simple (one page) index web page (perhaps
"shadowed" from your version control tool), you will allow
people to find new and updated information themselves, and
add visibility into the project (this is great for new people).
- Even if the majority of your project team doesn't seem
open to having a project intranet, it can still be valuable
for the QA and test team for the project to have their own.
Sometimes, the best way to get people to try new things
is to show them how easy it can be.
Document Control Quick Wins
- Defect reports must be kept in a database that can track
the status of each record, and is accessible by all project
personnel so that a new defect may be entered by anyone,
anytime. Use a FREE or low-cost defect tracking tool that
has web access. Check the "CM Yellow Pages" website for
a good listing of these tools, or ask QA Labs about our
own tool: "TIQS".
Source Version Control Quick Wins
- Go "Cheap and Easy to Use". Use whatever tool(s) you
own and/or whatever your people know how to use (likely
examples include: VSS, CVS, RMS).
Build and Deployment Quick Wins
- Migration of code between environments should appear
to be One-Way only. This means that source code should appear
to be migrated from a development environment to a testing
environment to a production or "live" environment. However,
the code itself is migrated from the code library (more
specifically, from a tag or label within your code repository)
to the specific environment, not from one environment directly
to another. This allows you to always recover the exact
code base you placed on the environment at any time.
Audit Quick Wins
- Create checklists with simple "Yes" or "No" type-questions
that will take no more than an hour to execute early on
in the project. It allows other project personnel a chance
to see what will be coming, what QA's expectations are regarding
specific processes, and allow the team to give you feedback
on your checklists.
Summary
It's always better to start with small process improvements,
small changes that your team will accept, and slowly change
the process over time rather than to try and force a more
drastic change all at once.
Reduce costs - Take advantage of lower labour costs and today's