DC2009:Agile Ways to Develop Joomla! Extensions

Description

Pradeep Suthram, the Product Manager at PICnet, is responsible for maintaining and improving Non-Profit Soapbox, a hosted solution of Joomla! exclusively for non-profit organizations. He works with a team of 3 developers and a designer using design-driven development using agile methodologies to constantly improve/update the product so that new extensions/fixes can be deployed to hundreds of websites regularly and instantly. Learn from his experience in writing user stories, managing timelines/expectations, developing specifications, and keeping both developers and clients happy. During the last four years at PICnet, Pradeep has helped the company establish Non-Profit Soapbox as a unique and reliable service wrapped in a product for non-profit organizations.

Session Notes

Presenter: Pradeep (sp?)

Attendees: Phil, Oksana, Courtney, Hunter.

All have been exposed to it, at different levels. Some just beginning. Some have used parts of Agile implementation; though not all principles on a daily basis.

What would you like to get from this session?

• when to use it? what type of projects are best?
• how are you using it? what works? what doesn't?

Will review:

• principles learned from a good book
• battles we had to fight through to make agile work

COMPARISON

Agile...

• throws out concept of timelines, dependencies, and many other concepts of waterfall dev't.
• is a more engaging process, that invites feedback from user community & others, and incorporates it into the product throughout development.
• doens't have to wait for end points to include new feedback; as opposed to waterfall, which is generally focused on a fixed feature set.
• asks us to think through a feature or subset of features for a short period of time, and focus on t

Waterfall...

• we'd map out entire set of components from start to end, including all exceptions & rules.
• would move through broad understanding -- requirements -- to detailed specifications.

GETTING STARTED

Developers provide 3 estimates for a story.

• work hours = an honest hourly estimate of how long this will take, without inflation due to potential tech problems and other risks.
• difficulty (subjective index 1 - 3)
• volatility (subjective index 1 - 3)

General rules of thumb:

• Minimum of 2 hour estimate for any story.
• For stories > 8 hours, they are split into several more-granular stories.

All of this is provided at the pre-release meeting, where they also discuss they're vision of how project will run -- from both client and the company's perspective -- and reconcile potential conflicts.

Question: How is this used for vendor-client relationship? (as we've been discussing mostly internal clients thus far.)

• Oxana: we've given very on-the-fly feedback throughout development, using wireframes & drawing on top of existing site.

• Phil: In Pivotal Tracker, I like having the conversation regarding a story in one place. It encourages client interaction in the process. And clients are actively involved in prioritization.

Question: But how do we get that initial set of stories? In starting the project, I've always done a lot of research to write up a document that provides a strong picture of our needs.

• Agile development need not start with Agile requirements collection.

MOVING FORWARD WITH DEVELOPMENT

Given a set of stories, I go to Developer to look for red flags and ask him/her to come up with estimates for a later time. Then I do the same with the designer with my vision, who takes that and uses his/her expertise to create a usable, pretty visualization for the feature/functionality.

We produce a low-fi mockup of the story, then everyone reviews & revises; move on to a medium-fi mockup, etc. Starting with medium-fi mockup, the developer may take it and run at any point, or may wait until we get to higher-fidelity mockups. It is design-driven development.

AHA MOMENTS

• better understanding of how we can transition to agile from waterfall.
• communication is key.
• understanding why I like Agile: Due to the concepts at it's core -- being able to react to an evolving project.

MISCELLANY

• There's a good book to reference; don't remember the title. Will post later.
• Fogbugz = free, installable web-based tool for agile bug tracking.
• automated testing tools: Selenium, Pyccuracy