Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Allen Ramses
Caldari Typo Corp
|
Posted - 2009.12.29 05:14:00 -
[1]
I must ask, how much time was allocated to final "hardening sprints" (as Alli calls them) before Dominion was deployed? I have this feeling that because Dominion was not as trouble free as it could have been, there wasn't one... That, or it certainly wasn't very big. Citadel torps are proof enough of this.
Another question I have to ask is if EVE's engines are also driven by scrum teams. _trinity.dll seems to have taken a suckerpunch to the kidneys, and the audio engine is having problems of its own, as usual. Is anybody dedicated to keeping the core of the client running smoothly?
One last question... Does anybody genuinely believe that scrum will work with a game as large and complex as EVE while still observing a fixed release schedule? Hell, will any production philosophy work for EVE while observing a fixed release schedule? Why not release the game "when it's done" instead of some arbitrary date two weeks (or six months, for that matter) ahead?
I would really like to know what your methods are, CCP. I'm really quite tired of having to deal with artifacts from an unfinished product, and I especially don't like abandoned patches (see Empyrean Age and Quantum Rise, with Dominion fairly soon).
____________ I'd make a forum signature that didn't suck, but I'm restricted by a character limit that does. |
Myra2007
Perkone
|
Posted - 2009.12.29 05:41:00 -
[2]
As diminishing as the chances of a meaningful answer would be under normal circumstances - I think the fact that probably half of the devs or more are on winter holidays really ruins it.
I mean we've seen CCP Applebabe posting on server-downs. Doesn't that say everything? --
Originally by: Professor Slocombe
I will only buy tickets if the prize is your stuff and you leave Eve. Forever. You irritating self obsessed cretin.
|
Haryman
Gallente Griffintown Development Corp
|
Posted - 2009.12.29 21:37:00 -
[3]
No fixed schedule = Duke Nukem Forever
|
ForceM
Gallente POS Builder Inc. Silent Requiem
|
Posted - 2009.12.29 22:11:00 -
[4]
Originally by: Haryman No fixed schedule = Duke Nukem Forever
i lolled :) -----
|
Allen Ramses
Caldari Typo Corp
|
Posted - 2009.12.31 00:18:00 -
[5]
Edited by: Allen Ramses on 31/12/2009 00:19:57
Originally by: Haryman No fixed schedule = Duke Nukem Forever
Yes, I suppose this is true. But for the sake of argument, 3D Realms seems to suffer from Feature Creep. CCP at least seems to have a general idea of what needs to be done in a patch (even if they don't do it right). CCP doesn't seem to follow the "At this point in time, no more features are to be implemented. Finish what's left and get it out the door." method, unfortunately.
I don't know about you, but I'd much rather have a solid patch every nine months than a shoddy patch every six. Apocrypha was a problematic patch which was redeemed after Apocrypha 1.5, but it would have been better if CCP stayed Apocrypha until 1.5 was ready.
EDIT: Activision?? Man, I must be on drugs
____________ I'd make a forum signature that didn't suck, but I'm restricted by a character limit that does. |
Okonaa
|
Posted - 2009.12.31 01:04:00 -
[6]
every big game developer uses scrum at least in some parts in a developing process.
|
Ban Doga
|
Posted - 2009.12.31 08:00:00 -
[7]
Originally by: Allen Ramses Edited by: Allen Ramses on 31/12/2009 00:19:57
I don't know about you, but I'd much rather have a solid patch every nine months than a shoddy patch every six. Apocrypha was a problematic patch which was redeemed after Apocrypha 1.5, but it would have been better if CCP stayed Apocrypha until 1.5 was ready.
Yes, I'd prefer that too.
I see really little comfort in having a new expansion out on December 1th seeing/knowing that one month after there are still major issues (e.g. http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1234899) left unresolved.
However it seems having 2 expansions per year and planning each new expansion as pompous as possible is more important than reducing the disruption of gameplay they cause.
Looking at the changes that were introduced into the patch for the production that weren't present on the staging system (SISI) really gives the impression that development happened until the last minute before shipping. The repercussions of that can still be felt and will continue to be until the next expansion tries to smooth that out (again eating away the time for planned features).
If you don't have time to get today's job right today you won't have time to get tomorrow's job right tomorrow and make up for whatever you choose to ignore today. That's one of the reasons why certain features that did not make it into their planned release never make it into the game at all or why certain aspects of the game appear to be hilarious for new players but still never got addressed properly.
|
Fearless M0F0
Gallente Aliastra
|
Posted - 2009.12.31 09:34:00 -
[8]
A properly run SCRUM dev cycle should not need "hardening sprints", you are supposed to divide the work in pieces small enough that you can design, develop and test in a single sprint.
... easier said than done, thought
Quote: Does anybody genuinely believe that scrum will work with a game as large and complex as EVE while still observing a fixed release schedule?
Quoth the Almighty Wikipedia: A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach ł accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the teamĘs ability to deliver quickly and respond to emerging requirements.
Ye, I'm a certified SCRUMmaster
|
Hyperforce99
Gallente GoldTech Mischievous Industrial Logistics Ltd.
|
Posted - 2009.12.31 09:36:00 -
[9]
yes the audio engine could use a fixer. Its been stalling for me more than I would like. Space has no sound... but I'd still like to hear every single explosion at 100 KM range please. (right now I more than often hear nothing at all but a random shot at close range :( --------------------------------------------- Somewhere beyond happyness and sadness, I need to calculate what creates my own madness o/ |
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2009.12.31 10:02:00 -
[10]
Originally by: Okonaa every big game developer uses scrum at least in some parts in a developing process.
That's like saying that doing mini-waterfalls is SCRUM
|
|
Elena Laskova
|
Posted - 2009.12.31 10:28:00 -
[11]
Edited by: Elena Laskova on 31/12/2009 10:31:13
Scrum doesn't address the majority of the issues that make large, continuous projects difficult to handle.
Assuming a lightweight methodology like "scrum" is **complete** ensures that you can fail with it. This mistake leads to things not being done at all, and to applying the currently popular methods to things for which they are not well suited.
The IT business has been coming up with "magic methodologies" on a regular basis since the beginning. Most of them claim to achieve exactly the same benefits as their predecessors. They claim to address the same fundamental problems. They claim that most of what's gone before was inadequate and missed the point. So far, such claims have proven to be only partly true.
"Scrum" (which isn't an acronym) has its charm. But we've seen no evidence it would address the issues with the last EvE patch.
The only thing that has never changed in software development: "Good, Fast, Cheap: choose two". This seems to be an immutable law, and is entirely independent of the methodologies used.
|
Ban Doga
|
Posted - 2009.12.31 10:38:00 -
[12]
Originally by: Elena Laskova
The only thing that has never changed in software development: "Good, Fast, Cheap: choose two". This seems to be an immutable law, and is entirely independent of the methodologies used.
I strongly disagree here.
Because whenever you choose "cheap" or "fast" it won't stay fast and it won't stay cheap in the long run. Quality (assuming this is the "good") is the one irreplaceable thing in software and choosing "fast" and/or "cheap" ususally cuts right into that. This inevitably leads to increased turnaround times later (See http://en.wikipedia.org/wiki/Technical_debt).
Unfortunately software systems likes MMOs (unlike the 2314th version of tetris which won't get 2 expansions per year) always have a "later" they will need to keep in mind and eventually deal with.
|
Elena Laskova
|
Posted - 2009.12.31 12:04:00 -
[13]
Ban: I understand what you're saying - "technical debt" is a meaningful idea.
But you're making a narrowing assumption about the meaning of good/quality. "less good" doesn't mean "unmanageable technical debt". "faster" doesn't mean "cut out testng to get the code out the door".
Nobody can *afford* to build perfect software. It's not art: you build to a profit objective. There is an ongoing tradeoff between what you do and what it costs. The curse of software is that you can't "see" the quality, so "pointy-headed manager" types always choose to manage to time and cost, and compromise on function and quality (the two major aspects of "good").
Technical debt is the *symptom* of a very common style of management. And, if anything, is slightly encouraged by scrum (which can be good for speed and function).
|
Ban Doga
|
Posted - 2009.12.31 13:35:00 -
[14]
Originally by: Elena Laskova Ban: I understand what you're saying - "technical debt" is a meaningful idea.
But you're making a narrowing assumption about the meaning of good/quality. "less good" doesn't mean "unmanageable technical debt". "faster" doesn't mean "cut out testng to get the code out the door".
Nobody can *afford* to build perfect software. It's not art: you build to a profit objective. There is an ongoing tradeoff between what you do and what it costs. The curse of software is that you can't "see" the quality, so "pointy-headed manager" types always choose to manage to time and cost, and compromise on function and quality (the two major aspects of "good").
Technical debt is the *symptom* of a very common style of management. And, if anything, is slightly encouraged by scrum (which can be good for speed and function).
I see where you are going and I concur with that.
In my experience tho, you can't "just go faster" because someone told you to do so. You either have to drop software quality (testing, documentation, thinking about how/when/why this will be used, reviews, etc.) and/or cut the feature list (less feature, simplified features). Assuming otherwise would mean addressing waste of time (still interesting but not the thing I was talking about)
Cutting the feature list is usually less dangerous, but still can be: just look at the imbalance between Titans and Motherships right now - all the result of simply dropping the "Mothership Buff".
Also I never said dropping quality results in "unmanageable technical debt" or "faster" means "stop testing". Although those are one of many examples and sometimes it really happens that way.
I cannot "see" the value of a gold mine if I happen to find one. But that does not mean there is no way to assess this value and express it in a way that is understable for me (hard $$). The same thing applies to software and there are ways to make software quality visible and comprehensible even for someone who is not an expert in this field (a good currency here is hours: "If we do this botch today we gain 8 hours and can deliver tomorrow but then we will have to spent 20 hours before we can ever touch this part again: Y/N?").
And as always: This is just a posting in a forum. Don't expect to learn my complete point of view about any certain thing by reading one of my posts. So don't expect your judgement "you're making a narrowing assumption about ..." to be accurate.
|
Acrid Acid
|
Posted - 2009.12.31 13:45:00 -
[15]
Wait wait wait... What the hell is ''scrum''? Only definition I found says its some kind of game...
|
Ban Doga
|
Posted - 2009.12.31 13:52:00 -
[16]
Originally by: Acrid Acid Wait wait wait... What the hell is ''scrum''? Only definition I found says its some kind of game...
http://en.wikipedia.org/wiki/Scrum_(development)
It's one of the "agile methods" for software development.
|
Fearless M0F0
Gallente Aliastra
|
Posted - 2009.12.31 14:39:00 -
[17]
Originally by: Elena Laskova
Scrum doesn't address the majority of the issues that make large, continuous projects difficult to handle.
Assuming a lightweight methodology like "scrum" is **complete** ensures that you can fail with it. This mistake leads to things not being done at all, and to applying the currently popular methods to things for which they are not well suited.
ahhh, another epic flamewar about scrum by somebody who have no idea what is talking about or had a bad experience with it because their project manager didn't "get it"
The first chapters of Ken Schwaber's book about scrum explains where it comes from and why it works better for software development. It is much more than just some "lightweight" methodology.
Warning, heavy theoretical stuff below:
There are two approaches to control a process: Defined and Empirical.
You use a defined approach when given a well defined set of inputs you always obtain the same outputs (building bridge, mass manufacturing of widgets, etc)
On the other hand, if your process is not well defined generating unpredictable and unrepeteable outputs an empirical approach works better. Software development falls into this category.
Empirical approaches are hard to swallow by software developers because their scientific minds are more compatible with having everything defined.
|
Elena Laskova
|
Posted - 2009.12.31 14:51:00 -
[18]
Edited by: Elena Laskova on 31/12/2009 14:53:33
I ran an agile project this year (my project, but the technical group handled the methodology).
It worked out very well. Especially: * Handling the inevitable mutability of our customer's requirements * Adjusting to technical constraints which turned up during the project
Overall, one of my more interesting projects, and well received by the customer.
That said, I stand by my earlier comments. Agile development is a modest but real advance in S/W development. But it's not magic. In particular, while it helps with some of the inevitable issues due to the fallibility of humanity, it doesn't remove them all.
FWIW my experience (which is considerable) is that S/W developers hate overly-structured methods. People who don't understand S/W love them though, because developers are very good at fooling their handlers /lol.
|
Haguu
Caldari School of Applied Knowledge
|
Posted - 2009.12.31 16:29:00 -
[19]
I am far more familiar with traditional CPM/Waterfall project management than agile/scrum but it seems to me that scrum has a lot of advantages. My original assumption (prejudice) was that scrum would be better at something like a new release than something "larger" / more fundamental like changing the foundation - e.g. redesigning for today's 64-bit multi-core processors. But I suppose that there is no reason that agile would not work there as well. But it is not like Dominion where the development teams need to iteratively respond to the designers changes; it is a technical issue as to how to write efficient engine to support a reality where processors have started having more cores rather than getting faster. But if you assume that a new engine is something to be iteratively discovered rather than a priori designed and then implemented, then agile would work well.
Do you scrummasters think agile would work equally well on foundation changes? |
LaVista Vista
Conservative Shenanigans Party
|
Posted - 2009.12.31 17:13:00 -
[20]
Originally by: Haguu I am far more familiar with traditional CPM/Waterfall project management than agile/scrum but it seems to me that scrum has a lot of advantages. My original assumption (prejudice) was that scrum would be better at something like a new release than something "larger" / more fundamental like changing the foundation - e.g. redesigning for today's 64-bit multi-core processors.
It's fair to say that SCRUM is slightly harder to implement if your development techniques does not already involved TDD and you have things like continous intergration servers and the like at hand.
It is possible to use SCRUM to replace layers of an application over time. But if your product isn't a long-term thing and will not require long-term maintanence, it's probably not worth doing.
|
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |