Process Flow and Tracker is an agile process tracker built on Drupal.
Please visit the PFT Sandbox (reset to sanity once every 24 hours).
Drupal on agile, agile on Drupal
Agile basically means getting it done right. It does for getting it done what object oriented analysis, design and programming does for software: it divides all the complexity into bite-sized chunks.
So if your project is set up right, you find yourself bleary eyed in the saddle on a Monday morn, with the definite idea of putting your shoulder to the wheel, but without any idea at all of where (it costs too much to redo the thinking five times); but you can fire up something (whether it's a spreadsheet, a sophisticated application, dotproject, whatever), but you got yourself a Google map on all your clients, projects, phases, milestones, tasks, tests, days, so you can Zoom out and dizzyingly zoom in on what you got to do right now. Then at some point soon, and the easier the better, the lowest cost in pain and time the better, at some time you have the equivalent of a pile of tasks to do, that you can just do and cross off as having been done and you have that sweet feeling of having really moved along.
At some point in time, everyone needs a mentor, and working with Drupal is no exception. We offer private mentoring services for large and small projects (minimum: a prepaid block of 10 hours):
Just run index.htm (see EclipseProcessFramework).
What we get is a very refreshing, non-bloated approach to the familiar roadmap (phases), core principles, roles, work products, disciplines and basic lifecycle; but with a refreshing infusion of agile approaches.
Basically put, like me, Scott Ambler is a refugee from RUP. He is interested in "tailoring into" RUP and other "full-fledged" methodologies based on agile best practices.
His Agile Modeling (AM) Home Page is a dedicated explanation.
Seminal book: Agile Modeling .
A recent excerpt from the Agile Modeling mailing list sees Scott's position on single source information (i.e., capture requirements in acceptance tests rather than use cases) and on avoiding unnecessary documentation: