Inicio arrow Artículos - apuntes Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Artículos y apuntes de formación


De dónde viene esto de lean y kanban
articulos
01.03.2012

 

Este artículo está publicado en el nuevo dominio de Navegápolis (.com)

Ésta es su nueva dirección

 
Así era la primera implementación de Scrum para software
articulos
26.12.2010

Scrum_4_software_originalScrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, que trabajan con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Esta forma de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando cómo trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos("New New Product Development Game"): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de la implementación de Scrum para software que él empleaba en el desarrollo de Delphi.

Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones...) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o "Epics" de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban...

Para tener una visión de retrospectiva, este es el "paper" de Ken Schwber presentado en 1995 su implementación de Scrum en OOPSLA: "SCRUM Development Process " y este otro su artículo del mismo año "Living on the Edge" en el que describía su implementación de Scrum para Software.

Como adelanto, esta sería la traducción de la "metodología" y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.


Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-

Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte  orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior  de sistemas heredados.
…..

FASES DE SCRUM

SCRUM comprende las siguientes fases:

1.- Pre-juego

Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.

2.- Juego

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

3.- Post-juego

Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión.

Scrum_1996

Pasos de cada fase

[...]

 
Gestión Visual Kanban
articulos
07.11.2010

gestion visualGestión Visual

En una calle la organización es compleja: circulación de coches, peatones, zonas de aparcamiento, carriles para autobuses, etc. pero la señalética nos indica todo. Estamos acostumbrados a la "gestión visual."

La industria de la automoción es posiblemente la primera que incorporó la "gestión visual" en el propio escenario de producción: todo está a la vista, la identificación de los sectores, los productos son reconocibles y están etiquetados indicando su fase dentro del proceso de la cadena.
En todo momento se sabe qué se está produciendo. La información está en el mismo entorno de trabajo, visible, expresada con simplicidad, y no en ordenadores o libros de registro de procesos.

Gestion Visual

Kanban

 Kanban es una técnica de control visual. Es un sistema de señalización para desencadenar acciones.
 

 
Construyendo un laberinto de nombres para perdernos.
articulos
22.08.2010

En los 80 se nos decía: Brujula"Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo?. Empezáis sin tener ni una página de requisitos, ni un análisis y una planificación de los trabajos, y sus tiempos. ¿Os imagináis que un arquitecto hiciera lo mismo?".

Gestión predictiva y producción basada en procesos

Aprendimos a hacer requisitos del sistema, especificaciones de requitisos del software, planes de proyecto, gestión de riesgos, matrices de trazabilidad. Y desde entonces nuestros clientes no pueden darnos planes de productos estables y nos piden re-inventar sus productos de forma continua.

 
Scrum Management: adopción flexible de la agilidad, que implica a toda la organización.
articulos
08.07.2009

mapaEs frecuente apostar por un camino profesional: PMI, Scrum, Lean, CMMI... por ser el que las circunstancias nos han puesto delante como solución, y tirar así por él sin conocer cuál es su trayectoria en un mapa de situación general. De dónde viene y a dónde va; y sobre todo hacia dónde queremos ir por el tipo de empresa y proyectos  en los que trabajamos.

Hace un rato comentaba Angel: "... aún hay un gran desconocimiento sobre metodologías ágiles en entornos que podríamos llamar "tradicionales". Ocurre lo mismo con los que llevan años trabajando con Scrum u otras metodologías ágiles.."

Aunque las clases y los apuntes de introducción son menos amenos que los que entran directamente en harina mostrando cómo estimar un backlog, componer una pizarra kanban, etc.  he pasado a post los apuntes del que consideré curso necesario de introducción en la plataforma Scrum Manager, antes de tratar historias de usuario, reuniones, gráficos burn-down, etc. para partir desde el marco de situación de la agilidad, y desde la conveniencia de considerarla de forma global y flexible.
Para acostumbrarnos desde el principio a ser los artífices de nuestro marco de trabajo, y los que seleccionamos, adaptamos o diseñamos los procedimientos trabajamos.

Mapa de situación.

 
La lista definitiva de modelos y buenas prácticas para proyectos de software
articulos
29.10.2008

numerosEscribir "lista definitiva", de "buenas prácticas...", y más, en un blog, puede sonar como los "requisitos definitivos" de un proyecto ágil: ¿Estos son? ¿No van a cambiar?

Este artículo es un backlog, o pila, si empleamos en nuestro idioma: una lista en continuo cambio, para ir completando y mejorando entre todos, vuelta tras vuelta.

CRITERIO DE CLASIFICACIÓN

Prácticas

Dicen "CÓMO" hacer las cosas: cómo describir y gestionar los requisitos (historias de usuario, elementos de backlog...), cómo estimarlos, cómo realizar las reuniones para validar con el cliente, cómo realizar el mantenimiento del código, las pruebas, la integración...

 

 
Prácticas ágiles de estimación y planificación
articulos
01.06.2008

metroEste artículo explica tres prácticas ágiles de estimación y planificación:

  • El gráfico burn-up o gráfico de producto, para mostrar en un vistazo el plan general de desarrollo del producto. A partir de la velocidad del equipo y las estimaciones previstas en la pila del producto, representa las fechas o sprints en los que se irá terminando cada versión.
  • El gráfico burn-down o gráfico de avance, para monitorizar el ritmo de trabajo del sprint.
  • La estimación de póker, para conducir reuniones con estimación de tareas por juicio de expertos: en su concepción original y para estimación sobre sucesiónd e Fibonacci.

