Software chapado en oro
La primera vez que vi el chapado en oro utilizado como una descripción para el software fue en un documento de Barry Boehm, donde dio la siguiente causa raíz:
Oro platino. Las especificaciones de requisitos fijos antes del diseño tendían a alentar el chapado en oro del software. Los usuarios a quienes se les preguntó sobre sus requisitos con frecuencia razonaban: "No sé si necesitaré esta función o no, pero también podría especificarla por si acaso".
En su descripción, recomienda utilizar los métodos descritos en su investigación, incluido el modelo de ciclo de vida del software en espiral en el que los proyectos se definieron para producir una serie de prototipos, uno por ciclo, y a medida que las espirales se hicieron más grandes, un producto con todas las funciones. Spiral tuvo una amplia influencia entre los investigadores de software y fue un puente importante entre la cascada y Agile. Una limitación crítica de la espiral es que cada vez alrededor de la espiral, los ciclos se hacen más largos y más caros.
Al igual que con Agile, la espiral intenta evitar el enchapado en oro al determinar con mayor precisión y programar la entrega del proyecto el tiempo suficiente para que los equipos puedan completar los requisitos, mientras que al mismo tiempo es lo suficientemente corto como para permitir centrarse en el objetivo desde el primer día hasta el día de la entrega. Una forma en que los métodos ágiles como Scrum son superiores es que Scrum corre por un período de tiempo que no se alarga con las iteraciones. Según el documento, la gestión de proyectos parece tener más influencia en el chapado en oro que los desarrolladores individuales.
Talento para Time Boxing
Ser capaz de cronometrar el tiempo es muy importante, pero no es una habilidad binaria. No lo tienes o te falta. Eres mejor o menos bueno con eso. Ya sea que provenga de su jefe o de usted, preferiría que nadie dijera que no puede detener el chapado en oro. Eso suena a personal, generalizado y permanente.
Un análisis de causa raíz podría ayudar a identificar varios problemas. Estoy bastante seguro de que no todos te señalarán, y que a menos que trabajes con psicópatas, otros en tu equipo verán necesidades similares para mejorar su conjunto de habilidades ágiles. Si conoce a alguien sin problemas, no lo conoce muy bien. Si conoce a alguien que piensa que no necesita mejorar, no se conoce a sí mismo muy bien.
Espero que las mejoras que identifique sean cosas que pueda resolver con su propia conciencia y ayuda del equipo. Sin embargo, creo que no es donde termina esto. Mi expectativa del supervisor o gerente que escribe sus comentarios sería que también pueden entrenar a sus subordinados para tener éxito. Esto es particularmente crítico cuando la organización está experimentando un cambio revolucionario como cambiar de planeado a ágil (o ad-hoc a ágil).
¿Prototipo rápido y sucio o de riesgo gestionado?
Tenía un gerente que solía solicitar que las tareas se realizaran de cierta manera.
Rápido y sucio, pero algo bello.
Sabía la tontería de esto, y era parte de su irónico sentido del humor. Mucha gente dice cosas como esta y están hablando muy en serio. En algún lugar, existe un compromiso o una oportunidad para aliviar el problema con una tecnología o enfoque mejorado.
¿Qué podemos sacrificar para adaptarse a nuestra caja de tiempo?
En el capítulo uno de Extreme Programming Explained , segunda edición, Kent Beck habla sobre lo que se necesita para moverse rápido. Su respuesta es que "solo hace lo que debe hacer para crear valor para el cliente".
Riesgo
En la primera edición del mismo libro, Beck se identifica un poco más de cerca con las opiniones de Boehm sobre el control del riesgo como críticas para su metodología al decir:
"El riesgo es el problema básico del desarrollo de software"
En ambas ediciones, Beck enumera y describe ocho riesgos comunes, seguidos de una afirmación de que XP (o quizás, por extensión, Agile) aborda cada uno de una manera particular. Para mí, la mayor parte de su explicación se reduce al uso de incrementos más pequeños e iteraciones más rápidas que nos permite reorientar el rumbo antes de que los riesgos sean demasiado grandes para manejarlos.
Mentalidad de Suficiencia
Beck discute los recursos en el contexto de una historia sobre la gente de la montaña y la gente del bosque e introduce un concepto llamado "Mentalidad de Suficiencia". En el contexto de su situación, le pregunta "¿Cómo lo haría si tuviera suficiente tiempo?" Solo este primer capítulo, disponible como vista previa de un libro, puede proporcionar mucha información sobre cómo XP (y otros métodos ágiles) piensan sobre limitaciones como el tiempo.
La compulsión podría ser el síntoma, no la enfermedad
Hace años, miré un libro sobre la procrastinación que decía que mucha procrastinación se origina en el miedo. Si no comienzas, no te equivoques, y tal vez no seas criticado. La compulsión y el perfeccionismo dan algo que nuestro sentido moral nos dice que es mejor que la dilación, pero que probablemente tenga el mismo resultado. ¿Considera que tal vez tiene un problema con la dilación en otra forma?
Crítica y competencia
En metodologías ágiles como Scrum, las oportunidades de ser criticado o castigado por procrastinación nunca han sido tan altas. Ese es un círculo vicioso. Procrastino porque me critican, me critican porque postergo. Con las reuniones de scrum diarias, siempre estamos alertas porque siempre estamos un día o menos informando al equipo lo que hemos logrado.
En un equipo ideal, Scrum brinda una oportunidad diaria para corregir la dilación. Los errores no deberían tener tiempo para crecer antes de que llegue la ayuda. Los equipos no siempre están donde deberían ser confiables, por lo que los líderes dentro del equipo pueden necesitar abordar de manera proactiva las críticas o el miedo a las críticas para permitir que las cosas avancen.
En nuestro mundo laboral, cada persona en un equipo también debe competir con los demás. Es un poco esquizofrénico creer en tener un equipo que comparta el trabajo y la gloria por los logros, pero luego use un proceso anual de gestión del desempeño que recompense al 20% de sus miembros, castigue o expulse al 10% o más de los miembros, y pretende que la mayoría del 70% contribuye mejor sin incentivos. Creo que este es un gran elefante en la sala WRT que promueve el trabajo en equipo, y para hacer referencia a la historia de Kent Beck, muestra profundos lazos culturales con ser gente de montaña.
El camino a seguir
Como miembro de un equipo ágil, sería bueno estudiar y dialogar con otros sobre lo que funciona. Si su equipo está utilizando TDD para automatizar sus pruebas unitarias con una herramienta, busque a la persona que mejor lo haga para que lo asesore. Si su supervisor o gerente tiene un problema con su enfoque de documentación, averigüe qué le gusta o quién lo hace de la manera que le gusta y siga su enfoque. Si se reduce a la velocidad de codificación sin procesar, investigue lo que se necesita para codificar más rápido.
Los líderes pueden tomar medidas en la dirección correcta modelando los comportamientos deseados, como hablar con franqueza sobre sus propios problemas (no los de otra persona), ofreciendo y siguiendo con ayuda, manteniendo un diálogo sobre cómo el equipo puede moverse al estilo Agile Marine (es decir, ningún hombre Dejado atrás). No todos en el equipo tienen las mismas habilidades. Puede ser apropiado explorar el emparejamiento de los miembros del equipo o la asignación de tareas y roles que puedan enfatizar las fortalezas complementarias de las personas involucradas. La planificación para el crecimiento o remediación de habilidades debe ser una parte gratificante del trabajo tanto para el supervisor como para el subordinado, pero debe realizarse temprano y, a menudo, para ser eficaz.