project management - open - ¿Cómo medir el rendimiento del desarrollo de software?

project manager software (15)

Estoy buscando algunas formas de medir el rendimiento de un equipo de desarrollo de software. ¿Es una buena idea usar la herramienta de compilación? Usamos Hudson como una herramienta de compilación automática. Me pregunto si puedo tomar la información de los informes de Hudson y obtener de ella el progreso de cada uno de los programadores.

Compartiría mi experiencia y cómo aprendí un proceso muy valioso para medir el desempeño del equipo. Debo admitir que me he basado en el seguimiento de KPI simplemente porque la mayoría de los departamentos harían lo mismo pero no realmente por la idea hasta que tuve la responsabilidad de evaluar el rendimiento de los desarrolladores donde, después de una serie de lecturas, evolucioné con la siguiente solución.

En cada proyecto, entretendría al equipo en una discusión sobre los requisitos del proyecto y los involucraría para que todos sepan lo que se debe hacer. En la misma discusión a través de la colaboración, dividiríamos los proyectos en tareas y ponderaríamos esas tareas. Ahora, anteriormente, estimaríamos la finalización del proyecto en 100%, donde cada tarea tiene una contribución porcentual. Bueno, esto funcionó por un tiempo pero no fue la mejor solución. Ahora basaríamos la tarea en el peso o los puntos para ser exactos y utilizaríamos medidas relativas para comparar la tarea y diferenciar los pesos, por ejemplo. Hay un requisito para desarrollar un formulario web para recopilar datos de usuario. La tarea iría como

1. User Interface - 2 Points 2. Database CRUD - 5 Points 3. Validation - 4 Points 4. Design (css) - 3 Points

Con esta estrategia, podemos señalar un aproximado semanal de cuánto hemos completado y qué está pendiente en el grupo de trabajo. También podemos determinar quién ha obtenido mejores resultados.

Debo admitir que todavía enfrento algunos desafíos en esta estrategia, ya que no todos los desarrolladores se sienten cómodos con cada tecnología. De alguna manera, algunos están entusiasmados por aprender tecnologías simplemente porque encuentran que el alto porcentaje de puntos de 2015 cae en esa sección, algunos harían lo que pueden.

Recuerde, no realice un seguimiento de un KPI por su propio bien, realice un seguimiento para su comprensión.

Compruebe cuántas líneas de los códigos ha escrito cada uno.

Luego dispara el 70% inferior ... ¡NO EL 90%! ... ¡TODOS LOS DÍAS!

(para la gente que no está segura, sí, estoy bromeando. Respuesta seria here )

Creo que esto requiere un enfoque muy cuidadoso al decidir las formas de medir el rendimiento de los desarrolladores, ya que la mayoría de los métodos tradicionales, como la línea de códigos, la cantidad de registros, la cantidad de errores corregidos, etc. han demostrado ser subjetivos con los conceptos de ingeniería de software actuales. Necesitamos valorar el enfoque de rendimiento del equipo en lugar de medir KPI individuales en un proyecto. Sin embargo, trabajar en un entorno de desarrollo comercial es importante para mantener un seguimiento y observar de cerca los siguientes factores de los desarrolladores individuales;

Comentarios de revisión de código: en cada proyecto, podemos decidir la cantidad de revisiones de código que deben realizarse durante un período determinado. Basados en las revisiones del código, los individuos reciben comentarios sobre sus mejoras estándar de codificación. Las cuestiones recurrentes de las revisiones de código del mismo código de un individuo deben ser atendidas. Puede utilizar herramientas de revisión de códigos automatizadas o revisiones de códigos manuales.
Prueba de cobertura y exhaustividad de las pruebas. - El% cubierto debe decidirse por adelantado y, si cierto desarrollador no lo intenta a menudo, debe ser atendido.
Disponibilidad para iniciar sesión en tareas complejas y entregarlas sin mucha lucha.
Lograr lo que se define como "Hecho" en una historia de usuario
Nivel de dominio de cada área técnica.

Con un enfoque ágil en algunos de los proyectos, las medidas del equipo de desarrollo y el rendimiento esperado se deciden en función de los lanzamientos. En cada planificación de lanzamiento, hay diferentes ''contratos'' negociados con los miembros del equipo para el desempeño esperado. Considero que este enfoque es más exitoso, ya que no hay ninguna razón para adherirse a las mediciones relacionadas con la IU en una versión donde hay un algoritmo complejo para ser lanzado.

El principal problema con métricas de rendimiento como esta, es que los humanos son MUY buenos para jugar cualquier sistema que mida su propio rendimiento para maximizar esa métrica de rendimiento exacta, generalmente a expensas de otra cosa que es valiosa.

Digamos que usamos la compilación hudson para recopilar estadísticas sobre la salida del programador. ¿Qué podría buscar y cuáles serían los efectos secundarios no deseados de medir que una vez que los programadores están al tanto de ello?

