viernes, 13 de junio de 2008

What is Scrum?
Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices. Scrum has been used from simple projects to changing the way entire enterprises do their business.
Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. Learn more... For an overview audio of Scrum, click here. For a video of Scrum, quality, and enterprise competitiveness, click here. For an description of Scrum in the Financial Times : The London Financial Times interviews Ken Schwaber and Ian Shimmings of Conchango about Scrum.
Scrum VSTS - Scrum Tutorials and Tool
Learn more about Scrum through a
multimedia kit, or download a Scrum kit for Microsoft VSTS. Both are provided through the hard work of Conchango. Also available is eScrum, built by Microsoft also for use with the VSTS platform.
Scrum Alliance
The
home of the Certified ScrumMasters organization, offering training, gatherings, information, and materials regarding Scrum, including frequent articles..
ScrumMaster Certification
To acquire the formal Scrum methodology, Scrum Project Management software, and training - or to find a Certified ScrumMaster to help you implement Scrum, go to ScrumAlliance. To learn iterative, incremental development the agile way using Scrum, the next ScrumMaster Certification classes that I teach :
When
Where
Registration

Video de scrum aplicado a las empresas

http://video.google.com/videoplay?docid=-7230144396191025011&q=Google+Tech+Talks&hl=en




La dificil tarea de planificar


Unos de las tareas mas difíciles (si no la mas difícil) a la que nos enfrentamos al abordar el desarrollo de software es realizar la planificación del trabajo a realizar. Para muchos proyectos necesitamos realizar una planificación bastante detallada ya sea para presentar un presupuesto a un cliente o si es una aplicación interna para estimar las fechas de entrega. También hay que tener en cuenta que este plan los vamos a tener que ir revisando Sprint a Sprint para adaptarnos a los cambios que nos encontremos por el camino.

Un buen recurso donde podemos aprender como planificar proyectos si utilizamos Scrum es el libro Agile Estimating and Planning, cubre todos los pasos necesarios para realizar la estimación, la planificación y el seguimiento de los proyectos.

El libro se divide en en siete partes:


Parte I: Realiza una introducción al propósito de la planificación y a la planificación ágil en particular.

Parte II: En esta parte se adentra en estimar el tamaño del trabajo a realizar. Nos proporciona dos medidas para calcular el tamaño, los puntos de historia y los días ideales.

Parte III: Una vez estimado el tamaño tenemos que priorizar las historias para saber en que orden se van a desarrollar.

Parte IV: Lo siguiente es decidir la longitud de las iteraciones y calcular la velocidad para calcular cuanto vamos a tardar en recorrer el tamaño estimado y en base a esto decidir las fechas de entrega. También nos explica a usar los buffers como herramienta para manejar la incertidumbre.

Parte V: Una vez comenzado el proyecto tenemos que realizar un seguimiento del proyecto comparándolo con lo planeado y adaptar el plan si fuera necesario.

Parte VI: Porque la planificación ágil funciona.

Parte VII: Un ejemplo practico donde se pone en acción todo lo visto anteriormente.

En definitiva un libro muy recomendable donde se expone de manera clara y practica todo lo necesario para poder planificar nuestros proyectos si utilizamos Scrum.

Scrum aplicado a la implantacion de ERPs

En uno los proyectos de gestión de la implantación de ERPs en los que estoy envuelto ahora estoy viviendo un pequeño infierno.Requerimientos que se tomaron hace escasamente tres semanas han sido cambiados por el cliente radicalmente, y más de una vez, desde el momento en que revisó el documento donde el implantador había documentado su análisis.
Lógicamente éste se ha rebotado y ya ha empezado a hablar de ampliaciones en el proyecto, algo que ha erizado el pelo de mi cliente. Nosotros en medio e intentando reconducir la situación... (sí ya se, otro proyecto que es igual)Y es que el proceso de toma de requerimientos, su transformación en un diseño/modelo para la configuración posterior del ERP en general está muy mal resuelto por monolítico y poco ágil.
Es muy complicado, por no decir imposible, clavar en un documento los requerimientos del cliente - siempre hay matices o situaciones y que se les acaban ocurriendo cuando acaban viendo el sistema en funcionamiento. Históricamente se han utilizado prototipos que aunque mejoran la situación no acaban de resolverla.Para romper este enfoque en cascada echo mucho de menos el poder aplicar en las implantaciones de ERPs una metodología como scrum, donde los requerimientos se van cerrando por el (y al) cliente a medida que el producto se va desarrollando y perfeccionando por el equipo.
Pero a ver quien convence a un cliente de que el proyecto de implantación de su ERP no tiene una planificación con un alcance cerrado y conocido de antemano, aunque esa planificación siempre se incumpla.Este es un tema, scrum aplicado a la implantación de sistemas de información, que me gustaría desarrollar en algún post.
Aqui te mostramos un video de lo complicado que se puede tornar la toma de requerimientos:

viernes, 6 de junio de 2008


DESARROLLO INNOVADOR CON SCRUM


