Acceptance Test-driven Development (ATDD) is a popular topic these days-everyone’s excited about the idea of writing tests prior to development. Yet many teams run into difficulties as they attempt to implement this practice. It’s all too easy to fall into the trap of writing acceptance tests that mostly specify keystrokes and button clicks. Join "Cheezy" Morgan as he offers an overview of ATDD while sharing his experiences and insights gained working with numerous teams implementing ATDD.
Agile Development Conference & Better Software Conference West 2012
Whose job is it to ensure that the user has a good experience with a new application? As agile processes are taught today, the user experience (UX) design practice is usually left out or at best described as an optional team role. However, the companies that build useful, usable, and desirable software know that UX is baked into the whole development process. Jeff Patton describes what user experience design is and isn’t, and how every person on the team has something to contribute.
Although “agile architecture” may sound like an oxymoron to you, the reality is that a simple, elegant architecture is a key enabler of any successful system, particularly large scale ones. Scott Ambler describes agile architecture practices-at both the project and enterprise level-that form a middle ground between the extremes of big architecture up-front and outright hacking.
Don’t let anyone tell you differently: agile testing is hard! First, we have to get over the misconception that you don’t need testers within agile teams. Then, we have to integrate testers with the developers and engender a holistic quality approach. And those are only the challenges when the going is easy! In more difficult contexts, testing in agile environments is-well, even more difficult.
The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the long run. How can we know the right balance of upfront design work versus emerging design approaches?
One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides examples of typical requirements and explains how to improve them using the Easy Approach to Requirements Syntax (EARS). EARS provides a simple yet powerful method of capturing the nuances of functional requirements.
Software development organizations adopting Scrum have struggled to apply it to big projects with multiple teams. Dan Rawsthorne is frequently asked, “What does ‘big’ Scrum look like?” Because no two organizations are alike, this simple question does not have a simple answer. However, Dan has discovered patterns that are common in organizations that successfully implement “big” scrum. The first pattern he explores-Product Owner Team-allows the organization to handle agility up and down the hierarchy.
“Speed” describes how fast an object is moving and let’s us compute the distance it has traveled. “Velocity” is different-it defines both speed and direction. So why do I meet so many teams who talk about their velocity but lack direction? Once you can track speed and distance, the real challenge becomes envisioning, validating, and measuring direction and purpose.
Velocity is one of the most common metrics used-and one of the most commonly misused-on agile projects. Velocity is simply a measurement of speed in a given direction-the rate at which a team is delivering toward a product release. As with a vehicle en route to a particular destination, increasing the speed may appear to ensure a timely arrival. However, that assumption is dangerous because it ignores the risks with higher speeds. And while it’s easy to increase a vehicle’s speed, where exactly is the accelerator on a software team?
The deployment destination for today’s applications is going through its biggest transition since the rise of the application server. Platform-as-a-Service (PaaS) and other cloud service offerings are putting pressure on every stakeholder in the application lifecycle, forcing us to modernize both our skill sets and tool stacks.