Pensamiento Centroamericano

El taller numero 1 del curso gestión de proyectos con SCRUM consistía en  crear una planificación estratégica del proyecto. En gestión de proyectos tradicional,es posiblemente el  Project Manager el encargado de crearla para tener un rumbo hacia donde quiere llegar y que todos los interesados también conozcan la finalidad. En SCRUM debe ser el Product Owner quien tenga la visión total del proyecto y la planificación es una herramienta para transmitirla a los interesados. Al realizarla se tienen que tener en cuenta algunos aspectos, entre ellos puedo mencionar: La visión debe transmitir de forma breve la finalidad esperada del proyecto cual sera el producto o servicio único que crearemos.  La misión debe expresar como lo haremos Los objetivos especifican cada uno de los elementos o metas intermedias que debemos lograr para alcanzar nuestro objetivo principal. No debemos confundir la planificación estratégica del proyecto con la planificación estratégica de la empresa

El día 24 de junio de 2015, durante el desarrollo del curso libre: Gestión de proyectos con SCRUM, surgió la duda de que relación (o como podemos relacionarlos) tiene el modelo CANVAS con SCRUM. A continuación tratare de responder luego de documentarme acerca del contenido. 1. Al inicio del curso definimos que un proyecto es finito, tiene un inicio y un fin, mientras que la administración de la empresa  es por decirlo así infinita, de modo que tendrá una interrupción solamente si se tiene que finalizar las operaciones del negocio. 2. El modelo CANVAS, es una metodología que nos proporciona una plantilla para desarrollar el modelo de negocios de la empresa o documentar el modelo de negocio de una empresa existente (se relaciona con la operación completa de la empresa) 3. SCRUM es una metodología de gestión de proyectos 4. Entonces como se relaciona CANVAS con SCRUM     ¿Puedo crear mi modelo CANVAS con SCRUM?            Si, se puede definir un proye

En términos generales, se trata de una guía de Sprints necesarios para completar el proyecto y como serán lanzados es creada durante la planificación de lanzamientos y nos muestra una expectativa de de que y cuando serán completados requerimientos. También nos sirve para monitorear el progreso de avance ya que por medio de esta se puede crear la linea base. Los lanzamientos pueden ser entregables a mitad del proyecto o un entregable final. Para crear el plan de lanzamientos se deben tener disponibles: 1. Una backlog priorizada 2. La velocidad del equipo (estimada) 3. Condiciones de satisfacción Dependiendo del tipo de proyecto, si es por característica o por fecha se puede realizar el plan de dos maneras distintas. Si el proyecto es por característica se puede dividir los puntos de esfuerzo de todas las caracteristicas necesitadas entre la velocidad estimada del equipo para obtener el numero de Sprints necesarios para completar la funcionalidad. Si el proyecto es conduc

Para coordinar diferentes equipos Scrum se utilizan las reuniones "Scrum de Scrum". La cual es muy similar a la Scrum Daily Meeting pero esta con un enfoque en multinivel. La reunión tiene lugar todos los días y no debe durar mas de 15 minutos por ejemplo. En esta cada equipo envía un representante el cual debe responder a las preguntas. 1. Qué ha completado el equipo desde la ultima reunión? 2. Que completara hasta la siguiente reunión? 3. Que impedimentos tiene para lograrlo? Las respuestas deberían estar enfocadas en elementos que impacten a otros equipos. El Product Owner jefe es quien modera la reunión, en general no solo debería ser el Scrum Master quien  participe en las reuniones sino alguien diferente del equipo podría ir cambiando diariamente. Sprint Review Común Podrían también realizarse pequeñas Sprint Review multiequipos en la cual se muestre a todos que se realizó durante el Sprint y cual es el status general del proyecto. Sprint Retrospective Co

Scrum funciona de mejor manera cuando es aplicado por un equipo en una sola localidad, pero en la realidad es muy común que un solo equipo no pueda completar un gran proyecto o que los recursos estén repartidos en diferentes localidades y como consecuencia de ello los equipos deben ser aumentados o bien distribuidos. Las razones por ejemplo pueden ser técnicas, que no existan expertos en algún tema, relacionadas con el tamaño del proyecto, que este sea muy grande, o relacionadas con el negocio, aprovechando diferentes zonas horarias para mantener la productividad. La comunicación es parte importante del marco Scrum, y en especial se debe tener un especial cuidado con esta cuando se trata del reto de trabajar con proyectos en ambientes distribuidos y todos los miembros deberían tener acceso a las apropiadas herramientas de comunicación  como videoconferencia o web cams. Para romper las mas comunes barreras de comunicación. Es importante asegurarse que el numero de equipos Scrum no

