viernes, 30 de mayo de 2008

Que son eso de las metodologías ágiles



Las metodologías ágiles.

En el Manifiesto Ágil se definen los cuatro valores por las que se deberían guiar las metodologías ágiles.“ Estamos buscando mejores maneras para desarrollar software y ayudar a otros a desarrollarlo. En este trabajo valoramos:

Al individuo y sus interacciones más que al proceso y las herramientas.·


Desarrollar software que funciona más que a obtener una buena documentación·


La colaboración con el cliente más que la negociación de un contrato.· Responder a los cambios más que seguir una planificación.De esta manera, mientras mayor valor tengamos en la parte derecha más apreciaremos los de la parte izquierda “Manifiesto Ágil.

Veamos que significa cada uno de estos valores:1) Al individuo y sus interacciones más que al proceso y las herramientas.Sin duda la herramienta fundamental del desarrollo de sistemas decisionales es el cerebro humano.

Unas jornadas maratonianas de 14 horas de trabajo van en detrimento de la calidad del producto final. Pero una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse.

Un factor clave para el éxito es construir un buen equipo, que se lleve bien entre ellos, y que además sepan como construir su propio entorno de desarrollo.

Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte a él. Esto nos resta eficiencia, es mejor que el equipo lo configure en base a sus necesidades y sus características personales.Además las interacciones que haga el equipo con el usuario final deberían ser igual de fluidas siendo este usuario un miembro más del equipo, con un objetivo común, que es conseguir que el proyecto funcione y sea útil para él.

Si todo esto funciona bien es obvio que la elección de las herramientas y el proceso mismo de desarrollo pasan a estar en un plano totalmente secundario en la ecuación del éxito del proyecto.


2) Desarrollar software que funciona más que a obtener una buena documentaciónUno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema. Sin duda es un arma de doble filo, una buena documentación actualizada en cada modificación y bien mantenida al día, te permite saber el estado de la aplicación y como realizar las modificaciones pertinentes, pero son pocos los que con las presiones externas de tiempo y dinero acaban actualizando la documentación.


En la filosofía ágil lo primordial es evitar estos fallos, la regla no escrita es no producir documentos superfluos, y solo producir aquellos que sean necesarios de forma inmediata para tomar una decisión importante durante el proceso de desarrollo. Estos documentos deben “ir al grano”, ser cortos y centrarse en lo fundamental, olvidándonos de los circunloquios que no aportan nada a la comprensión del problema.


3) La colaboración con el cliente más que la negociación de un contrato.La consultoría informática de los últimos años se ha convertido en una lucha a muerte entre el proveedor del servicio y el cliente que lo contrata. Por una parte el cliente intenta que se hagan el mayor número de funcionalidades con el mismo dinero, por otra parte el consultor intenta que por ese dinero solo se realicen las funcionalidades contratadas inicialmente. En las reuniones de seguimiento de los proyecto es fácil oír frases del tipo “esta modificación no entra en el contrato” respondida generalmente por la tan típica “pues yo ya no tengo más presupuesto y así no podemos trabajar”. Al final este tipo de proyectos hacen que el consultor informático sea un híbrido entre analista y abogado.

Desarrollando habilidades legales para salvaguardarse en caso de conflicto jurídico.Sin embargo para que un proyecto tenga éxito la complicidad y el contacto continuo entre el cliente y el equipo de desarrollo es fundamental. El cliente debe ser y sentirse parte del equipo. De esta manera ambos entenderán las dificultades del otro y trabajarán de forma conjunta para solucionarlo.


4) Responder a los cambios más que seguir una planificación.Una organización cambia constantemente, se adapta a las necesidades del mercado y reorganiza sus flujos de trabaja para ser mas eficiente. Es difícil pues, que en el desarrollo de un proyecto, este no sufra ningún cambio, pues es seguro que las necesidades de información de la empresa habrán cambiado y mas cuando se trata de sistemas decisionales, no siempre tomamos las decisones de la misma manera.


Son muchos los factores que alterarán nuestra planificación inicial del proyecto, si la adaptamos a estos cambios corremos el riesgo de que cuando acabemos, nuestra aplicación no sirva para nada y el cliente se haya gastado el dinero en vano. La habilidad de responder a los cambios de requisitos, tecnología, presupuestarios o estrategia, marca sin duda el camino del éxito del proyecto.


