(no subject)
Jun. 14th, 2005 08:48 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
It has been a while since you've had to deal with a work rant from me, so scroll past if you wish.
I'm still having big doubts about the functionality of the Agile methodology, at least in our environment. Perhaps it can work in places where the needs of the business are well planned out and prioritization is all that needs to happen. We certainly don't fit that description.
We're now in a position where we have to deliver an amount of functionality. We thought we had a fair grasp on how much that was, only to have it grow three orders of magnitude in our Monday planning meeting.
So, development has some initial user stories to work on this week. Good for them. Unfortunately, the scope of them is mainly "stub out the presentation layer for this new page" "stub the business layer for this page" and so on. The scope of things which is testable for them is roughhly "yup, there's a page there."
We need to reach some level of full ownership in this project, because we're in danger of repeating the problems of the last one and reinventing the square- we're going to go from a point where test may have all of a half-hour of work (as will probably be the case this week) to points where several of these pages which are now being stubbed will be completely functional all at once, resulting in seventy or more hours of testing needing to be crammed into one week. I'd note that this is one of the things which is allegedly contrary to the methodology- which claims to deliver (citing from the principles of the methodology) "Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely" or which writes test out of the bigger picture of what constitutes development altogether. As it is, there's nothing consistent other than that test gets regularly screwed. If that's going to happen, i'd rather deal with a good ol' fashioned waterfall deathmarch- at least with those, there should be some specifications and planning documents which let me write test planning in advance.
Full ownership may be the only thing which saves it, thinking logically. If I can get the development process to unify all the user stories related to a particular aspect of the whole and prioritized by aspects, and aspects completed before the next ones are completed, it may be sustainable. I'm not going to hold my breath waiting, though- cyanotic blue doesn't look good on me.
I'm still having big doubts about the functionality of the Agile methodology, at least in our environment. Perhaps it can work in places where the needs of the business are well planned out and prioritization is all that needs to happen. We certainly don't fit that description.
We're now in a position where we have to deliver an amount of functionality. We thought we had a fair grasp on how much that was, only to have it grow three orders of magnitude in our Monday planning meeting.
So, development has some initial user stories to work on this week. Good for them. Unfortunately, the scope of them is mainly "stub out the presentation layer for this new page" "stub the business layer for this page" and so on. The scope of things which is testable for them is roughhly "yup, there's a page there."
We need to reach some level of full ownership in this project, because we're in danger of repeating the problems of the last one and reinventing the square- we're going to go from a point where test may have all of a half-hour of work (as will probably be the case this week) to points where several of these pages which are now being stubbed will be completely functional all at once, resulting in seventy or more hours of testing needing to be crammed into one week. I'd note that this is one of the things which is allegedly contrary to the methodology- which claims to deliver (citing from the principles of the methodology) "Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely" or which writes test out of the bigger picture of what constitutes development altogether. As it is, there's nothing consistent other than that test gets regularly screwed. If that's going to happen, i'd rather deal with a good ol' fashioned waterfall deathmarch- at least with those, there should be some specifications and planning documents which let me write test planning in advance.
Full ownership may be the only thing which saves it, thinking logically. If I can get the development process to unify all the user stories related to a particular aspect of the whole and prioritized by aspects, and aspects completed before the next ones are completed, it may be sustainable. I'm not going to hold my breath waiting, though- cyanotic blue doesn't look good on me.