Diferencia entre revisiones de «Medicion Para Gestion Agil»

De Dos Ideas.
Saltar a: navegación, buscar
(Página nueva: ==¿Por qué medir?== La información es la materia prima para la toma de decisiones, y la medible y cuantificable proporciona criterios objetivos de gestión y segu...)
 
(fYJGjioyD)
 
(No se muestra una edición intermedia de otro usuario)
Línea 1: Línea 1:
==¿Por qué medir?==
+
Whoa, whoa, get out the way with that good inofrmation.
La  información  es  la materia  prima  para  la  toma de  decisiones, y  la  medible  y  cuantificable proporciona  criterios  objetivos  de  gestión  y seguimiento.
 
 
 
Desde  los  niveles  concretos  de  programación, hasta  los  más  amplios  de  gestión  global  de  la empresa, tres son  los  fondos de escala del zoom en  los  que  se  pueden  aplicar  métricas  para obtener información cuantificable:
 
 
 
* Desarrollo y gestión de la solución técnica.
 
* Gestión de proyecto
 
* Gestión de la organización
 
 
 
En  el  primero  se  puede  medir,  por  ejemplo,  la proporción  de  polimorfismo  del  código  de  un programa,  en  el  segundo,  el  porcentaje  de porcentaje realizado, y en el  tercero,  también por ejemplo, el nivel de satisfacción laboral.
 
 
 
Este  tema  presenta  sugerencias  y  mediciones: para  la  gestión  de  proyectos,  desde  una perspectiva  ágil;  pero  en  esta  introducción  se exponen  consideraciones  generales,  comunes  a todos ellos.
 
 
 
==Flexibilidad y sentido común==
 
 
 
Medir es costoso.
 
 
 
Antes  de  incorporar  un  procedimiento  de medición, hay que cuestionar su conveniencia y la forma de aplicarlo en nuestra empresa.
 
 
 
Medir no es un fin en sí mismo, y no se deben implantar procesos de medición sólo porque sí.
 
Tomar  una  lista  más  o  menos  “prestigiosa”  de métricas e  incorporarla en  los procedimientos de la  empresa,  puede  tentar  por  la  imagen  de profesionalidad  que  transmitirá  un  escenario trabajo monitorizado con  indicadores y complejas mediciones, pero no dice mucho a favor de cómo se han cuestionado y adaptado esas métricas a la
 
realidad  de  nuestros  proyectos  y  nuestra empresa.
 
 
 
==Criterios para el diseño  y aplicación de métricas==
 
 
 
===Cuantas menos, mejor:===
 
 
 
* Medir es costoso
 
* Medir añade burocracia
 
* El objetivo de “Scrum Management” es  lograr la mayor relación valor / simplicidad.
 
 
 
Cuestiones para cada indicador:
 
 
 
¿Por qué vamos a usar tal o cual indicador?
 
¿Cuál es el valor de emplearlo?
 
¿Cuál el de omitirlo?
 
¿Se  pueden  tomar  decisiones  de  gestión  sin
 
esa información?
 
 
 
La  cita  “No  se  puede  gestionar  lo  que  no  se puede medir”, por la redondez de su forma, tienta a  considerarla  incuestionable. Se  desarrollan  así patrones  de  gestión  que  renuncian  a  la experiencia,  capacidad  y  sentido  común  del gestor,  cuando  éste  podría  bastar;  y  se  termina reclamando  métricas  para  todas  las  áreas  de gestión, produciendo gestores mecanicistas.
 
 
 
 
 
El sentido común puede bastar, por ejemplo, para gestionar  y  tomar  decisiones  de  gestión  de  las personas  en  una  empresa  de  ingeniería  de  10 empleados,  sin  necesidad  de  procedimientos  de medición  de  clima  laboral.  Sin  embargo  éstos seguramente  serán  necesarios  en  una  gran empresa  con  cientos  de  empleados  en  sedes  y
 
departamentos diferentes.
 
 
 
El  objetivo  de  la  gestión  Scrum  es  el  valor,  y  la cuestión de los indicadores del área de gestión de proyecto es:
 
 
 
¿Cómo contribuye el uso de este indicador en el  valor  que  el  proyecto  le  va  a  aportar  al cliente?.
 
 
 
===¿El  indicador es apropiado para el  fin que se debe conseguir?===
 
 
 
Medir no es, o no debería ser, un fin en sí mismo.
 
 
 
¿Cuál es el fin?
 
¿Cumplir  agendas,  mejorar  la  eficiencia  del equipo, las previsiones…?
 
 
 
Sea crítico. El que lo haga, o diga que lo hace, la mayoría,  no  es  razón  para  que  se  tenga  que hacer  en  su  empresa,  proyecto  o  equipo.  Si después  de  conocerlo  y  analizarlo  no  le convence,  si  prefiere  no  emplear  esa métrica,  o modificarla, usted es el gestor.
 
 
 
Determinar qué medir es la parte más difícil. En el mejor de  los casos,  las decisiones erróneas sólo supondrán  un  coste  de  gestión  evitable;  pero muchas veces servirán para empeorar los que se intentaba mejorar.
 
 
 
Algunos ejemplos de errores por no cuestionar los indicadores, en los tres niveles de gestión:
 
 
 
====Medición de la eficiencia en la empresa:====
 
 
 
La  organización  XYZ,  dedicada  al  desarrollo  de software, está integrando un sistema de calidad y mejora integral para toda la empresa.
 
 
 
 
 
