Re: JIRA - tools question
- Oh, we have continuous builds and have working software we 'ship' regularly, as well...
The idea of test launch/soft launch of a game is definitely a strategy but one that might not be applicable for a high profile IP, because, if Halo was launched in a region (assuming that was even possible) like Canada or SE Asia, well, it'd be big news and blow the marketing release. THat was my point.
--- In firstname.lastname@example.org, Andrew Burrows <andy@...> wrote:
> The steps Adam outlined are how we develop social games. We challenge our
> teams to produce working software as quickly as possible, ideally by the
> end of the first day of our sprints (5 day sprints). We then iterate on
> working software.
> On Tue, Oct 2, 2012 at 11:35 AM, Adam Sroka <adam.sroka@...> wrote:
> > **
> > On Tue, Oct 2, 2012 at 7:34 AM, Charles Bradley - Scrum Coach CSP CSM
> > PSM I <chuck-lists2@...> wrote:
> > >
> > >
> > >
> > > Ron,
> > >
> > > I don't know. I think maybe it has been implied.
> > >
> > >
> > > Adam wrote:
> > >
> > > > 2) If you know exactly what you are going to build and when you are
> > > > going to have it built why are you literally
> > > > wasting your time with Scrum? You'd have more time to do what you
> > intend
> > > > to do anyway if you weren't making
> > > > your people go to pointless planning meetings. They are, in fact,
> > > > pointless, unless there is some possibility that
> > > > you will learn something and change the plan.
> > >
> > > I know what Adam is trying to get at, but it does seem we're being pretty
> > > hostile to a newcomer. That is not new for this list, but I'm afraid we
> > > might have gone over the "hostility line" here -- but not by much.
> > >
> > Adam doesn't always pull his punches, especially when he is on the
> > wrong coast and having trouble sleeping. That said, my intent was to
> > stop diddling around and get to the heart of the matter. Hostility is
> > not what I was aiming for per se, but I was trying to get a reaction.
> > > CuriousChimp,
> > > My guess is that you have said several things on this list that imply
> > that
> > > you are not doing something that is close to Scrum, and that's why you're
> > > getting a lot of resistance. Whether you are doing Scrum correctly or
> > > incorrectly is probably still up for discussion, as you haven't provided
> > > much evidence that you are doing Scrum. Further, what evidence you have
> > > provided has been in non-Scrum terms. (What is a producer? What is a lead
> > > game designer? What is a business owner? What is a 'resource'? None of
> > > these are Scrum terms.) Maybe if you told us some more about your Scrum
> > > implementation, we might be able to help more.
> > >
> > There was a lot of "we are different because..." That always gives me
> > pause. The game industry terminology is familiar to me.
> > > Earlier in this thread, you asked...
> > > > ...why is it that if I ask for a data tracking plugin to interpret the
> > > > same data provided in the burndown in a simple fashion, people have to
> > tell
> > > > me they 'smell' another problem?...
> > >
> > And a bit before that:
> > >
> > > We have specific delivery requirements in terms of feature set, and we
> > > want to add some functionality beyond original product goals. We're
> > working
> > > on a high profile game in a competitive space, and this data will help us
> > > plan whether we need additional resources, etc.
> > >
> > I don't know how to get the requested information from JIRA, but I
> > suspect if you can put it in you can get it back out. More importantly
> > however, if you had this information and you used it to make staff (or
> > equipment, or whatever "resource" means) decisions you would be making
> > a horrible mistake that I have seen fail many, many times.
> > Here's something that works for me: build a playable version of the
> > game as quickly as you can -- days, weeks at most. Look at the
> > remaining features and slice them into tiny pieces that you expect to
> > be able to finish similarly quickly. Build the most important ones
> > first.
> > Keep improving the artwork and the game play incrementally while you
> > are adding features. Automate your performance tests and run them all
> > the time. As soon as you have problems aggressively optimize.
> > Whenever it is that you need to be done you will have a defect free,
> > performant, fun game. It may or may not have some feature that you
> > imagined when you started. You'll survive.
> > > Because we don't believe in giving addicts more drugs without a thorough
> > > examination first. I'm not saying you are a "command and control" addict.
> > > I'm just saying that you seem to be asking for more drugs without
> > letting us
> > > know that you're currently on the path to recovery. I suspect you'll get
> > > more support and more advice if you can tell us that you are on a good
> > Scrum
> > > path.
> > >
> > That's a good way to put it, much better than anything I said, in fact.
> Andrew Burrows
> Managing Producer, Large Animal Games
> Call me: 212-989-4312
> Follow me: @readytoscrumble
> We're Hiring: http://largeanimal.com/jobs
- In my experiences using and coaching teams using GH, we very rarely even saw/knew about the underlying JIRA system. 90+% of the time we used the card walls("boards", "planning board", etc) and a couple of searches. We didn't even have to know that JIRA existed, except for some very default/basic administrative config that is shared by both.
I have really enjoyed numerous Atlassian tools. I get especially amused when someone tells me about their "Sharepoint wiki." I show them Confluence, and they usually are completely hooked and realize how much Confluence kicks the pants off of Sharepoint (at least in the way that most dev teams use them).-------
From: Cass Dalton <cassdalton73@...>
Sent: Friday, October 5, 2012 6:51 AM
Subject: Re: [scrumdevelopment] Re: JIRA - tools question
We have started to test out GH as well. The downside to GH over Rally and VersionOne is that GH is a plugin on top of a system that is designed as an issue tracker where the others are designed from the ground up to be Agile management tools. The up side is that JIRA is very customizable and integrates with a large number of other tools including several SCM tools.
On Wed, Oct 3, 2012 at 11:57 AM, Angelo Schneider <angelo.schneider@...> wrote:Hi,
We use the greenhopper plugin for Jira.
Works fine for planning sprints and see what is done and what not.
privat: -------------------- www.oomentor.de --------------------------
Angelo Schneider OOAD/UML Angelo.Schneider@...
Putlitzstr. 24 Patterns/FrameWorks Fon: +49 721 9812465
76137 Karlsruhe C++/JAVA Mob: +49 172 9873893