Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

El Equipo de Desarrollo

Son las personas que trabajan en el producto durante el Sprint para entregar una versión Terminada al final del mismo. Deben trabajar para que esa versión lista al final de cada Sprint pueda ser subida a producción. No quiere decir que al final de cada Sprint haya que subir obligatoriamente una nueva versión sino que está lista, probada y preparada (Terminada) para que potencialmente pueda ser desplegada en producción si alguien así lo decidiese. Son los miembros del Equipo de Desarrollo los que trabajan en la creación de esa nueva versión o Incremento del producto que se prepara cada Sprint.

Los Equipos de Desarrollo se estructura y organizan de tal forma que puedan gestionar su propio trabajo. Para conseguir esto los equipos de desarrollo deben cumplir estas características:

  • Son autoorganizados: Ellos mismos se asignan las tareas según su conocimiento y la preparación o la disponibilidad que tenga cada uno. No es el Scrum Master ni el Product Owner quién reparte las tareas, ni les indican cómo deben hacer su trabajo. Son ellos los profesionales que trabajan en esto y quienes mejor conocen cómo hacer las cosas para terminar el Sprint con una versión que podría ser subida a producción.
  • Son multifuncionales: Esto suele causar confusión con frecuencia. Equipos multifuncionales son aquellos en los que se pueden encontrar en su interior a miembros del equipo con todas las habilidades necesarias para trabajar en la nueva versión, es decir, que tendremos dentro del equipo a alguien capaz de realizar análisis funcional si es necesario analizar algún aspecto en este Sprint y a alguien con conocimientos de DBA si es necesario realizar alguna tarea de administración de base de datos. Tener un equipo completamente multifuncional es una cosa difícil pero nos dará bastante ventaja a la hora de desarrollar ya que no habrá que asignar la tarea a otro departamento, que tendrá sus propias prioridades, para luego mantener a la espera todo el trabajo del Sprint hasta que este departamento pueda llevarla a cabo y entregarla.
  • No existen títulos dentro del Equipo de Desarrollo: Todos son desarrolladores, no existe un miembro que tiene el título de Analista y por tanto sólo desarrolla esas tareas. Lo mismo para el Tester y sólo él o ella testean, podrían hacerlo todos aunque haya miembros del equipo que por sus habilidades y conocimientos estén más especializados para hacer algún tipo de tareas sobre otras pero la responsabilidad cae dentro de todo el Equipo de Desarrollo.
  • No hay sub-equipos dentro de los Equipos de Desarrollo: Esto quiere decir que no hay un sub-equipo de testers o de analistas que sólo se encargan de esto, tampoco los hay de dominios específicos dentro del producto, por ejemplo, no hay un sub-equipo que trabaje sólo con las funcionalidades que tienen que ver con la facturación y otro con las funcionalidades de control de almacén. Todos trabajan en todas las partes del producto.

Los Interesados

Los Stakeholders tienen un nombre bastante feo en su traducción al español para Scrum: Los Interesados. Se les llama así por que tienen algún interés en el producto que se está construyendo. Pueden que sean los dueños o accionistas de la empresa que está pagando por el desarrollo, el jefe del departamento de ventas que quiere un nuevo módulo para la facturación o simplemente los usuarios de la aplicación que se está desarrollando y que tienen particular interés (de ahí lo de Interesado) en que la aplicación o el producto (recordemos que Scrum no se usa sólo para el desarrollo de Software) funcione lo mejor posible.

Estos Interesados han nombrado a un Dueño del Producto para que los represente y a él deben dirigirse siempre que quieran alguna modificación, recordarle alguna prioridad o añadir nuevas características al producto. No deberían dirigirse directamente al equipo de desarrollo para explicarles lo importante que es que la nueva exportación a Excel esté incluida en la próxima versión que se lance. De priorizar estas cosas y darles el valor oportuno debe encargarse el Dueño del Producto. En él estarán centralizados todas las peticiones de cada Interesado.

El jefe de ventas está interesado en la integración de la facturación con los móviles, el jefe de almacén quiere un nuevo sistema de avisos cuando cae el stock, un usuario de administración quiere que los listados puedan exportarse a Excel con sólo un botón porque le ahorraría un montón de clics de ratón. Todos tienen interés en que el producto salga lo mejor posible pero alguien tiene que decidir qué se construye ahora. Los presupuestos tampoco son infinitos y hay algunas cosas a las que hay que decir ‘No, ahora no puede hacerse’ o simplemente ‘No’.

De esta gestión de los Interesados y sus intereses debe hacerse cargo el Dueño del Producto que tendrá que anotar o tener en cuenta cada solicitud y ver si es factible hacerse o no y si va a dar mayor valor al producto final construyendo eso antes que cualquier otra cosa.

Si el Equipo de Desarrollo está en una empresa externa habrá que gestionar también los cambios en la Lista de Producto y los nuevos requerimientos. Será necesario hacer caer de esa lista de cosas por hacer otras funcionalidades ya acordadas que ahora se estiman menos importantes pero que tendrían un coste de desarrollo similar, o bien aumentar el presupuesto (pero recordemos que los presupuestos no son infinitos).