El mismo  incluye métricas para conocer el grado de eficiencia de los distintos departamentos.
 
Para el departamento de RR.HH. se ha diseñado e  implantado  un  indicador  habitual  en  estos departamentos, que determina la eficiencia en los procesos de selección de personal.
 
Consiste  en medir  el  coste  de  cada  proceso  de selección  (anuncios,  selección  de  currículos, entrevistas…) y dividirlo por el número de puestos cubiertos.
 
 
 
Como  no  sólo  es  importante  la  eficiencia,  sino también  la satisfacción del cliente  (cliente  interno
 
en  este  caso,  que  será  el  departamento  que solicita  personal)  esta  métrica  se  combina  con otra para determinarlo: tiempo de respuesta.
 
Cuánto tiempo se tarda en cubrir las vacantes.
 
 
 
La  implantación  del  indicador  ha  dado  buenos resultados:  Desde  su  implantación,  el departamento  de  RR.HH.  ha  comenzado  a  ser más  eficiente  y  conseguir mayor  satisfacción  de su cliente:
 
# Va  reduciendo  los  costes  que  suponen  la incorporación de nuevas personas a la empresa.
 
# Va reduciendo  los  tiempos de respuesta a  los departamentos que solicitan nuevo personal.
 
 
 
====Medición del avance del proyecto.====
 
 
 
La  organización XYZ  ha  diseñado  un  cuadro  de información  para mostrar el  grado  de  avance  de los distintos proyectos.
 
 
 
Los indicadores de avance de cada proyecto, y de las  tareas  en  las  que  se  descompone,  se elaboran  con  el  sistema  clásico  y  comúnmente utilizado por la gestión de proyectos predictiva:
 
# Se realiza  la estimación del  tiempo de  trabajo necesario para cada tarea
 
# Diariamente  se  actualizan  los  tiempos  de trabajo invertidos
 
# La diferencia muestra el porcentaje ejecutado de las tareas, y por tanto, el de cada proyecto.
 
 
 
====Medición  de  la  eficiencia  de  los  trabajos  de programación====
 
 
 
La  organización  XYZ  ha  adoptado  métricas estándar de eficiencia de Ingeniería del Software:
 
LOC/Hour:  Número  total  de  líneas  de  código nuevas o modificadas en cada hora.
 
 
 
Al  implantar esta métrica, vinculada además a  la retribución por desempeño de los programadores, se  ha  conseguido  programar  mayor  número  de líneas de código sin aumentar la plantilla.
 
 
 
Para evitar que se trate de un incremento “hueco” de  líneas de  código,  o  que  conlleve un  aumento de  los errores por programar más deprisa, se ha dotado  de  mayor  “rigor”  al  sistema  de  métrica, incorporando  al  poco  tiempo  otras métricas  para complementar y mejorar el sistema de calidad:
 
 
 
Test  Defects/KLOC,  Compile  Defects/KLOC  y Total  Defects/KLOC,  para  controlar  que  no aumenten el número de errores deslizados en el código.
 
También  se  incorporaron  indicadores  “appraisal time” para medir  tiempo  y  costes del diseño  y  la ejecución de las revisiones de código.
 
 
 
Y  por  el  temor  a  que  el  sistema  de  medición pueda  resultar  excesivamente  costoso  se incorporan  también  indicadores  de  coste  de calidad (COQ) que miden  los  tiempos de revisión y  los  contrastan  con  las mejoras  en  los  tiempos eliminados por reducción de fallos.
 
 
 
===¿Lo que vamos a medir es un indicador válido de lo que queremos conocer?===
 
 
 
Hay  tareas  de  programación  relativamente mecánicas,  orientadas  más  a  la  integración  y configuración  que  en  al  desarrollo  de  nuevos sistemas.
 
Para  aquellas  puede  resultar  medianamente acertado  considerar  la  eficiencia  como  volumen de trabajo realizado por unidad de tiempo.
 
 
 
Para  las  segundas  sin  embargo,  es  más apropiado  pensar  en  la  cantidad  de  valor integrado  por  unidad  de  desarrollo;  expresadas estas en horas, iteraciones o puntos de función.
 
 
 
¿Qué queremos conocer: la cantidad de líneas de programa, o el valor que entregamos al cliente?.
 
¿Está relacionado lo uno con lo otro?
 
¿Se  puede  medir  objetivamente  el  valor entregado al cliente?
 
 
 
En  nuestro  trabajo  son  muchos  los  parámetros que  se  pueden  medir  con  criterios  objetivos  y cuantificables:  el  tiempo  de  tarea,  los  tiempos delta  y  los de  las  interrupciones, el nº de puntos
 
de  función,  la  inestabilidad  de  los  requisitos,  la proporción de acoplamiento, el nº de errores por línea de código…
 
 
 
¿No  estaremos  muchas  veces  midiendo  esto, simplemente porque es cuantificable?
 
 
 
 
 
¿No  estaremos  midiendo  el  nº  de  líneas  que desarrollan  las  personas  cuando  en  realidad queremos saber el valor de su trabajo?
 
¿No  nos  estará  pasando  lo  mismo  cuando pretendemos  medir:  la  facilidad  de  uso,  la facilidad  de  mantenimiento,  la  flexibilidad,  la transportabillidad, la complejidad, etc.?
 
 
 
==Ver también==
 
 
 
[[Velocidad Trabajo Tiempo]]
 

Revisión actual del 04:39 6 sep 2011

Whoa, whoa, get out the way with that good inofrmation.