Como consecuencia de estos cuatro valores, el Manifiesto Ágil también enuncia los doce principios que caracterizan un proceso ágil diferenciándolo de otro tradicional en los que este enfoque no se había aplicado lo suficiente, siempre se había dejado implícito pero sin hacer hincapié en ellos.


I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darán una ventaja competitiva a nuestro cliente.

III. Hacer entregas frecuentes de software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la principal medida del progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenido. Los promotores, usuarios y desarrolladores deben poder mantener un ritmo de trabajo constante de forma indefinida

IX. La atención continua a la calidad técnica y al buen diseño mejoran la agilidad.

X. La simplicidad es esencial. Se ha de saber maximizar el trabajo que NO se debe realizar.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se han organizado ellos mismos.

XII. En intervalos regulares, el equipo debe reflexionar con respecto a cómo llegar a ser más efectivo, y ajustar su comportamiento para conseguirlo.

Llegados a este punto podemos intuir que las formas de hacer las cosas están cambiando, adaptándose más a las personas y a las organizaciones en las que han de funcionar las aplicaciones.Para completar todo esto os adjunto un link imprescindible http://agilemanifesto.org/
¿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?

Como se menciono anteriormente el término SCRUM tiene su origen en el ámbito del rugby, se trata de una posi-ción entrelazada en círculo que toman los integrantes de ambos equipos.
El pro-pósito del scrum es el de reiniciar el juego, rápida, segura e imparcialmente, después de una infracción menor o de una detención.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.Eso lo hace muy versatil para desarrollar proyectos de workflow por ejemplo, pero mi duda es si se puede aplicar de forma eficiente a un proyecto de datawarehouse.
A priori, un buen proyecto para aplicarlo sería el de una "reingenieria de un dwh existente", y tengo precisamente tengo una entre manos, asi que voy a decicar este post a "refrescar" los principios sobre los que se basa SCRUM a ver si lo puedo aplicar o no a este proyecto.
El Scrum se ha desarrollado teniendo como principios fundamentales:
Principio de requisitos indefinidos de Humphrey.
Para un nuevo aplicativo, los requerimientos no serán totalmente conocidos hasta que el usuario no lo haya usado.
Lema de Wegner.
Es imposible definir completamente un sistema iterativo. •
El principio de incertidumbre de Ziv en la ingeniería del software.
La incertidumbre es inherente e inevitable en el proceso de desarrollo de aplicaciones.Podríamos decir que Scrum se basa en cierto “caos controlado”, el proceso del ciclo de desarrollo de Scrum parte del conocimiento de que el proceso de desarrollo fundamental del producto esta totalmente indefinido, es incluso caótico, pero establece ciertos mecanismos para controlar esta indeterminación, manipular lo impredecible y controlar la flexibilidad.
Y aqui nos encontramos con la primera pega, SCRUM es segun sus propios autores un.... "Modelo de desarrollo ágil de productos""Producto", un DHW NO es un producto que se pueda acabar como ya dije en el post anterior, asi que quizás no sea tan buena idea lo de SCRUM.
Pero los principios me parecen muy adecuados. Claro si pensamos en el origen de la metodología es obvio que esta orientada a producto así que no se yo hasta que punto voy a poder aprovecharla.
Pero sigamos viendo, ahora me centraré en el ciclo de vida de Scrum. Este es una analogía de la jugada de rugby de la que recibe su nombre. En Scrum el balón ha de disputarse entre ambos equipos, los jugadores de un equipo se reúnen en circulo y deciden que es lo que van ha hacer, luego se posicionan enfrente del otro equipo de forma entrelazada, con el balón en medio, y comienza la jugada en la que no se sabe que va a pasar, ni quien tendrá el balón ni hacia donde se atacará.
El equipo ha de adaptarse rápidamente hacia una jugada ofensiva o defensiva según quien se haya hecho con el balón.
¿Eso me sirve para el rediseño de un DWH?
Uy que pinta un poco mal. Si yo ya tengo claro hacia donde tengo que ir, que estructura tengo que optimizar, que usuarios utilizan el sistema y como lo utilizan.
¿Necesito esa adaptabilidad tan extrema?.
Empiezo a ver que no, pero quiero darle una oportunidad antes de descartarlaEn la metodología Scrum se establecen tres fases : pre-juego, juego y post-juego.En el pre-juego se definen y/o revisan las funcionalidades que ha de tener el sistema, haciendo la lista de funcionalidades que cuando estén completadas podremos decir que el desarrollo del sistema.
Dicha lista recibe el nombre de Release Backlog .Una vez hecho esto se elige un subconjunto de estas funcionalidades con el que se va a trabajar el próximo mes, llamado Sprint Backlog y entonces comienza la siguiente fase.En el juego es donde se desarrolla el Sprint, las reglas de esta fase son sencillas, se distribuyen las tareas para cada miembro del equipo, se trabaja duro y se intentan conseguir el objetivo.
Todos los miembros del equipo han de participar en una reunión diaria que en ningún caso deberá exceder los 30 minutos, llamada Sprint-meeting.
En esta reunión cada desarrollador debe dar respuesta a tres preguntas:
• Que hizo desde la última reunión.
• Que dificultades se estan teniendo en el desarrollo de la tarea.
• Que va a hacer hasta la próxima reunión diaria.
Al finalizar el Sprint, pasamos a la fase de post-juego, en ella se evalúa la entrega de funcionalidades del Sprint , se ven las tareas pendientes, se evalúa el progreso del proyecto y se redefine el tiempo de entrega del mismo si fuera necesario.
En este paso se compara las funcionalidades actuales con el Release Backlog y en el caso de no cumplirse se vuelve a la fase de pre-juego para realizar una nueva iteración.
Si por el contrario, sí se cumplen entonces pasamos la creación de la versión final y a la creación de la documentación pertinente.
Pues creo que yo ya lo tengo claro, no me aporta demasiado para una reingenieria de DWH, quizás para un proyecto de DWH nuevo desde cero si que me podría ser útil, pero para una reingeniera de DWH claramente no, porque ya se que funcionalidades ha de dar, y porque no tengo que ir dando pequeñas funcionalidades cada semana, ya que lo tengo bastante mas simple, cuando acabe la reingenieria, desactivaré el antiguo data y conectaré el nuevo data.
Y si todo va bien los usuarios no se darán ni cuenta.
Bueno, para finalizar explicaré los roles básicos de SCRUM así os haceis a una idea, os pongo los 4 principales.
• Scrum Master: Es el responsable de asegurar que el proyecto se es-tá desarrollando según las reglas de la metodología Scrum.
• Product Owner. Es el responsable de la lista de funcionalidades (Re-lease Backlog).
• Scrum Team: Es el equipo responsable la organización y ejecución de cada uno de los Sprints.•
User/Customer: Participan en la creación y revisión de la Release Backlog.
Pero a mi me sigue gustando SCRUM, ya que la forma de trabajar que se adopta es muy colaborativa, un equipo de Scrum tiene entre 7 y 9 miembros, a los que se les incentivará para que adopten soluciones ingeniosas y que aprendan de forma conjunta en un ambiente totalmente cambiable pero controlado parcialmente.

