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?
agile
programming-practices
productivity
development-process
scrum
Andy Bowskill
fuente
fuente
Respuestas:
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.
fuente
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.
fuente
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:
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.
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:
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.
fuente
¿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. ;)
fuente