Go directly to workshop page for Leveraging Drupal

General Analysis

Analysis is not so effective if it is not  intimately associated with a code sprint itself (that is, itself done in an incremental and iterative manner). However, I did want to get a "total immersion" mindset before starting out. To do so I reviewed:

Feedback from previous PFT users

Roadmap from DrupalCon Barcelona 2007 presentation

Input from bibliography

Process toolsets

Drupal architectures

Feedback from previous PFT users

  • Usability
    • Be able to follow simple workflows in entering roles, their associated user stories, their acceptance tests, iterations and releases.
    • Be able to visualize the progress made in a project (i.e. burndown graphs.
  • Link up to source code version control repositories. Be able to trace version control (changesets, or builds) to user stories and back.
  • Link up to running demos, test sites, production sites associated with iterations, releases, monitor those sites and Drupal instances.
  • More support for estimates, planning and teamwork.
  • My own ideas, among them:
    • embed all of this inside the project itself, in the context of prototyping with Drupal itself, and to do so kick-start that project with a number of useful modules, etc.
    • Package as distribution or installation profile
    • Internationalized and localized

Roadmap from previous DrupalCon Barcelona 2007 presentation

  • Multi-lingual support!
  • Quantitative tracking and statistics
  • Linkup with SVN for traceability
  • Linkup between requirements and architecture
  • Linkup with automated testing
  • Multisite install for self-contained projects with top-level overview
  • Workflow wizard as well as dashboard for each user when they login

Input from bibliography

Go back to the roots, of Agile, Scrum, etc. But also... KanBan, JIT, systems originally created to super-exploit workers but which could somehow cast light on how workers could cooperate efficiently and democratically in many social contexts.

Process toolsets

Everything seemed to be leading back to physical cards in plastic envelopes, on walls, empty trolley carts in the factory, something easily visual.

Why software? Why not colored plastic and cardboard... And then it hit me: shoot, everything is a card! A card that can be stuck on a wall next to other cards, so the overall picture is always clear; and I can pluck a card off the wall and get down to it, in comfortable but non-overwhelming detail. That's got to be in there!

Drupal architectures

  • jQuery will be the usability candy once we get it done!
  • If everything is a card, how do I have content types which can inherit easily from other content types?
    • Share fields among content types, with one class (card) being the "abstract" content type never to be used, except for the place where all the fields are housed (never deleted).
    • Use the Content Type Inheritance Module, with its automatic theming template polymorphism into the bargain?
  • How do I show ad-hoc and non-exclusive relationships between cards (nodes) of different kinds: show features containing user stories, show projects containing releases, releases containing iterations, iterations containing user stories, tasks, defects, change requests...

OK, enough "general analysis", time to get to work...