Keep it Simple from Agile 101 book

Some time ago, I had a conversation with an IT colleague, about the sector nowadays. Something reminded me of an Andrés Diplotti cartoon I’d seen on Google+. In it you could see a client reviewing the application that the programmer had delivered. The client says : “It’s all fine, but I don’t see a Cancel button”. The programmer replies: “I don’t program for cowards who cancel at the last minute.”
I’ve been a programmer for a long time. I’m still a programmer, in part. So I can recognize this kind of arrogance (maybe not to that extent). I suppose that it’s a sin of my youth, a brashness that’s been mellowing with age and that some of us already felt in college.
Back then I had just discovered software-design patterns in the book The Gang of Four. Our applications started to be filled with design patterns, the more the better. It looked like we were in some sort of contest. We had to see who used the most obscure, complex pattern —the one that would be the hardest to understand. With this in mind, I can understand the posts and articles I read now. They discuss refactoring old code to get rid of design patterns, and about how expensive it is for some projects.
As the years have gone by, I have suffered the KISS principle (Keep it Simple, Stupid) in my own flesh.  Not just with patterns, but also with the customization of on-screen graphic components. Or with “phantom requirements.” This is a term I once heard from a fellow worker. It refers to those features that no one has requested, but that you consider important for your clients. Things that “most probably” they’ll end up needing. It’s the malady known as featuritis. It makes us think that the more features or characteristics our app has, the more valuable the client will find it.
A long time ago, a client’s project manager commented that someone on another work team had told him that a feature he wanted was impossible. I told him that practically everything can be done, provided enough time is spent on it. I wasn’t clear enough. I should have added: but is it reasonable to use all that time for that feature? You can use practically any programming language to send a rocket to the Moon. But, do you really want to go to the Moon, or do you want a finished app by the deadline?
So, you are saying that my design is too complex?


You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

How we used Scrum in our software projects

These days I have been preparing and updating a Prezi presentation about how we used Scrum (or Agile development) in our software development projects.

You won’t find there a Scrum theory implementation but the process and methods we used to try to become more Agile (whatever that means) and to deliver software regularly and frequently (working software).

Reach the presentation at Prezi: Practical Scrum – How we used it.
or have a look at it here:

New chapter from book Agile 101: Principles Behind the Agile Manifesto

Nearly 15 years ago, in 2001, 17 software developers met in Utah. They were critical of the then popular software-development models, which they considered rigid or heavy. That meeting included people like Kent Beck, Martin Fowler or the Scrum founders. They had decided to meet in order to talk about the new techniques and processes to develop software.
That meeting gave rise to a number of principles governing the new alternative (and Agile) methods they were proposing: the Principles behind the Agile Manifesto. One of these principles is:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Clearly, this is what should be done in any type of development. We start every project with that in mind, but soon people start getting into a rush. Our director asks how many hours we’ve spent (and we’ve spent a lot already). Our client asks when all the features will be ready. Our workmates ask if they can take that two-week holiday we owe them.

It starts to look ugly. We’re in a mess again. We have to redo the Gantt chart with the new delivery deadlines, we have to look for another set of dates for those holidays (even our own holidays), and we have to give the director loads of explanations. “The client requested lots of changes” “The technology was new.” “We miscalculated.”

Here’s where we should be firm and ask the team for some extra effort, and decline little changes requested by the client. If it isn’t written exactly like that in the contract we signed or the minutes of a meeting we had six months ago, we’re sorry but we can’t do it.

The thing is, clients also did this. They wrote a very clear contract in which they stated each and every feature that they wanted (or the ones they wanted when they drafted it). Maybe they no longer needed those features or had realised that there were other, more important things, but they’re in the contract and they should be done. The project cannot end and leave 30% of undeveloped functionality.

At the moment, we have lost sight of what should be our top priority in our job: early and continuous delivery of valuable software. From here on, there are just tough negotiations and a contract that we would try to fulfil as soon as possible with the least amount of damage possible.

The contract might have tonnes of clauses and stipulations, but regardless of what it says, what the client wanted on signing it was a solution to the problem at hand, not an argument about whether to implement one functionality or another.

But if we deliver our software early and often, we can let clients test it and use it and tell us what they think. We can allow them tell us if there is something missing or what could be improved. They will want us to implement things they find they now need, and they will be delighted in turn to take out that .rpt file-exporting feature that no one remembers requesting or knows why it was requested in the first place.

When we finish the project, the client will have a product that really solves their problems, one that has been evolving while they learned, and one that they have been able to use and test from the early stages of the project. It sounds better for both the provider and the client, right?

New chapter from Antonio Martel's book, Agile 101: Principles Behind the Agile Manifesto
 “How do you
manage a project when you have received no previous training in project
management? Well, by suffering a lot.”
Albert Cubeles

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

SI QUIERES CONTRATAR MIS SERVICIOS PUEDES ENCONTRARME EN:

Tel: +34 690317539
Skype: antoniomartel
admin@antoniomartel.com

Haz clic en la imagen para obtener tu copia del libro gratis

Conéctate

facebook twitter google linkedin rss youtube