Following the ideas in One Model for Effective Software Development, this article presents one model for an Effective Inter-team Process. It provides an overview of the value delivery process (e.g., developmental value stream) for a software project that requires multiple teams.
Html is here, PDF is here.
The spreadsheet is a simple analogy to allocate responsibilities for many organizational and design decisions you need to make. Responsibilities can be assigned by rows, by columns, or by some combination of the two. The spreadsheet conundrum gives you suggestions on how you can do that assignment.
The PDF is here. HTML is here.
Following the ideas in One Model for Effective Software Development, this article presents one model for an Effective Team Process. It provides an overview of the value delivery process (e.g., value stream) for software. Here is the html, here is the pdf.
Based on a suggestion by Dave Snowden to find the essentials of software development, I examined practices, principles, and values from agile, pre-agile and lean. From that examination, I’ve developed a preliminary model for effective software development. I’ve used the term effective based on Stephen R. Covey’s The 7 Habits of Highly Effective People written in 1989-90. Html is here, PDF is here.
You’ve read about agile development, BDD/ATDD, agile architecture, and many of the other facets of agile. Many articles tend to discuss individual aspects, rather than putting them in a perspective of a whole development picture. Over the past year and a half, I’ve been coalescing ideas on software development. This view has emerged from my interactions with students, agile enthusiasts, and agile coaches, trainers, and authors. I’ve listed at the end many of the people from whom I’ve gathered different perspectives and feedback. This article merges in ideas that have appeared in my books on BDD/ATDD, software development, programming, and interface-oriented design. The PDF is here; HTML version is here.
I like to try multiple different approaches to solving a problem to see how they compare. I might learn something from one approach that I could apply to another. As an example, I created an alternative approach to calculations with fractions. The fraction idea comes from J.B. Rainsberger’s class on Test Driven Development. It is a great demonstration of TDD.
In this example, I’m going to use Gherkin as the specification language for the customer facing behavior For applications where the external behavior and its component parts are specified by the customer and/or stakeholders, having examples in Gherkin can dramatically decrease the communication impedance between the customer and the developer. PDF is here. HTML is here.
Some agile practice articles discuss how individuals should be organized into teams and work
collaboratively. Other articles describe how product backlog items/features and sprint backlog
items/stories/tasks should be estimated and scheduled. In this article, the flow perspective focuses on how customer or business value is delivered. This flow is sometimes shown with value streams, story maps, customer journeys, workflows, or other means. Understanding and making the flow visible can help with organizing the other views of agility. The article in html is here. The article as a PDF is here.
There is a flow from external requirements to internal tests. Requirement Driven
Development (RDD) (aka Behavior Driven Development / Acceptance Test Driven
Development / Specification by Example) focuses on the external behavior.
Test Driven Development focuses on the internal behavior that creates the
external behavior. There is an overlap between the two. TDD can go all the
way up to external behavior. RDD can differentiate into more detailed
behavior. Go here for html. Go here for PDF.
Software applications should satisfy the requirements. To put it in reverse, requirements drive the development. Every requirement should have a test for it that checks that the requirement is implemented properly. Any code that does not satisfy a requirement (functional or non-functional) is not needed.
Read this blog as PDF. Read this blog in HTML.
This kata revolves around a common domain term – money. Money appears in many applications, so the code from this kata might be adapted to those applications. Although it uses a dollar, it’s easily changeable to the currency of your choice by just replacing the currency symbol. Since requirements /tests written in Gherkin are implementation independent, you can implement this in any language. Some languages may be easier than other since they have more extensive libraries. Programmers can try multiple implementations and then have discussions as to the relative merits of each one.
The full kata in a PDF. The kata in html.
The kata is released under the Creative Commons copyright.