¿Cómo lidia con los requisitos cambiantes? [cerrado]

13

En mi trabajo actual, siento que tenemos muchos cambios de requisitos. Somos una tienda "ágil", así que entiendo que debemos adaptarnos y qué no, pero en algún momento el cambio es grande y nada trivial.

Mi pregunta es, ¿cómo se comunica efectivamente el costo del cambio? Debido a ser ágil, si un cambio es lo suficientemente grande, algo se eliminará del sprint actual, pero generalmente se agregará la próxima vez. Dado que nuestro modelo es SaaS, el cliente final es efectivamente el negocio en sí, y saben que obtendrán la función de corte n semanas más tarde.

Supongo que lo que estoy tratando de lograr es la eliminación de una función realmente no es algo que se use para la comunicación, ya que solo se retrasó por semanas n . ¿Qué otras formas tiene para que la empresa entienda lo que cuesta un cambio?

    
pregunta Joe 04.09.2010 - 18:17

4 respuestas

13

@Joe "Somos una tienda" ágil ", así que entiendo que se supone que debemos ajustarnos y qué no, pero en algún momento el cambio es grande y nada trivial".

Si su proceso no le permite controlar la tasa de cambio en los requisitos, su proceso no es ágil sino aleatorio. Ágil no significa "tomar cualquier cosa que se me presente".

Para controlar el cambio / creepto de los requisitos, puede adoptar, en su proceso, la noción de que un requisito no cambia (la noción de que está en el corazón de Scrum). Tratar el cambio de un requisito como reemplazar un requisito antiguo por uno nuevo . Debe tener una acumulación de requisitos y debe hacer que el usuario elija cuáles desea implementar.

Querías X e Y en dos semanas, pero de repente quieres Z. Bueno, entonces puedo entregarte las tres en 4 semanas. O puedo dar un par (X y Z) o (X e Y) o (Y y Z) en dos semanas y entregar el restante más tarde. Elige.

Así es como se negocia con los clientes. Así es como se comunica el costo del cambio de requerimiento. Si su grupo no tiene ese poder, no está en una tienda ágil y no hay nada que pueda hacer al respecto. Apesta, pero es cierto.

En caso de que pueda negociar, debe realizar un seguimiento (con precisión) del tiempo que lleva implementar los cambios de requisitos y requisitos. Es decir, debe recopilar estos datos de proyectos pasados y presentes.

Recopila el tiempo estimado original y el tiempo de finalización real (además de recursos como el conteo de desarrolladores) por solicitud (o módulo afectado por N solicitudes). Mejor aún, estime el tamaño de la solicitud / cambio de solicitud (en términos de líneas de código o puntos de función en proyectos y solicitudes anteriores).

Supongamos que tiene una métrica con la que puede hablar con el usuario. Usted sabe que una nueva solicitud tomará, digamos, 1K líneas de código, o 10 páginas web con un promedio de 5 campos de entrada cada uno (50 puntos de función).

Luego, mirando los datos históricos específicos de sus proyectos anteriores (algunos por líneas de códigos, algunos por páginas web, otros por puntos de función reales), y puede estimar cómo cada uno de estos costos términos de tiempo de finalización absoluta. Para aquellos con datos suficientes, también puede identificar aquellos requisitos que rastrean un conteo real de desarrolladores.

Luego, usa eso y le dice a su cliente que se basa en datos históricos; usted argumenta que las fallas del proyecto tienden a seguir una distribución exponencial; y luego está armado con el siguiente argumento para su cliente:

  

Basado en datos de nuestros proyectos pasados y presentes y disponibles   recursos, el requisito que solicite tomará

     
  1. X cantidad de tiempo para completar con un 25% de probabilidad de falla (o   75% de éxito)

  2.   
  3. 1.5 * X cantidad de tiempo para completar con un 5% de error (o 95% de éxito)

  4.   
  5. 0.5 * X cantidad de tiempo para completar con un 95% de error (o 5% de éxito)

  6.   