Es un texto del curso de métricas ágiles de Open Knowledge de ScrumManager.

Safe Creative #0806010707492

 
Midiendo velocidad, trabajo y tiempo en gestión ágil
articulos
07.05.2008

tiempoVelocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil. Las tres componen la fórmula de la velocidad, definiéndola  como cantidad de trabajo realizada en por unidad de tiempo.

Velocidad = Trabajo / Tiempo
Tiempo
En las métricas ágiles el tiempo se puede considerar de dos formas diferentes: como real o como ideal.
Ambas son válidas, y cada organización opta por la que considera más adecuada para ella.
Sea cual sea criterio, éste debe mantenerse de forma homogénea en todas las métricas y estimaciones.
 
Agilidad Kanban
articulos
25.02.2008

tiempoSegún el producto, o incluso el momento de evolución en el que está, puede resultar más dinamizador para el equipo cambiar como criterio base de "time box" el sprint backlog, por el de "mínima funcionalidad integrable".
Gestionar estas "MFI" al estilo que el modelo de Producción de Toyota consideraría cada unidad Kanban.

Tiene la ventaja de seguir lo más cerca posible las prioridades del cliente. La versión del Just in Time de la programación. También tiene el riesgo de que el equipo pierda la visión general del producto, y el concepto de "objetivo del sprint". Para evitarlo se deben mantener tres niveles de zoom de los requisitos del proyecto: funcionalildades de producto, de versión y tareas; y es muy útil trabajar con pizarras Kanban:

 
IFM: Cómo orientar la gestión del proyecto al retorno de la inversión
articulos
31.01.2008

ifmLa gestión ágil entrega de forma periódica y continua pequeñas partes del sistema completamente terminadas y operativas, por eso el cliente (propietario del producto, en terminología Scrum), decide qué le corre más prisa, según las necesidades de su negocio, y por tanto qué partes se deben programar antes; vamos, lo que Scrum llama "priorización del product backlog".

Pues bien, un criterio interesante para "priorizar el product backlog" puede ser obtener el mayor ROI posible, y cuanto antes. ¿A que sí? :-)

Si el desarrollo ágil puede entregar partes del sistema de forma temprana, merece la pena estudiar si también es posible comenzar el retorno de la inversión de forma anticipada.

 

 
Prototipos de papel para análisis de requisitos y usabilidad ágiles
articulos
05.01.2008

barquitoCuando el cliente no termina de tener claros algunos puntos o cuando la usabilidad es un valor clave del sistema, el prototipado en papel es una excelente técnica de trabajo; y como estos son factores habituales en los proyectos ágiles, es muy útil disponer en el inventario de recursos esta forma de prototipado ligero para echar mano de ella cuando se necesite.

 

 
9 Bloques: rutina para obtener requisitos con Scrum
articulos
18.12.2007

9 bloques"La parte más difícil en la construcción de sistemas de software es decidir precisamente qué construir" (Frederick P. Brooks Jr.)

El 60% de los problemas de los proyectos tienen su origen, directa o indirectamente en los requisitos; y los problemas de los requisitos surgen por alguna de estas razones:

1.- El cliente no tiene una visión clara de lo que quiere.
2.- El suministrador obtiene los requisitos superficialmente, quizá siguiendo un proceso, pero sin "sumergirse" en conocer el negocio del cliente y realizar desde ahí el análisis.
3.- Implicación y comunicación cliente-equipo de desarrollo. 

 

 
¿Qué tal resultará la implantación de una metodología ágil?
articulos
05.11.2007

exitoEsta podría ser una lista de comprobación con los principales factores que condicionan los resultados de la gestíón ágil de proyectos. Desde luego tenerlos todos es complicado, pero ¿quién dijo que la gestión ágil fuera fácil? Smile

ADQUISICIÓN

  • El propietario del producto tiene definida la visión de lo que necesita.
  • El propietario del producto está comprometido y se implica con el equipo.
  • El propietario del producto conoce los principios del desarrollo ágil.
  • De forma previa, o incluido en el primer sprint, se realiza un análisis de adquisición.
  • El modelo de adquisición del cliente permite un patrón de desarrollo ágil
  • La prioridad para el negocio del cliente es el valor innovador, por encima del plan de un producto cerrado.
 
El "Gantt" ágil
articulos
27.09.2007

graficoEn la gestión predictiva, la "bola de cristal" con visión global de proyecto es el diagrama de Gantt. ¿Y en la gestión ágil?.
El modelo ortodoxo de Scrum trabaja con el Gráfico Burn-Down, pero es una bola de cristal que alumbra con "cortas": sólo al sprint actual.  Para vaticinar el proyecto "con largas", apuntando más lejos en la dirección de la visión del cliente, es muy útil el gráfico Burn-Up.
 

 
Lo mejor de CMMI y Scrum
articulos
19.09.2007

columnasLa tesis (ISO 12207, 15504, CMMI…) ha identificado y definido las cosas QUE hay que hacer.
La antítesis (XP, Scrum, FDD...) ha mostrado formas de trabajar que funcionan bien: CÓMO hacer determinados "qués".
Posiblemente la síntesis , la moraleja de ambos sea cuestionar los "POR QUÉs"

¿Qué hacer para que los proyectos de software salgan bien?

 

 
<< Inicio < Anterior 1 2 3 4 Siguiente > Fin >>

Resultados 1 - 15 de 52
Advertisement





Artículos relacionados

Registrado en Safe Creative