Man, my brain doesn’t have space for all that whinging.
The description for that task is saying that the gamecode and graphics support will continue up until the 25th before that task is completed (although it will very possibly be delayed again).
Correct, this production schedule is just for 3.0.
I said “feature complete”, which is what it says on the schedule. Doesn’t the term “feature complete” leave room for bug fixing?
It absolutely does, but my argument is who gives a shit if it doesn’t work yet? They’re providing information to their community that doesn’t actually indicate anything meaningful. It’s deceptive.
Burndown charts are meaningful because they show how development is actually progressing. QA finds bugs, developers address them, and that process iterates until the feature is good to ship.
Can QA start their work on a task before it reaches feature complete status?
Also,
That chart is specifically limited to issues that they feel must be fixed before they release 3.0 to the Evocati player test group. They mentioned in the latest Around the Verse that they have many more bugs tracked for the general 3.0 branch.
I want to see the burndown chart for the developers’ accrued vacation time. None of them are going to want a lot of time banked when this blows up.
I have never seen a software project where lots of groups keep announcing small delays where they are actually anywhere near ready. I would bet huge money that they are all playing chicken waiting for one of the other groups to finally crack and admit how far they are behind and take the heat. Particularly since the groups are spread across different studios in different countries. I have been on that ride, can’t recommend it.
Dear lord. Yes. QA and development should be working together very closely for the entire duration. That’s how modern development works, devops, continuous integration, very frequent releases, break fast and fix as you go.
I ask that because I recall seeing this in the description of one of their items (Render To Texture):
This system is still in progress, but due to its overall size and some of the other features for 3.0.0 that require Render to Texture, teams are using the system as soon as they are able, which means that Render to Texture is requiring bug fixing support while it’s being developed which results in further delays of the system as a whole. The date below does also take dedicated bug fixing time into account.
Which implies that the individual items do not typically receive bug fixing support until they are feature complete.
It kind of depends on what you mean by “a task”. Generally the way software production happens is that a big task (e.g. “create YouTube”) is broken into smaller tasks (“login”, “upload video”, “display video”, “comments”, etc.) and each of those is made up of tasks (“create new account page”, “verify that user isn’t already a member”, “write username and password to database”, “send confirmation email”) and so on. At the lowest level, each of those things should have something called a “unit test” associated with it to verify that the small piece actually works as expected, and then when you hook them together you might have to test some interactions but you should know that each small piece does what it’s supposed to.
For something like graphics rendering, there are likely some tasks that just accept the rendering as some kind of plug-and-play thing where they just call the “render” method and it happens, and if the system is built well it should be irrelevant how “render” is actually implemented, and those teams can keep developing while it’s still in progress. But there are other teams that are probably blocked until that’s done; you can make “mock” or fake implementations that let you still get some work in but if you can’t predict the performance there’s only so far you can go with that.
It sounds like “Render to Texture” is nominally complete but insufficiently tested, but they decided to go ahead and let other teams work with the prerelease code and that’s caused some bugs to become visible. Normally you’d want to be pretty sure your stuff works with your own tests before you let other teams do it. So in general individual items should be having their bugs fixed without impacting everyone else.
I think your confusion is in that being “feature complete” to the point where you can claim something is done implies that the bug fixing is already finished so the idea of “not getting bugs fixed until the task is feature complete” isn’t really a thing.
This has only made me more confused, since I thought something becomes feature complete before the bug fixing has been finished.
One thing to realize is that during integration phases is that it is not only coding bugs that are discovered, there are design and architecture bugs. These can often result in huge rework across multiple areas that were considered done that now need major work. That is a reality for any large project.
It’s valid enough to say “feature complete” refers only to the initial implementation, but like I posted earlier with the 90/90 rule and Lantz notes, there’s a lot more to development than the initial implementation. To such an extent that it really is deceptive to tell endusers you’re “feature complete” when a feature hasn’t passed QA and isn’t ready to ship.
For comparison, here is the final production schedule from Alpha 2.6. What is particularly useful about this is that the dates are not speculative, since this was created as a retrospective after the update went live. As with the 3.0 schedule, the colored bars indicate the dates in which all of the items in those categories became feature complete.
Different teams use different meanings. I don’t like using feature complete until the bugs are done because it can sometimes encourage developers to put out a buggy feature that they know QA will kick back to them, but it will at least hit the feature complete deadline.
Sorry to jump in so late in the discussion, but what is this? They have some kind of subscription club to get more info?
Yeah, I guess they send you a monthly PDF magazine and you get various cosmetic perks. They have both a $10 and $20 subscription level. And if you stay subscribed for a year you get a coupon for 10% off a DLC, capped at $50.
This is the sort of thing that I generally feel is OK in a released F2P game. For an unreleased B2P game, it’s disgusting.
Oh, wow. I didn’t even know about this. That’s pretty gross for an EA game.
Subscription revenue contributes to Star Citizen project development by funding behind-the-scenes shows like Around the Verse, Reverse the Verse and the “10 For the” series in addition to Jump Point, the monthly digital magazine about Star Citizen.
You have $156 million dollars raised already! Why are you asking for more money to make progress updates?
Well they are really deluxe progress updates. We’re talking multiple weekly 20+ minute long videos, professionally edited with music and titles. Those aren’t free to produce, and by separately funding them they avoid the trap I referenced in my original post, where people backing the game pay for that fluff.
I believe you also get free access to ships and stuff, if you subscribe. They have a ship of the month thing, and then I think they get rental credits that let them temporarily test drive ships without buying them.
I get that, but how about just try not spending so much damn money to produce the video updates? People want more info, they don’t need it presented with all the jazz.
Marketing bro.