Software Release Dates and Features - Project Management

Giriş

Bu yazıda proje yönetemiyle ilgili bazı notlar var.

Yayım Yöntemi - Software Release Dates and Features

Yazılımın içerdiği özellikler ve yayım tarihi için 4 tane yöntem izlenebilir. Bunlar şöyle.

We have historically seen over and over again that there are two working and two non-working ways of combining the two fundamental constraints on software releases: dates and features.

1. Fixed date, flexible features, aka "release what's ready": you release at a pre-determined date, but you only release what is working. This is a model that is successfully used by Ubuntu, Windows, Linux, and many others.

2. Fixed features, flexible date, aka "release when ready" or "It's done when it's done": you determine the set of features beforehand, and then you simply work until the features are finished. Some Open Source projects work this way.

3. Fixed date and features.

4. Flexible date and features.

1. Fixed date, flexible features ve Fixed features, flexible date

Windows ve Linux 1 numarayı takip ediyorlar.  Yani her 6 ayda bir hazır olan özellikleri yayımlıyorlar. Açıklama şöyle. Linux daha sonra 2 numarayı uyguluyor. Yeni özelliklerdeki hatayı gideriyor ve bir sürüm daha yayınlıyor.

#1 and #2 have been shown to work well in many different projects. For example, both Ubuntu and Windows are released with a fixed 6-month cadence with whatever features are ready in time for the release. If you make the cadence fast enough, even if a feature misses the release, customers don't have to wait a very long time for the next release.

Linux actually uses an interesting staging of the two: as soon as there is a new release, there is a fixed-time "merge window" of two weeks, during which new features are added. When this merge window closes, the set of merged features up to that point is fixed, and a "stabilization period" starts, during which the fixed set of features is stabilized, any bugs fixed, etc. This process takes as long as it takes, there is no deadline. When everything is stable, a new release is made, and the process starts anew. It turns out that this actually leads to a fairly stable release cadence of 6-8 weeks, but the point is that this cadence is not enforced, it emerges naturally.

Note that this does not invalidate my assertion that #3 doesn't work: Linux development does not fix dates and features. They do #1, then make a cutoff point and switch over to #2.

2. Fixed Date And Features

Eğer süre uzunsa sıkıntılı bir süreç. Açıklaması şöyle

#3 is always a big problem, especially with a larger feature list and longer timeframes. It is pretty much impossible to predict the future (many have tried), so your estimates are almost always off. Either you have finished all the features and are sitting around bored twiddling your thumbs, or, more likely, you bump up against the deadline and frantically try to finish all the features in a hellish death march.

It does work if you keep the feature list and timeframe short enough. E.g. this is essentially what a Sprint is in Agile Methodologies: a fixed set of features in a fixed timeframe. However, the timeframes are reasonably short (typically a Sprint is one week or two), and it is ensured that there is rapid and immediate feedback and adjustment. You generally have a Sprint Retrospective after every Sprint, where you gather all the problems and successes of the Sprint and incorporate what you have learned into the next Sprint. And of course there is a Sprint Planning Meeting where the team discusses the next Sprint with the customer and agrees on a set of features to be implemented during that week.

Weekly (or two-weekly) Sprint Retrospectives are still not fast enough feedback, though, so there is also a Daily Standup Meeting with essentially the same goals as the Sprint Retrospective, except being able to react even faster: check whether the previous day's goals were met, and if they weren't, figure out what the problem was and fix it. (Note, I wrote "what" the problem was, not "who"!)

It is also very important that every Sprint ends with the release of a working product, so that the customer can immediately start using the new features, play around with them, get a feel for them, and give feedback for the next Sprint what is good, what isn't, what should be changed, etc.

3. Flexible date and features

Sürekli bir şey eklendiği için hiç bitmiyor. Açıklaması şöyle

#4 almost always leads to never-ending releases with feature creep. Debian 3 and Windows Longhorn were famous examples that interestingly happened around the same time. Neither of the two had a fixed release date, and neither of the two had a fixed set of features. Longhorn took 5 years, Debian 3.1 took 3. In both cases, what happened was that they didn't want to cut features because the long release meant that people would have to wait even longer for the features to appear in the next release. But because of not cutting features the release date slipped even further, so they added even more features because otherwise users would have to wait even longer, but that made the release date slip, and so on and so forth. An even more famous example might be ECMAScript 4.

Eğer Proje Gecikiyorsa

Daha fazla adam yığmak ta çözüm değilse, #3 olan proje #1 veya #2'ye dönüştürülmeye çalışılabilir. Açıklaması şöyle.

So, what can you actually do in your situation? Well, you are currently in situation #3, and that simply does not work. You have to turn your situation #3 either into a #1 or a #2 by either relaxing the release date or dropping features. There simply is nothing else you can do.

The damage was done 6 months ago, and it cannot be magically fixed. You are in the situation where the amount of features cannot be delivered in the amount of time, and one of the two has to give.

Bazı özelliklerden vazgeçilmesi,  sözleşmedeki bazı muğlak ifadeleri kullanarak yapmak mümkün. Açıklaması şöyle.

For several projects, it is not uncommon to pretend #3 to the customer, but make use of the fact feature specs from a contract often leave room for details. An experienced project manager decides about how these details are filled to match the schedule. So from a higher level of abstraction, the project goes for 3, but from a more detailed level of abstraction, it is #2.

Bazı özelliklerden vazgeçilmesi için her şeye karşı çıkan adam rolünü de oynamadan şu pazarlık yöntemi seçileblir.

The solution to this is very easy: for a while, say yes to absolutely everything, but make sure it comes at a cost they need to negotiate with other stakeholders.

For example, Marketing asks you to change a deadline because they want to show the product at some trade show. You go along with it:

"yes, I like the idea, I want to help you. In order to achieve it, we will need to cut x and y, or z from the product. Let me set up a meeting with the x, y and z stakeholders so you guys can decide how you want to proceed."

Or you are told that feature A is absolutely needed for the next release:

"of course, I love feature A, we should add it. It will require that we don't finish feature B or C though, let me bring in Mike and Gary so you can decide with them what should be cut. Or, we could extend the deadline, should we set up a meeting to discuss the cost of pushing it for your feature?"

This goes nowhere very quickly, but by doing this you are actively training people to understand that every request has a cost. You are not blocking anything, you are actively facilitating the process but anyone that wants something will soon realize that they need to negotiate with others.