jueves, 17 de febrero de 2011

Una Solución pre-Scrumban / A pre-Scrumban Solution



Hace unos meses, leyendo las aportaciones de la comunidad española que trabaja con prácticas ágiles, me topé por primera vez con el término “Scrumban”. A partir de allí me leí el estupendo paper de Kanban vs SCRUM, y me alegré al saber que compartía problemas con ellos y podía leer sobre sus soluciones.

En este post, voy a centrarme en un problema que me he encontrado en el pasado y en una solución que adopté, y en siguientes posts voy a estudiar cómo se relacionan con las tendencias Scrumban que mis compañeros de agilismo están explorando.

En proyectos en los que he implantado SCRUM, había una serie de problemas recurrentes. Uno de estos problemas era qué hacer cuando el equipo de desarrollo también realiza tareas de soporte. Muchas veces, el equipo de desarrollo no sólo tiene que desarrollar nuevas funcionalidades, sino también arreglar bugs y realizar soporte puro y duro. En compañías grandes, los equipos suelen estar diferenciados, pero cuando se trata de empresas pequeñas, los desarrolladores tienen que contestar el teléfono y “apagar fuegos”.

El problema con SCRUM es que no permite incluir tareas nuevas cuando un Sprint ha empezado. Esto no es una restricción caprichosa, pues tiene un buen fundamento: hay que acotar el nivel de cambio dentro de un equipo para poder entregar el paquete de software prometido a final del Sprint. Si estamos cambiando continuamente el alcance de un Sprint, los conceptos de velocidad y compromiso por parte del equipo a entregar lo acordado para ese Sprint, se pierden. ¡No vamos a comprometernos a entregar algo que no sabemos qué es!

Pero si el equipo de software también tiene que ofrecer soporte... ¿cómo podemos decirle a un cliente (usuario, manager…) que tiene que esperar a que el Sprint se acabe para solucionar el problema? Aunque el problema sea urgente, tendrá que esperar a que el Sprint acabe, se priorice la solución en la pila de producto (por el Product Owner) y finalmente, se entregue al final del Sprint siguiente (supongo que, como el problema era urgente, el Product Owner lo prioriza). En el mejor caso, si el problema sucede el último día de un Sprint, el tiempo de respuesta seria la duración del siguiente. Y en el peor, si sucede el primer día del Sprint, dos veces esta duración. E incluso podríamos calcular un tiempo medio de respuesta, haciendo estadísticas de cuando suceden los problemas durante un Sprint en nuestra compañía, calculando su distribución temporal y obtener un tiempo medio de finalización del Sprint en curso (al que sumaríamos después la duración del siguiente). Sea como sea, esto no funciona si el problema es realmente urgente y se debe solucionar.

En un pasado, yo utilicé un método “híbrido”: bajábamos la velocidad de equipo de forma artificial para dejar un buffer para “soporte”. Hay que recordar que en SCRUM, los equipos son multifuncionales y por lo tanto todos los miembros del equipo podían realizar soporte. Definíamos una serie de tareas del Product Backlog como “opcionales”, utilizando una versión reducida del Moscow Method:

- Tareas M “Must”: conformaban el Sprint, el compromiso del equipo.
- Tareas S “Should”: estas tareas se realizarían si no había tareas de soporte. En caso de que surgieran dichas tareas, las tareas “Should” podrían descartarse. No formaban, a priori, parte del compromiso del equipo con el cliente.

Este método no es perfecto, pues también limita la capacidad de soporte del equipo, pero dicha capacidad máxima de soporte era algo que se acordaba con los clientes/usuarios. Por ejemplo, “el equipo dedicará un máximo de 20% a soporte”. Entonces “Tareas Must” = Compromiso = Velocidad - 20%. Si no se realizaban tareas de soporte, el equipo debía realizar las tareas “Must” y “Should”. Las soluciones de bugs se ponían en producción cuando el Sprint finalizaba, con lo que el tiempo de respuesta se reducía.

3 comentarios:

  1. Unit Testing – your slot game builders, test every part to find out} occasion that they} work as intended. If you employ Unity https://topcleo.app/ or Unreal Engine for slot improvement, you'll be able to|you possibly can} simply translate to multiple of} different platforms. Offering your slot game on Android, iOS, Windows, Console, and VR lets you attain probably the most prospects. However, supporting many platforms requires more resources. The UI/UX may be designed using tools like Adobe XD and Figma. So, your UI/UX designers should create a working version of the ultimate design using the up to date artwork.

    ResponderEliminar
  2. Aside from the games, visitors can also enjoy close by institutions similar to 헤븐카지노 duty-free retailers, upscale motels, movie theatre, shopping centres, and the COEX Centre. The country is much from legalizing casinos for locals or opening further casinos for locals as a result of|as a end result of} the federal government believes that the social impression of gambling shall be detrimental for its locals. Addiction, criminal activities, and damaged households may end up} from gambling. Koreans are believed to be highly susceptible to gambling addiction.

    ResponderEliminar
  3. "A respected retailer will certain you} get the true deal in terms of|when it comes to|by way of} material and motor," Ky explains. "They may even offer a assure on the toy and the charging cable." "Suction toys are very orgasm-reliable," assures Ky, so that you should not wrestle with reaching the tip dildoes aim if that's your goal - no matter how you use the toy. Our editors have independently chosen the merchandise listed on this page.

    ResponderEliminar