¿Cómo debe operar el equipo semi-ágil durante la "fase de prueba" similar a una cascada impuesta por la administración

7

No estoy buscando consejos sobre cómo debería funcionar un proceso ágil. Conozco esa parte. Tengo curiosidad por saber cuál es la mejor manera de adaptar el proceso a una corporación grande y bien establecida que ama sus "procesos" y revisiones de pasaportes / pasajes.

Para los que tienen la suerte de no saber lo que son, las cosas de las puertas / pasaportes son esencialmente hitos en cascada presentados por los equipos de desarrollo a los ejecutivos: Puerta 0 - inicio, identificación de proyectos npv positivos; Puerta 1: trabajo de planificación para el lanzamiento, comienza la codificación, Puerta 2: código completado / fase de prueba, Puerta 3 ...

Dentro de nuestro equipo, hemos intentado adoptar Agile tanto como pudimos (revisiones por pares, iteraciones, comunicación constante, hacer lo que tenga sentido, mejora continua ...), estas puertas vienen desde muy arriba y no hay nada que podamos hacer. Se puede hacer al respecto.

De muchas cosas que me molestan, una de ellas es que el entorno corporativo en el que estamos, impone algunas restricciones que parecen tener efectos adversos en la forma en que trabajamos. Un ejemplo es que durante el desarrollo solo nos centramos en las nuevas funciones e ignoramos los errores existentes e incluso introducimos nuevos errores. Esto es desafortunado y va en contra de ágil, pero no tenemos otra opción ya que el código completo podría estar en 2 meses, pero la fase de "prueba / corrección de errores" puede durar 6 meses después de eso. Estamos bajo una presión constante para "terminar el trabajo", pero el énfasis está en completar características, no en obtener un producto estable. Esta parte con la que aprendimos a vivir.

Mi pregunta es ¿qué estrategia (modo de operación exitoso) han encontrado otros equipos / compañías para la fase de "prueba" que sigue a un hito de "código completo"?

Durante el "nuevo desarrollo" tenemos iteraciones y cada una se llena de historias y tareas. Sin embargo, actualmente una vez que el desarrollo está "hecho", no hay más iteraciones ni más planificación. En su lugar, solo usamos la base de datos de seguimiento de errores para monitorear la cantidad de errores nuevos que se encuentran y la rapidez con la que se resuelven los errores.

Personalmente, no veo la diferencia entre agregar una nueva función de interfaz de usuario y hacer que la función de interfaz de usuario existente funcione. Para mi trabajar es trabajar. Propuse que continuáramos teniendo iteraciones como de costumbre y que continuáemos programando el trabajo como antes, pero ni la gerencia ni otros miembros del equipo parecían estar de acuerdo con eso. Entonces, 1) ¿estoy lejos y es la base de datos de seguimiento de errores lo mejor que podemos hacer? y 2) si hay un mejor enfoque, me gustaría explorarlo y tal vez adquirir suficiente munición para devolverle a mi jefe. Al mismo tiempo, estoy de acuerdo en que muchas veces, al reaccionar ante errores, no podemos darnos el lujo de esperar hasta la próxima iteración.

--- Aclaración leve basada en las primeras respuestas ---

Acabamos de entrar en la fase de prueba. Por el momento, no hay más historias, no más iteraciones. Sólo la base de datos de seguimiento de errores. Eso no me sienta bien, por eso tengo curiosidad por lo que otros equipos harían en esta situación. Además, algunos errores son definitivamente del tamaño de una historia de tamaño medio, mientras que otros errores tardarían 5 minutos en solucionarse. ¿Deberían los errores de 5 minutos también convertirse en historias si tuviéramos que continuar con las iteraciones? El otro argumento que hemos tenido es que durante el "nuevo desarrollo" solo interactuamos con la herramienta de seguimiento Agile (Rally), pero en "pruebas" si continuamos con las iteraciones, tendríamos que mantener el rastro del papel en Rally, así como en software de seguimiento de errores.

    
pregunta DXM 13.12.2011 - 08:20

7 respuestas

5

No creo que realmente llegues a ningún lado sin volver a trabajar de la manera en que se hacen las cosas en este momento.

  

Un ejemplo es que durante el desarrollo solo nos enfocamos en nuevas características   e ignorar los errores existentes e incluso introducir nuevos errores.

