métrica

Saludos Rebeldes Ágiles, Para ver el vídeo completo da click aquí: https://www.linkedin.com/posts/jgarzas_agilidad-bdd-hdd-activity-7178798486358802434-ZK5i?utm_source=share&utm_medium=member_desktop Hoy os traigo en vídeo un extracto de mi último libro, disponible en gestionagildeproductos.com Tradicionalmente, las historias de usuario se han escrito masivamente con el triste formato de "Como usuario quiero...", pero hay más maneras de hacerlo. Vamos con tres alternativas interesantes: 1. BDD (Behavior Driven Development) - In order to (con el fin de): Identificar el objetivo o el beneficio esperado. - As a (como un): Definir el rol del usuario o del sistema. - I want (quiero): Describir la acción o la característica deseada. Este enfoque nos ayuda a centrarnos más en el comportamiento y el resultado esperado de las funcionalidades. OJO existe un “branch” aquí en este formato y eso usar Gherkin. 2. HDD (Hypothesis Driven Development) - Creemos que [hipótesis]: Establecer una suposición basada en nuestra comprensión del usuario o del mercado. - Obtendrá como resultado [lo que esperamos]: Predecir el efecto de nuestra hipótesis. - Tendremos confirmación de ello cuando [métrica de confirmación]: Definir cómo vamos a medir si nuestra hipótesis era correcta o no. HDD nos empuja a pensar en experimentos y a validar nuestras ideas antes de comprometernos a construir funcionalidades completas, reduciendo el riesgo y fomentando la innovación. 3. Job stories, explicado con un ejemplo… - CUANDO un cliente necesita comprar medicamentos y productos de salud de manera conveniente - QUIERO poder buscar, seleccionar y adquirir los artículos que necesito en línea - PARA recibir los productos de manera rápida y eficiente Más consejos en gestionagildeproductos.com y prácticas en la newsletter "This is the Agile Way", que se envía todos los jueves. Si aún no estás suscrito, puedes hacerlo en [thisistheagileway.com. Que la Agilidad te acompañe, #Agilidad #BDD #HDD #JobStories #GestiónDeProductos #productowner

Seguro que alguna vez has querido sacar alguna métrica muy concreta sobre tu equipo y te has chocado con el muro de cómo recuperar en un excel la información de tu Jira. En este webinar veremos los tiempos que pasa una tarea en cada estado y a partir de ahí llegaremos a calcular el flow efficiency de nuestro producto. ¡Y todo sin tener que tocar ni una línea de código! Compartiremos una plantilla para que cualquiera sea capaz de conseguirlo. Os dejamos por aquí el enlace a la plantilla y a la presentación: https://docs.google.com/spreadsheets/d/1_UBtMNxD1yxWvN22HW_hwjKtRyE-rTUD9QTJMDDd8Y0/edit #gid=369226980 https://docs.google.com/presentation/d/1ta2EGInZo1ezNE2r9DrJKTCtMM9Kn8u4sGueBed_VEw/edit #slide=id.g2d1fcccf89_0_1 ¿Quiénes son los ponentes? Carmen Portillo. Con más de 15 años acompañando organizaciones en procesos estratégicos y de desarrollo organizacional, continúa disfrutando de su mayor pasión, acompañar a las personas y equipos de trabajo en sus propios procesos de cambio y transformación. Sergio del Mazo. Mi primer trabajo en serio como informático fue en un heldpesk y en mi cabeza ahora todo son incidencias que hay que resolver. Disfruto enfrentándome a esas pequeñas dificultades del día a día, intentando dar la mejor solución posible. Creo que Jira, si se usa bien, puede ser una palanca de cambio muy útil y potente.

¿Sabes cómo y dónde encontrar cuellos de botella en vuestro flujo de trabajo? ¿Son permanentes? ¿Sabes cómo y dónde mejorar el flujo? ¿Cuál de los estados tiene más problemas? Si te asaltan preguntas sobre la mejora de procesos vente a jugar e interactuar conmigo en esta sesión práctica e introductoria en la que te llevarás nuevas herramientas con la que responder preguntas difíciles a partir de la observación de métricas y gráficos. Entre otras muchas cosas veremos: 1. Aging WIP 2. Liquidity 3. Net Process Flow 4. Jump Plot 6. Flow Time 7. Cumulative Flow Diagram 8. Histograms 9. Run Charts y más Por último nos adentraremos en el lado oscuro de las métricas veremos algunos ideas para gestionar su uso y minimizar el daño que nos podemos hacer con ellas. Toda métrica que adquiera suficiente relevancia, pasará a gestionarse en si misma, y se desconectará de la realidad subyacente que pretendía representar. Ley de Goodhart Pablo Grueso ------------- ¡Conoce Autentia! -Twitter: https://goo.gl/MU5pUQ -Instagram: https://lk.autentia.com/instagram -LinkedIn: https://goo.gl/2On7Fj/ -Facebook: https://goo.gl/o8HrWX