Después del Sprint Review Meeting el Scrum Team y el Scrum Master se reúnen para hacer una retrospección del Sprint en esta se reflexiona sobre el pasado Sprint y se verifican tres cosas . 1. Que se hizo bien durante el Sprint 2. Que no se hizo bien. 3. Que puede mejorar El tiempo es limitado por ejemplo tres horas. La Sprint retrospective es parte del proceso de inspección y adaptación del proceso , sin esta reunión el equipo no será capaz de mejorar sus procesos y enfocarse en la mejora continua, al final de la reunión se tendrán sugerencias prácticas para mejorar.

Al final de cada Sprint se tiene una Sprint Review Meeting, durante esta se exponen los elementos de la Scrum Product Backlog fueron completados a corde a la definición de listo durante  el Sprint y puede realizarse un demo de la funcionalidad. Se debe agregar que los items de la Scrum Product Backlog no se consideran completos si no se han demostrado, si existen inconvenientes en la demostración los ítems deben ser abordados en la siguiente iteración. Esta reunión puede mantenerse informal no se precisan diapositivas power point y el tiempo de preparación para la misma es limitado, durante esta reunión el product owner inspecciona las entradas del backlog y las acepta o agrega nuevas historias de usuario para adaptar la funcionalidad. Los participantes típicamente son el Scrum Owner, Scrum Master, el Scrum Team y adicionalmente stakeholders, gerentes, desarrolladores de otros proyectos.

Es una corta reunión diaria, idealmente realizada al inicio del día de trabajo. Cada miembro que trabaja hacia el completar el actual sprint debe participar. Durante esta reunión se da respuesta a las siguientes preguntas: 1. ¿Que se ha completado desde la reunión anterior? 2. ¿Que se completara hasta la siguiente reunión? 3. ¿Que impedimentos existen para concluir las tareas? Todos los miembros del equipo deberían estar y soportar la reunión. La reunión no debería durar mas de quince minutos. Los problemas y preocupaciones surgidos durante la reunión deben ser apuntados y atendidos por el Scrum master luego de la reunión.

El reporte Sprint burndown muestra el progreso del sprint hacia el logro de la meta. Provee transparencia sobre el rendimiento actual (tasa de avance). Permite una fácil estimación si el Sprint se logrará en tiempo  o si se deben encontrar medidas adicionales, para acelerar el completar las actividades remanentes. El Sprint Backlog inicial define el punto de inicio de los esfuerzos. El esfuerzo remanente  de todas las actividades son recolectadas a diario y añadidos a la gráfica. Al inicio el rendimiento no es tan bueno como  se predijo debido a estimaciones incorrectas o impedimentos que deben ser removidos antes de lograr el máximo de velocidad.

La definición de listo es utilizada, para decidir cuando una entrada en la Product Backlog esta completa, la definición de listo no es mas que un listado comprensible de actividades que aseguran que solamente las características realmente completada sean lanzadas, no solo en términos de funcionalidad sino también en términos de calidad. La definición de listo puede variar de un equipo Scrum a otro pero en un solo equipo debe ser consiste en un mismo equipo. Existen distintos niveles para la DoD 1.  Para un ítem en la Scrum Product Backlog 2.  Para un Sprint 3.  Para un lanzamiento

Es una herramienta visual de medida que muestra el trabajo completado por día, en contra de la estimación proyectada para completar el siguiente lanzamiento.  Su propósito es comprobar que el proyecto va en camino de entregar la solución esperada en las actividades programadas. La medida de progreso en Scrum es llamada Velocidad. y es expresada por ejemplo en puntos de esfuerzo completados por iteración. Un punto importante al calcular la velocidad es que solo se deben incluir historias de usuario completadas. Historias parcialmente completadas parcialmente no se incluyen. Después de unas pocas iteraciones la velocidad del equipo es predecible y se pueden realizar estimaciones mas precisas para completar una entrada en la product backlog. En la realidad los ítems en la Product Backlog son cambiantes, algunos son actualizados otros son añadidos y otros eliminados en la Burdown Down Chart normal esto no se refleja pero para ello existe otro diagrama que puede ser utilizado V

