Behavior-Driven Development Extreme Programming and Scrum compliment each other, but they weren’t made from the start to fit together hand in glove. Practicing Extreme Programming and Scrum are more effective when practiced together, and even more effective when practiced together as Behavior-Driven Development. Increasing Feedback and Communication Much of agile software development methodology is grounded in the lean manufacturing principles developed and perfected by the Toyota Motor Company, and translated to software production by a number of software luminaries in the 90’s. Toyota understood that eliminating waste is essential to achieving its goals, and it understood that a rigorous pursuit of quality for its processes and products is essential to eliminating waste. The rework caused by defects and the downstream difficulties brought about by components built earlier in the process are powerful detriments to throughput. Lean and agile approaches depend on frequent inspection and feedback of work product at every stage of the process to avoid creating waste. Rich and frequent communication along with the focus on quality is what allows the advances in productivity and flexibility achieved by agile organizations. Scrum, XP, and the Communication Gap Extreme Programming (XP) brought mainstream attention to agile development. XP borrowed planning practices from Scrum, but in the beginning, Scrum was a bit of an unknown compared to XP. It wasn’t long before it became clear that using Scrum and XP together brought needed organization and planning practices together with agile engineering practices. Yet since XP and Scrum are separate methodologies, there are gaps between the two that sometimes make for a bumpy ride when transitioning from Scrum’s planning practices to XP’s software engineering practices. XP and Scrum necessarily have two processes in play on agile teams addressing different aspects of software production. Behavior-Driven Development (BDD) comes out of the friction between these two processes. BDD tightens communication and feedback across the gap between XP and Scrum. It offers some new ways to use old practices, and these in turn bring more focused workflows to agile development that might be considered a methodology of its own. An Old New Thing Agile project teams use Extreme Programming (XP) and Scrum together on agile projects because each has a focus that the other doesn’t have. XP and Scrum also have a lot of common ground and that makes them natural partners. With a layer of Behavior-Driven Development (BDD) over XP/Scrum, the individual agile practices tend to flow together with fewer coarse transitions between analysis, design, development, and testing activities. Getting XP and Scrum to play well together means being slightly stricter with some of the practices, as well as tweaking some of the practices subtly so that they complement each other better. BDD creates more harmony between the user story practices from Scrum and the Test-Driven Development practices from XP. The user stories practices represent analysis and specification in agile projects and Test-Driven Development represents software design. The resulting increased fluidity between analysis and design is brought about by a stronger focus on acceptance criteria. Acceptance criteria are those parts of requirements that specify when a requirement has been satisfied by shippable software. BDD borrows Domain-Driven Design’s focus on establishing and evolving a shared language (ubiquitous language in DDD parlance) used by the team in requirements, abstractions (class names, variable names, methods, database tables, columns, etc), specifications, documentation, and all manner of project artifacts, as well as in conversations and other communications between members of the team, customers, and stakeholders. BDD uses Context/Specification test style in its TDD practice to arrive at smaller, simpler, and more focused test groupings that more readily document the system. Context/Specification tests focus on how the system and its modules and units behave in specific usage contexts rather than on how individual classes and methods have been implemented. The contextual perspective more naturally reflects the system’s user stories, and often leads to a more fluent understanding of the customer’s expectations of the system. Contextual specification helps keep developers focused on the desired user experience, and produces test code that is more navigable, more discoverable, and generally more understandable-which is itself a boon to agility, raising productivity and quality to a yet higher level. It’s Still TDD Nothing in Behavior-Driven Development changes Test-Driven Development’s mechanics. Everything that you do today with TDD is still done in exactly the same way. Not even the use of Context/Specification style tests changes the essential work style and goal of practicing of TDD. Red-Green-Refactor, test-first programming, friction-aversion, design principles and practices, micro-incremental design, and all of the usual suspects are still in play. It’s perfectly valid to continue to refer to TDD when talking about those parts of the practice that are specific to TDD mechanics. It’s not just because BDD is the new thing that developers immediately have to replace TDD with BDD in their vernacular-especially since the terms aren’t always synonymous. BDD covers more ground than TDD, although TDD is at its core. |