¿Existe alguna manera de medir el costo del desarrollo ágil sin registrar la cantidad de tiempo que le tomó hacer una tarea?

Question

Imagine la escena, una empresa está pensando en utilizar la metodología Scrum para el desarrollo ágil. Han implementado el Scrum para Team Systems y todos están muy contentos con él. Sin embargo, la empresa quiere capitalizar su costo de desarrollo y ha pedido que se modifique la plantilla del ítem de trabajo atrasado de Scrum para incluir el tiempo necesario para realizar la tarea. La idea es que necesitan saber cuánto tiempo pasó un desarrollador haciendo un trabajo productivo I.E. cuánto tiempo pasaron agregando nuevas características.

El problema que algunas personas en el negocio tienen con esto (incluyéndome a mí) es que registra cómo el tiempo perdido que has gastado en algo como que derrota el objeto de Scrum. Todo lo que quiero saber desde el punto de vista de un desarrollador principal es que tenemos mucho tiempo para hacer tanto trabajo. Registramos cuánto tiempo queda en la tarea y podemos ver cuán lejos estamos de cumplir nuestros objetivos.

Tal vez me está faltando el punto? Dígame usted. Sin embargo, si alguien conoce una manera en la que podemos trabajar sin registrar la cantidad exacta de tiempo que pasamos haciendo algo y aún complacer a las personas que invierten el dinero, entonces su respuesta sería muy apreciada.

Answer 1

Como gerente de desarrollo, estoy interesado en asegurarme de que el desarrollo se desarrolle sin inconvenientes (a través de Scrum) y que el tiempo se refleje por proyecto para saber dónde gastamos nuestro dinero (Time Tracking).

Por lo tanto, durante un sprint, se les pide a los miembros del equipo que actualicen la cantidad de tiempo restante en las tareas pendientes para calcular el gráfico rebajado. No debería tomar más de un par de minutos. Dado que estamos usando Scrum, el equipo decide las tareas y no me importa quién haga qué, siempre que tengamos una tabla de quemados.

También les pido que hagan un seguimiento de su tiempo por proyecto y esto no está muy detallado. No quiero rastrear cada minuto de su tiempo. Esta información se utiliza para tener una idea de cuánto tiempo demora la publicación de una versión o mucho dinero para desarrollar un producto.

Dado que estamos utilizando el seguimiento del tiempo de Scrum, es muy simple, ya que todos los miembros de un equipo trabajan en el mismo proyecto durante un largo período de tiempo.

Answer 2

Hemos estado usando Agile/SCRUM durante aproximadamente 2 años, y nunca hemos registrado datos reales.

Parece que de vez en cuando se realizan intentos para que todos graben esta información. Por lo general, esto es como resultado de un sprint pobre donde la culpa recae directamente en la estimación deficiente. Pero es muy fácil olvidarse de marcar esto, aunque estoy seguro de que con suficiente "suave insistencia" se convertiría en un hábito.

La idea que veo una y otra vez, y con la que estoy de acuerdo, es que su velocity debe responder a cualquier pregunta que usted (o los propietarios del producto) necesiten sobre el progreso de las tareas.

Answer 3

Scrum y otros métodos de desarrollo ágiles funcionan mejor cuando existe confianza entre las personas involucradas en ambos lados. La gerencia necesita confiar en que los desarrolladores trabajen duro y funcionen bien. Los desarrolladores deben confiar en que la administración respeta su aporte y les pide que realicen un trabajo adecuado según las necesidades del negocio. En ausencia de esta confianza, su proceso será disfuncional. Ningún entorno es perfecto, pero en algún momento los problemas de confianza pueden ser lo suficientemente malos como para que no sea viable.

Habiendo dicho eso, hay varias cosas que yo, como desarrollador, tengo que hacer "solo porque". Yo, por ejemplo, tengo que hacer exactamente este tipo de cosas porque esa es la forma en que funciona toda la organización, incluidos los desarrolladores. Puedo vivir con ello. Yo diría que sigan su tiempo, pero planeen los sprints. Registre su tiempo "improductivo" de manera significativa, como investigación de tecnología, tareas de oficina, etc., para que la gente de negocios entienda que siempre es productivo, incluso cuando no está desarrollando código.

EDITAR Oh - y si la actividad de seguimiento del tiempo es particularmente onerosa, como rellenar los registros diarios detallados, asegúrese de mantener un registro de la cantidad de tiempo que pasa seguimiento de su tiempo con toda claridad para que sepan lo mucho que la la actividad está costando

Answer 4

Scrum no es rígido, se trata de adaptabilidad y lo que satisface sus necesidades.

¿Por qué no calcula las historias en horas en lugar de historias? Nosotros también enfrentamos la misma situación y comenzamos a estimar en horas. Todos los días contra ese horario estimado, el desarrollador registra la cantidad de tiempo que trabajó en una historia. A diario se puede ver cuánto tiempo necesita la historia y, al final, se puede ver la estimación y el tiempo real empleado.Utilizamos XPlanner para rastrear esto y el desarrollador tarda un minuto en registrar el tiempo diario. En base a esta información, siempre puede medir la velocidad que ayudará en la siguiente iteración.

Además de las historias relacionadas con proyectos, registramos el tiempo perdido en otras actividades, p. reuniones, medio ambiente, soporte de producción, etc. Durante un período de tiempo esta información nos dio mucha información y logramos reducir mucho ese tiempo perdido.

Answer 5

La primera pregunta es: ¿es usted una tienda de consultoría o una tienda interna de TI? Si lo primero, pueden ser necesarios para permitirles facturar a los clientes correctamente. Si lo último, y todos ustedes son asalariados, entonces las razones no son tan claras. Siempre sospecho que cualquier gerente quiere saber "cuánto tiempo pasó un programador haciendo un trabajo productivo". Es una medida, y una de las cosas clave que les digo a los equipos con cualquier forma de desarrollo ágil es que las métricas se deben capturar para propósitos claros con los que el equipo esté de acuerdo.

Me gustaría preguntar cuál es la "pregunta detrás de la pregunta" - o lo que la administración realmente está buscando. ¿Por qué les preocupa la productividad del desarrollador? ¿Les está resultando difícil explicar a sus administradores de qué está pasando? ¿Hay métricas de equipo que podrían proporcionarse para generalizar?

En resumen: su gerente podría ser considerado como un cliente del equipo, así que descubra lo que quiere su cliente, y piense de la mejor manera, como equipo, para proporcionarlo.