Quality Snapshot for S^2

I have refered on the past to the capability of reporting metrics against the Symbian Platform. Finally we are there!

This week the team produce the first snapshot of Bug , Code size and Code Churn with real data. The snapshot is to be presented on Friday to the Release Council for feedback. Let’s have a look at it in more detail:

Defect/Bug Metics

These are graphics auto-generated from Bugtracker Metrics, it allows you to drill down to as much detail as you want. The data in the snapshot is frozen from an specific date, but you can re-run the queries live from the bugtracker metrics interface.

defectmetrics

Now that we can measure it, we can start introducing some standard defect management practices.

Read more of this post

Advertisements

The Symbian Integration plan and 584 package features

One thing I keep getting asked is “where do you get the data for the integration plan?”. In the past, I have mentioned that how features are added to integration plan, but from today I am publishing together with the pan: the raw data used to create it, the scripts that provide the data and filters that we used to manage the information available.

accessingintplan

Read more of this post

Risk Analysis – Integration plan (part 2)

Every person has a different risk profile. This is the willingness of that person to take a chance to achieve a reward versus the probability of failure. The amount of risk we are willing to take seems to be correlated to the reward promised and the time frame associated to it (i.e. will I get teh reward tomorrow, in 2 or 10 years). Risk profiles of companies are somehow a weighted average of the risk profiles of their employees. Hence, different companies (even in the same market segment) have different risk profiles. Read more of this post

Planning Flow

Today just a quick update on integration planning..Over the last few weeks, we have been working on providing a bit more clarity on what artefacts are we use to plan platform releases, and how do they related to each other:

planning_flow

In a nutshell:

  • We produce a platform release plan that provides implementation details to the Platform Plan (roadmap)
  • The Platform Release Plan contains plan per active S^n release
  • Each Release Plan is informed by the Integration plan and the Test and Quality Plan (not yet available)
  • The Integration plan is derived from the information available in package backlogs and feeds into the kit schedule

More information about all these artefacts can be found here. Read more of this post

Integration Plan (part 1)

Recently I blogged about using Bugzilla to track features. I am happy to report that things are moving forward really well thanks to the community and Mylyn. We now have created the high-level delivery plan for Symbian^3 in Bugzilla, and completed the details for one of the key features: New Graphics Architecture (NGA – aka Screenplay).

intp3

As you can see from the picture, Mylyn makes it really simple for anyone to keep an eye on the plan.

BUG_ID 176 is the top level entry for NGA. In this post, I won’t go into the specific details of NGA, but explain the next step that we are taking in our planning: The Integration Plan.

Having all this data in Bugzilla allows us to build a good view of  the progress of a specific release. As we do not want to be monitoring every single submission, we have decided to follow the implementation of  “Key Features” (we are currently discussing the key features for Symbian^3)

The aim is to extract all the good information provided by the package owners and put into a format that facilitates the analysis of the health of the release. Taking a leaf from the Agile book, and introducing a 2-week regular heartbeat for our kits releases and tracking feature increments against it (for regular kit updates click here).

Also, any data beyond 6 months from “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). Hence, it is understood that the detailed plan beyond 3 months will be fluid and beyond 6 months is only an indication of intent.

It is  probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase the confidence in it by promoting frequent stage deliveries and asking the contributors to provide regular updates when changes occur.

intp1

The above table is a section of the full integration plan for Symbian^3

Read more of this post

Games Open Source People Play

A clear difference between a collaborative project and an “uni-lateral” project is – how to establish a level of confidence on whether all the parties involved on the project will deliver their contributions as intended.  I don’t think this problem is unique to Open Source Software, but in fact can be found in many “trust-based” transactions.  By “trust-based” transactions, I mean exchanges where the completion can not be warranted beyond relying on the other party to do the right thing.

Prisioners dilemma depicted by scs.imsa.edu

Prisoner's dilemma depicted by scs.imsa.edu

Few decades back, a field of mathematics called Game Theory modelled this situation in “the prisoner’s dilemma“.   Imagine that you and your best friend have been arrested by the police for a crime to which both of  you were part to.  You are put into different interrogation cell’s and offer the following deal:

“At the moment, neither of you is talking… but we have enough evidence to put both of you prison for 2 years. However, If you are prepare to incriminate your accomplice, we will cut your sentence to 1year community service and he will spend 5 years in jail.  But you must hurry, because we are offering the other guy the same deal. If he gives you up, you will spend 5 years inside…you have 5 minutes to decide” But you know that if both of you talk, the jail term will be 3 years for both of you… so what do you do?

There is no clear cut answer to the question, hence is called a dilemma 🙂 In fact, John Nash identified a theoretical equilibrium point at the “guilty-guilty” scenario. This is the only scenario where, considering the other person’s choice, you couldn’t have been better of if you had chosen differently. However,  actual lab experiments showed that “real” people don’t tend to choose the Nash equilibrium more often than the other 3 scenarios.

A variant of the problem is the “iterated prisoner’s dilemma” , this is when the game is played repeatedly and the impact of the decision into future transactions is taken into account in the current “game”. It’s this version of the dilemma that in my opinion applies to collaborative development projects.

In collaborative projects the 2 players are the contributor and  “benevolent dictator“/project lead. Will the contributor keep to his/her public commitments? Will the project lead accept the contribution and give the kudos where is due?

Ultimately, the attitude of both players will be influenced by the prospect of future collaborations. If you are trying to facilitate these kind of relations, here my views on how to make it successful:

  • Iterated the Game as much as possible: Ensure the collaboration is not based on a one-off  interaction. The easiest way to do this is to have a multiple-deliveries integration plan vs  big bang approach.
  • Raise the stakes: The prisioner’s dilemma is based on the fact that the reward of defecting is far larger than cooperating.  You can alter the situation by raising the stakes for mutual cooperation, making it much more attractive to both parties. (i.e. in a situation where “if nobody talks, you are both free” there is no dilemma)

Lastly, make sure common sense prevails.  Although game theory is a fascinating subject, proposed solutions to this dilemma have failed to consistently predict how real human (i.e. not only rational but also emotional) beings actually behave.

Less Open Source and More Community Source?

When faced with the option of buying a car,  I considered 2 options:

  • Shall I buy a new or semi-new one from a dealership. Yes, you do  pay a premium for the same car but if it is not quite right I have a guarantee and a large company behind it that will provide support and get it sort it. Or,
  • Shall I buy it on-line from a private party.  With a lager market to choose from (with websites such as autotrader), it would allow me to find a cheaper option and to “fix-it up” to my standards. Also, I can normally check the history of the car and have an accurate guess at what might be wrong with it.

What I never considered is to walk-in into a dealership an be confronted with the following scenario: “You can take this car for free, you can inspected if you want. There is one catch, if it breaks down or you want to change anything you need to come to us to fix it!” Clearly, this never actually happened to me.

Lately there is a trend in open source that make me feel like I am walking into that sort of dealership. As a user of  platform software, it is great to have access to the code but it is frustrating not to have influence over how it changes. Read more of this post