¿Sabes cómo y dónde encontrar cuellos de botella en vuestro flujo de trabajo? ¿Son permanentes? ¿Sabes cómo y dónde mejorar el flujo? ¿Cuál de los estados tiene más problemas? Si te asaltan preguntas sobre la mejora de procesos vente a jugar e interactuar conmigo en esta sesión práctica e introductoria en la que te llevarás nuevas herramientas con la que responder preguntas difíciles a partir de la observación de métricas y gráficos. Entre otras muchas cosas veremos: 1. Aging WIP 2. Liquidity 3. Net Process Flow 4. Jump Plot 6. Flow Time 7. Cumulative Flow Diagram 8. Histograms 9. Run Charts y más Por último nos adentraremos en el lado oscuro de las métricas veremos algunos ideas para gestionar su uso y minimizar el daño que nos podemos hacer con ellas. Toda métrica que adquiera suficiente relevancia, pasará a gestionarse en si misma, y se desconectará de la realidad subyacente que pretendía representar. Ley de Goodhart

Todos hemos oído la famosa frase: "What gets measured gets managed" y es muy cierta. Seguro que somos capaces de recordar al menos un caso en el que hemos visto tomar decisiones importantes sin disponer de datos suficientes... Para evitar este tipo de errores, muchas empresas y equipos fijan métricas o indicadores de performance (KPIs), otros siguiendo las últimas tendencias, las implementan a través de juegos o gamificación. En todos los casos el objetivo final es medir buscando siempre obtener la combinación perfecta que haga que el equipo esté motivado, sea más productivo y mejore de forma continua. Pero no es suficiente sólo con medir; medir por medir, medir a las personas... a veces es peor el remedio que la enfermedad, tan importante es implementar una métrica como saber quitarla a tiempo. Qué es lo bueno de una métrica? Sin lugar a dudas, la tendencia. Qué es lo malo de una métrica? Que nos puede dar información errónea, que puede dirigir a un equipo al objetivo incorrecto. Qué es lo feo de las métricas? Los trucos que se hacen para que el número salga y cumplir el objetivo. Desde nuestra propia experiencia del día a día queremos contar el resultado obtenido en distintos equipos usando las métricas más comunes del desarrollo de software ágil: velocidad, cycle time, flow efficiency, defect density, número de bugs....

Un día sin escribir una línea de código puede ser más productivo que una semana picando código sin parar. Nunca el número de líneas, métodos o clases debe considerarse como métrica de avance del proyecto, al menos, mirándolo desde una perspectiva general. El mejor código es aquel que nos ahorramos de escribir porque la funcionalidad …Leer Más - por Jummp

Si la visión que tienes del desarrollo de software está demasiado condicionada por los enfoques clásicos y por gestiones orientadas a procesos demasiado rígidas es posible que no estés de acuerdo con la siguiente reflexión de Ken Schwaber: “El software que funciona es la principal medida de progreso”. Lo demás son papeles y palabras (teniendo …Leer Más - por Jummp

Uno de los grandes problemas del desarrollo de software en la Administración Pública lo tiene la utilización generalizada del ciclo de vida clásico o en cascada, no hago referencia directa a MÉTRICA v.3 ya que la misma no deja de ser un ordenación particular de dicho ciclo de vida que además es lo suficientemente abierta …Leer Más - por Jummp

El puglin de Sonar Quality Index proporciona otra métrica agregada (resultado de otras métricas) para obtener un valor que indique la calidad del software. En este caso lo que se pretende es obtener un valor entre 0 y 10. Particularmente me gusta más SIG MM ya que se centra en la mantenibilidad que es lo …Leer Más - por Jummp

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos. Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos: – Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en …Leer Más - por Jummp