Uso de métricas para arquitecturas software
68 views
Skip to first unread message
Harald
Nov 5, 2009, 5:24:11 AM11/5/09
to agile-spain
Creo que hemos visto que existen diferentes tipos de métricas y
diferentes opiniones sobre su utilidad. En este hilo propongo comentar
las métricas de arquitectura porque creo que son importantes y fáciles
de gestionar.
Antes de nada haré un breve resumen del "estado del arte" basado en
los siguientes trabajos:
1) http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
donde Robert C. Martin describe las simptomas que indican la "Erosión
de la Arquitectura" como el lo llama y las posibles causas.
2) http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides/AlexanderVonZitzewitz_Successful_projects_with_architecture_management.pdf
se evoluciona el trabajo de Robert C. Martin y donode se identifican /
resumen unas métricas y se proponen unas reglas que se implementan en
la herramienta de la misma empresa.
El origen de todos esto es la erosión del software que significa
costes adicionales en la construcción y en el mantenimiento del
código. El grado de erosión se puede medir a través de las siguientes
métricas:
1) ACD = Average Component Dependency
2) Average number of direct and indirect dependencies
3) rACD = ACD / number of elements
4) NCCD: normalized cumulated component dependency
5) Instability
Di = Number of incoming dependencies
Do = Number of outgoing dependencies
Instability I = Do / (Di+Do)
6) Abstractness
Nc = Total number of types in a type container
Na = Number of abstract classes and interfaces in a type container
Abstractness A = Na/Nc
7) Metric Distance
D = Abstractness + Instability
Se identifican unas reglas que permiten evitar que el grado de la
erosión sea demasiado y que aseguran una buena arquitectura:
Rule 1: Define a cycle free logical architecture down to the level of
subsystems and a strict and consistent package naming convention
Rule 2: Do not allow cyclic dependencies between different packages
Rule 3: Keep the relative ACD low (< 7% for 500 compilation units,
NCCD < 6)
Rule 4: Limit the size of Java files (700 LOC is a reasonable value)
Rule 5: Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6: Limit the size of a Java package (e.g. less than 50 types)
A mi me parece que como punto de partida no está mal, pero tengo unas
dudas:
-¿la erosión del software es un problema real o no? Teniendo en cuenta
que metodos como TDD cambien el metodo de trabajo y las arquitecturas
podrían surgir de forma emergente.
-¿existen otras métricas a tener en cuenta para medir una
arquitectura?
-¿el seguimiento de las métricas realmente permiten mejorar el
resultado o no atacan el problema de fondo?
diferentes opiniones sobre su utilidad. En este hilo propongo comentar
las métricas de arquitectura porque creo que son importantes y fáciles
de gestionar.
Antes de nada haré un breve resumen del "estado del arte" basado en
los siguientes trabajos:
1) http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
donde Robert C. Martin describe las simptomas que indican la "Erosión
de la Arquitectura" como el lo llama y las posibles causas.
2) http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides/AlexanderVonZitzewitz_Successful_projects_with_architecture_management.pdf
se evoluciona el trabajo de Robert C. Martin y donode se identifican /
resumen unas métricas y se proponen unas reglas que se implementan en
la herramienta de la misma empresa.
El origen de todos esto es la erosión del software que significa
costes adicionales en la construcción y en el mantenimiento del
código. El grado de erosión se puede medir a través de las siguientes
métricas:
1) ACD = Average Component Dependency
2) Average number of direct and indirect dependencies
3) rACD = ACD / number of elements
4) NCCD: normalized cumulated component dependency
5) Instability
Di = Number of incoming dependencies
Do = Number of outgoing dependencies
Instability I = Do / (Di+Do)
6) Abstractness
Nc = Total number of types in a type container
Na = Number of abstract classes and interfaces in a type container
Abstractness A = Na/Nc
7) Metric Distance
D = Abstractness + Instability
Se identifican unas reglas que permiten evitar que el grado de la
erosión sea demasiado y que aseguran una buena arquitectura:
Rule 1: Define a cycle free logical architecture down to the level of
subsystems and a strict and consistent package naming convention
Rule 2: Do not allow cyclic dependencies between different packages
Rule 3: Keep the relative ACD low (< 7% for 500 compilation units,
NCCD < 6)
Rule 4: Limit the size of Java files (700 LOC is a reasonable value)
Rule 5: Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6: Limit the size of a Java package (e.g. less than 50 types)
A mi me parece que como punto de partida no está mal, pero tengo unas
dudas:
-¿la erosión del software es un problema real o no? Teniendo en cuenta
que metodos como TDD cambien el metodo de trabajo y las arquitecturas
podrían surgir de forma emergente.
-¿existen otras métricas a tener en cuenta para medir una
arquitectura?
-¿el seguimiento de las métricas realmente permiten mejorar el
resultado o no atacan el problema de fondo?
Abel Muiño
Nov 5, 2009, 5:33:13 AM11/5/09
to agile...@googlegroups.com
No soy un experto en "teoría de métricas", pero teniendo en cuenta que Sonar es (últimamente) la herramienta de moda (open source), me interesan las opiniones sobre algunas de las métricas:
Métricas incluidas por defecto:
http://docs.codehaus.org/display/SONAR/Metric+definitions
Isotrol (pretende medir calidad del diseño y arquitectura)
http://docs.codehaus.org/display/SONAR/Isotrol+MetricsAnalytics
SIG (pretende medir la mantenibilidad)
http://docs.codehaus.org/display/SONAR/SIG+Maintainability+Model
Más plugins (obtención de métricas desde bugtrackers, etc...)
http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/
Un saludo!
--
Abel Muiño - http://ramblingabout.wordpress.com/
Métricas incluidas por defecto:
http://docs.codehaus.org/display/SONAR/Metric+definitions
Isotrol (pretende medir calidad del diseño y arquitectura)
http://docs.codehaus.org/display/SONAR/Isotrol+MetricsAnalytics
SIG (pretende medir la mantenibilidad)
http://docs.codehaus.org/display/SONAR/SIG+Maintainability+Model
Más plugins (obtención de métricas desde bugtrackers, etc...)
http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/
Un saludo!
2009/11/5 Harald <harr...@gmail.com>
--
Abel Muiño - http://ramblingabout.wordpress.com/
Jonathan Vila Lopez
Nov 5, 2009, 5:34:07 AM11/5/09
to agile...@googlegroups.com
Hola....
Disculpad mi desconocimiento del tema....me interesa pero realmente soy un total novato en esto de las métricas y mas aun si son de arquitectura.
Si no se esta en una factoría de software, cual es la utilidad de las métricas ? Me explico.... cuando son desarrollos custom y en los cuales se hace un diseño por rolling wave o bien siguiendo Scrum ( ojo, disculpadme si voy totalmente equivocado..... soy muy novato en todo esto ).....cómo podemos llegar a tener los datos necesarios para hacer una estimación paramétrica usando los calculos que menciona Robert C. Martin ?
Teniendo en cuenta que contamos con personal muy calificado, y que muchas de las estimaciones se hacen en diferentes momentos del proyecto (al inicio indicando orden de magnitud con % de confianza, y mas hacia adelante con una confianza mayor pero nunca 100% )..... yo pensaba que con la tecnica PERT de estimación ya habia suficiente.......
Estoy seguro que a medida que vaya conociendo mas sobre esta materia cambiare mi opinión.....
Gracias.
-----------------------------------------------
Slitzweitz !!!!!!
Disculpad mi desconocimiento del tema....me interesa pero realmente soy un total novato en esto de las métricas y mas aun si son de arquitectura.
Si no se esta en una factoría de software, cual es la utilidad de las métricas ? Me explico.... cuando son desarrollos custom y en los cuales se hace un diseño por rolling wave o bien siguiendo Scrum ( ojo, disculpadme si voy totalmente equivocado..... soy muy novato en todo esto ).....cómo podemos llegar a tener los datos necesarios para hacer una estimación paramétrica usando los calculos que menciona Robert C. Martin ?
Teniendo en cuenta que contamos con personal muy calificado, y que muchas de las estimaciones se hacen en diferentes momentos del proyecto (al inicio indicando orden de magnitud con % de confianza, y mas hacia adelante con una confianza mayor pero nunca 100% )..... yo pensaba que con la tecnica PERT de estimación ya habia suficiente.......
Estoy seguro que a medida que vaya conociendo mas sobre esta materia cambiare mi opinión.....
Gracias.
-----------------------------------------------
Slitzweitz !!!!!!
2009/11/5 Harald <harr...@gmail.com>
José Manuel Beas
Nov 5, 2009, 5:43:26 AM11/5/09
to agile...@googlegroups.com
Harald
Nov 5, 2009, 6:52:36 AM11/5/09
to agile-spain
Si, pero Sonar que yo sepa no implementa las métricas mencionadas.
Herramientas con soporte para este tipo de métrica son:
1) Commercial
Lattix
Structure101
SonarJ (free up to 500 classes)
2) Open Source
PMD (metrics only)
jDepend (dependencies)
Architecture Rules (on top of jDepend)
Los de SonarJ sacaran en noviembre una integración de su producto
SonarJ con Sonar de Codehouse. Vamos, pequeña confusión de nombres,
pero son productos / empresas diferentes.
Un saludo,
Harald
On 5 nov, 11:33, Abel Muiño <amu...@gmail.com> wrote:
> No soy un experto en "teoría de métricas", pero teniendo en cuenta que Sonar
> es (últimamente) la herramienta de moda (open source), me interesan las
> opiniones sobre algunas de las métricas:
>
> Métricas incluidas por defecto:http://docs.codehaus.org/display/SONAR/Metric+definitions
>
> Isotrol (pretende medir calidad del diseño y arquitectura)http://docs.codehaus.org/display/SONAR/Isotrol+MetricsAnalytics
>
> SIG (pretende medir la mantenibilidad)http://docs.codehaus.org/display/SONAR/SIG+Maintainability+Model
>
> Más plugins (obtención de métricas desde bugtrackers, etc...)http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/
>
> Un saludo!
>
> 2009/11/5 Harald <harrin...@gmail.com>
Herramientas con soporte para este tipo de métrica son:
1) Commercial
Lattix
Structure101
SonarJ (free up to 500 classes)
2) Open Source
PMD (metrics only)
jDepend (dependencies)
Architecture Rules (on top of jDepend)
Los de SonarJ sacaran en noviembre una integración de su producto
SonarJ con Sonar de Codehouse. Vamos, pequeña confusión de nombres,
pero son productos / empresas diferentes.
Un saludo,
Harald
On 5 nov, 11:33, Abel Muiño <amu...@gmail.com> wrote:
> No soy un experto en "teoría de métricas", pero teniendo en cuenta que Sonar
> es (últimamente) la herramienta de moda (open source), me interesan las
> opiniones sobre algunas de las métricas:
>
> Métricas incluidas por defecto:http://docs.codehaus.org/display/SONAR/Metric+definitions
>
>
> SIG (pretende medir la mantenibilidad)http://docs.codehaus.org/display/SONAR/SIG+Maintainability+Model
>
> Más plugins (obtención de métricas desde bugtrackers, etc...)http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/
>
> Un saludo!
>
> 2009/11/5 Harald <harrin...@gmail.com>
>
>
>
>
>
> > Creo que hemos visto que existen diferentes tipos de métricas y
> > diferentes opiniones sobre su utilidad. En este hilo propongo comentar
> > las métricas de arquitectura porque creo que son importantes y fáciles
> > de gestionar.
>
> > Antes de nada haré un breve resumen del "estado del arte" basado en
> > los siguientes trabajos:
>
> > 1)
> >http://www.objectmentor.com/resources/articles/Principles_and_Pattern...
>
>
>
>
> > Creo que hemos visto que existen diferentes tipos de métricas y
> > diferentes opiniones sobre su utilidad. En este hilo propongo comentar
> > las métricas de arquitectura porque creo que son importantes y fáciles
> > de gestionar.
>
> > Antes de nada haré un breve resumen del "estado del arte" basado en
> > los siguientes trabajos:
>
> > 1)
> > donde Robert C. Martin describe las simptomas que indican la "Erosión
> > de la Arquitectura" como el lo llama y las posibles causas.
>
> > 2)
> >http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides/Alexande...
> > de la Arquitectura" como el lo llama y las posibles causas.
>
> > 2)
Harald Messemer
Nov 5, 2009, 7:42:53 AM11/5/09
to agile...@googlegroups.com
Si no se esta en una factoría de software, cual es la utilidad de las métricas ? Me explico.... cuando son desarrollos custom y en los cuales se hace un diseño por rolling wave o bien siguiendo Scrum ( ojo, disculpadme si voy totalmente equivocado..... soy muy novato en todo esto ).....cómo podemos llegar a tener los datos necesarios para hacer una estimación paramétrica usando los calculos que menciona Robert C. Martin ?
Las métricas de las que hablaba en la introducción no tienen que ver con la estimación de esfuerzos de un desarrollo. Se trata única- y exclusivamente de métricas para medir la arquitectura a través de la estructura del código existente. ¿A que se debe la confusión?
Un saludo,
Harald
Jonathan Vila Lopez
Nov 5, 2009, 7:45:59 AM11/5/09
to agile...@googlegroups.com
@Harald : Oki........ entonces ahora lo entiendo un poco mejor.......simplemente nunca habia oido a hablar de este tipo de metricas y de ahi mi confusion ........... tendre que informarme mejor para ver que rendimiento le puedo sacar a ello.... Gracias por abrirme otra ventana de conocimiento..... :)
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
2009/11/5 Harald Messemer <harr...@gmail.com>
Abel Muiño
Nov 5, 2009, 8:33:39 AM11/5/09
to agile...@googlegroups.com
Me desconcierta usted, señor JMB :-)
En un hilo (creo que) abogas por medir la longitud de los métodos, acoplamiento entre clases y similares cosas como ayuda a ver si un código es bonito.
Pero es nombrarte a Sonar (que hace, entre otras cosas, eso...) y renegar de las métricas :-)
Para mi, las métricas son eso... números. Que ayudan a decidir si hay que intervenir en un proyecto o no. La decisión de cuando y porqué no es universal, dependerá del entorno y la forma de trabajo.
Pero si no mides, no sabes lo que haces.
En un hilo (creo que) abogas por medir la longitud de los métodos, acoplamiento entre clases y similares cosas como ayuda a ver si un código es bonito.
Pero es nombrarte a Sonar (que hace, entre otras cosas, eso...) y renegar de las métricas :-)
Para mi, las métricas son eso... números. Que ayudan a decidir si hay que intervenir en un proyecto o no. La decisión de cuando y porqué no es universal, dependerá del entorno y la forma de trabajo.
Pero si no mides, no sabes lo que haces.
2009/11/5 José Manuel Beas <jose....@gmail.com>
Jerónimo Lopez
Nov 5, 2009, 8:49:47 AM11/5/09
to agile...@googlegroups.com
Personalmente, las métricas que cuestan "cero" obtenerlas siempre serán bienvenidas, siempre que sean fácilmente interpretables como es el caso de Sonar.
Después, aprovechando que se habla de "arquitecturas software" os paso un par de enlaces de la gente de dosideas.com con la traducción de un artículo de Martin Fowler acerca de la "arquitectura":
Harald Messemer
Nov 5, 2009, 9:25:19 AM11/5/09
to agile...@googlegroups.com
2009/11/5 Jerónimo Lopez <jero...@gmail.com>
Personalmente, las métricas que cuestan "cero" obtenerlas siempre serán bienvenidas, siempre que sean fácilmente interpretables como es el caso de Sonar.
Creo la cantidad de las métricas y su interpretación es un tema importante. Aunque cueste poco o nada sacarlas, si no queda claro como interpretarlos, el valor que aporta es dudoso. Trabajando con métricas (o indicadores) me suelo aplicar las siguientes pautas:
0) El menor número de indicadores posibles. Un cuadro de mando con 3.000 relojes despista en vez de ayudar.
1) Cada indicador debe tener un baremo que relaciona el valor medido a valores comparativos (sea el valor deseado, optimo, capacidad técnico, etc.). A parte de una interpretación subjetiva o individual, debe haber una interpretación del inventor de la métrica.
2) Variaciones del indicador versus el baremo establecido deben investigarse. Los valores pueden salir fuera de los baremos, pero debe haber una explicación.
3) Si los baremos no sirven hay que cambiarlos. Los valores / baremos pueden variar según fase de proyecto.
4) Si los indicadores no sirven hay que quitarlos o sustituirlos. No todos los indicadores se necesitan siempre.
5) Revisar los indicadores después de cada actualización. Si sacas un indicador, pero no lo mira, no hace falta ni sacarlo.
Vamos, las métricas hay que gestionarlas para sacar provecho de ellos. En concreto, las métricas de arquitectura o de código en general, me parece recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los hitos a conseguir e incluirlos en el proceso de build / compilación nocturna / integración continua para gestionarlos de forma continua.
Un saludo,
Harald
José Manuel Beas
Nov 5, 2009, 10:09:40 AM11/5/09
to agile...@googlegroups.com
No reniego de las métricas. :-)
Tal y como yo entendí a Jonathan, en proyectos pequeños o con criterios que van y vienen "rápidamente", no se puede sacar beneficio de las métricas para ayudar a definir la arquitectura. A eso respondí con el "+1"
Para mi, si los números no son significativos, son "waste" el solo mirarlos. :-)
Tal y como yo entendí a Jonathan, en proyectos pequeños o con criterios que van y vienen "rápidamente", no se puede sacar beneficio de las métricas para ayudar a definir la arquitectura. A eso respondí con el "+1"
Para mi, si los números no son significativos, son "waste" el solo mirarlos. :-)
2009/11/5 Abel Muiño <amu...@gmail.com>
Abel Muiño
Nov 5, 2009, 10:11:21 AM11/5/09
to agile...@googlegroups.com
2009/11/5 Harald Messemer <harr...@gmail.com>
Trabajando con métricas (o indicadores) me suelo aplicar las siguientes pautas:
0) El menor número de indicadores posibles. Un cuadro de mando con 3.000 relojes despista en vez de ayudar.
1) Cada indicador debe tener un baremo que relaciona el valor medido a valores comparativos (sea el valor deseado, optimo, capacidad técnico, etc.). A parte de una interpretación subjetiva o individual, debe haber una interpretación del inventor de la métrica.
2) Variaciones del indicador versus el baremo establecido deben investigarse. Los valores pueden salir fuera de los baremos, pero debe haber una explicación.
3) Si los baremos no sirven hay que cambiarlos. Los valores / baremos pueden variar según fase de proyecto.
4) Si los indicadores no sirven hay que quitarlos o sustituirlos. No todos los indicadores se necesitan siempre.
5) Revisar los indicadores después de cada actualización. Si sacas un indicador, pero no lo mira, no hace falta ni sacarlo.
Me parece un buen planteamiento.
Vamos, las métricas hay que gestionarlas para sacar provecho de ellos.
Cierto. Generarlas debe ser "gratis" para que merezca la pena. El coste está en su gestión e interpretación.
En concreto, las métricas de arquitectura o de código en general, me parece recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los hitos a conseguir e incluirlos en el proceso de build / compilación nocturna / integración continua para gestionarlos de forma continua.
El problema que veo es que, en equipos pequeños o jóvenes, sin mucha experiencia, puede ser dificil de consensuar a priori qué métricas son necesarias.
Como yo estoy en ese grupo, lo que me parece más práctico es experimentar con una herramienta como Sonar (que es gratuita y no me la van a rechazar "desde arriba" ni tengo que hacer una inversión de mi propio bolsillo) y ver qué es lo que más valor me aporta.
A día de hoy, en lo que más más me fijo es en la relación entre número de tests y complejidad del código. Si la complejidad de código crece sin que tb crezca el número de pruebas, eso hace que investigue más el tema.
Es una aproximación experimental, más que teórica... y muy mejorable. Quedo a la escucha :D
Harald
Nov 5, 2009, 10:26:42 AM11/5/09
to agile-spain
> > En concreto, las métricas de arquitectura o de código en general, me parece
> > recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los
> > hitos a conseguir e incluirlos en el proceso de build / compilación nocturna
> > / integración continua para gestionarlos de forma continua.
>
> El problema que veo es que, en equipos pequeños o jóvenes, sin mucha
> experiencia, puede ser dificil de consensuar a priori qué métricas son
> necesarias.
>
Pienso que al final de cuentas lo de las métricas es una medida más
> > recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los
> > hitos a conseguir e incluirlos en el proceso de build / compilación nocturna
> > / integración continua para gestionarlos de forma continua.
>
> El problema que veo es que, en equipos pequeños o jóvenes, sin mucha
> experiencia, puede ser dificil de consensuar a priori qué métricas son
> necesarias.
>
para asegurar la calidad del entregable. Si quieres calidad tienes que
gestionarla. Si el equipo es pequeño, necesitarás menos tiempo para
esta gestión que en un equipo más grande. Si el equipo con
experiencia, tendrás que dedicar más tiempo en coaching que con
equipos más experimentados.
Yo creo que vale la pena de sacar provecho de los conceptos que se
discuten aquí como TDD e integración continua, aunque añadiría también
la gestión de la arquitectura. Necesitas dedicar más tiempo durante el
proyecto para asegurar la calidad, pero recuperas este tiempo y más en
la fase final del proyecto o despues del proyecto, debido a itienes
que dedicar menos tiempo despues del proyecto para inyectar la
calidad.
Harald
Nov 5, 2009, 10:33:55 AM11/5/09
to agile-spain
Se me ha ido la pinza antes :-(
> > En concreto, las métricas de arquitectura o de código en general, me parece
> > recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los
> > hitos a conseguir e incluirlos en el proceso de build / compilación nocturna
> > / integración continua para gestionarlos de forma continua.
> El problema que veo es que, en equipos pequeños o jóvenes, sin mucha
> experiencia, puede ser dificil de consensuar a priori qué métricas son
> necesarias.
tienes que corregir tantos fallos de prisa y corriendo.
Además, el coste que tiene la corrección de los fallos es más elevado
más tarde en el proyecto. No hay que ignorar este detalle.
> Como yo estoy en ese grupo, lo que me parece más práctico es experimentar
> con una herramienta como Sonar (que es gratuita y no me la van a rechazar
> "desde arriba" ni tengo que hacer una inversión de mi propio bolsillo) y ver
> qué es lo que más valor me aporta.
Échale un vistazo también a SonarJ (www.hello2morrow.com) que es
gratuito hasta 500 clases. Las diferencias con Sonar son importantes:
te permite definir una arquitectura y realizar un seguimiento si la
implementación corresponde a la arquitectura definida, te propone
refactorizaciones para corregir fallos identificados, lo puedes poner
en build-cycle junto con las pruebas unitarias.
Un saludo,
Harald
> > En concreto, las métricas de arquitectura o de código en general, me parece
> > recomendable consensuarlo a nivel de equipo, incluir su cumplimiento en los
> > hitos a conseguir e incluirlos en el proceso de build / compilación nocturna
> > / integración continua para gestionarlos de forma continua.
> El problema que veo es que, en equipos pequeños o jóvenes, sin mucha
> experiencia, puede ser dificil de consensuar a priori qué métricas son
> necesarias.
Pienso que al final de cuentas lo de las métricas es una medida más
para asegurar la calidad del entregable. Si quieres calidad tienes que
gestionarla. Si el equipo es pequeño, necesitarás menos tiempo para
esta gestión que en un equipo más grande. Si el equipo con
experiencia, tendrás que dedicar más tiempo en coaching que con
equipos más experimentados.
Yo creo que vale la pena de sacar provecho de los conceptos que se
discuten aquí como TDD e integración continua, aunque añadiría también
la gestión de la arquitectura. Necesitas dedicar más tiempo durante el
proyecto para asegurar la calidad, pero recuperas este tiempo y más en
la fase final del proyecto o despues del proyecto, debido a que no
para asegurar la calidad del entregable. Si quieres calidad tienes que
gestionarla. Si el equipo es pequeño, necesitarás menos tiempo para
esta gestión que en un equipo más grande. Si el equipo con
experiencia, tendrás que dedicar más tiempo en coaching que con
equipos más experimentados.
Yo creo que vale la pena de sacar provecho de los conceptos que se
discuten aquí como TDD e integración continua, aunque añadiría también
la gestión de la arquitectura. Necesitas dedicar más tiempo durante el
proyecto para asegurar la calidad, pero recuperas este tiempo y más en
tienes que corregir tantos fallos de prisa y corriendo.
Además, el coste que tiene la corrección de los fallos es más elevado
más tarde en el proyecto. No hay que ignorar este detalle.
> Como yo estoy en ese grupo, lo que me parece más práctico es experimentar
> con una herramienta como Sonar (que es gratuita y no me la van a rechazar
> "desde arriba" ni tengo que hacer una inversión de mi propio bolsillo) y ver
> qué es lo que más valor me aporta.
gratuito hasta 500 clases. Las diferencias con Sonar son importantes:
te permite definir una arquitectura y realizar un seguimiento si la
implementación corresponde a la arquitectura definida, te propone
refactorizaciones para corregir fallos identificados, lo puedes poner
en build-cycle junto con las pruebas unitarias.
Un saludo,
Harald
Xavi Gost
Nov 6, 2009, 3:31:52 AM11/6/09
to agile...@googlegroups.com
Un articulo sobre metricas agiles
http://www.infoq.com/news/2009/11/good-agile-metrics
Por lo visto no somos los unicos que vamos perdidos :)
Xavi Gost
Reply all
Reply to author
Forward
0 new messages