Kanban: Definition of Lead Time and Cycle Time. March 2, 2010 at 12:58 pm When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way.
Here is a useful definition from the “Lean and Kanban” blog: Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team.
This whole period of time is the lead time. The lead time is the time and not the effort. Sometime you start working on the bug. Again the cycle time is not the effort. Desarrollo software de manera ágil de un vistazo. Webinar recording Filippo De Santis – Xkanban. Sistema KANBAN. Descargar Original En la actualidad, la necesidad de producir eficientemente sin causar trastornos ni retrasos en la entrega de un producto determinado es un factor de suma importancia para las empresas que desean permanecer activas en un mercado como el actual, que exige respuestas rápidas y cumplimientos en calidad, cantidad y tiempos de entrega.
Después de la segunda guerra mundial, Japón quedó con una economía desastrosa y con tecnología obsoleta. Sin embargo, y a pesar de todo eso, sus sistemas de producción sufrieron posteriormente un cambio de tal magnitud que revolucionó la economía a nivel mundial: la introducción de nuevas técnicas productivas que evitan el derroche y el despilfarro, juntamente con conceptos relacionados a la calidad, los cuales permitieron hacer de Japón uno de los países líderes en la fabricación industrial. Fue originalmente desarrollado por TOYOTA en la década de los 50 como una manera de manejo del flujo de materiales en una línea de ensamble.
Se define como: Www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf. Proyectalis - gestion de proyectos, metodologías ágiles, consultoria, formacion, project management. Proyectalis. Scrum y XP desde las trincheras. Kanban y Scrum. Authors@Google: Eric Ries "The Lean Startup" Planning Poker. Scrum Training Series: Free Scrum Master Training. eXtreme Programming y los métodos ágiles (2001) TEDxRainier - Joe Justice - WikiSpeed. INVEST in Good Stories, and SMART Tasks. (French) In XP, we think of requirements of coming in the form of user stories.
It would be easy to mistake the story card for the “whole story,” but Ron Jeffries points out that stories in XP have three components: Cards (their physical medium), Conversation (the discussion surrounding them), and Confirmation (tests that verify them). A pidgin language is a simplified language, usually used for trade, that allows people who can’t communicate in their native language to nonetheless work together. User stories act like this. We don’t expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively. But what are characteristics of a good story? Why I still use use cases. Agile Product Ownership in a Nutshell. Manifiesto por el Desarrollo Ágil de Software. EVENT: The Agile Manifesto 10th Anniversary Reunion. Hay peores cosas que quemar libros de Tecnología, una de ellas es no leerlos. Gestión de proyectos ágil...y las experiencias de más de 12 años de proyectos ágiles. - 233gradosdeti.com.
Cómo sobrevivir... A la planificación de un proyecto ágil - 233gradosdeti.com. Descarga el índice y el primer capítulo El libro consta de los siguientes capítulos, donde se tratan numerosos conceptos sobre la estimación y planificación de proyectos ágiles: 1.
Hoja de ruta del superviviente a una planificación software usando técnicas ágiles. 2. El Roadmap de un proyecto ágil. 2.1. 2.2. 2.3. 2.4. Acceleration: An Agile Productivity Measure (Agility@Scale: Strategies for Scaling Agile Software Development) Incremental versus iterative development. Javier Garzás. Metodologías ágiles: Los artículos mas destacados. Metodologías ágiles Esta página es una guía para orientarte en la lectura de los artículos más destacados de este blog sobre temas relacionados metodologías ágiles, Scrum, etc.
Artículos más destacados: - Mis 10 mejores libros ágiles - El método kanban para la gestión de proyectos - La historia de usuario, el “requisito” ágil - Lean Software Development - Claves para implantar el rol de Product Owner - De qué va eso de “equipo ágil auto-organizado - La agilidad está muriendo. Bienvenido el postagilismo - Ejemplos y buenas prácticas para descomponer historias de usuario en tareas Metodologías: - Las metodologías Crystal. Algunas claves de las metodologías ágiles: el ciclo de vida iterativo Sin duda una de las claves que un proyecto ágil es el uso de un ciclo de vida iterativo, a veces también incremental, frente al ciclo de vida en cascada. ¿CMMI o Métodos Ágiles?
6 jun, 2010 Enviado por Javier Garzás | 2 comentarios Desde hace tiempo se escucha, y lee, con frecuencia, en conversaciones, en proyectos, en algún correo que alguien envía con alguna duda, en alguna Web, blog, etc., la pregunta… ¿CMMI o Métodos Ágiles (SCRUM)?
O la respuesta en sus múltiples variantes: “la empresa tal utilizó CMMI y le funciona mejor que SCRUM”, o “SCRUM es nuestra metodología, CMMI no se adapta a nuestra organización”, etc. Por desgracia, parece haber calado en el día a día la percepción de que los métodos Ágiles y CMMI son polos opuestos. Can Scrum help to improve the project management process? A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. Una metodología para cada proyecto, o la escala de Cockburn. 28 jun, 2011 Enviado por Javier Garzás | 2 comentarios No existe una metodología de desarrollo software única, mejor y universal; existe una mejor metodología por tipo de proyecto.
Las variables clave a la hora de seleccionar una metodología son el tamaño del equipo, su distribución, la criticidad del proyecto y las prioridades. Las anteriores son las principales conclusiones de uno de los artículos más significativos en la historia de las metodologías, llamado la “Cockburn Scale”, en referencia a su autor. El artículo de Cockburn rompe con la antigua idea, que aún se mantiene en muchas empresas, de que existen metodologías de libro que se implantan directamente y por completo.
La figura de más abajo muestra como son necesarias diferentes metodologías en función de la criticidad, el tamaño del equipo y la optimización. Desarrollo ágil o tradicional: ¿existe el punto intermedio? 15 ago, 2010 Enviado por Javier Garzás | 5 comentarios Un muy interesante artículo en Computer me volvió a recordar como desde hace ya tiempo se observa en el día a día que cuando las organizaciones se plantean implantar un método ágil, y estudian en detalle la idoneidad para su organización, con sus clientes y tipo de proyectos, raramente implantan el método ágil al 100%, y lo que hacen son adaptaciones al mismo, muchas veces incorporándole prácticas formales, como, por ejemplo, el robustecer y hacer menos iterativa la fase de diseño de la arquitectura software.
Está bastante aceptado, y documentado, que el desarrollo ágil es más idóneo en proyectos con cambios considerables, y que para proyectos estables se obtiene más beneficio de realizar diseños más rigurosos y desarrollos “upfront”. De mezclar culturas organizacionales flexibles o rígidas con proyectos cambiantes o estables están apareciendo cuatro métodos de desarrollo. Scrum para Dummies (1/2). Las ideas de Scrum en 2 post de 5 min. 23 may, 2012 Enviado por Javier Garzás | 0 comentarios Scrum para Dummies (1/2).
Las ideas de Scrum en 2 post de 5 min. En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done) 17 ene, 2014 Enviado por Javier Garzás | 1 comentario En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done) Por lo general, la gente que empieza a implantar agilidad, o los que lo han intentado pero no con mucho éxito, suelen tener en común el pasar por alto un grupo de aspectos que son de los más importantes: los que definen las relaciones y compromisos entre los diferentes roles que participan en el desarrollo software.
Estimación software: una breve guia. 2 jun, 2011 Enviado por Javier Garzás | 4 comentarios No es la primera vez que sale por aquí el tema de la estimación software, una de las áreas menos madura en las organizaciones de desarrollo, como comentábamos hace tiempo revisando datos reales de proyectos software; por ello esta serie de post sobre “una breve introducción a la estimación software”. The New Methodology.
In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation. Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto. 18 jun, 2012 Enviado por Javier Garzás | 15 comentarios Hace unos meses, en una de esas asesorías que de vez en cuando me piden sobre qué pasa en un proyecto software en crisis.
Ocurrió entonces una de esas reuniones de proyecto en las que los participantes tienen, y muestran, decenas de diagramas Gantt, esos de Microsoft Project, con decenas de barras azules horizontales, flechas de dependencias, porcentajes de avance dentro de las barras, porcentajes de uso de recursos, columnas de fechas de inicio, fin, real, etc. Siempre que en una reunión salen estos diagramas, diagramas que, algunos, por su tamaño, son impresos en varios folios pegados con celofán, tengo la sensación de que la mente de los participantes se traslada a otro plano astral, en el que la única preocupación es cuadrar barras, flechas y recursos, en un espacio temporal… donde dichos pronósticos la mayoría de las veces no se cumplirán.
He de confesar que años atrás fui un gran usuario y creyente en dichos diagramas. 7 responsabilidades vitales de un product owner. 26 mar, 2013 Enviado por Javier Garzás | 2 comentarios Un product owner, normalmente, es uno de los futuros usuarios del sistema. O alguien de marketing, o un “product manager” o, en definitiva, alguien que sabe lo que quieren los usuarios del sistema en desarrollo. Te recomiendo leer antes de seguir aquel post de claves para implantar el rol de product owner. Product Owner. 28 jun, 2012 Enviado por Javier Garzás | 3 comentarios Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo ágil (1/2) “El rol del product owner es una función nueva y disruptiva para la mayoría de las organizaciones, y por ello no es fácil de cubrir con otros roles y estructuras existentes.” (Roman Pichler) El “product owner” (o propietario del producto, aunque utilizaré las palabras en inglés por ser de mayor uso) es aquella persona con una visión muy clara del software que se quiere desarrollar, que es capaz de transmitir esa visión al equipo de desarrollo y que, además, está altamente disponible para transmitir esa visión.
Procesos software: Modelos y certificación (CMMI, ISO 15504, etc.) Esta página es una guía para orientarte en la lectura de los artículos más destacados de este blog sobre temas relacionados con procesos software, certificación de la calidad software, CMMI e ISO 15504. Más abajo, la he dividido en tres secciones: una que trata sobreel modelo de procesos software CMMI, otra sobre ISO 15504 y la última sobre la certificación de la calidad software. Lo básico sobre procesos software y certificación de la calidad software. Cómo descomponer historias de usuario en tareas (parte 1) 3 may, 2012 Enviado por Javier Garzás | 0 comentarios Aun incluso después de leer el User Stories Applied de Cohen, parece que el tema de cómo, en un proyecto ágil, descomponer historias de usuario en tareas (te recomiendo aquí este post sobre historias de usuario) para muchos no queda del todo claro. Y este es uno de esos problemas que siempre salen cuando llega el momento de trabajar con historias de usuario: la descomposición en tareas.
Para aclarar este tema, en el libro sobre gestión ágil de proyectos que estamos escribiendo, introducimos un conjunto de ejemplos y buenas prácticas que se recomiendan aplicar a la hora de descomponer historias de usuario en tareas. Entrevista a Jeff Sutherland (Co-creador de Scrum) 29 ene, 2014 Enviado por Javier Garzás | 1 comentario (Enlace a la entrevista en inglés) Jeff Sutherland es uno de los creadores del Manifiesto Ágil, de Scrum y la guía de Scrum y autor de “Software in 30 Days” entre otras muchas cosas.
Entrevista en el blog: Alistair Cockburn. Entrevista en el blog: Robert C. Martin (Uncle Bob) Veterano ciclo de vida iterativo e incremental. 10 ene, 2010 Enviado por Javier Garzás | 4 comentarios El motivo de este post viene a raíz de una reunión en la que se debatía el mejor ciclo de vida para un proyecto, y en la que alguien dijo: “el ciclo de vida iterativo e incremental es un riesgo ya que es algo nuevo, y no hay mucha experiencia”. Y como esto de que “el ciclo de vida iterativo e incremental es nuevo” ya lo había escuchado muchas veces, me dije, voy a dejar en el blog testimonio escrito de la “longevidad” de dicho ciclo de vida, así hago mi pequeña contribución en google a evitar que quieran seguir haciéndole “liftings”.
Veterano ciclo de vida iterativo e incremental. Los peores bugs de la historia. ¿Cuántos proyectos fallan? Velneo. Javier Garzás. Minutos Ágiles (10): Predictivo vs Adaptativo. Minutos Ágiles (1): Ciclo de vida en cascada, iterativo y ágil.