SCRUM está en la línea de los módelos ágiles de gestión de los que ya hablé hace algunos meses. Algunas de sus principales asunciones son:
los productos y por tanto sus especificaciones están en constante evolución y en un entorno de incertidumbre,
lo que determina el éxito de un producto es incorporarle valor para sus usuarios,
la rápidez y la flexibilidad en la evolución de los productos son un valor diferenciador muy importante
SCRUM se está utilizando actualmente en empresas referentes de nuestro sector como
Google, y tanto para pequeños como para grandes proyectos.
El libro insiste en que ninguna metodología es la mejor para el 100% de los casos, sino que depende del proyecto, del producto, de la empresa, … En mi opinión, tampoco es necesario aplicar una metodología concreta 100%, sino que pueden aprovecharse las ventajas de cada una para determinadas tareas, por ejemplo,
estabilización de aplicaciones.
¿En qué puede traducirse esto en nuestro ámbito de trabajo? Pues, por ejemplo en:
Formación de equipos multidisciplinares, en los que intervengan los clientes, desarrolladores y usuarios
Especificación continúa y flexible
Solapamiento de fases del modelo en cascada
Generación de más versiones de producto, con menos delta de funcionalidad entre ellas, pero que vayan aportando un valor importante
Feed-back rápido de las funcionalidades que se van desarrollando por parte de los usuarios
Flexibilidad en la identificación de las prioridades a desarrollar en cada momento
Creación de equipos autogestionados y automotivados de profesionales brillantes
Para terminar, os incluyo un diagrama con el flujo de actividades típico que propone SCRUM. Creo que algunas ideas las vamos incorporando (como las reuniones de sprint, que corresponderían con reuniones de seguimiento).

FUNCIONA SCRUM


¿En Realidad Funciona?La premisa básica de scrum, y en gran medida de los métodos ágiles, es que si el colaborador está comprometido con el equipo de trabajo, y el jefe confía en ellos, entonces el equipo invierte el tiempo en producir algo, en lugar de estar justificando el avance o falta del mismo. Esto reduce la necesidad de reuniones y reportes de situación. Básicamente, se parece mucho a las tareas universitarias, en las que el profesor dice qué hay que hacer y cuando hay que entregarlo. Al principio, todos los involucrados, y en especial el equipo de trabajo, se sentirán extraños, pues no hay una estructura centralizada de control. Pero en el momento en que el equipo se organiza, la falta de control central se vuelve la principal ventaja del método.
Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aventurada, y existe un riesgo de toparse con límites reales, que puedan llegar a cancelar el proyecto. Una falla puede tener mucho impacto en los miembros del equipo de trabajo por los niveles de envolvimiento personal con el proyecto.
Lo Que No FuncionaA continuación comparto una lista de las trampas más comunes de una implementación primeriza de scrum en una organización con métodos tradicionales, y que en mi experiencia son señales claras de que no se está trabajando de acuerdo al principio inicial de scrum de autorregulación.• La junta scrum no es un reporte de avance. Los participantes del equipo deben ver la junta scrum como una oportunidad para resolver sus problemas inmediatos. Una clara señal de que las juntas no están funcionando como deberían es que los integrantes del equipo miran al dueño del scrum y le relatan sus actividades, como en un reporte de situación, en lugar de hablar entre ellos o solicitar la intervención del dueño del scrum en algún asunto relacionado con las áreas periféricas de la organización. • No se contemplan todas las actividades necesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entregable para el usuario final. Es muy común que en los primeros sprints se olviden algunas actividades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es normal, pero también es importante que se corrija el rumbo una vez detectado esto. Una actividad no puede considerarse completa sin estos productos adicionales. El dueño del scrum debiera desincentivar que un miembro del equipo cambie de actividad antes de terminarla por completo.• Interferir con el equipo de trabajo durante el scrum. Es muy tentador para el dueño del producto acercarse al equipo para solicitar un pequeño cambio. Y es también muy fácil para el equipo aceptarlo – al fin y al cabo, estamos siendo ágiles, ¿o no? El dueño del scrum debe combatir estas intervenciones para mantener al equipo centrado en entregar la funcionalidad en tiempo y en forma.
Referencias• www.controlchaos.com • Ken Schwaber. Agile Project Management with Scrum.




2004, Microsoft Press
SCRUM EN LAS EMPRESAS

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado?
¿Por qué acomodar la empresa a la "forma" del modelo?: Sea la forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos?
Scrum puede "implantarse" (forma) o "institucionalizarse" (fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto.
Poner un ScrumMaster en el departamento de programación de una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas... es una combinación peligrosa que suele producir empresas fragmentadas.
Más que aplicar una "forma" para el área de desarrollo se trata de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de "Scrum Manager" que de "Scrum Master".
¿Por qué no trabaja el departamento de marketing en un campo de scrum?. ¿Por qué los directivos de la empresa no tratan la estrategia de la organización en un campo de scrum?. ¿Por qué no es ágil toda la empresa?.
Las siguientes son las líneas directrices de esta visión de "gestión scrum" en cuyo desarrollo colaboro con Claudia (buena amiga y consultora de procesos de software) y que compartimos aquí con todos a los que os puedan resultar útiles.
El fondo de esta gestión scrum es la síntesis de conocimiento producida por la resolución dialéctica de las iniciativas de procesos (CMMI, ISO, PMI) y de agilidad. De ésta toma el modelo de Campo de Scrum como entorno para el desarrollo de los proyectos.No emplea prácticas de áreas de procesos o patrones ágiles de forma cerrada.Sobre la base de los entornos de trabajo definidos a finales de los 80 como Campos de Scrum, plantea principios que ayudan a la gestión para determinar la forma más apropiada a su organización y su proyecto.


http://www.navegapolis.net/content/view/613/

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.