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