Líneas de código (los desarrolladores simplemente producen montañas de código repetitivo y otra ingeniería innecesaria, o simplemente incorporan todos los malditos métodos)
Fallos en las pruebas unitarias (no escriba ninguna prueba unitaria, entonces no fallarán)
Cobertura de la prueba unitaria (escriba pruebas débiles que ejerzan el código, pero en realidad no lo prueban correctamente)
Número de errores encontrados en su código (no haga ninguna codificación, entonces no obtendrá errores)
Número de errores solucionados (elija los errores fáciles / triviales para trabajar)
Tiempo real para terminar una tarea en base a su propio estimado (estimación más alta para dar más espacio)

Y sigue.

El punto es que, sin importar lo que mida, los humanos (no solo los programadores) son muy buenos en la optimización para satisfacer exactamente esa cosa.

Entonces, ¿cómo debería ver el rendimiento de sus desarrolladores? Bueno, eso es difícil. Involucra a gerentes humanos, que son buenos para entender a las personas (y al BS que obtienen), y pueden mirar a cada persona de manera subjetiva en el contexto de quién / dónde / qué deben averiguar si están haciendo un buen trabajo o no. .

Lo que hagas una vez que hayas descubierto quién está / no está actuando es una pregunta completamente diferente.

(No puedo tomar crédito por esta línea de pensamiento. Es originalmente de Joel Spolsky. Here y here )

Esta es una pregunta antigua, pero aún así, algo que puedes hacer es tomar Velocity de Agile Software Development, donde asignas un peso a cada tarea y luego calculas la cantidad de "peso" que resuelves en cada sprint (o iteración o cualquier DLC que uses). ). Por supuesto, esto se debe al hecho de que, como un comentarista mencionado anteriormente, debe mantenerse al tanto de si sus desarrolladores están trabajando o chateando en línea.

Si sabe que sus desarrolladores están trabajando con capacidad de respuesta, entonces puede confiar en esa velocity para obtener una estimación de cuánto trabajo puede hacer el equipo. Si en cualquier iteración este número disminuye (considerablemente), entonces se estimó pobremente o el equipo trabajó menos.

En última instancia, el uso de KPIs junto con la velocidad puede proporcionarle información sobre el rendimiento por desarrollador (o por equipo).

Existe un error común que muchas empresas cometen al configurar su herramienta de administración de lanzamientos. El kit de herramientas de administración de lanzamientos de Salesforce es uno de los mejores disponibles en el mercado hoy en día, pero si no sigue los pasos vitales de configuración, definitivamente tendrá algunos resultados muy malos. Podrás usarlo pero no a su capacidad total. El establecimiento de procesos de administración de versiones aislados de los procesos de negocios es uno de los peores errores que se pueden cometer. Las herramientas de gestión de lanzamientos van de la mano con la estrategia empresarial, los objetivos, la gobernanza, la gestión del cambio y otros aspectos. Los procesos de gestión de lanzamientos deben configurarse de manera que todos los miembros de la empresa estén en la misma página.

Objetivos de la administración de lanzamientos El objetivo principal de la administración de lanzamientos es tener un conjunto consistente de procesos confiables y repetibles que sean independientes de los recursos. Esto permite alcanzar el valor comercial más favorable y, al mismo tiempo, optimizar la utilización de los recursos disponibles. Teniendo en cuenta que la mayoría de las organizaciones se centran en ejecutar proyectos de negocios cortos y de alto rendimiento, es esencial para la optimización de la cadena de valor de entrega de la aplicación asegurarse de que no haya retrasos en la entrega del valor de negocio.

Tomemos, por ejemplo, el kit de herramientas de migración de force.com, ya que esta herramienta ha demostrado ser excelente en materia de gobierno. Una herramienta de administración de lanzamientos debería permitir una visibilidad y responsabilidad óptimas en el gobierno.

Procesos y ciclos de lanzamiento Los procesos de administración de lanzamiento deben ser coherentes para toda la empresa. Es necesario contar con procesos simplificados y estandarizados en los distintos usuarios de herramientas. Esto se debe a que usarán la misma plataforma y los mismos recursos que permiten la finalización eficiente de sus tareas. Tener diferentes procesos para diferentes divisiones de su negocio puede llevar a fallas graves en la administración de herramientas. Los diferentes grupos de usuarios deberán tener visibilidad de lo que están haciendo los demás. Como se mencionó anteriormente, la visibilidad es de gran importancia en cualquier proceso de negocios.

Cuando se trata de los ciclos de lanzamiento, también es imperativo tener un sistema centralizado que rastree todos los requisitos de los diferentes conjuntos de usuarios. También es necesario tener este sistema centralizado para que los equipos de desarrollo de software obtengan información sobre las características y los cambios solicitados por la empresa. Las solicitudes deben convertirse en prioridades para asegurarse de que la empresa obtenga el máximo beneficio. Tener un equipo directivo es importante porque está involucrado en la revisión de los requisitos del negocio, además de priorizar los cambios más apropiados que el negocio necesita hacer.