La probabilidad de falla en función de la cantidad de recursos de tiempo generalmente es del 95%, 25% y 5% (se asemeja a una distribución exponencial). Usted transmite el mensaje de que cierta cantidad de línea de base brinda una probabilidad bastante buena de éxito (pero con riesgos reales). 1.5 de eso podría dar casi una cierta probabilidad de éxito con un riesgo mínimo, pero mucho menos que eso (0.5 de las garantías originales casi seguro)

Les dejas digerir sobre eso. Si aún siguen con la proposición arriesgada (¡ hecho ayer! ) al menos usted tiene por escrito que se lo ha dicho. Si existe la esperanza de que su grupo no solo sea ágil sino también de ingeniería, entonces, el cliente podría considerar seriamente sus números y programar estas y futuras solicitudes en consecuencia.

Es su trabajo como ingeniero explicar en términos ingeniosos, verificables y claros que los cambios solicitados no son una comida gratis.

    
respondido por el luis.espinal 12.10.2010 - 19:36
8

Por lo que describiste, no tienes un problema. Solicitan un cambio y están dispuestos a esperar hasta que usted diga que se puede hacer o están dispuestos a posponer otra característica. Parece un equilibrio entre: tiempo, recursos y requerimientos.

    
respondido por el JeffO 15.09.2010 - 17:08
4

Puede intentar establecer una edad mínima para una nueva adición / cambio (no aplicable a las correcciones de errores). Por ejemplo, no se pueden realizar cambios nuevos hasta que tengan 3 semanas de antigüedad.

Tener una edad mínima para una tarea es bueno porque al principio, cada tarea parece ser extremadamente importante, pero si esperas un tiempo, entonces la importancia a menudo se reducirá significativamente. Dependiendo de su intervalo de tiempo, le dará al menos esa cantidad de tiempo de estabilidad en las tareas en las que está trabajando.

Para hacer un seguimiento de la edad, permitiría que las tareas se agregaran a alguna lista, pero no se considerarán tareas en las que trabajar hasta que ese período haya expirado.

    
respondido por el Brian R. Bondy 04.09.2010 - 18:35
0

Este es un problema muy común, sin importar qué tan rápido avance un proyecto en términos técnicos, el cliente lo percibe como mucho más lento y se siente libre de cambiar los requisitos, ya que les gusta pensar que los desarrolladores no deben hacer mucho.

Esta percepción defectuosa proviene de tres tareas principales de desarrollo que consumen tiempo y que los clientes nunca tendrán en cuenta adecuadamente:

  1. Revisiones / limpieza de códigos: el código antiguo se hincha y desordena y necesita revisiones y limpiezas periódicas, esto lleva mucho tiempo y el cliente nunca lo creerá.
  2. Auditoría de seguridad y correcciones: especialmente si tiene miembros del equipo junior, tendrá muchos problemas de seguridad relacionados con el código y querrá revisar regularmente todo el nuevo código que se ha escrito y reescribir las cosas que no se ven bien. desde una perspectiva de seguridad, el cliente nunca sabrá ni tendrá en cuenta este momento.
  3. Cambios relacionados con la arquitectura: una base de código en crecimiento puede (y probablemente lo hará) en múltiples puntos requiere un replanteamiento estructural y refactorización, esto puede implicar: A - Cambios / optimizaciones relacionadas con el rendimiento (cambios de algoritmos, reemplazos de bibliotecas, motores de caché, etc.) o: B - Cambios / optimizaciones relacionados con la productividad (legibilidad, reutilización del código, facilidad de comprensión, nuevas convenciones de codificación, un nuevo marco, etc.).

Ninguno de los anteriores será comprendido y debidamente explicado por los clientes finales.

Básicamente, lo que no tiene "vistas" (elementos GUI) no se ha hecho.

Llamemos a esto el teorema de projenix, jaja, no es una broma: D

    
respondido por el Projenix 19.01.2016 - 18:15

Lea otras preguntas en las etiquetas