DC2009:Agile Ways to Develop Joomla! Extensions

From Managing Nonprofit Technology Projects Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.
  • Doesn'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.

A-HA's 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
Retrieved from "https://mntp.aspirationtech.org/index.php?title=DC2009:Agile_Ways_to_Develop_Joomla!_Extensions&oldid=445"