En SCRUM, todas las actividades necesarias para la implementación de alguna entrada en product backlog son realizadas mediante Sprints o también llamadas iteraciones. Los Sprint duran de 2-4 semanas. Los Sprint en general siguen el siguiente proceso. Los Sprint, inician con dos sesiones, la sesión del Que? y la sesión del  Como?  la combinación de ambas sesiones se conoce como la Sprint Planning Meeting, en la sesión del Que? el equipo elige las entradas del Product Backlog que se implementaran durante el Sprint. En la sesion del Como? el equipo parte las historias de usuario en pequeñas y especificas tareas, entonces se puede iniciar con el Sprint. Al finaliza el Sprint se realiza la Sprint Review Meeting, la cual es una reunión conducida hecha por el Product Owner, en esta reunión se define si los items de la product backlog fueron implementados completamente y de forma correcta. Adicionalmente el Scrum Master hace y conduce la Sprint Retrospective Meeting en la cual se revis

Todas las entradas en el Scrum Product Backlog deben estar estimadas para permitir al Product Owner priorizarlas y crear el plan de lanzamiento.  Esto significa que el Product Owner necesita una valoración honesta de cuan dificil puede resultar el trabajo. Es recomendado que el Product Owner no asista a la estimación de esfuerzo para quitar presión en el Scrum Team. La metodología SCRUM no defina una especifica forma de medir el trabajo pero usualmente se realiza en forma de esfuerzo, este esfuerzo suele representarse en distintas formas como elementos del 1 al 10, tallas de playeras S, M, L, XL, XXL. o la serie de fibonacci. Es importante que todos los miembros del equipo tengan un entendimiento generalizado de las métricas y que todos se sientan cómodos con el. Scrum Planning Poker El método mas utilizado para la estimación de esfuerzo es el planning poker con este la influencia entre participantes es minimizada y se mejora la precision de la estimación. para realizar el plan

Los ítems en el scrum product backlog usualmente se escriben en forma de historias de usuario. Una historia de usuario es una pequeña historia de como un usuario utiliza el producto. Contiene un nombre una narrativa, criterio de aceptación y condiciones para que la historia este completa. La ventaja de utilizar historias de usuario es que se centra en lo que exactamente el usuario necesita o quiere sin entrar en detalle de su implementación. Existen diferentes recomendaciones acerca de como definirlas. Una plantilla puede ser la siguiente Como quiero para   Actor: el dueño de la historia de usuario; usualmente se coloca usuario pero se recomienda ser mas especifico. por ejemplo, administrador de sistema, supervisor, etc. Con esto se logra entender mejor la historia en su contexto. Descripción Narrativa: lo que el actor quiere hacer Meta: lo que el actor desea lograr realizando la accion

La definición mas simple de la Scrum Product Backlog es una lista de cosas que se necesita que esten listas para el proyecto. Esta reemplaza los artefactos tradicionales de especificación de requerimientos. Estos elementos puede ser de naturaleza tecnica  o pueden ser usuario-centricos por ejemplo en forma de historias de usuarios. El propietario de la Scrum Product Backlog  es el Scrum Product Owner .  El Scrum Master y otros interesados contribuirán con ella para ampliar y completar el To-Do list. Trabajar con luna Scrum Product Backlog no significa que el Scrum Team  no pueda crear y usar otro(s) artefactos. Por ejemplo en artefactos adicionales  puede ser un resumen de varios roles de usuario,  descripciones de flujo, guías de usuario de interfaz,  storyboards, o prototipos. Sin embargo  esos artegacons no reemplazan  la Scrum Product Backlog  pero complementan del detalle de su contenido. El Scrum Product Owner  usa el Scrum Product Backlog durante el Sprint Planning Meeting p

En un proyecto normal un product manager define los requerimientos, la realización es delegada al Project Manager y el coordina las actividades necesarias para la realización del proyecto. El marco de Scrum no define a un "project manager" en el sentido clasico sin embargo estas actividades definitivamente son requeridas. Por lo que el marco de Scrum divide  las responsabilidades  de un project manager en los roles de Scrum Product Owner y Scrum Master. La definición del rol y responsabilidades del Scrum Master toma en cuenta que las decisiones acerca de funcionalidad, plan de lanzamiento y costos pueden realizarse mucho mas fácil y mejor  si una persona es responsable del contenido y de la planeación. De otra manera se crea tension entre el Scrum Product Owner (no responsable del proyecto) y el project manager (no responsable por el contenido).  si esas responsabilidades  son combinadas todo sera mucho mas fácil. No olvides  que el Scrum Master toma algunas de las resp

