LesleyB has asked for the wisdom of the Perl Monks concerning the following question:

Greetings o Wise Ones

I've been indulging in the fantasy of Perl as a paying job again recently and have seen some adverts which discuss agile development.

I've decided I'm not exactly definite what an agile development environment actually consists of. I've always thought it meant using a framework (e.g. CGI::Application or Catalyst) and not only developing re-usable code but actually re-using it too.

I believe the aim of an agile development environment is to be able to construct an application quickly.

However I don't really know, nor do I have anyone but you kind folk to ask. So I'd like to know if the above thoughts hold true.

I would also like to know what is there in Perl or CPAN that qualifies as or provides an agile development environment?

Replies are listed 'Best First'.
Re: Agile methods in Perl
by dHarry (Abbot) on Sep 28, 2008 at 16:57 UTC

    Agile (software) development has nothing to do with frameworks. You can use frameworks or not use frameworks with it. What makes development "agile" is (non limitative):

    • the iterative character
    • minimal planning
    • emphasis on stakeholder involvement

    It seems perpendicular to the waterfall method: non-iterative, everything planned upfront and stakeholders only involved in initial stage.

    There are many agile methodologies around, as an example I would like to mention XP, eXtreme Programming and RAD, Rapid Application Development.

    As with any methodology there are pitfalls: The project in question needs to be suitable for agile development otherwise it won’t work. Also the organization/company needs to be ready for it. If the stakeholders are not "available" enough or management is uncomfortable with it you can also forget about it. Last but not least the designers/programmers also need to be ready for it. If you have never worked in an agile environment I suggest you go on same training/course.

    The good news is that you can use Perl "as-is".

    HTH

      What he said. As far as I can tell, "agile" is a few buzzwords, a few common-sense ideas about software development, and a few good ideas taken to unhelpful extremes. To paraphrase Larry Ellison, programming is a fashion industry, so as long as you pick up the core ideas and say the buzzwords at the right times, you should be fine in whatever language.
Re: Agile methods in Perl
by Perlbotics (Archbishop) on Sep 28, 2008 at 17:13 UTC

    As others already said, it is not a framework. Frameworks can support agile development, e.g. creating mock GUIs or test frameworks that support daily regression tests. It is rather a bunch of SW development related models/methodologies and a project management idea - or buzzword - depending on ones believes.

    One of these methodologies is XP. Freely associated with Perl, I think of the following resources...

    Here's something about the theory: Alistair Cockburn, Agile Software Development (2005) (not Perl related / Update: management literature; rather an overview than a list of concrete practical advice).

Re: Agile methods in Perl
by Xenofur (Monk) on Sep 28, 2008 at 12:32 UTC
    From my experience with other software projects agile development quite simply means that the development cycle and company processes are geared towards getting work done on a project out into the wild as fast as possible, for example weekly patches in an MMO as opposed to the usual quarter-yearly patches most MMOs have.
Re: Agile methods in Perl
by eighty-one (Curate) on Sep 28, 2008 at 15:43 UTC

    I have never worked in an 'agile' environment, so take what I say with a grain of salt. We did, however, cover agile methodologies in grad school. From my understanding, agile is a way of developing software. And although there are technologies and frameworks that naturally lend themselves to agile methodologies, they are not necessarily a requirement, nor does using them automatically mean you're doing agile development.

    Actually, the Wikipedia article looks quite good. It's long, but probably does a better job explaining than I could.