Cómo detener el enchapado en oro y simplemente contentarse con lanzar desarrollos de trabajo [cerrado]

29

El equipo de desarrollo del que soy miembro se ha adaptado recientemente para trabajar de acuerdo con las prácticas ágiles. Esto ha resaltado personalmente el hecho de que no puedo evitar el código (y la documentación) chapados en oro y, en consecuencia, supero las estimaciones originales, cuando pude haber entregado soluciones que cumplen los requisitos mucho antes.

Creo que mi ética raya en lo obsesivo porque me apego demasiado a mi código y rara vez me contento con liberarlo antes de refactorizarlo y perfeccionarlo en el enésimo grado. Estoy feliz de haberme dado cuenta de esto, pero ¿cómo puedo cambiar mi actitud / mentalidad para estar contento con mi progreso y liberarlo a tiempo?

Andy Bowskill
fuente
77
Definir chapado en oro. Para mí, el chapado en oro está agregando cosas innecesarias (en términos Lean, produciendo desperdicio como funcionalidad innecesaria, demasiada documentación o documentación que no agrega valor). Parece que no está agregando cosas que no son necesarias, sino que solo pasa tiempo refactorizando en lugar de eliminar nuevos productos de trabajo.
Thomas Owens
Por chapado en oro me refiero a esforzarme por perfeccionar un diseño (tal vez para tratar de fomentar su reutilización en el futuro) que ya cumpla con sus requisitos, no necesariamente agregando nuevas funcionalidades.
Andy Bowskill
¿Qué piensa tu jefe?
JeffO

Respuestas:

22

Lo mejor es enemigo de lo suficientemente bueno.

Siempre puede hacer más pruebas, escribir mejor documentación, descubrir esos casos de esquina, completar lo que cree que faltan características, hacer que la arquitectura sea más limpia. Nunca se acaba. Sin embargo, tiene que terminar. Hay fechas de vencimiento que deben cumplirse, restricciones externas que dependen de la parte del producto que se está terminando. La lucha por la perfección en una pequeña parte de un producto perjudica al producto en su conjunto.

David Hammen
fuente
2
Gracias David, eso me recuerda mucho a una cita pertinente que leí recientemente: "Perfecto es el enemigo de lo hecho".
Andy Bowskill
1
Como el original está en francés (Voltaire), es un poco difícil decir qué versión es "correcta", a menos que se haya escrito en francés, claro.
David Hammen
24

En primer lugar, desearía que más desarrolladores tuvieran este problema, no porque el software terminaría siendo lanzado más tarde de lo esperado sino porque probablemente sería una versión de mayor calidad.

Si está excediendo sus propias estimaciones originales, tal vez necesite incluir sus pasos de "chapado en oro" como parte de sus estimaciones. Si no son sus propias estimaciones, tal vez debería participar en su formulación.

En cualquier caso, si tiene una fecha límite de lanzamiento, debe cumplirla. Cualquier "chapado en oro" debe dejarse como un paso final que no debe retrasar un lanzamiento. Si considera que debe incluirse como parte de un lanzamiento, considere agregar el "baño de oro" en su propio tiempo (es decir, fuera del horario laboral).

Lo que debe hacer es presentar sus pasos de "chapado en oro" a su equipo y / o gerencia y discutir por qué cree que son importantes. Si puede convencerlos de que estos pasos son beneficiosos, deberían formar parte de futuras versiones.

Bernardo
fuente
Gracias Bernard, buen consejo. Sí, esto también resalta el tiempo y el costo versus la calidad de la compensación del producto final.
Andy Bowskill
@AndyBowskill, estoy teniendo el mismo problema que tú. ¿Como estas ahora?
datasn.io
14

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.

DesarrolladorDon
fuente
Buena respuesta detallada. +1. Re "pero debe suceder temprano": es otoño, así que usaré una analogía deportiva estadounidense. Imagínese si un equipo de fútbol operara como un negocio típico con sus revisiones anuales de empleados. "Estamos reduciendo su salario en un 50%. Se perdió tres capturas fáciles en el primer juego, en los siguientes cuatro juegos no tuvo su cara hasta el segundo trimestre, y su carrera fue deficiente durante toda la temporada". Una vez al año, las críticas hacen más daño que bien. No existe la crítica constructiva si es demasiado tarde en el futuro.
David Hammen
Enlace roto con la gente de la montaña y la gente del bosque.
Comodín
7

¿También programas para divertirte? También me han molestado las restricciones en el trabajo que le quitan la diversión a la programación y, para compensarlo, a veces pongo en marcha un nuevo proyecto en casa y "lo hago bien". La división me permite satisfacer tanto mis necesidades como las de la empresa.

O bien, podría desarrollar una nueva habilidad que no sea programar para hacer en su tiempo libre que (eventualmente) satisfaga lo que el trabajo no puede proporcionar. ;)

duanev
fuente
Bienvenido y gracias por hacer tu primera publicación en Stack Exchange Programmers. Considere ingresar preguntas de seguimiento como comentarios a la pregunta y no como respuesta. Puede obtener más información sobre los criterios para escribir preguntas y respuestas de alta calificación, y obtener una insignia al leer las preguntas frecuentes en programmers.stackexchange.com/faq
DeveloperDon
Gracias duanev, tu primer párrafo definitivamente también me suena cierto.
Andy Bowskill