Watching the speed of development and the quality of Unity I was wondering how OTEE goes about creating this wonderful product? I know you are all super stars :), but I was wondering if anyone from OTEE would be willing to share how they go about developing Unity so maybe us mere mortals might learn. Is one the more common methodologies (XP, Scrum, Waterfall :), etc.) used, a variation, or is it some completely different OTEE methodology? Stuff like:
At what point is a rough decision made on what features will be in a given release?
Are initial features handled at the high level with little detail?
When is testing done?
How often is code integrated?
How is work split up?
How are requirments tacked?
Is work done in small batches or larger batches? Here the end of a batch is completely tested code.
If iterations are used, how long is the typical iteration?
Is work assigned or does everyone “choose” what to work on?
I think the secret ingredients are BloodSugarSexMagik! Oops… wrong meeting.
Seriously though, some of these questions are quite hard to answer. At the moment we don’t use any particular “development process”, but we believe in some ideas of some methods. I would think we’re quite “agile” (in a sense that we can actually do something or react to something pretty fast). At the current company size we’re pretty much self-managing and if we’d start appointing scrum masters (or whatever else), there would be no people to do the actual work!
That depends. For example, some 2.0 features have been decided long ago; while some 1.6 features got pulled in quite late (the “hey, Vista is actually coming out soon!” moment for example). The decision is most often made in the evening
Possibly yes. First you think of “html<->unity communication” and only after that all the gory details are realized.
Always!
Depends on the feature. Sometimes we do twenty subversion checkins a day, all with minor stuff; sometimes we don’t. For example, non power of two textures in 1.6 was some work to get in; I only checked that in when it was more or less actually working. Everyone checks stuff in when it’s sufficiently complete; and the rest of the team always works on the latest svn revision.
By splitting the work in 2/3/4/… pieces! For example, Joe does most of the core engine, scripting, asset pipeline work; I do most of windows and graphics work, etc.
Hm… we kill them? :roll:
Depends on the work in question (see 4). We try to integrate early (hence small batches), however sometimes it does not make sense. If you’ve just started something that goes deep into the various systems, then integrating too early would leave others with a broken build. There’s no such thing as “completely tested code” though…
Let’s see… Unity 1.2.2 was 2006Mar, 1.5 2006Jun, 1.5.1 2006Sep, 1.6 2006Nov. Does that give 2-4 months per “iteration” (aka “release”)? And if you count in our beta program, the iterations are shorter. Like I said above, we don’t stick to any formal “process”, so it’s hard to define what “iteration” is. Ourselves we’re always running on the latest revision; and externally iterations are visible through real or beta releases.
See 5. Some of the work can be assigned “by definition”, e.g. currently whatever comes up for Windows is automatically done by me.
I’ll let others expand upon this or deny everything I’ve said.
Aras, thanks for the quick reply What you posted was along the lines I was expecting. Talking this weekend with someone who works for Red Hat on JBoss, how OTEE does things seems very similar to how the JBoss teams work. At JBoss they use Jira fairly extensively for their “tracking”, and their work for the most part is self organizing.
hehe, I guess I should have used tracking instead of tacking
On releases, do you generally have target time frames that you work towards? For example, early on was the goal set for 1.6 to be Novemberish/Early December, or did you get into late October or early November and decide at that point to try to finish in November?
For integration, I assume there is some automated testing here, is that correct? If so, what do you use? Is it home grown, some standard framework, etc?
For requirements/bugs we currently use FogBugz. It’s okay, though if asked whether I’d prefer Jira or FogBugz I’d have no answer (I like Jira as well).
Obviously we try to meed the planned dates. Whether we are successful at that or not is a different question. Unity 1.6 turned out to be ok in planning.
And FWIW I’m already enjoying some of the “freedom” that I feel in how releases and feature work seem to get mapped out. I say that after having come from Macromedia and Adobe where the release processes are very rigorous (from early release conception through delivery of the final product), with multiple check-points and approval processes along the way. I don’t want to go into too great a detail but suffice it to say that small companies seem quite a bit more agile in meeting customer needs than larger companies. Of course on the flip side I think some of that rigor can be a good thing as it can help keep you on track as well as ensure that things don’t “fall through the cracks”. I don’t yet have enough time here with these guys to comfortable offering suggestions and process changes, but over time perhaps I’ll help identify the good parts from my Macromedia/Adobe experience and help incorporate those into the release process here at OTEE.
I dare not deny what Aras has to say, I’m way too much the OTEE noob to dare tread on that ground… :lol:
Tom, I would be interested in what parts of the Macromedia/Adobe processes you though were particularly valuable as well as those parts that were mainly waste. I image that Adobe follows a more “traditiona” approach, is that the case?
Sorry for the slow reply… Here are some high-level thoughts:
Valuable: the release process now starts with the product team’s crafting an initial release plan (features and whatnot) which is then run through multiple rounds of customer visits before being crystallized into a final and approved release plan. This allows for actual customer needs/feedback being used early in the process as opposed to later (when it’s often too late to do much with that feedback). This was introduced recently, after the last Director release for example, and is a good thing.
Wasteful: well, I don’t know that anything is a waste per se, it’s just that the whole process is generally set up to support rather lengthy product release cycles and while I appreciate the desire to avoid user update fatigue, I think it’s hard to track and respond to need changes quickly in such an environment. The release plan crafted today may not be on the mark 12-18 months out from now. On top of that when you’re in a company with 70+ products (obviously less than that during the Macromedia years, but there were enough to cause the same condition) you have to target and shoot for specific windows in the release cycle to get web team attention, into production, etc., that too inhibits quick and appropriate changing of plans to meet the true needs at hand.
Edit: forgot to address the question about whether they follow a “traditional” process or not… I’m not sure what your definition of traditional is but I suppose they do. It starts with the product team crafting a release idea, that idea is shown to a number of customers to iteratively improve the plan until it’s ready for executive approval, once that happens the team sets to work on the release against a target ship date (while a specific date is set it really defines more of a window than a single date). So I suppose that’s “traditional”… (I’m glossing over a lot of details of course)
