> On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:
> > I think the bigger issue, that many people have expressed here, but not
> > said as such, is the Qt release cycle is not Agile.
> I would thank God it is not, but the rest of your post proves that it is.
> > As more teams adopt Agile development practices, the chasm between what
> > user teams needs and what is being delivered grows.
> Well, only teams working on products with the life span of a fruit fly,
> like a Web page. Most will be companies which go out of business. When
> one is developing things which will inevitably have a 30+ year life span
> or exist in a regulated environment Agile simply isn't an option. Think
> payroll, accounts receivable, and most medical devices. Yes, most
> medical devices in America are said to have a 7-10 year product life,
> but the "end of life" units inevitably get reconditioned and sold to
> poorer countries where they get used for another couple of decades.
> > As a result, it seems that Qt is drifting away from what it's users want or
> > need. Sometimes though, it's not even so much that we need release, we just
> > need a patch to hold us over to the next release. My Agile team does two
> > week sprints so we can reorder priorities twice a month. The Qt community
> > has no say (AFAIK) in determining the priority status, or what is worked on
> > when. The worst issue I know of as an example of this is the Canvas bug on
> > iOS (https://bugreports.qt.io/browse/QTBUG-37095 ). It's been in there for
> > 2.5_yeara_, 17 votes and 36 watchers. Which in my experience is pretty damn
> > high, though there are older and higher ones. Use the search string "votes
> > >= 17 AND status != Closed and type = Bug" to get a list of that
> > and it's brethren. Which brings up the question, why isn't the Qt staff
> > using a similar search to prioritize their backlog on a regular basis?
> This is inevitably what happens with Agile. Developers get to choose the
> stories (in this case bugs) they work on and it is way cooler to put
> your name on a new feature than to fix someone else's code, especially
> if there is a management team in place measuring "performance" by how
> many stories get completed each sprint instead of just how much better
> the end product is.
Developers do not get to choose what stories to do. The priorities are not set
by engineering. Business decides the priorities in sprint planning, and
engineering does them. In proper Agile teams, the developers get to pick
(assign to them) which stories they do in that sprint, not what goes into the
In the Jeff Sutherland book "SCRUM: The art of doing twice the work in half the
time" Sutherland citest he FBI's post 9/11 modernization effort called the
Virtual Case File System, which was axed because it over past due and over
budget. The replacement project Sentinel, a $450M project. It too started out
not Agile, but based with another several years of being overdue and over
budget (estimated $350M more to complete) that was moved to Agile and actually
delivered. Similarly Healthcare.gov started off not Agile and ended Agile.
Clearly, the problem isn't the methodology, it is your application of it.
Interest mailing list