 A good
workflow can make or break a group's quality initiative. I've seen too
many cases where a manager wants to improve quality, but ends up
hurting productivity. Why? Because he ended up disrupting the team's
workflow instead of improving it. For
example, say the manager requires developers to check coding standards
and fix all violations before check in. With most tools, this requires
a lot of extra work-each developer has to run the tool, look at a
report of problems, sort through false positives, figure out which of
the reported violations he is responsible for fixing, and then actually
fix them. This extra work slows down the development process and
distracts developers from the creative tasks they're hired to do.
Eventually, the process will decay, and the team will be back at square
one.
The teams
that succeed where others fail are the ones that make quality tasks an
unobtrusive part of their existing workflow. Developers just write code as normal and check it
into source control. Every night, an automated infrastructure finds and
analyzes the new code. It does this all on its own, without anyone on the team
having to think about it. If it senses that human intelligence is needed-for
instance, to fix coding standard violations or review test failures-the
automated infrastructure pushes tasks the appropriate team members, as shown in
the image below.
Team
members just need to react. When developers get to work each morning, they start
up their IDE as normal, then they click a button to import any quality tasks
(fixing coding coding standard violations, reviewing test failures, and so on)
assigned to them. This way, developers don't need to leave their normal work
area to review and perform their assigned tasks. It's much more efficient than
working from a report because they can click directly from the task to the
related code.
Since developers aren't
distracted with unnecessary tasks, they accomplish more and get to
focus on the creative tasks they enjoy most. And since the analysis is
managed automatically, managers know that code is checked consistently
and correctly. It's a win-win situation for both development and
management.
What's the key to making this work? You need to industrialize
the development process, relieving humans from any task that does not truly
require creativity and human intelligence.
This requires an integrated infrastructure composed of the
following elements:
- A
requirements management system
- A
source control system
- A
bug-tracking system
- A
staging system you can safely test on
- A
production system that runs the live application
- A
deployment system that manages deployment to the staging system or
production system using a repeatable process
- A
monitoring system that provides visibility into the entire process
- A
build system that builds the application
This integrated infrastructure is absolutely essential.
On top of this infrastructure sits a backbone process that I
call a "nightly run." At the schedule time each night, it automatically...
- Checks out the code.
- Compiles the code.
- Links the code.
- Verifies whether the application is in
compliance with the organization's policies (SOA governance, security, SOX,
coding policies, etc.).
- Deploys the built application to the
staging system.
- Runs the regression test suite to ensure that the team is alerted
when modifications impact application behavior.
- Deploys the built application to the
deployment system (e.g., a production server or an embedded target) if the specified
criteria are satisfied.
- Monitors the entire process and
generates reports for process visibility.
This is the basic process that distributes work across the
team. This is your production line. The following image illustrates how people
work with it. Light bulb icons are used to mark the tasks that require human
intervention.
- The
customer and project manager interact and define requirements, which are fed
into the requirements management system.
- The
development manager is notified of the requirements, then assigns development
tasks to specific developers.
- The
developer is notified about the assigned development tasks. Notification is
sent to the IDE- the developer's normal working environment.
- The
developer responds by adding code and tests to the source control system.
- The
developer is notified about quality tasks (code review issues to address,
non-compliant code, test case failures to review, etc.). He responds by
updating code and/or tests in the source control system (as in Step 4).
- QA
receives assigned test quality tasks, creates new tests, and reviews the
creation of tests.
- The
development manager receives "progress reports" from the monitoring system so
he can assess the process effectiveness.
- The
customer interacts with the deployed system. Potential bugs are reported to QA.
- QA
explores each reported problem and files a bug in the bug-tracking system if
needed.
- The
development manager assigns tasks to developers, as in step 2.
- The
development manager and QA cooperate to perform root cause analysis. This
promotes process improvement.
- The
development manager and project manager receive information about the deployed
system's behavior.
If you think about what tasks in this workflow require human
intervention, what do you notice? Nothing repetitive. Nothing that a computer
could handle. Only things that truly require human intelligence. This is the
key to fostering creativity.
This whole process is what I call Automated Defect Prevention (ADP).
ADP is a practical approach to software management through process improvement.
This strategy is enabled by an infrastructure that automates repetitive tasks,
tracks project status, and provides instant access to the information needed
for informed decision making and process improvement. Applying ADP, teams
evolve a sustainable quality process that delivers predictable outcomes.
Of course, Rome wasn't built in a day. If you try to
implement this all at once, you risk overwhelming the team, which sets the
stage for failure. If you really want it to last, be patient and ease into it.
Incremental implementation is the path of least resistance.
Dr. Adam Kolawa is the
co-founder and CEO of Parasoft, a provider of automated infrastructures that
control and improve the process of developing software applications. Kolawa co-authored Automated Defect Prevention: Best Practices in
Software Management (Wiley, 2007)
and Bulletproofing Web Applications
(Wiley, 2001); he has also written or contributed to over a hundred commentary
pieces and technical articles. In 2007, eWeek recognized him as one of the 100
Most Influential People in IT. Kolawa holds a Ph.D. in theoretical physics from
the California Institute of Technology
.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed