Where in the scrum process is programming architec

问题:

Let's say I have my vision and now my product backlog of items. That part is in writing and ready to be used. I am about to create my sprint(s). I am curious. When does a programming team sit down and say "let's use this platform, this framework, and language" and things like "We need a class here," or "I see a way we can use an Interface with that" and so on. When is that kind of talk going on?

Are there meetings that come before the sprint where someone decides for all teams - "We are going to use Linux, MySQL, PHP and CodeIgniter" and then one of the teams has a sprint to implement that infrastructure, while other teams wait for completion to start the other sprints (team A2 build a ui or security model and the features of it from the product backlog)?

Is this also where tools like trac would be used at the team level, when the sprints first begin?

Sorry if I'm all over the place with this. I've just never seen it done and just when I think I understand it I think of a new question.

Also it's beside the point but what do you name your teams? Bob's team, Smith's team, something more colorful?

Thank you.

回答1:

Short answer is "It depends" as for the first part there could be other teams that dictate those kinds of terms to some extent. For example, on my current project some things are almost a given,e.g. IDE=Visual Studio, Bug tracking=HP Quality Center, Version Control=Subversion, O/S for developers XP Professional,etc.

There can be a Sprint 0 where some infrastructural elements are handled like a CI server, wiki for the team, making sure everyone has accounts in SVN, and other administrative things to get handled.

Team names like code names can come up at anytime though they can have different meanings as what someone can use for a team name in one place may not be so good somewhere else,e.g. Team Voltron may not go over well for those completely unfamiliar with the term.

回答2:

Some teams start their projects with a Sprint Zero, where they refine the vision, define the global architecture (choices of platform, language, not class or interfaces), the definition of "done"...

This Sprint is special, it's about preparation and, unlike the other sprints, might not lead the team to deliver any working software..

回答3:

If you are part of an agile-scrum team, chances are there your company already has defined patterns and architectures.

In my opinion scrum-teams are not responsible for design, There are separate design-teams who are responsible for overall design and integration-plan of any ongoing projects.

The design-team does the strategic part of projects development phase which is architecture, design and integration plan. These teams may have their own scrum sprints.

Scrum-master along with team-leads are responsible for tactics of implementing projects as per design.

programmers, testers and QA engineers have operational responsibility of writing and testing code.

回答4:

I would split it into few parts.

Things like choosing tools/platforms (Linux, MySQL, PHP etc) I'd have agreed before even starting sprint 0. I consider sprint 0 more like setting vision and high-level architecture which, to some point, is dependent on tools/platforms of your choice. People you'd like to have in the team will also be different for ASP.NET project than for PHP project.

Another thing is moving to discussions like "I need a class here and interface there." This level of details can't be really decided up front during sprint 0. We just go with these decisions all along the way. This mean we're changing our architecture rather often but it's a rare situation when changes are deep. And almost always when we change something it is well-grounded decision.

To summarize: key technology decisions before you start, high-level architecture during sprint 0, lower-level design decisions whenever needed (during sprints).

回答5:

"Sprint 0" is the standard approach to starting up. For ongoing major architecture decisions (switch toolkit, language, platform), a series of investigation spike stories have worked well if they are as small and focused as possible. The story is to address a specific question or prove a concept. Infrastructure questions can -- and I'd argue must -- be broken down into small stories or you may wander off the map.

Smaller infrastructure changes have sometimes worked well as a "tax" to other stories, sometimes not. (E.g. research and add a dependency injection tool, switch to generic hibernation tool) Taxing stories requires excellent communication between product and development. It presumes that some eager dev has already done some late night homework on the infrastructure.

Without success, we've tried hoping major architecture decisions will happen over the course of normal work. This fails because scrum keeps you too focussed.