[asterisk-dev] Project Planning Template

[Dan Jenkins]

Sounds good Matt,

Dan

-- 
Dan Jenkins - Senior Web Developer
email: dan.jenkins at holidayextras.com
twitter: dan_jenkins <http://twitter.com/dan_jenkins>
linkedin: jenkinsdaniel <http://www.linkedin.com/in/jenkinsdaniel>
skype: d-jenkins
blog: www.dan-jenkins.co.uk
about.me: about.me/dan_jenkins



On 5 November 2012 02:29, Matthew Jordan <mjordan at digium.com> wrote:

> On 11/03/2012 08:20 AM, Dan Jenkins wrote:
> > Hi Matt,
> >
> > Unfortunately I wasn't at AstriDevCon and I'm not entirely sure how you
> > currently manage the different projects that go into major releases; but
> > we utilise Jira heavily at my place of work and it seems like you could
> > too (outside of just making jiras and working on them). Firstly, the
> > wiki page in Confluence is a great "human readable" overview of what the
> > project is, what it aims to do, what's going to be involved and so I'd
> > absolutely keep that; but it seems like you'd want more within Jira
> > itself - for the people working directly on the project.
> >
> > Firstly, this process seems like a lot of work (and I wasn't a fan when
> > we changed over to this), but it really does help and makes the team
> > working on the project very clear on what needs doing, what the
> > requirements are etc.
> >
> > When we get a project in, we get a list of requirements with it - this
> > comes in the form of an "Epic" jira, which has a list of requirements
> > within it.
> >
> > We, as developers, break these requirements down into chunks of work
> > called "stories", each story is a deliverable - this would maybe be a
> > little different for you, but i can imagine a story would be "construct
> > AMI events", "construct AGI" and so on. Stories are high level bits of
> work.
> >
> > These stories get linked to the Epic as "fulfilled by" in Jira.
> >
> > Then within each of these stories we break down everything that we need
> > to do to complete that story. These are called "dev tasks" within our
> > workflow and are sub tasks to the story within jira.
> >
> > In the end you should have your Epic (with requirements), Stories which
> > are linked to the epic (all your stories should complete your
> > requirements) and then dev tasks which are sub tasks to the stories.
> >
> > I'm not sure on the limitations of your Jira installation as I know
> > Atlassian give different plans different functionality.
> >
> > This would then allow you to make dashboards (if you wanted) for
> > different projects; allowing people to glance at a project and really
> > understand where everything is etc.
> >
> > Like I said at the beginning, you might already be doing all of this
> > within Jira; but I've had little experience of your workflows within
> > Jira (only ever submitted bugs).
> >
> > Am I telling you something you know about already?
> >
>
> Yes and no :-)
>
> So, historically, the ASTERISK project in Jira hasn't been used to plan
> projects beyond patch attachment and discussion, so there are no
> Epics/Stories.  While we could enable Epics/Stories in that project,
> we've focused instead on making it useful for issue reporting/tracking.
>
> That being said, as a fan of Agile methodology (which we use at Digium),
> I'd love to use Epics/Stories in Jira.
>
> There is, however, a difference between how we do software development
> at Digium versus the Asterisk project as a whole.  Not every
> organization (or individual!) that develops for Asterisk may follow that
> process, and its difficult to mandate a software engineering process
> (much less a requirements analysis/breakdown methodology) across
> everyone that contributes to the project.  I'm hopeful that whatever
> requirements documentation we ask folks to do for a major project is
> generic enough that they can use it regardless of their organization's
> development processes.
>
> So, if a project decides to use User Stories, we may want to explore
> enabling Epics/User Stories in the ASTERISK project and using a
> {jiraissues} macro to document them on the Confluence page.  But if
> someone likes Use Cases they can use those too - in the end, I'm happy
> with anything that results in a minimum set of requirements getting
> written down!
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121105/f27d0abe/attachment.htm>