Estoy bastante seguro de que esto es un grave error. Trate de explicar que la corrección de errores se vuelve más difícil y más costosa cuanto más se pospone. No creo que haya ninguna excusa para posponer las correcciones de errores por tanto tiempo.

Todos los métodos ágiles que conozco enfatizan que el software debe estar técnicamente listo para enviarse al final de cada ciclo / iteración (o incluso de manera continua). Eso significa que cualquier error que no desee enviar debe solucionarse antes de que se inicien las nuevas funciones.

Intente trabajar con personas y explique sus inquietudes.

Finalmente, si no puede obtener ningún tipo de acuerdo sobre dichos conceptos básicos, puede ser mejor seguir adelante.

Editar

Basado en su pregunta modificada: Estoy de acuerdo en que la corrección de errores se debe manejar como nuevas características. Normalmente tendría tareas individuales para errores "pequeños" (hasta unas pocas horas) e historias con subtareas para errores "grandes" (varios días, posibles de dividir en tareas). Si sus colegas no están de acuerdo, señale que las ventajas de los métodos ágiles se aplican a la corrección de errores al igual que a las nuevas características.

En cuanto a utilizar una herramienta de seguimiento ágil o una base de datos de errores: Idealmente, los dos están integrados. Si no lo son, entonces sí, tendrás que seguir el trabajo en ambos. Es molesto, pero lo hice yo mismo, y no me pareció un gran problema. Realiza un seguimiento de los errores como de costumbre, y simplemente copia y pega la identificación del error en el título de una tarea / historia cuando programas un error en el que se va a trabajar. La tarea es solo un enlace al bugtracker (eays si ambos están basados en la web), y toda la discusión está en la base de datos de errores. Si vinculas de forma consistente, es probable que incluso puedas ejecutar informes en ambos sistemas.

Finalmente, si crees que no puedes cambiar la forma en que se organiza el desarrollo, tendrás que trabajar dentro de estas restricciones. Probablemente ayuden cosas como introducir algunos métodos ágiles en la fase de corrección de errores.

Aún así, estoy convencido de que dividir el desarrollo en una "fase característica" y una "fase de corrección de errores" es un error grave, posiblemente fatal. Puede que no sea tan serio para su compañía (cada situación es diferente), pero si lo es, y si su organización no puede cambiar esto, entonces su organización puede ser tan disfuncional que estaría mejor en otro lugar. Pero esa es tu llamada para hacer ... ¡buena suerte!

Editar 2

Finalmente, si las políticas de la compañía dictan "características primero, solución de errores más adelante", tal vez puedas evitarlas, por ejemplo. al redefinir las correcciones de errores como nuevas características (la diferencia es a menudo una cuestión de opinión de todos modos). Hasta cierto punto, puedes intentar introducir nuevas ideas "desde abajo" de esa manera. Ya sabes, "si no puedes vencerlos, únete a ellos".

    
respondido por el sleske 13.12.2011 - 12:06
4
  

Un ejemplo es que durante el desarrollo solo nos centramos en las nuevas funciones e ignoramos los errores existentes e incluso introducimos nuevos errores.

Esto es algo malo. Una cosa muy mala.

No eres "semi-ágil" si estás introduciendo errores durante una iteración. Deberías haber conseguido que las cosas funcionaran y haber vuelto a poner las cosas en el backlog porque no se estaban haciendo.

Si tardas 6 meses más en construir cosas, no pasas 6 meses probando y corrigiendo errores.

Se supone que es simple. Deja de apresurarte y llama código malo "hecho".

Si la administración insiste en acelerar el código incorrecto a un estado "hecho", no tienen en cuenta la pérdida de tiempo que tienen los 6 meses de corrección de errores llamada "prueba". Informarles.

  

También algunos errores son definitivamente del tamaño de una historia de tamaño medio, mientras que otros errores tardarían 5 minutos en solucionarse. ¿Deberían los errores de 5 minutos también convertirse en historias si tuviéramos que continuar con las iteraciones?

Realmente no tienes más remedio que poner los errores en el registro e intentar iterar correctamente. Las cosas no se "hacen" hasta que están libres de errores.

Si no puede obtenerlo sin errores, volverá a la reserva para la siguiente iteración. Entonces, podrás hacerlo libre de errores.

    
respondido por el S.Lott 13.12.2011 - 12:08
3

Intente esto: reduzca sus iteraciones a un tamaño que pueda hacer y probar en la fase de codificación. Su fase de prueba finalizará pronto (IE: sin embargo, el tiempo de ejecución de sus pruebas unitarias)

