|
| [ Follow-ups set to news:comp.software-eng ]
Max wrote:
> the organization I work for has decided to adopt Scrum on one project.
> We are just starting and we do not have a mentor so we are facing some
> challenges.
You will do better with either a mentor, or incremental adoption. Put
another way, don't jump into the deep end of the pool, the first time,
without a coach on site!
> One is the following. We went through the planning meeting for the
> first iteration. During the meeting the Product Owner indicated that a
> specific feature had the highest priority. Now it does not seem that we
> can break down this feature in many small user stories. After all the
> end user is required to do very little to log on to the system: provide
> username and password and click an OK button. That's it. On the other
> hand, the infrastructure required to log on to the system turns out to
> be quite complex (it's an enterprise application). So here's the
> problem we are facing as a Team: we know that at the end of each
> iteration we have to provide a production-quality increment. However,
> if we add the user story "Logging on to the System" to Iteration 1, we
> won't be able to finish it in time (according to the estimates) //if we
> implement the entire back-end to support real authentication//. On the
> other hand, if we decided to mock some part of the back-end in order to
> meet the deadline for the iteration, we feel that we will not generate
> any business value.
I thought Scrum iterations were one month. You should also shoot for
team-level iterations once a w . That's where you do the engineering
tasks, and create internal releases.
Now, one month to log-on to an enterprise application? You may already have
the latent User Story "run on many servers at once". That would require
distributed passwording, distributed user accounts, secure channels, etc.
Another Scrum topic might be "start modestly". (I know that's a principle of
all the other "Agile" methodologies.) So you might need to let go of the
entire idea of scalability, and only create a one-server "enterprise"
solution. The ideal here is to delay expensive and irreversible decisions
until the last possible cheap responsible moment, when you have the most
data to make the right decision.
Logging-on to one server is trivial, right?
However, if you delay the "clustering" requirement, you might then have more
data channels to secure and distribute; not just the passwords!
> What should we do in this case or, more in general, what should we do
> anytime we have to implement a feature that has a small number of user
> stories associated and a big backend?
Everything in that big backend must have a link to a user request. If the
user did not request rapid transaction time across WAN-decollocated servers,
they should not pay for them. If they do request something, you have an
excuse to add _that_one_thing_, alone, to the back-end. For everything you
think the back-end needs, you must find away to express that as a suggestion
to the customer liaison. Then keep your trap shut about most of them!
Engineers learn all these best practices, and they don't want to see their
next project go to seed, and decay over time, the way certain legacy
projects always did in their past. Part of Scrum is letting go of this fear;
letting go of the idea that so much infrastructure must be created up front.
And your question is indeed Coaching 101, so for a project as important as
one using the E-word ("Enterprise"), you might want to get a name-brand
coach who has actually retrofitted clustering to a project grown
incrementally!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
|
|