Buscar este blog

miércoles, 16 de febrero de 2011

¿Cuando una historia de usuario está "acabada acabada"?

Parece simple, pero en realidad no lo es tanto. ¿Cuando se puede decir que una historia de usuario está acabada realmente?


Primero vamos a comenzar con algunas definiciones.
  • Acabado: 
    • Hacer que algo llegue a su término.
  • Historia de usuario: 
    • Es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación).
    • Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.
Entonces, ¿cuando podríamos decir que una historia de usuario está finalizada o acabada realmente? Como el término acabado es un tanto ambiguo, creo muy importante que cada equipo defina lo que para cada uno significa que una historia de usuario se pueda dar por finalizada dentro de un equipo.

He aquí algunos aspectos que pienso que se deberían tener en cuenta:
  • Partes básicas que forman parte de las pruebas de validación.
  • Pactar con el cliente las pruebas de validación de cada historia.
  • Entorno se va a utilizar para pasar las pruebas de validación definidas por cada historia.
  • Decidir quien es la persona/s que deciden cuando una historia se cierra. (Cliente, Equipo de Calidad, Producto Owner,...)
  • Utilizar una herramienta de control de incidencias que permita mapear bugs con las historias afectadas.
  • ...
Es un buen trabajo, que cada equipo lo que es para ellos el concepto de "historia acabada acabada" para evitar así que puedan darse malos entendidos.

Saludos,
JK

Why scrum can feel like a Overhead?


Scrum an agile development methodology framework, many people might not agree and would say its a methodology. As Uncle Bob has commented scrum is deliberately incomplete and can be adapted and makes it best fit for each team.

Then in this scenario can it be really a overhead??

There can be various reasons of why scrum can be felt as burden or a overhead, let´s jot jolt down some of them..

1) Scrum has been imposed on the people and they feel its more to control them than to make life easier. This kind of sensation can be noted when it was only management´s decision to implement scrum and no adequate process of adaptation was undertaken. This can make people think that scrum is overload, its bringing more responsibilities. But really speaking there is only 15mins daily and 3-4 hours bi-weekly. if you hear its a overload/ Overhead, one of the things you can be sure is team is manifesting that the decision is being pushed on them.

2) The case also can be that team doesn't like to follow processes or was not following any formal process of development. In these situations the sprint planning, the daily meetings and the important aspect of iterative delivery can be result like a overhead for the team.
Most probably results from previous development process were late delivery, not meeting user requirements and unmate commitments.

3) The most probable reason is the team only looks at the things they have to do and not what are the improvements/ benefits such as greater visibility into progress, closer contact with customers and users who can validate that the most-desired features are being built, closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and so on....

4) The other possible reason can be that the scrum principles are not being followed correctly. The daily meeting are not limited to 3 answers and are being done for extended period of time. The planning meetings are uninformative and also extended period of time. The sprints and teams are not blinded. and so on...

5) Feeling of scrum overhead can also be existent if the team doesn't feel integrated. If there is non-existence of common projects or common Goals. This situation normally arises in the companies which are oriented towards services rather than products.

Said this a team can work its progress towards a scrumbutt most probally goes through one of these reasons. The most important part of implementation teams believing in scrum and understanding how it helps them to improve the work environment.

In my own experience Scrum is lightweight, the management is low and it gives more productive time and helps us in improving our focus on the planned work, reducing the deviations and raising the alarms in early stages.

Common sense is most important aspect of Scrum.









martes, 15 de febrero de 2011

jueves, 3 de febrero de 2011

15 minutos por Skype

En el grupo donde estoy de Scrum Master - rol que veo poco mediterraneolizable y en ese tema quizá entro algún día - se da la particularidad de que no estamos todos en la misma ubicación física, sino que estamos físicamente en dos sedes y a la practica en unos tres o cuatro oficinas. En este caso se planteó hacer la reunión diaria de manera telemática, y se selecciono Skype para hacer una sala de chat donde realizar la reunión. La primera decisión fue si lo hacíamos en chat de texto o en videoconferencia, pero dado que la conferencia - y no hablemos ya de la videoconferencia - con más de un interlocutor no acaba de funcionar de manera maravillosa (aún no sé porque tecnicismos), optamos por la magnifico, estupendo y tradicional mecanismo de chat en texto, almenos para comenzar.

Seria falso relatar las magnificas cualidades del chat de texto - carece de sentido - porque no hemos hecho ninguna reunión “de pie” en con el grupo, por lo que comentaré las cosas que me han llamado la atención de realizar las reuniones por chat:

1) Dado que las reuniones duran 15 minutos, es importante tenerlo escrito antes y pegar el resumen personal, ya que si hay que escribirlo en el mismo momento, cosa que alarga la reunión.

2) Hacen falta unas cuantas bastantes conversariones por skype para que las reuniones se hagan más cortas y el equipo sepa cuando se está alargando o no y que se hagan más eficientes.

3) Todo el mundo puede coger la batuta de la reunión, pero no es mala idea que cada persona pegue su resumen del día, espere unos momentos a ver si alguien quiere comentar alguna cosa y que pase el turno de palabra a un compañero que no haya dicho nada. Léase: paso de testigo.

4) Si hay que hacer algún comentario dirigido a una persona, puede ser interesante indicarlo de manera directa, p.e.

@roberto : este bloqueo es el mismo que el de ayer, no?


Así se facilita que no entren más personas en la conversión directamente.

5) La información que se escribe, se guarda en un log y luego puede ser interesante querer buscarla por algún motivo. Por ese motivo, añadir marcadores en el texto que se escribe, puede ayudar en un futuro a localizar cosas. Como ejemplo puedo añadir mi nombre de al principio

[juanp]

ayer: bla, bla, bla

hoy: bla, bla, bla

bloq: ninguno


Así, sé que buscando en los logs por [juanp] encontraré mis entradas.

6) Por el mismo motivo que (5) al comenzar la reunión es bueno poner una buena separación, porque Skype pone todos los logs juntos, dos buenas lineas de asteriscos pueden hacer correctamente su función.

Como el tema es curioso, he surfeado a ver si encontraba alguna cosa interesante. Sorpresa!
A Practical Guide to Distributed Scrum: Distributed Daily Scrum Meetings comenta pros i contras del chat de texto ; será interesante ver si en el futuro podemos ampliar o refinar este cuadro.

ProsCons
  • Whole team takes part in each day.
  • Team can discuss blockers and remove them immediately.
  • A transcript of the chat can easily become a set of notes for the meeting.
  • May be easier for non-language speakers to write their thoughts instead of speaking.
  • The team loses both face-to-face and verbal communication. Unlike teleconference interaction, the Scrum Team cannot hear voice inflections.
  • No guarantee the Scrum Team is paying attention to the chat session.
  • Full accountability for the meeting occurring at the same time every day is fully on the ScrumMaster.
  • Can be chaotic depending on how the team conducts the meeting.