El Scrum Product Owner es un rol central en la metodología Scrum. La mayoria  de las responsabilidades del un clásico product manager y de un project manager  están combinadas en este único rol. El representa al usuario final y/o  algún otro interesado  y sus responsabilidad  es maximizar el valor del producto asegurándose que el trabajo correcto este hecho en el tiempo correcto. Como consecuencia esto significa obviamente que el Scrum Product Owner  tiene que trabajar muy cerca del Scrum Team  y coordinar sus actividades durante toda la vida del proyecto.  A ningún otro se debería permitir decir al equipo sobre las prioridades. El Scrum Product Owner tiene las siguientes responsabilidades. Administrar la Scrum Product Backlog Administrar la forma de liberación de funcionalidad Administración de interesados Trabajar de cerca con el Scrum Team El scrum Product Owner puede delegar ciertas actividades (por ejemplo el mantenimiento fisico del Scrum Product Backlog), pero al

En términos generales  el trabajo del Scrum Master  es asegurarse que el Scrum Team  se adhiera la la teoría de Scrum , practicas y reglas. El Scrum Master es parte del Scrum team y actúa como un líder-sirviente  para el equipo. Al inicio este sera un trabajo de tiempo completo por lo que no contribuirá directamente  a los resultados del Sprint. Sin embargo  después de algunos Sprints  el proceso estará resuelto  por lo que la carga de trabajo  para el Scrum Master debería caer y entonces el podría contribuir  activamente  al resultado del Sprint. Ya que es crucial que haya confianza entre el Scrum Master y los otros miembros del equipo  podría ser ideal  si el Scrum Master reclutara el equipo por si mismo, sin embargo en la realidad es mas frecuente que la gerencia  seleccione el Scrum Master. Para obtener la confianza requerida  el Scrum Master no debería tener la responsabilidad de la linea de mando sobre algún miembro del equipo.  En caso contrario  la necesaria comunicación ab

La metodología SCRUM cambia las restricciones de la gestión de proyectos tradicional. La gestión tradicional de proyecto se basa en tres aspectos 1. La Calidad 2. Tiempo 3. Presupuesto La gestión de proyectos con SCRUM se centra en 1.  Funcionalidad 2.  Presupuesto  3.  Tiempo Esto no quiere decir que elementos como la calidad o la documentación no sean tomados en cuenta por la metodología, simplemente están implícitos en la definición de listo, la cual se define desde el inicio del proyecto. La funcionalidad  incompleta o no comprendida totalmente debe ser redefinida por el cliente, ahora bien la funcionalidad a implementar sera definida a través o en el curso  del proyecto e implementada de manera incremental. El desarrollo incremental permite manejar el cambio y la flexibilidad de manera controlada sin incurrir en costos adicionales, y riesgo de poner en peligro secciones grandes del trabajo previo, al final de cada iteración llamada "s

Estudios han revelado que el 80% de los proyectos de software no se concluyen efectivamente o no se satisfacen las necesidades, las metodología de cascada es uno de los  factores clave para que esto ocurra  por que?. Las fases tradicionales en un modelo de cascada consisten en un analisis de requerimientos, un diseño, un desarrollo y fase de pruebas y el lanzamiento o puesta en producción. Como se muestra la metodología consiste en una estricta cadena secuencial de fases, se necesita concluir una fase para continuar con la siguiente, esto es difícil, costoso y frustrante para el equipo ademas de consumir demasiado tiempo. La linea de tiempo es planificada al inicio del proyecto y se obtiene un entregable funcional únicamente al finalizar la cadena, esto quiere decir que si se retrasa una fase todo el proyecto se retrasa. Con el método de cascada los usuario de este, deben evitar el riesgo tratando de anticipar de antemano todas las posibilidades.  Esto quiere decir que en una

Scrum es un marco liviano de gestión de proyectos, es un acercamiento iterativo e incremental en el desarrollo del trabajo. Usado mayormente para el desarrollo de proyectos de software. Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986) En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a ella. (wikipedia) https://hbr.org/1986/01/the-new-new-product-development-game/ar/1 https://hbr.org/2011/05/the-big-idea-the-wise-leader Puede ser utilizado en cualquier tipo de desarrollo de software, desde paquetes comple