¿Estamos en la antesala de una revolución?. Posiblemente. ¿Pero podemos aplicar esta metodología a los sistemas decisionales o solo es aplicable a los sistemas operacionales?Esa es mi gran duda.
viernes, 30 de mayo de 2008
Que son eso de las metodologías ágiles
¿Estamos en la antesala de una revolución?. Posiblemente. ¿Pero podemos aplicar esta metodología a los sistemas decisionales o solo es aplicable a los sistemas operacionales?Esa es mi gran duda.
SCRUM para DWH?
El Scrum se ha desarrollado teniendo como principios fundamentales:
lunes, 26 de mayo de 2008
"Metodología ágil para la planificacióny seguimiento de proyectos "
SCRUM es una metodología que nace ajena al desarrollo del software, de hecho sus principios fundamentales fueron desarrollados en procesos de reingeniería por Goldratt, Takeuchi y Nonaka en la década de 1980 y no fueron aplicados al proceso de desarrollo de software hasta 1993 por Jeff Sutherland, siendo formalizada con la colaboración de Ken Schwaber en una presentación en OOSPLA 96.
Explicando Scrum a mi abuela
MAS INVESTIGACIÓN
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx
"Estabilizar Aplicaciones"
Primero de todo y antes de continuar, necesitas una herramienta de seguimiento y control de errores. Si no tienes una herramienta de este tipo instalada en tu organización, no hace falta que sigas leyendo porque todo lo que hagas no va a servir de nada.
Puedes encontrar una justificación para implantar una herramienta de seguimiento y control de errores en el mi artículo "Seguimiento y control de errores".
Si has seguido leyendo es porque tienes una herramienta de seguimiento y control de errores.
La creación del equipo
El equipo debe estar formado por el grupo de programadores, el grupo de probadores (también llamados testers) y el líder del grupo, que podría ser el gestor o el programador jefe.
Los roles parecen obvios, los programadores arreglan errores, los probadores prueban la aplicación reportando errores y el líder del grupo es el encargado de que todo funcione como debe ser y no se desmorone.
Programadores. Arreglan los errores, evidente, no? Es de vital importancia que los programadores solo arreglen errores que hayan sido introducidos mediante la herramienta de gestión de errores.
Probadores. Aparentemente tendrían un solo cometido que sería la de probar la aplicación buscando errores, pero tienen otro que es igual o más importante que el primero que es el de verificar que los errores arreglados realmente se han arreglado. Esto ocurre porque un porcentaje de los errores que los programadores arreglan no terminan de estar bien arreglados, errores en la reparación de errores. (diabólico pero cierto)
Líder del grupo. Es una pieza clave en este proceso. Por un lado es el que conduce las reuniones SCRUM, realizando la tarea de facilitador del grupo, procurando que todo el mundo pueda realizar el trabajo lo mejor posible. Por otro lado es el encargado de priorizar los errores, es decir, indicar qué errores son más importantes y por consiguiente se repararán en primer lugar.
Priorizar los errores
Cuando los probadores empiezan a reportar errores, aparecen errores de todo tipo, desde el error que cuelga la aplicación o peor, todo el equipo, hasta el error de que le falta una tilde a tal o cual palabra.
Como nuestro objetivo es estabilizar la aplicación lo más rápidamente posible (véase el título del artículo), lo primero que haremos es indicar a los probadores qué criterios tienen que seguir para priorizar los errores.
Nosotros como líderes del equipo y responsables del proceso repasaremos las prioridades de los errores para verificar que han sido introducidas correctamente y modificaremos las que sean necesarias.
Podríamos establecer muchos tipos de clasificación de errores pero como lo que nos interesa es la estabilización de la aplicación, estableceremos por ejemplo la siguiente clasificación.
Bloqueantes
Errores que impiden que se siga probando o se sigan arreglando errores, es decir errores que impiden seguir trabajando al equipo.
Críticos
Errores de tipo cuelgue de la aplicación, cuelgue del sistema, errores de programación no controlados, etc…
Normales
Mal funcionamiento de la aplicación, es decir, la aplicación no hace lo que debería hacer.
A partir de aquí no importa mucho para la estabilización de la aplicación pero son útiles para la mejora de la misma.
Estéticos
Fallos ortográficos o estéticos como alineación de botones, capitalización de títulos.
Mejoras
Sugerencias, mejoras de usabilidad, etc…
Reuniones SCRUM
Estas reuniones se llevan a cabo hasta que el proyecto está listo para ser lanzarlo al mercado o puesto en producción. Se han de realizar todos los días antes de empezar a trabajar a primera hora de la mañana si es posible.Primera Reunión
Explicar al equipo cómo se va a trabajar. Se hace una breve introducción de cómo son este tipo de reuniones, reuniones cortas, no son reuniones para solucionar problemas, tan solo para coordinar trabajo. Si existe algún problema que impida trabajar se expone, para solucionarlo, pero no el trabajo en si. Tienen que servir para organizar no para resolver. Si hace falta una reunión para resolver alguna cuestión relacionada con los errores, se hace después, ya que posiblemente no hace falta que estén todo los miembros del equipo.
Establecer los criterios para priorizar los errores. Se explica a todos cuál será el criterio para clasificar los errores, basándonos en la tabla anteriormente mostrada.Primera reunión y siguientes
¿Qué es lo que se hizo desde la última reunión? Como las reuniones son diarias no habrá mucho que tratar, es importante destacar que sólo el trabajo que se hizo para la consecución del objetivo es válido. Todo lo demás se verá como un impedimento al objetivo.
¿Qué es lo que se va a hacer hasta la siguiente reunión? Es muy importante que quede claro que al salir de la reunión todo el mundo sabe lo que tiene que hacer, y todos están alineados en la misma dirección. La dirección que queremos seguir está clara, estabilizar la aplicación lo antes posible. Para lo cual corregiremos siempre los errores por prioridad, corrigiendo primero los bloqueantes que impiden que el equipo trabaje y seguidamente los críticos que provocan que la aplicación se estrelle.Mucha gente no sabe organizarse y pierde el tiempo en cosas poco importantes, estas reuniones también sirven para organizar la agenda diaria de cada miembro del equipo y asegurarnos de que todos tienen el mismo objetivo.
¿Cómo se va a llevar a cabo? Todo el mundo tiene claro cómo va a hacer lo que tiene asignado, es el momento de que surjan a la luz todos los problemas que tienen las personas para la realización de su trabajo. ¿Existe hay necesidad de máquinas, personas, recursos o tiempo? Si es así el facilitador tiene la obligación de conseguir o si no es posible buscar otras formas de satisfacer esas necesidades.
La finalidad de las reuniones SCRUM es alinear a todas las personas en la misma dirección y sacar a la luz los problemas e impedimentos que hay para conseguir el objetivo.
El éxito de este sistema se basa en arreglar los errores por prioridades, los errores críticos hacen que la aplicación sea más difícil de probar y por tanto no se pruebe bien. Además de bajar la moral del equipo, así que cuánto antes los eliminemos mejor.
Es tu obligación como líder del grupo y responsable de la estabilización de la aplicación que se mantenga esta norma lo más estrictamente posible.
Es muy importante también que no se añadan funcionalidades ni mejoras hasta que la aplicación esté estable, la razón es que podemos multiplicar los errores fácilmente si realizamos modificaciones sobre aplicaciones inestables.Resumiendo, las claves de este sistema son:
Priorizar la resolución de errores
Mentalidad de equipo, mismo objetivo
Organización del trabajo
PROGRAMACION AGIL "SCRUM"
Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 días), por medio de iteraciones o Sprints.
Ideal para proyectos con un rápido cambio de requerimientos.
Contexto SCRUM
Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo como puede hacer XP.
Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto.
Sus raíces teóricas están en las teorías de la auto-organización.
Actores SCRUM
Propietario del producto
Representa a todos los interesados en el producto final.
Sus áreas de responsabilidad son:
- Financiación del proyecto.
- Retorno de la inversión del proyecto.
- Lanzamiento del proyecto.
Equipo
Responsable de transformar el Backlog de la iteración en un incremento de la funcionalidad del software.
-Auto-gestionado.
-Auto-organizado.
-Multi-funcional.
Scrum Master
-Responsable del proceso Scrum.
-Formación y entrenamiento del proceso.
-Incorporación de Scrum en la cultura de la empresa.
-Garantía de cumplimiento de roles y responsabilidad.
Metodología De Trabajo
Equipos de entre 6 y 10 personas revisan los requisitos, la tecnología disponible y evalúan los conocimientos para colectivamente determinar como incrementar la funcionalidad.
Reuniones diarias, antes de empezar a trabajar, con una duración máxima de 4 hrs.
Se llevan a cabo hasta que el proyecto este listo para ser puesto en producción o ser lanzado al mercado.
En la primera reunión se explica al equipo la forma de trabajo, especificando que son reuniones cortas para coordinar trabajo y no para solucionar problemas. Se establecen los criterios para arreglar los errores por prioridades (base del éxito del sistema).
Al inicio de cada iteración se revisa el trabajo pendiente en el proyecto y se selecciona la parte a la cual se le incrementara funcionalidad, para al final de la iteración incorporarla al SW y presentársela a las partes involucradas.
En cada reunión las preguntas claves a contestar son:
-Qué es lo que se hizo desde la última reunión?
-¿Qué es lo que se va a hacer hasta la siguiente reunión?
-¿Cómo se va a llevar a cabo?
Artefactos SCRUM
Sprint
Es la base del desarrollo Scrum.
Su duración máxima es de 30 días.
Se llevan a cabo las tareas pre-establecidas y no se puede modificar el trabajo acordado en el backlog.
Sólo el ScrumMaster puede abortar un sprint si lo considera no viable por alguna de las sgtes. razones:
Las circunstancias del negocio han cambiado.
La tecnología acordada no funciona.
El equipo ha tenido interferencias.
Product Backlog
Crea un listado con los requisitos de los usuarios o propietarios del sistema para planificar el proyecto.
No es una lista completa y definitiva. Es sólo una estimación inicial de los requisitos.
Es un documento dinámico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.).
Sprint Backlog
Especifica la serie de tareas que se van a desarrollar según los requisitos señalados.
Estas tareas tienen una duración de entre 4 y 16 hrs. de trabajo.
Las de mayor duración intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo.
Al final del sprint se busca un incremento en la funcionalidad.
Mas información
http://www.ingenierosoftware.com/equipos/estabilizar-aplicacion.php
http://www.agile-spain.com/agilev2/donde_aprender_mas_sobre_scrum
http://blogs.msdn.com/josemurl/archive/2005/09/15/467898.aspx
http://www.exa.unicen.edu.ar/catedras/ingsoft/informeagiles.doc