We have 5259 guests and 8 members online
Home > Articles > Current Edition > Continuous Integration

Continuous Integration

 E-mail
Tuesday, 10 May 2011 16:22
 
Continuous Integration - May 2011

Integration

"Time waste differs from material waste in that there can be no salvage.  The easiest of all wastes and the hardest to correct is the waste of time, because wasted time does not litter the floor like wasted material." - Henry Ford

The topic for this month’s edition of the Agile Journal is “Continuous Integration and Improvement.”

Charles Suscheck in his article, “From Red Tape to No Tape: Maximizing Agile in Your Organization - Part 1,” describes two organizational philosophies—one that is adverse to successful agile adoption and one that facilitates the agile processes. Next month, in part two of his article, Charles will cover recognizing and correcting organizational misalignment with agile principles.

My article, “How Do I Write Requirements using Stories and Acceptance Criteria?” is part one of a two-part article.  Part one of this article covers:
  • The tie between writing agile requirements using stories, the Product Vision, and an Agile Requirements Positioning Statement
  • What is a story
  • Why stories
Next month, part two of my article will cover:
  • Getting ready to write stories and eliciting requirements using stories
  • How much detail to capture
  • Writing acceptance criteria
Graham Parson’s article, “Integrating Performance Testing into the Agile Development Process,” discusses how you can implement performance testing within the agile process that is easy enough for many agile team members to use. This allows for rapid configuration, execution, and analysis of performance tests.

In “Distributed Multi-Source Development,” Philip Marshall discusses how with agile methods, multi-source development using open source and appropriate policy and process, development organizations can increase innovation and agility, and embrace new technologies.

Steve Berczuk, Brad Appleton, and Robert Cowham in their article, “Agile SCM: Basics for Small Teams,” clearly and concisely list the essential items for success with SCM in tools and processes, grouped into general priorities.

“Requirements Come Second,” by Allan Kelly describes that when it comes to fixing a broken development process or organization, starting with requirements can make the situation worse. Although counter-intuitive, the first priority should be making development more effective rather than focusing attention on the requirements process.    

Finally, “CM: The Next Generation of Build Essentials,” by Joe Farah, tells us why “the build”  is central to configuration management and it's critical to do it right.

Your agile buddy,
Russell Pannone
Editor-In-Chief
Agile Journal

 
Featured articles...

red tape
From Red Tape to No Tape: Maximizing Agile in Your Organization - Part 1
by Charles Suscheck 
Companies using agile development must recognize that they won’t reap the benefits of agile without the correct organizational philosophy. Companies often don’t even realize that they are following a path that can limit agile adoption. Part one of this article describes two organizational philosophies—one that is adverse to successful agile adoption and one that facilitates the agile processes. Part two will provide guidelines for detecting a philosophy that does not support agile development and offers suggestions to align your organization’s philosophy to match your needs. You’ll have to wait until next month when I present part II of this article on recognizing and correcting organizational mis-alignment with agile principles.  

Read More >>
 

Write
How Do I Write Requirements using Stories and Acceptance Criteria?—Part One
by Russell Pannone
How do you define your project and business requirements?  Do you use the classic method of creating a Business Requirements Document (BRD) early in the project regardless of the project length?  How has that worked for you, especially on a 6-month or year-long project?  Did you need BRD change requests during the project because the team discovered new information, market conditions changed, or someone had an even better idea?  Agile has a different take on the concept of requirements.  Instead of presciently scribing the exact requirements for the project, and compensating for all eventualities, Agile recommends creating a vision of the product, succinct bite-size statements of business value from the Customer’s or Business Partner’s point-of-view, and criteria to verify the delivery completeness; or in Agile terminology, a Product Vision, Stories, and Acceptance Criteria.
Read More >>
 

Performance
Integrating Performance Testing into the Agile Development Process
by Graham Parsons
"One of the key purposes and benefits of Agile development processes (“Agile”) is that they emphasize working software as the primary measure of progress. To ensure that the current state of the software is working, every iteration includes unit and acceptance testing. Many organizations report that, following the adoption of Agile, the quality of their released systems has been improved.
Read More >>

More articles...
distribute Distributed Multi-Source Development
by Philip Marshall
What are leading development organizations doing to increase innovation, agility and embrace new technologies? The answer: Distributed multi-source development

 

Large software projects that are late. Missed schedules. Budget over-runs.

These aren’t pleasant challenges to manage, yet they are hallmarks of traditional waterfall software development methodologies. This common approach to creating software is yielding to two powerful approaches to development: distributed development using Agile methodologies, and multi-source development, combining closed source with free and open source components.

Read More >>
 
School Agile SCM: Basics for Small Teams
by Steve Berczuk, Brad Appleton, Robert Cowham

As much as software developers are stereotyped are solitary coders, software development is a collaborative activity. Communication among team members is essential in ensuring working continuously working software. And working software is what makes communication with stakeholders easier. You can show the state of your application rather than explain progress in terms of more abstract concepts. Your SCM system (and processes) are an essential part how you communicate both in and about code between developers and to stakeholders.

Read More >>
 
medal
 

Requirements Come Second
by Allan Kelly
Despite our best efforts we need to know what we are going to code before we write the code.  And as much as we might like to test before we write the code we can't really run tests until we have some code.  Agile overlaps requirements discovery and implementation so coding can start with minimal or outline requirements but there is still a sequence.

Yet when it comes to fixing a broken development process or organization starting with requirements can make the situation worse.  Although counter-intuitive, the first priority should be making development more effective then focusing attention on the requirements process.
Read More >>
 
powerlines CM: THE NEXT GENERATION of Build Essentials
by Joe Farah
CM allows us to repeatably build product that can be delivered to the customer. In the hardware world, the "build" process is called "manufacturing" and the deployment is known as "shipping and installation". In the software world, our manufacturing is done through a Build process, and our deployment is often automated, perhaps over the internet. However, unlike for hardware development, software teams continually build and re-build the entire software product continually during development and can deploy these builds locally for verification. So the build process is not just a manufacturing process, but a development process as well. Deployment, during development, may involve deployment to the workspace area for developer testing, to a central test area and/or to lab equipment. After that, there are still deployment considerations for verification, production certification and finally to customers.
Read More >>
 
 

 
Last Updated on Thursday, 19 May 2011 14:40
 
Cialis

Agile Marketplace - Announcements and Special Offers

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper