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
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
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...
- Good old Node family? (no 6.x version yet???)
- Node Hierarchy?
- Node Auto Term [NAT]?
- The new field API backported to Drupal 6 (I wish...).
OK, enough "general analysis", time to get to work...





Recent comments
10 weeks 5 days ago
12 weeks 4 days ago
14 weeks 4 days ago
18 weeks 23 hours ago
19 weeks 4 days ago
19 weeks 4 days ago
22 weeks 1 day ago
22 weeks 3 days ago
24 weeks 4 days ago
24 weeks 4 days ago