SCRUM e Ingeniería de Software. Descontrol?

SCRUM e Ingeniería de Software. Descontrol?

, , 0

En el artículo anterior empecé a desgranar algunas ideas acerca de Scrum, las metodologías ágiles y la ingeniería de Software.

En resumen, mi planteo es que pareciera que las metodologías ágiles abren la posibilidad para el caos.

Pero antes dos o tres conceptos acerca de SCRUM (una de tantas metodologías ágiles).

SCRUM en pocas palabras

Los conceptos son simples, y por eso me gusta. Por empezar, Scrum se plantea como un Framework. es decir una manera de organizarse, dónde luego se puede combinar con otras técnicas más tradicionales para efectuar las tareas específicas.

Hay muchísima info en la web que explican qué es Scrum. Pero les dejo una presentación en Prezi que me pareció bastante clara:

Definido como una serie de pasos sería algo así:

  • Primero: definimos que hay que hacer. Product Backlog
    • Para esto nos juntamos el equipo de desarrollo + los usuarios
    • Se recopilan las necesidades a manera de Historias de usuarios.
    • Entre todos los participantes se define quien es el Product Owner
    • Como se va a probar a los efectos de decir: «Ya está. Esto es lo que queremos».
    • Se les asigna una prioridad relativa.
  • Segundo: se define que historias se van a desarrollar primero y cuanto tiempo está el equipo dispuesto a esperar. A este tiempo lo llamaremos Sprint.
  • Tercero: el equipo completo se aboca a desarrollar / construir / o como se quiera llamarlo, las historias de usuario escogidas y diariamente se hace un seguimiento de 15 minutos (sí! 15 min) para ver como va la cosa y destrabar lo que haga falta. Estas reuniones se llaman reuniones de Scrum (por el rugby). Se actualiza un diagrama de avance que se llama Burn-down
  • Cuarto: al final del Sprint se hace una Demo o bien una Entrega . Esto es super-importante porque obliga a enfocarse y definir que está listo y que no. Además se refuerza el sentimiento de equipo y el feedback del usuario.
  • Quinto: un día después del Sprint se hace una reunión de Retrospectiva. Esto sirve para aprender sobre que se hizo bien y que cosas mejorar para el siguiente Sprint.
  • Sexto: Se vuelve al primer paso, pero esta vez para ver que cosas quedaron para desarrollar o si hay cosas nuevas y volver a empezar.

Fuente: http://www.sigis.com.ve Soluciones Integrales GIS 

Técnicas tradicionales vs Agile

Entonces alguien podría decir: Y el UML, los diagramas entidad-relación?, los diagramas de estado?

O bien: Y el change managment?, y el documento de aprobación de requerimientos? y las pruebas de usuario? y el documento de aceptación?, etc., etc…
Bueno, esa es la magia. El equipo decide que sirve y que no, o que cosas son indispensables utilizar. Por ejemplo, la separación de ambientes, el sistema de versionado de código, las herramientas CASE, etc., etc.
Algo similar ocurre con las estimaciones. Estamos acostumbrados a utilizar diferentes métodos de estimación (prospectiva) para tratar de adivinar cúanto tiempo llevará desarrollar un proyecto: Heurísticos (basados en la opinión de un experto o grupo de expertos) o paramétricos tales como COCOMO, SLIM, FPA, Puntos casos de uso, etc.)
En SCRUM esto se hace más naturalmente. Se acuerda inicialmente con el equipo de una manera heurística, pero los subsiguientes Sprints se van refinando con la realidad.
En los próximos artículos vamos a tomar un proyecto de Business Intelligence y ver en paralelo como sería enfocarlo con una metodología tradicional y cómo sería utilizando SCRUM.
Si tenés dudas escribime a ajsueldo@gmail.com y con gusto las contestaré.
Continuará…

Related Posts

Leave a Reply