are often used to support this process,
and many projects achieve good results
from using the management template
known as Scrum.
While defining a thin set of rules,
Scrum fosters discipline and makes
defects (in software as well as in the process) visible. But Scrum is too abstract to
be applied “out of the book.” You must
implement and adopt it for software engineering. Implementation practices, for
instance, might include distinguishing
between special development phases,
on a micro level, inside a Scrum release.
Here are some examples:
■ ■ Opening the release with an interval
to write acceptance tests
■ ■ Opening the release with an interval
to get more-detailed requirements
■ ■ Closing the release with a frozen zone
that allows developers to work only on
bug fixes, not on new features
■ ■ Closing the release with a code-freeze
interval in order to complete and ship
the final release
Technical release management.
Technical releasing consists of building the software and providing the final
product to the customer. Build management (comprised of compiling scripts,
packaging components, and distributing
components) is essential for agile ALM.
Technical release management
includes activities to identify configura-
tion items, track and audit changes to
requirements and configuration items,
and integrate and deliver the imple-
mentation. In software engineering,
change is more the rule than the excep-
tion. Because requirements change, it
is important to keep the requirements
in sync with their implementations.
Possible gaps between functional and
technical release management should
be bridged. Strategies such
as version control system
(VCS) hooks help marry both
parts of release manage-
ment. A leading tool that
supports technical release
management is Maven. With
Maven, the dependencies
between your Java artifacts
become visible.
CRI TIQUE THE PRODUC T
time-consuming activities
is essential.
Continuous integration
(CI) refers to the automation of the build, test, and
release process with the goal
of integrating the activities
of colleagues and the work
items others produce. This
can result in a build ecosystem in which a new-code
commit directly triggers a continuous
build, including compilation, technical
tests, audits, packaging, functional tests,
and deployment.
All different artifact types, platforms,
and languages (for example, Java,
Groovy, Scala, PHP, COBOL, and others)
should be integrated using a unified tool
infrastructure. If no native build system
exists for a respective language or platform, non-native build technologies can
be used to include these artifact types in
the CI farm.
One tool that can serve as your central
tool hub is the build engine Hudson.
Integrating Hudson with the tool Mylyn
results in a tool chain that spans different project roles and activities. Then, the
work on artifacts is traceable, starting
with the source code in the developers’
workspaces on up to tasks (work items)
in your ticket system.
Using a component repository such
as Nexus helps to differentiate between
source code and Java binaries, and
the repository operates on binaries
separately—for example, through staging binaries from one test environment
to another environment.
Collaborative Development
Writing software collab-
oratively means that all
stakeholders, especially Java
developers and testers, work
on the solution construc-
tively and with shared goals.
The agile testing matrix
(see Figure 2) defines test
quadrants, which are inte-
grated and aligned using the
outside-in and barrier-free approach to
software development.
The main drivers of the outside-in
approach are
■ ■ Understanding your stakeholders and
the business context
■ ■ Mapping project expectations onto
outcomes more effectively
■ ■ Building more-consumable software,
making systems easier to deploy
and use
■ ■ Enhancing alignment with stakeholder
goals continuously
Acceptance tests determine whether
a system satisfies its specified acceptance criteria, which helps customers
decide whether to accept the software.
This means that acceptance tests also
tell the programmers what the customer
doesn’t want them to do.
Executable specifications allow you to
use tools that read the specifications
automatically (either after manually
starting the process or continuously
as part of a CI process); process them
against the system under test; and output the results in an objectively measurable, efficient, and readable way. The domain expert specifies the tests in simple
Agile ALM provides
processes and
tool chains that
are flexible and open
to change.
COMMUNITY
JAVA IN ACTION
ABOUT US
BUSINESS-FACING
Q2
ACCEPTANCE TESTS
BEHAVIOR-DRIVEN
DEVELOPMENT
Q3
EXPLORATORY TESTS
USABILI T Y TES TS
ACCEP TANCE TES TS
SUPPORT THE TEAM
OU TSIDE- IN
BARRIER-FREE
COLLABORATIVE
Q1
UNI T TES TS
COMPONEN T TES TS
TES T-DRIVEN/
BEHAVIOR-DRIVEN
DEVELOPMENT
Q4
PERFORMANCE TES TS
LOAD TES TS
SECURI T Y TES TS
blog
TECHNOLOGY-FACING
Figure 2
Automation and
Continuous Integration
Automating manual steps
involves delivering results in
an objective and reproducible
way. Automating the most
error-prone, repetitive, and
