(c) Ariel Bravy

• Scrum is appropriate for projects where we can’t define requirements up front and chaotic conditions are anticipated throughout the product development life cycle.
• Small teams that work independently are more effective.
• A scrum is a team of eight individuals in Rugby. Everyone in the pack acts together with everyone else to move the ball down the field.
• After initial planning, a series of short development phases, or spri nts, deliver the product incrementally.
• A sprint typically lasts one to four weeks and an entire project only a few months.
• The team tracks all currently identified tasks, capturing them in a list called the backlog. The backlog drives team activity. Before each sprint, the team updates the backlog and reprioritizes the tasks—each team signs up for a number of tasks and then executes a sprint. Individual team members agree to complete tasks they believe are feasible during each sprint.
• A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver valuable functionality.
• The team can reduce delivered functionality during the sprint, but the delivery date cannot change.
• During the sprint, the team holds frequent (usually daily) Scrum meetings. The meetings serve a team-building purpose and bring in even remote contributors, making them feel a part of the group and making their work visible to the rest of the team.
• Scrum meetings need not be daily. Two or three times a week works.
• Planning proceeds relatively quickly because the initial assumptions will surely change as sprints deliver incremental functionality.
• Stick to the topics of the sprint. It’s very easy to get off topic and extend what was supposed to be a 10 to 15 minute meeting into a half-hour or more.
• During the scrum meeting, each member should answer these questions:
  • What have you completed, relative to the backlog, since the last Scrum meeting?
  • What obstacles got in your way of completingthis work?
  • What specific things do you plan to accomplish, relative to the backlog, between now and the next Scrum meeting?
• The Scrum meeting should last 15 to 30 minutes, which provides enough time to address obstacles, but does not allow time to brainstorm a solution. All discussion other than responses to the three questions is deferred to a later meeting involving only those actually affected by the discussion.
• The Scrum master leads the Scrum meetings, identifies the initial backlog to be completed in the sprint, and empirically measures progress toward the goal of delivering this incremental set of product functionality. The Scrum master ensures that everyone makes progress, records the decisions made at the meeting and tracks action items, and keeps the Scrum meetings short and focused.
• After each sprint, all project teams meet with all stakeholders, including high-level management, customers, and customer representatives. All new information from the sprint just completed is reported. At this meeting, anything can be changed. Work can be added, eliminated, or reprioritized. Customer input shapes priority-setting activities.
• Items that are important to the customer have the highest priority.
• Product delivery can take place after any sprint. Typically, final delivery takes place after a wrap-up phase that is run as a final sprint.
• Given what was delivered during the last sprint and the current state of the market, the stakeholder meeting should address the question, “Should this project continue?”
• Summing up, these are some advantages of using Scrum:
  • the product becomes a series of manageable chunks,
  • progress is made, even when requirements are not stable,
  • everything is visible to everyone,
  • team communication improves,
  • the team shares successes along the way and at the end,
  • customers see on-time delivery of increments,
  • customers obtain frequent feedback on how the product actually works,
  • a relationship with the customer develops, trust builds, and knowledge grows, and
  • a culture is created where everyone expects the project to succeed.
• From their experience at AG:
  • In experimenting with the Scrum software development process, we found that small teams can be flexible and adaptable in defining and applying an appropriate variant of Scrum.
  • I’ve noticed an increase in volunteerism within the team. They’re taking an interest in each other’s tasks and are more ready to help each other out.
  • Any rule is just a rule, and if there are compelling business reasons, no process should stand in the way of making the best decision for the overall project.
    

[]s
-- AFurtado

The statements or testimonies I offer in this post represent my own personal views.
I am speaking for myself and not on behalf of my employer, Microsoft Corporation

• Microsoft has many initiatives (desktop, entertainment, online, enterprise).
• Get a subset of that, such as Windows operating systems.
• Get a subset of that, say, Vista.
• Get a subset of the tasks that are needed to support Vista's lifecycle, such as providing service packs (SPs) and hotfixes.
• Get a subset of that, such as SPs and hotfixes related to the operating system shell components.
• Get a subset of that such shell components, say, some (not all) Control Panel components.
• Get a subset of the responsibilities related to Control Panel components SPs/hotfixes, such as being responsible for the actual test process (designing/implementing test cases, thinking about new automation opportunities, etc.).
• Hey, now you finally spotted my role inside the Microsoft world!

• The starting point for Domain-Specific Development IS NOT about creatively defining models and then generating applications from them. The model IS NOT the starting point.
• Domain-Specific Development is about what you are going to generate. You start from there, by identifying applications that already exist and are samples of the desired product line. Identify what parts can be generated or actually configured by generation. Only then think about creating languages to generate that. That's slightly different from MDA.

