We have 5223 guests and 11 members online
Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
So we have identified all the information and processes we need to deliver the value. But what about all the variants? We now look at a process based on David A. Kolb's circle of learning that can be used to identify all the variants. This process uses the knowledge of all the members of the project, business and IT. These examples will form the interface with development. So now we have the model..... Lets break it."
TrackBack URI for this entry
Show/hide comment form
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
(1) "Concrete experience" corresponds well to "Example"
(2) "Observation and reflection" corresponds well to "Model"
(3) "Abstraction and generalisation" does not correspond well to "Test"
(4) "Test hypotheses and new situation" does not correspond well to "Reflect"
(2) and (3) are both concerned with modelling, although they represent different points along the road to generalisation. Testing is an act of concretion, which is very much the opposite of abstraction, and is already covered in (4). Reflection is already covered in (2).
(Disclaimer: I'm no Kolb expert, but my wife's in HR and I helped her put together a presentation on learning cycles and styles a few years ago, where this was covered.)
When it comes to TDD, which I agree is definitely a learning cycle, the correspondence presented is also not strong. Running a test is even more obviously concretion rather than abstraction. And red/green is a direct effect of running the test, so is part of running the test and not a separate learning element. What follows from running the test causes learning (one hopes), but the execution result of the test is not itself the act of reflection by the developer.
Just focusing on "... -> Example -> Model -> Test -> Reflect -> ..." for a moment, rather than Kolb's model, I think what you have helped to highlight are the common missing steps that make for effective TDD/BDD/etc. In practice many practitioners unintentionally leave out the reflection stage, which is what leads to better quality code, i.e., accommodation of learning in the form of refactoring.
Going back to Kolb, it maps nicely to a TDD approach: (3) and (4) relate more closely to refinement of code and tests. It is also worth noting that the Kolb cycle can start at any one of the four elements, which is also reflected in day-to-day development.