Los cambios que deberían ocurrir en el sistema de Salesforce pueden ser muy difíciles y, por lo tanto, tener una reunión regular entre el negocio y la TI es bueno. Esto ayudará a determinar los mejores cambios para hacer en el sistema que beneficiará al negocio. Al considerar el costo y el valor de implementar una función, el comité directivo tiene la tarea de decidir cuáles son los cambios más importantes que se deben realizar. Aquí también es una buena investigación http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams

Hablando de KPI en desarrolladores de software. www.smartKPIs.com puede ser un buen recurso para usted. Contiene una biblioteca fácil de usar con medidas de rendimiento bien documentadas. Actualmente, enumera más de 3300 ejemplos de KPI, agrupados en 73 áreas funcionales, así como 83 industrias y subcategorías.

Los ejemplos de KPI para los desarrolladores de software están disponibles en esta página www.smartKPIs.com - desarrollo de aplicaciones Incluyen, entre otros, los siguientes:

Eficiencia en la eliminación de defectos
Redundancia de datos

Además de ejemplos de medidas de rendimiento, www.smartKPIs.com también contiene un catálogo de informes de rendimiento que ilustran el uso de KPI en la práctica. Los ejemplos de dichos informes para tecnología de la información están disponibles en: www.smartKPIs.com - KPIs en la práctica - tecnología de la información El sitio web se actualiza diariamente con contenido nuevo, así que revíselo de vez en cuando para ver contenido adicional.

Tenga en cuenta que si bien los ejemplos de medidas de desempeño son útiles para informar decisiones, cada medida de desempeño debe seleccionarse y personalizarse en función de los objetivos y prioridades de cada organización.

Hay muchas maneras diferentes de hacer esto. Libros enteros escritos sobre el tema. Podría usar los informes de Hudson, pero creo que eso llevaría a una información errónea y proporcionaría resultados crudos. Realmente necesitas tener metodología de seguimiento de tareas.

NO mida el rendimiento de cada programador individual simplemente utilizando la herramienta de compilación. Puede medir el equipo como un todo, seguro, o ciertamente puede medir el progreso de cada programador, pero no puede medir su desempeño con una herramienta de este tipo. Algunos módulos son más complicados que otros, algunos programadores se encargan de otros proyectos, etc. No es una forma recomendada de hacer esto, y los alentará a escribir código descuidado para que parezca que hicieron el mayor trabajo.

NO recomendaría utilizar la información de la herramienta de compilación como una forma de medir el rendimiento / progreso de los desarrolladores de software. Algunos de los problemas de confusión: posiblemente una tarea es considerablemente más difícil que otra; posiblemente una tarea está mucho más involucrada en el "espacio de diseño" que en el "espacio de implementación"; posiblemente (probablemente) la solución más eficiente sea la mejor solución, pero esa mejor solución contribuye con menos líneas de código que una muy ineficiente que proporciona muchas más líneas de código; etc.

No acorte o busque formas rápidas y fáciles de medir el rendimiento / progreso de los desarrolladores. Hay muchos factores que afectan la salida de un desarrollador. He visto a muchas personas probar varias métricas ...

Líneas de código producidas: anima a los desarrolladores a producir basura ineficiente. Medidas de complejidad: fomenta el análisis y la refactorización Número de errores producidos: anima a las personas a buscar tareas realmente simples y a odiar a sus evaluadores ... la lista continúa.

Al revisar a un desarrollador, realmente necesita ver qué tan bueno es su trabajo y definir "bien" en el contexto de lo que necesita la empresa y en qué situaciones / posiciones ha colocado la empresa. El progreso debe evaluarse con la misma consideración y reflexión. .

No.

Métricas como esas están condenadas al fracaso. Diferentes personas trabajan en diferentes partes del código, en diferentes clases de problemas, y las mediciones absolutas son, en el mejor de los casos, engañosas.

La forma de medir el desempeño de los desarrolladores es tener excelentes gerentes que hagan bien su trabajo, tengan buenas especificaciones que reflejen los requisitos con precisión y sigan el progreso de todos cuidadosamente contra esas especificaciones.

Es difícil hacer lo correcto. Una solución de software no funcionará.

Por lo general, el uso directo de métricas para medir el rendimiento se considera una mala idea y una de las formas fáciles de llevar a un equipo a la práctica.

Ahora, puede usar métricas como% de proyectos completados a tiempo,% de abandono cuando el código se va completando, etc ... es un campo amplio.

Aquí hay un ejemplo:

Joe escribió el 60% de los errores de misión crítica. Esa es una métrica simple y directa. Fuego Joe, ¿verdad?

¡Pero espera hay mas!

Joe es el desarrollador senior. Es el único hombre en quien se confía para escribir código ultra confiable, siempre. Ha escrito aproximadamente el 80% del software de misión crítica, porque es el mejor .

Las métricas son una mala medida de los desarrolladores.

Recibimos 360 comentarios de todos en el equipo. Si todos los miembros de tu equipo piensan que eres un tonto, entonces probablemente lo eres.

Probablemente lo haría mejor midiendo qué tan bien su equipo rastrea a los horarios. Si un miembro del equipo (o todo el equipo) llega tarde tarde, deberá trabajar con ellos para mejorar el rendimiento.