Alternativamente: Ignora las puertas. La definición de Código Completo de su empresa no tiene sentido de todos modos. Si no ha escrito ningún código para una característica en la fase de prueba, declare que esa característica está "hecha" y presente un error por el hecho de que aún no funciona.

    
respondido por el Matthew Scouten 13.12.2011 - 17:02
2

¿Cómo sabes que tu código está completo sin ninguna prueba? ¿Cómo validas que puedes cruzar la Puerta 2?

Mi forma de hacer Agile in a Waterfall como desarrollador es hacer un TDD oculto detrás de una cortina de depuración.

Al hacerlo, sé cuándo mi código está completo y confío en su estabilidad.

Por supuesto, la codificación demora más de 2 meses, pero la codificación + las pruebas demoran menos de 8 meses.

Acerca de las nuevas características / corregir errores, estoy seguro de que puede asegurarse de que no se pueda introducir la nueva característica si ese error no se ha solucionado antes.

    
respondido por el mouviciel 13.12.2011 - 10:14
1

Hm. No es que realmente haya hecho esto, pero me parece que uno de los modelos más ideales para esta situación estaría basado en la técnica ágil de "jugar y luego desechar el experimento". Trate todo el código que creó durante dos meses de no tener la oportunidad de crear un buen código como un experimento largo: ahora tiene claro qué quiere lograr y también más o menos cómo. Tíralo y comienza a hacer las cosas bien. Cada vez que finalice con éxito una función, repórtela como "error corregido". Después de todo, hacer todo bien desde el principio es la mejor manera de corregir errores de código heredado inherentemente defectuoso. Considere el esfuerzo de dos meses como un código mal legado que necesita ser completamente refactorizado, simplemente repórtelo como corrección de errores.

    
respondido por el herby 13.12.2011 - 10:36
1

Hay problemas para mapear procesos puramente ágiles (como SCRUM) en una configuración de proyecto. El mayor problema es que, en el enfoque ágil, hay una constante negociación y reevaluación del alcance para cada iteración. Sin embargo, en un proyecto, tendrá un plazo fijo, un presupuesto fijo y una expectativa de lo que se debe entregar EN ESTA FECHA. Para mí, SCRUM se trata de mantenimiento de software más que una metodología de proyecto.

Mi sugerencia (que me he empleado) es reducir las puertas. Si está intentando mantener, por ejemplo, iteraciones de 4 semanas, entonces sus puertas deben ser de 4 semanas. Establecer entregables y "definiciones de hecho" para cada puerta. Si, al final de una iteración / puerta aún tiene errores en su código, entonces la puerta no está completa y debe marcarse como vencida. Esta es la mentalidad en la que tanto usted como las partes interesadas de su negocio deben tratar de entrar. Al final de cada iteración, debe haber un conjunto completo de objetivos y no características a medio terminar o que no funcionen.

    
respondido por el pap 13.12.2011 - 12:56
1

¿Solías trabajar para mi antigua empresa? Las similitudes son aterradoras ...

Algunos consejos ... nada de lo que digas o hagas cambiará el proceso de ninguna manera significativa. Usted no es un primer ministro, no tiene muchas certificaciones de PM ni ninguna importancia política para efectuar un cambio en una operación tan grande. Exponer cómo están haciendo las cosas mal inevitablemente equivaldrá a que apuntes con el dedo a alguien de mayor importancia política que tú y te despidan. También he visto que esto suceda.

Sus opciones son claras, conviva con ellas y acéptelo, porque es probable que el proyecto tenga un presupuesto enorme y que los clientes se vean afectados por el bloqueo de los proveedores o los contratos gubernamentales, por lo que literalmente hay incentivos para completar el trabajo en menos tiempo. Además, ¿por qué centrarse en la calidad si no afecta su balance final?

Si la situación anterior no describe la posición del mercado de su empresa, es solo una cuestión de tiempo antes de que una startup ágil y ágil coman su almuerzo y lo pongan fuera del negocio. Si lo hace, entonces puede decidir vivir con él y continuar o irse a una compañía que realmente se centra en producir software, y no a una compañía que encuentra formas de justificar un presupuesto masivo consumiéndolo.

    
respondido por el maple_shaft 13.12.2011 - 13:12

Lea otras preguntas en las etiquetas