So doesn't it sound a bit weird to use a one-size-fits-all modeling language such as UML to generate everything in the world? This way, due to the lack of abstraction, the models might be entirely different from the final things you are trying to describe. And, in my personal opinion, using things such as tags, stereotypes, annotations, decorators, etc. is a patchwork overload that turns UML into a Frankstein.

Cultural moment: patchworks, BTW, appeared during war times,
when there was a shortage of some specific clothes,
so dressmakers put together whatever was available.

Models are not the starting points, are not end goals in themselves. They are means to reach what really matters here: abstraction and automation.

[]s
-- AFurtado

Does it even seem to fit in the mailbox?

• A button is used to fire projectiles.
• Projectiles kill enemies if a projectile-enemy collision is detected.

While this was an innovation when Space Invaders was created (Japan run out of quarters because of the game, case you don't know), many other following games used the same features. Therefore, the pragmatic programmer would promptly think about creating a framework to encapsulate the commonalities, allowing subsequent games to be produced much quicker and easier. Today, specific to the game domains, such reusable frameworks are called game engines.

So how can we use the reusable framework and still have different game logic for each game? That's where the variabilities comes into play. While sharing commonalities and being eligible to (re)use the common framework, a game can have distinct features. For example, a shot'em up game can have a special feature such as a scrolling background.

But wait, different games can have this same scrolling background feature, so why is this a variability and not a commonality?

• First of all, the feature is optional: games can or cannot have a scrolling background.
• Secondly, it is configurable: the background can scroll horizontally, vertically or in both dimensions at the same time. The scroll can happen for different reasons, for example, it can be time-based or player position-based.
• Finally, it is extensible: what if the game designer/developer decides to implement a brand new type of scrolling background, in which, for example, the camera is fixed into the player's ship (when the player asks the ship to move left, actually all the scenario and enemies move right)? This is exactly what was done in the game Time Pilot:

So if commonalities are encapsulated under a reusable framework, what about variabilities? In fact, variabilities configure the reusable framework. The framework should provide hooks to allow the variable feature to be properly set up, or even be defined as not existent at all. More roughly speaking, in code, it would be something like this:

namespace ShotEmUpGameFramework {

   public class ShotEmUpGameTemplate : Game {

      // game developer provides the bidimensional velocity for the scrolling
      public void SetTimeBasedScrolling(Vector2 velocity) {...}
  
      // game developer provides entity whose position the scrolling will be based on
      public void SetMovementBasedScrolling(Entity e) {...}      

      // game developer provides the scrolling function
      public void SetCustomScrolling(ScrollingDelegate d) {...}

      // if none of the above functions is called,
      // the framework (engine) assumes the game has no scrolling at all.

   }
}

Now today's last question is: and why are domain-specific languages useful for in such a context? DSLs (visual ones in special) are useful to improve the way we configure the reusable framework. In other words, DSLs capture, with a high level of abstraction, the variabilities of the specific product (game) you're developing and, together with a code generator, your model (DSL diagram) is transformed into the code (or XML file, or whatever) that configures the framework.

For example, it would be very tedious and error prone for the game developer to use the following code to tell (configure) the reusable framework, regarding the transitions of the states (screens or rooms) in a game:

Screen intro = MyGame.Screens.Add("Intro Screen");
Room room1 = MyGame.Rooms.Add("Room 1");
Room room2 = MyGame.Rooms.Add("Room 2");
intro.Connect(room1);
room1.Connect(room2);
room2.Connect(room1);

Imagine now what to do with dozens of rooms and screens. A wrong copy-and-paste in this boring unautomated task can result in bugs that may be costly to find later! Therefore, I'm sure you agree with me that using a diagram like the one below, based on a visual modeling language, is much quicker, convenient and less error-prone:

With the click of a button, a code generator receives the diagram as input and generates code as output, similar to the above code. The generated code, finally, configures and consumes a reusable framework (game engine). And the developer is happy, since there's no need to know what's going underneath.

Now imagine all other types of variabilities in a digital game, besides screen transition, that could benefit from such kind of automation: collision detection, entity behavior, ... Please help me find more!

[]s
-- AFurtado

The statements or testimonies I offer in this post represent my own personal views.
I am speaking for myself and not on behalf of my employer, Microsoft Corporation.

• 48% set-top box
• 25% game consoles
• 16% media PC
• 10% other

Although these are by no means scientific results, since it's only a web poll, it's interesting to check how game consoles are each time more envisioned not as isolated devices, but part of the so called "digital convergence". If you have a Xbox 360 at home, for example, why not trying to make it a Media Center Extender? Zune and Microsoft Surface give even more possibilities on how we can manage our content altogether to enhance our digital lifestyle. Expect (and create) good things atop that!

[]s
-- AFurtado