• Compartir
  • ?
  • Perfiles ▼
  • Comunidades ▼
  • Aplicaciones ▼

Blogs

  • Mis blogs
  • Blogs públicos
  • Mis actualizaciones

Agility@Scale: Strategies for Scaling Agile Software Development

  • Iniciar sesión para participar
Scott Ambler Scott is a Senior Consulting Partner of Scott W. Ambler and Associates, working with organizations around the world to help them to improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organizational level. He is the founder of the Agile Modeling (AM), Agile Data (AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies. Scott is the (co-)author of 19 books, including Disciplined Agile Delivery, Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. Scott is a senior contributing editor with Dr. Dobb's Journal and his company home page is ScottWAmbler.com
View my profile | Contact me | Ambysoft

More information

  • Rational Insight
  • See you at IBM Rational Innovate
  • Rational Invisible Thread Blog
  • Scaling Agile: An Executive Guide
  • Agile Scaling Model (ASM)
  • Improving Software Economics

▼ Etiquetas

Recent tweets

FeedWind

▼ Entradas parecidas

APM v8.1.4 Setting t...

Blog: Application P...
SushamaK 1100006DS0
Actualizada
A 0 personas les gusta estoNúmero de "me gusta" 0
Ningún comentarioComentarios 0

DL/I requirement: In...

Blog: Ingolf's z/VS...
Ingolf24 120000DRN3
Actualizada
A 0 personas les gusta estoNúmero de "me gusta" 0
Ningún comentarioComentarios 0

Webinar (July-12-201...

Blog: Rational Rhap...
Eldad Palachi 270001KJC2
Actualizada
A 0 personas les gusta estoNúmero de "me gusta" 0
Ningún comentarioComentarios 0

TXSeries V9.1 - Usef...

Blog: Do More with ...
JanakiS 27000496GC
Actualizada
A 0 personas les gusta estoNúmero de "me gusta" 0
Ningún comentarioComentarios 0

New requirement feat...

Blog: Ingolf's z/VS...
Ingolf24 120000DRN3
Actualizada
A 0 personas les gusta estoNúmero de "me gusta" 0
Ningún comentarioComentarios 0

▼ Archivador

  • enero de 2015
  • mayo de 2014
  • abril de 2014
  • septiembre de 2013
  • julio de 2013
  • junio de 2013
  • mayo de 2013
  • marzo de 2013
  • diciembre de 2012
  • octubre de 2012
  • marzo de 2012
  • febrero de 2012
  • noviembre de 2011
  • agosto de 2011
  • junio de 2011
  • mayo de 2011
  • abril de 2011
  • marzo de 2011
  • febrero de 2011
  • enero de 2011
  • diciembre de 2010
  • noviembre de 2010
  • septiembre de 2010
  • julio de 2010
  • junio de 2010
  • mayo de 2010
  • abril de 2010
  • marzo de 2010
  • febrero de 2010
  • enero de 2010
  • diciembre de 2009
  • noviembre de 2009
  • septiembre de 2009
  • agosto de 2009
  • julio de 2009
  • junio de 2009
  • mayo de 2009
  • abril de 2009
  • marzo de 2009
  • febrero de 2009
  • enero de 2009
  • noviembre de 2008
  • octubre de 2008
  • septiembre de 2008
  • agosto de 2008
  • mayo de 2008
  • marzo de 2008
  • febrero de 2008
  • enero de 2008
  • diciembre de 2007
  • noviembre de 2007

▼ Autores de blog

Agility@Scale: Strategies for Scaling Agile Software Development

Requirements Envisioning on Agile Projects at Scale

ScottAmbler 120000HESD | | Etiquetas:  modeling agility-at-scale agileadopt requirements | 8 Comentarios | 17.775 vistas
Stumble Upon

Contrary to popular belief, agile development teams do in fact model and yes, they even do some up front requirements and architecture modeling. Two of the best practices of Agile Modeling are Requirements Envisioning and Architecture Envisioning where you spend a bit of time at the beginning of the project doing enough initial modeling to get you going in the right direction. The strategy is to take advantage of modeling, which is to communicate and think things through without taking on the risks associated with detailed specifications written early in the lifecycle. In this blog posting I will focus on requirements envisioning, in a future posting I'll cover architecture envisioning.

The goal of initial requirements envisioning is to identify the scope of your effort. You need to do just enough modeling early in the project to come to stakeholder concurrence and answer questions such as what you're going to build, roughly how long it's going to take (give a range), and roughly how much it's likely to cost (once again, give a range). If you can get the right people together in the room, which can sometimes be a logistics challenge but not one that you couldn't choose to overcome, there are very few systems (I suspect less than 5%) that you couldn't initially scope out in a few days or a week. I also suspect that most of the remaining systems could be scoped out with less than 2 weeks of modeling, and if not then I'd take that as an indication that you're taking on too large of a project. I'm not saying that you'll be able to create big detailed specifications during this period, and quite frankly given the problems associated with "Big Requirements Up Front (BRUF)" you really don't want to, but I am saying that you could gain a pretty good understanding of what you need to do. The details, which you'll eventually need, can be elicited throughout the lifecycle when you actually need the information. A common saying in the agile community is that requirements analysis is so important for us that we do it every single day, not just during an initial phase. I'll discuss just in time (JIT) approaches to requirements modeling in a future posting.

To envision the requirements for a business application, you might want to consider creating the following models:
  • High-level use cases (or user stories). The most detail that I would capture right now would be point form notes for some of the more complex use cases, but the majority just might have a name. The details are best captured on a just-in-time (JIT) basis during construction.
  • User interface flow diagram. This provides an overview of screens and reports and how they're inter-related. You just need the major screens and reports for now.
  • User interface sketches. You'll likely want to sketch out a few of the critical screens and reports to give your stakeholders a good gut feeling that you understand what they need. Sketches, not detailed screen specifications, are what's needed at this point in time.
  • Domain model. A high-level domain model, perhaps using UML or a data modeling notation, which shows major business entities and the relationships between them, can also be incredibly valuable. Listing responsibilities, both data attributes and behaviors, can be left until later iterations.
  • Process diagrams. A high-level process diagram, plus a few diagrams overviewing some of the critical processes, are likely needed to understand the business flow.
  • Use-case diagram. Instead of a high-level process diagram you might want to do a high-level use case diagram instead. This is a matter of preference, I likely wouldn't do both.
  • Glossary definitions. You might want to start identify key business terms now, although I wouldn't put much effort into settling on exact definitions. I've seen too many teams run aground on "analysis paralysis" because they try to define exact terminology before moving forward. Don't fall into this trap.


For small teams simple tools such as whiteboards and paper are usually sufficient for requirements envisioning. But what happens at scale? What if you're working on a large agile team, say of 50 people, 200 people (IBM has delivered software into the marketplace with agile teams of this size), or even 500 people (IBM currently has teams of this size applying agile techniques)? What if your team is distributed? Even if you have people working on different floors of the same building, let alone working from home or working in different cities or countries, then you're distributed (see my postings about distributed agile development). Suddenly whiteboards and paper-based tools (index cards, sticky notes, ...) aren't sufficient. You're still likely to use these sorts of tools in modeling sessions with stakeholders, but because of one or more scaling factors you need to capture your requirements models electronically.

In January Theresa Kratschmer and I gave a webcast entitled Agile Requirements: Collaborative, Contextual, and Correct which overviewed agile approaches to requirements elicitation and management, including requirements envisioning. We also showed how Rational Requirements Composer (RRC) can be used to electronically capture critical requirements information, enabling you to address the needs of large and/or distributed agile teams, while still remaining lightweight and flexible. I suspect that you'll find the webcast to be very illuminating and RRC something that you want to take a look at (the link leads to a trial version). Of course RRC can be used in other situations as well, but that's not what I'm focused on right now.

Teams which find themselves in regulatory environments will likely need to do more than just use RRC, as might very large teams. Regulatory compliance often requires more complex requirements documentation, which in turn requires more sophisticated tools such as DOORS or Requisite Pro, and I would consider using those tools in the types of situations that warrant it. One of the things that people often struggle to understand about agile approaches is that you need to tailor your strategy to reflect the situation at handle. One process size does not fit all, so you will end up using different tools and creating different artifacts to different extents in different situations. Repeatable results, not repeatable processes, is the rule of the day.


Further reading:
  • Agile Requirements: Collaborative, Contextual, and Correct Webcast
  • Rational Requirements Composer
  • Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
  • Agile Requirements Modeling
  • Requirements Envisioning: An Agile Best Practice
  • Examining the Big Requirements Up Front (BRUF) Approach
  • DDJ's 2008 Modeling and Documentation Survey, which found that agile teams are more likely to model than traditional teams





Inicie sesión para acceder a esta característica
  • Añadir un comentario
  • Más acciones v
Notificar a otras personas
  • Añadir un comentario
  • Editar
  • Más acciones v
  • Poner esta entrada en cuarentena
Notificar a otras personas
notification

Enviar notificación por correo electrónico

+

Poner esta entrada en cuarentena

deleteEntry
duplicateEntry

Marcar como duplicado

  • Entrada anterior
  • Principal
  • Entrada siguiente
Canal de información para entradas de blogs ▼ | Canal de información para comentarios de blogs ▼ | Canal de información para comentarios en esta entrada ▼