The #DrupalPicchu sessions have been published, and I will be making the Drupal Lean Process presentation in Cusco. In preparation, the lit-drupal-lean project is in full swing right here on GitHub. Here’s a short-list of what has been achieved so far:
- Some of the most important docs and guides and templates have been gleaned over to the wiki. That includes material on MVP Planning, structured (hypotheses-driven) user stories, collaborative design and style and code guides, scaffolding and a host of templates to people your issue queue.
- Milestone 1 is in full swing, and the closed issues include some very interesting stuff, like an everything in code manifesto and drush generated install profile + features solution, etc.
- The codebase in branch master already includes a complete distro starter set, which will then grow via the addition of features, some of which will be base features and will be turned on by the install profile, and some of them will be optional and simply present.
Table of contents
[Skip to any section because you can]
I have been working in software development a long time. Early on I recognized the need for Process as a way of re-using best practices for teamwork. At that time, Process implied for most of us the Waterfall model, which divides a development project into discipline based phases, each to be visited once in turn, in a kind of cascade: Requirements; capture the requirements, do the Design, Implementation, Verification and Validation, Deploy, then shift into Maintenance mode. Most people still follow that model implicitly, it has stayed in the everyday consciousness of process, much like Newton’s laws instead of the Theory of Relativity, much like the theory of Creationism over the scientific Theory of Evolution kicked off by Charles Darwin. Yep, Waterfall often creeps in even when people say and even when people think they are using Agile. Of course, project difficulties and even failures based on the extremely high propensity (40% minimum) for requirements to change within the life-cycle of a project highlighted the dire need for at least an Iterative and Incremental model. And when that became too top-heavy, at least in its wonderful, eye-opening but hard to tailor and work with Rational Unified Process, I moved on to a kind of personal synthesis of CMMI (love that continuous improvement and organization wide adoption!) and Agile and Scrum approaches. More recently I have loved the simpler work in process and visual approach of the Kanban as a lean variety of Agile:
“Some Agile methods take a more flexible approach to time than Scrum does. (For example, Kanban does away with the notion of a two-week batch of work and places the emphasis on single-piece flow.) But you can still make time within a Scrum sprint in which creative activities can take place.” Gothelf, Jeff (2013-02-22). Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Media.
[Just thinking aloud here, that's what a blog is for, isn't it?]
I like use cases because they are great for modeling scope.
Once you have a use case, with its basic flow and alternative flows, then you can discover the most important paths through the basic and alternative flows, and clearly mark out the key scenarios.
Each one of these key scenarios corresponds to a single test case. So each use case has one or more key scenarios and the same number of test cases.
These test cases are what the customer and the developers must write together based on a user story which is going to be implemented.