lunes, 26 de mayo de 2008

"Metodología ágil para la planificacióny seguimiento de proyectos "


El término Scrum tiene su origen en el ámbito del rugby, se trata de una posición entrelazada en círculo que toman los integrantes de ambos equipos. El propósito del scrum que cada miembro desde su puesto contribuye al equipo, haciendo todos fuerza para el mismo lado.
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.


Más Informacio




Explicando Scrum a mi abuela

El otro día me encontraba hablando con un compañero de trabajo a través del teléfono móvil, cuando mi abuela me escuchó nombrar palabras raras en la conversación.Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que más atención la llamó, así que cuando colgué, lo primero que me preguntó fue con quién hablaba, de qué hablaba, y que era eso de Scrum.Imaginaros la cara que se me quedó, porque... ¿cómo explicar Scrum a mi abuela?.Aunque mi abuela es muy avanzada para la mayoría de la gente de su edad, la verdad es que no es fácil explicarla muchos de los aspectos tecnológicos emergentes, pero bueno, es mi abuela y tenía que intentar explicárselo de forma convincente.Aquí, os transcribo aquella inverosímil conversación.

MAS INVESTIGACIÓN
http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx

"Estabilizar Aplicaciones"

Estabilizar una aplicación mediante reuniones SCRUM
Por Joaquin Gracia28 de Marzo de 2005
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"

SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo.
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