tag:blogger.com,1999:blog-10583243.post4906864090576768851..comments2023-10-15T02:25:22.387-05:00Comments on Gazafatonario IT: Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocaciónLucho Salazarhttp://www.blogger.com/profile/16970569346922510096noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-10583243.post-4839471179424224462018-02-16T09:57:13.171-05:002018-02-16T09:57:13.171-05:00¡Johnny, estamos de acuerdo! Ya aprendimos además ...¡Johnny, estamos de acuerdo! Ya aprendimos además que la medición debe hacerse por observación en el gemba y no mediante una encuesta fría respondida muy lejos de donde ocurre la "acción". Muchas gracias por tu participación en el foro, como siempre, tus aportes son valiosísimos para quienes te seguimos. <br />¡Saludos, un abrazo!Lucho Salazarhttps://www.blogger.com/profile/16970569346922510096noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-38197723816880183932018-02-15T17:28:58.992-05:002018-02-15T17:28:58.992-05:00Posiblemente, el hecho de medir no sea el malo; la...Posiblemente, el hecho de medir no sea el malo; la métrica por sí mismo no es el problema. El problema -desde mi punto de vista- es el uso de la métrica con fines punitivos y no con fines de aprendizaje o de mejorar (uso no focal de la herramienta). El problema es medir cosas que no son importantes y que no nos aportan a tomar una decisión y una acción (métricas vanidosas). Una métrica es una herramienta, más puede ser mal utilizada. Considero que parte de nuestra labor como practicantes y coaches ágiles es generar conciencia de qué cosas hay que medir, el por qué, qué preguntas nos ayuda a resolver y qué acciones nos ayuda a enfocar; medir para aprender y accionar...debemos ayudar a transparentar esta información.Johnny Ordóñezhttps://www.blogger.com/profile/09010605618217559938noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-63854044491384409572018-02-15T17:23:35.258-05:002018-02-15T17:23:35.258-05:00Si lo importante es el valor entregado...¿es válid...Si lo importante es el valor entregado...¿es válido medirlo? ¿Cómo miden el valor entregado? ¿Cómo generan conciencia en los equipos sobre lo que es valor? Si el manifiesto propone medir 'software funcionando'...es válido medirlo? ¿Cómo miden 'software funcionando'?Johnny Ordóñezhttps://www.blogger.com/profile/09010605618217559938noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-86599032977525919612016-08-16T21:23:57.814-05:002016-08-16T21:23:57.814-05:00Excelente Post Lucho, de los mejores que te he leí...Excelente Post Lucho, de los mejores que te he leído. Vamos derrotando de a poco esas métricas que buscan control y sólo alejan la motivación de los equiposCarlos Sernahttps://www.blogger.com/profile/07154799295577920476noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-41610364152146320322016-01-14T15:24:30.005-05:002016-01-14T15:24:30.005-05:00De acuerdo, Carlos. Ese es el punto: ¿las métricas...De acuerdo, Carlos. Ese es el punto: ¿las métricas para qué? Si vas a medir el número de errores de un programador por cada mil líneas de código y cosas así para simplemente "calificarlo" a fin de año y ver si le aumentas o bajas el sueldo o lo promueves, estás en el lugar equivocado. Si vas a hacer eso mismo para entonces tomar medidas como entrenamiento y acompañamiento a ese programador, entre otras, entonces sí vale la pena. Pero incluso así, el entrenamiento y acompañamiento debería ser independiente del desempeño de la personaje, el objetivo debe ser siempre buscar formas mejores de hacer las cosas. Allí es donde marcamos la diferencia usando el enfoque Ágil: no concentrarnos tanto en el hacer como en el buscar continuamente formas mejores del hacer. Ese es el corazón de Ágil.Lucho Salazarhttps://www.blogger.com/profile/16970569346922510096noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-33057313992072927972016-01-14T13:48:42.571-05:002016-01-14T13:48:42.571-05:00Estoy de acuerdo que lo valioso es el software úti...Estoy de acuerdo que lo valioso es el software útil funionando, sin ambargo, como lo mencioné en mi aportación anterior, ese "incremento de software" es una medida de éxito al final, y es también un indicador de productividad del equipo; es decir, de alguna forma se está mediendo y controlando el proyecto, que se ponga enfasis en otros factores (métricas), eso es otra cosa, el punto es que se sigue midiendo de alguna manera, incluso la motivación del equipo es un indicador que permite retroalimentar el proceso en aras de mejorar. Incluso las metodologías ágiles buscan controlar de alguna manera el cumplimiento de lo comprometido en cada sprint, y eso lleva a los ajustes necesarios para adaptarse a las circusntancias.<br /><br />Por lo anterior, comentaba que se debe poner en contexto los conceptos métrica, medición y control.Blog de Carlos J. Duartehttps://www.blogger.com/profile/14244717271407169381noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-7818519390979259992016-01-14T06:42:14.757-05:002016-01-14T06:42:14.757-05:00Carlos, muchas gracias por el comentario.
Como dic...Carlos, muchas gracias por el comentario.<br />Como dice Oscar en una nota más arriba, ¿cómo se mide la productividad de un proceso que todavía tiene mucho de creativo, como el desarrollo de software? Por eso nos gusta que el software funcionando sea la medida universal de progreso. Si en cada iteración entregas un incremento del producto (software) que sea de Valor para el negocio (usuario), que incluso lo pueda poner en producción, que resulte en Retorno de la Inversión, que resuelva parte de un gran problema o varios problemas pequeños, entre otras características, eso permite conocer el estado del proyecto y mejor aun, el estado del producto, permite conocer no solo que se ha hecho, sino qué hace falta, permite conocer también la calidad exacta de lo que va del producto, el nivel de satisfacción y, más que eso, el grado de felicidad del cliente (usuario), ni hablar de la velocidad efectiva del equipo, pero más que ello, el estado de ánimo de los miembros del equipo, entre otros aspectos que miden la realidad del proyecto y que sirven de fundamento para seguir encontrando, vía retrospectivas u otras sesiones de Scrum, encontrar formas mejores de hacer las cosas, el mejoramiento continuo que, como ya sabemos, es el corazón del enfoque ágil, es lo que nos interesa, más que el hacer, encontrar continuamente formas mejores de trabajar.<br />Saludos,Lucho Salazarhttps://www.blogger.com/profile/16970569346922510096noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-67227668669597755062016-01-14T06:40:11.019-05:002016-01-14T06:40:11.019-05:00Este comentario ha sido eliminado por el autor.Lucho Salazarhttps://www.blogger.com/profile/16970569346922510096noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-68885023711651747442016-01-14T01:25:03.883-05:002016-01-14T01:25:03.883-05:00Es importante matizar el "control" dentr...Es importante matizar el "control" dentro de los proyectos de software; es decir, aún las metodologías ágiles establecen algún sistema métricas para el control del proyecto y la calidad, entiendase Burn down chart, para medir la velocidad y productividad del equipo; ¿para qué son las reuniones diarias y la revisión de sprint si no para establecer algún mecanismo de medición para mejorar el proceso?Blog de Carlos J. Duartehttps://www.blogger.com/profile/14244717271407169381noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-24889431622156587662015-06-18T21:35:15.707-05:002015-06-18T21:35:15.707-05:00Lucho que gran post
Que valioso darse cuenta que l...Lucho que gran post<br />Que valioso darse cuenta que los autores que influienciaron tendencias que hoy tienen a nuestra industria enfrascada en fracasos, cambian de forma de ver las cosas, lo que cuesta es transmitir esta visión a los influenciados.. pero en esas estamos..<br />Nos queda mucho trabajo por hacer.. <br />Pero con argumentos como estos y más aun con los resultados lograremos que menos ingenier@s pierdan sus familias por excesivo tiempo dedicado a jornadas laborales inhumanas en proyectos donde la predectibilidad es inoperante.<br />Soltemos el control y busquemos satisfacer objetivos… es más ganador y se genera menos desperdicio<br /><br />Pdta: gracias por citarme compa..<br /><br />Un abrazo y hasta la próxima <br />Jorge Hernán Abad Londoñohttps://www.blogger.com/profile/15648623250040658188noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-71606784615753122692015-04-30T13:47:00.364-05:002015-04-30T13:47:00.364-05:00¡Oscar, gracias!
Tú has dado en el clavo: esto de...¡Oscar, gracias!<br /><br />Tú has dado en el clavo: esto de la medición en la Ingeniería de Software también es una causa de haber tomado prestado en sus inicios prácticas de otras áreas aplicadas, por ejemplo, de la Ingeniería Civil, de la Mecánica o de la Industrial. Imagino que eso fue lo que le pasó de DeMarco por allá a principios de los 80 cuando empezó a escribir su libro.<br /><br />Afortunadamente, ya nos dimos cuenta que la Ingeniería de Software tiene su propia personalidad y, aunque es posible tomar prestado prácticas, preceptos y herramientas de otras industrias y áreas, también tiene su propio ecosistema, con un carácter y fisionomía propias que la hace y que nos hace (a quienes la practicamos) únicos.<br /><br />Salud@s.<br />Lucho Salazarhttps://www.blogger.com/profile/16970569346922510096noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-34877016959595677852015-04-30T09:52:43.469-05:002015-04-30T09:52:43.469-05:00Que buen Post Lucho, creo que es importante medir ...Que buen Post Lucho, creo que es importante medir y controlar, pero cuando se trata de procesos industriales y/o tareas monótonas; por ejemplo: Sembrar Caña, Construir una Pared, Encofrar columnas de hormigón, etc. En estos casos tiene sentido medir la productividad (horas/hombre u horas/maquina), para poder estimar, predecir y planificar el futuro. <br /><br />En las profesiones creativas, que tienen un toque de Arte y otro de Ciencia, como la Ingeniería de Software, donde se pretende plasmar la representación de la realidad en un ente abastracto (software), no tienen ningún sentido medir productividad, ya que descubrir la esencia de la solución, no es proceso monótono o repetitivo, es variable y muchas veces se falla en las primeras interpretaciones, al final lo que deberíamos medir es VALOR entregado y no cantidad de trabajo realizado en el tiempo, que como tu lo mencionaste puede ser de baja calidad, por las presiones de tiempos y el control.Oscar Amelungehttps://www.blogger.com/profile/05079195952091231182noreply@blogger.comtag:blogger.com,1999:blog-10583243.post-29024853829392031852015-04-24T13:45:02.619-05:002015-04-24T13:45:02.619-05:00Lamentablemente nuestras organizaciones han crecid...Lamentablemente nuestras organizaciones han crecido muchos roles que se encargan del control y no se ha avanzado efectivamente en trabajar colaborativamente con los desarrolladores de software.Anonymoushttps://www.blogger.com/profile/08462976251215963294noreply@blogger.com