DC2009:Agile Ways to Develop Joomla! Extensions

From Managing Nonprofit Technology Projects Wiki
Revision as of 17:35, 13 January 2016 by Miriam (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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