Del traductor:
El comienzo del año es un buen momento para evaluar cuidadosamente el año pasado. Eche un vistazo a lo que está sucediendo y comprenda cómo hacer que 2019 sea un año mejor, más tranquilo y más productivo. En este caso, encontramos útil el artículo Cómo reducir la velocidad para ir más rápido que nunca en el desarrollo de software escrito por Lemi Orhan Ergin . Y publicamos su traducción a continuación.
Puntos clave:
- La prisa no nos hace más rápidos o más eficientes; aumenta el estrés y hace que sea imposible concentrarse. En lugar de apresurarse, necesita un enfoque creativo, eficiencia y enfoque.
- Contratar a los especialistas más talentosos, trabajar juntos, practicar y estudiar juntos. Esto aumentará la profesionalidad y creará una cultura de excelencia en la empresa.
- Desarrolle flexibilidad de equipo y eficiencia de proceso al hacer planes y revisarlos regularmente. Encuentre, analice y elimine cualquier fuente de pérdida de tiempo.
- No puede ser flexible sin una base de código de calidad. Elimine defectos, publique versiones con más frecuencia, escriba pruebas antes de escribir el código principal, realice una refactorización, concéntrese en un diseño simple.
- Ejecutar software no significa que esté bien diseñado. Solo los verdaderos profesionales pueden crear software de alta calidad que le permita desarrollarse lo más rápido posible.
La ejecución de tareas más rápida posible puede convertirse en su enemigo si se involucra en el desarrollo sin control. Hay tres áreas importantes para reducir la velocidad: personas, procesos y productos. Antes de sumergirme en los detalles, déjame contarte una historia.
Que yo recuerde, fue 2011. Me uní al equipo que creó la plataforma para el marketing en línea. Mi tarea principal era agregar nuevas funciones lo más rápido posible. Yo era un desarrollador senior. Llamamos a los desarrolladores "senior" cuando se desarrollan más rápido que otros, ¿verdad? Sin embargo, cuando comencé a trabajar, notamos que era casi imposible trabajar rápidamente debido a deudas técnicas y fallas en el diseño del sistema. También notamos que con cada intento de acelerar, aumentamos la complejidad y destruimos la calidad. Llegué a la conclusión de que la única forma de acelerar es reescribir el sistema desde cero.
Recuerdo que durante una conversación telefónica con el gerente de producto dije que necesitábamos reescribir todo el sistema. Después de 30 segundos de silencio, el gerente preguntó: "Usted dice que su equipo ha desarrollado un producto de tan mala calidad que ahora este mismo equipo debería reescribir el mismo producto nuevamente, pero esta vez es mejor hacerlo. Derecho? Lo siento, pero esto es inaceptable. Deberías haberlo escrito mejor de inmediato.
El software Zombie necesita reescribirse una y otra vez
Según
el Informe de Caos del Grupo Standish , el 94% de los proyectos se rehicieron desde cero más de una vez. Este es un gran número. Al recordar los proyectos en los que trabajé, entiendo que casi todos fueron reescritos desde cero utilizando nuevas tecnologías, con nueva arquitectura y diseño. Copiar desde cero es tan típico de nuestra industria que las empresas a menudo lo ven como la única forma de desarrollar y administrar un proyecto. Primero escribimos, y luego reescribimos y reescribimos, una y otra vez.
Necesitamos conocer a nuestros principales enemigos. La velocidad es una cualidad vital en el desarrollo de software. Es importante no solo ingresar al mercado primero, sino también responder rápidamente a las opiniones de los clientes, agregar funciones y corregir errores para que los usuarios estén contentos con el producto.
Pero todos tenemos problemas con el concepto de "velocidad". Creemos que el avance rápido y las acciones razonables y efectivas están de alguna manera relacionadas con el establecimiento de plazos. Creemos que el resultado se logrará más rápido si trabaja más duro o atrae a más personas. Como resultado, agregamos nuevas personas al proyecto o trabajamos horas extras para acelerar el trabajo. La prisa no nos hace más rápidos ni más productivos. La prisa crea una atmósfera estresante, nos priva de la oportunidad de concentrarnos en el trabajo y destruye la productividad. Lo que se necesita es creatividad, eficiencia y concentración.
El desarrollo de software es una cosa muy complicada. No podemos deshacernos de esta complejidad. Por lo tanto, necesitamos vivir con ella. El requisito de trabajar rápidamente crea una atmósfera inestable y turbulenta, nos sumerge en el estrés y hace que sea imposible trabajar productiva e intensamente. Este enfoque simplemente no funciona.
Productividad del equipo (capacidad), plan maestro, estimaciones de costos laborales, horas de trabajo fijas, plazos y velocidad del equipo (velocidad del equipo): todo esto es ilusorio. La incompetencia es real. La velocidad de entrega depende directamente de la profesionalidad de las personas, la eficiencia de los procesos y la calidad del trabajo realizado. La mayoría de las veces, los propios desarrolladores establecen plazos internos para sí mismos, incluso si esto no es necesario.
Como resultado, obtenemos un sistema heredado. La presión de los plazos combinados con la incompetencia conduce a un código heredado, un callejón sin salida para un mayor desarrollo del sistema. Solía usar otro nombre para sistemas heredados: software zombie. Esta definición funciona mejor, porque el legado es literalmente un software muerto, pero parece funcionar en la producción. Funciona e incluso trae dinero, pero requiere la sangre, la vida y la energía de los desarrolladores para poder trabajar de alguna manera. Los desarrolladores tienen miedo de tocar el código que funciona, nadie quiere desarrollarlo.
Robert C. Martin habló muy bien sobre los sistemas heredados en su twitter : "Si su software se vuelve cada vez más difícil de desarrollar, está haciendo algo mal". Trabajando con prisa, estamos reduciendo tanto la calidad que con cada paso, el trabajo se ralentiza cada vez más. Estoy seguro de que la única forma de desarrollar más rápido es ralentizar el proceso hasta lograr la estabilidad.
El apuro en el desarrollo de software es malo
En una serie de CleanCoders, Robert C. Martin dijo : "El valor principal del software es la capacidad del sistema para adaptarse a los cambios futuros y simplificar su implementación". El apuro es malo en el desarrollo de software. Cualquier intento de apresurarse conducirá a una caída importante en la productividad, el enfoque, la efectividad de las personas, la adaptabilidad a los cambios y la flexibilidad del software.
Por ejemplo, siempre tenemos tiempo para corregir errores, pero no hay tiempo para escribir pruebas. No refactorizamos ni escribimos pruebas porque tenemos poco tiempo. Pero siempre tenemos tiempo para depurar, manejar muletas y corregir errores.
Estamos tan centrados en el proceso que a menudo nos olvidamos de lo más valioso para el desarrollo de software: las personas. Los procesos ayudan a las personas a crear mejores productos, aumentar la motivación y cultivar un ambiente de trabajo saludable. En última instancia, la eficiencia del proceso es importante, pero no hay nada más valioso que las personas.
Debes entender que nadie y nada es perfecto. Los clientes, ejecutivos, gerentes, miembros del equipo, representantes comerciales, incluso usted, no son todos perfectos. Los requisitos, la documentación, las herramientas, el código, un sistema desarrollado y su diseño tampoco serán ideales. Por lo tanto, debemos detenernos rápidamente y acelerar el desarrollo sin pensarlo. La única forma de moverse más rápido a un ritmo constante es reducir la velocidad en tres direcciones importantes:
- Personas: aumento de profesionalismo y habilidad,
- El proceso está mejorando la flexibilidad y la eficiencia,
- Producto - mejora de la calidad y automatización.
Dónde frenar cuando se trata de personas
Los procesos y las herramientas no crean un producto. La gente lo hace. Vale la pena reconocer que "contratar talentos" es la tarea más importante de la empresa, lo que tiene un impacto directo en el futuro de la empresa en su conjunto y en el producto que se está creando en particular.
Contrata a los más talentosos de tu organización. Al decir "lo más", no me refiero a lo más inteligente y experimentado. Estoy buscando al menos entusiasta, disciplinado y motivado. Si una persona tiene estas tres cualidades, desarrollará fácilmente sus talentos.
La contratación debería ser beneficiosa para ambas partes. Por lo tanto, ralentice el proceso de contratación y tómese el tiempo para mejorarlo. Las personas se unen a compañías en las que creen. Simule qué tipo de personas espera ver en su equipo. Y haga que las personas talentosas crean en usted, mirando su cultura, su idea del futuro y sus empleados.
El ego es el veneno que mata lentamente a su organización. Nunca dejes que se infiltre en tu organización. Comenzando por tontos que son agradables en la comunicación y terminando con idiotas brillantes, no dejes que los extremos se vuelvan parte de tu equipo. No contrates personas con un ego hinchado. Con ellos, nunca crearás una cultura corporativa que deleite a los demás.
Dejen de trabajar solos, trabajen juntos. No permita la fragmentación en el equipo. Los desarrolladores solitarios y héroes son un signo de organización disfuncional. Siéntate cerca. Establecer estándares con todo el equipo. Trabajar en parejas o grupos; revisar juntos Permita que todos los participantes en el proceso sean responsables del resultado.
Practicar juntos es la forma más efectiva de mejorar tus habilidades. Al interactuar, no solo inspiramos a otras personas, sino que también aprendemos unos de otros.
Ejecute regularmente
retiro de código ,
codificación de dojo y
randori con todo
su equipo. Pase 30 minutos todos los días solo practicando.
Deje que el conocimiento se extienda entre las personas. Aprender juntos
Realicé sesiones de
Brown Bag / Lunch & Learn con todos los equipos en los que trabajé desde 2010. Dos veces escuché de mis colegas: "Participar en las sesiones los miércoles me permite bombear, y esto me motiva mucho". Esto refleja claramente los beneficios de mantener mitaps internos regulares.
Recopile comentarios y déselos a otros. Para recopilar comentarios colectivos, organice una gran retrospectiva. He estado haciendo esto por más de un año. Por cierto, esta es una excelente manera de sumergirse en la resolución de problemas con un grupo de 20 o más personas.
Enseñar a otros y compartir conocimientos es la mejor manera de lograr el dominio. Hablar públicamente y contribuir a la comunidad.
En general, se acepta que los desarrolladores odian escribir documentación. Pero la realidad dice lo contrario. Cualquier resultado que otras personas lean es documentación. Comenzando desde el código del sistema y terminando con el código de prueba, desde mensajes hasta confirmaciones hasta el gráfico de confirmación en el repositorio, desde mensajes de registro hasta mensajes de error, los desarrolladores crean una gran cantidad de documentación sin darse cuenta. Y, sin importar lo que documente, si la gente lo lee, documente lo mejor posible.
No sois niños La organización no son tus padres. Todos deberían administrar sus carreras de forma independiente e invertir en sí mismos. Si su contribución implica perder tiempo o dinero, hágalo usted mismo.
Cómo ralentizar y mejorar el proceso
Todos los días nos enfrentamos a nuevos desafíos. Estas no son solo las necesidades del mercado y los requisitos de nuevos productos. Los desafíos técnicos también afectan nuestro progreso.
Los planes no son nada, pero la planificación lo es todo. Haga un plan y revíselo constantemente. Especialmente en las primeras etapas de un proyecto cuando se necesita la máxima flexibilidad. La reconciliación diaria con un plan como scrum diario o standup diario no es suficiente. Es necesario interactuar más estrechamente dentro del equipo, trabajar en parejas y consultar el plan aún más a menudo. Mantenga la duración mínima de iteración hasta una semana. Organice múltiples canales de comentarios con revisiones periódicas y sesiones de demostración.
Definir objetivos a corto y largo plazo. Los objetivos a corto plazo establecen el enfoque para el equipo, los objetivos a largo plazo evitan su pérdida.
Si desea comprender por qué algo va mal, visualice el flujo de trabajo, tanto desde el punto de vista técnico como organizativo. Visualice errores y fallas para maximizar el aprendizaje de primera mano.
Nunca tome decisiones basadas en sentimientos. Siempre recopile datos, analice y tome decisiones basadas en ellos. También es importante dar a cada desarrollador acceso a productos y métricas técnicas. Esto aumenta la participación y la comprensión del producto que se está desarrollando.
El desperdicio es todo en lo que pasa el tiempo, pero eso no tiene valor para el negocio. Encuentre y elimine el desperdicio en la oficina, en el código y en los procesos comerciales.
Los Boy Scouts dejan el estacionamiento más limpio que cuando llegaron. La misma filosofía se aplica al desarrollo de software. Siga la regla de exploración y mantenga el código más limpio después de cada cambio. Si va a agregar una nueva funcionalidad y ve fallas en el archivo que se pueden solucionar, hágalo sin pedir permiso. Recuerde escribir las pruebas primero. Esto le dará confianza para hacer cambios.
Puede descubrir desperdicios en cualquier punto del ciclo de desarrollo del sistema. Siga criterios claramente definidos para la preparación (definición de hecho) y elimine las tareas en el espíritu de "90% terminado, 90% restante".
No permita la aparición de ramas de larga vida: se consideran malvadas. No verifique su código manualmente. Con las pruebas manuales, es probable que verifique un script de ejecución exitoso. Todas las demás secuencias de comandos solo se pueden verificar mediante código. Por lo tanto, tome este problema en serio.
Cómo la desaceleración puede mejorar la calidad del producto
Una cosa es segura: sin una base de código de alta calidad, no puede ser flexible, lo siento. Lo primero que debe hacer es eliminar la deuda técnica y corregir los errores. Si es necesario, detenga el desarrollo de nuevas funciones y concéntrese en corregir errores.
El enfoque "Lo arreglaré rápidamente, luego lo arreglaré" no funciona en las realidades actuales, porque es demasiado arriesgado. Al eliminar errores, se necesita un enfoque más disciplinado. En primer lugar, escriba una prueba que reproduzca el problema. Después de eso, corrige el error y asegúrate de que la prueba pase ahora. Ahora puede enviar el parche de manera segura a producción.
Trabajé en equipos que pasaron casi todo su tiempo arreglando errores y manteniendo el proyecto. La razón de su sufrimiento es el trabajo inestable en la producción. Para continuar desarrollando nuevas funcionalidades, mientras corrige los errores, deberá dividir el equipo en equipos virtuales. Por ejemplo, en cada iteración, seleccionamos dos tipos que están involucrados en el soporte y la corrección de errores. Los llamamos Batman y Robin. No importa qué funcionalidad tenga prisa por terminar, los errores se corrigen sin interrupción del desarrollo principal.
Los desarrolladores a menudo usan una de las prácticas de desaceleración para acelerar aún más las solicitudes de extracción. Detienen el desarrollo continuo, realizan comprobaciones y realizan revisiones de código para mejorar la calidad del código. El código no verificado nunca llegará a producción.
Nuestro objetivo final debe ser la transición a la entrega continua y los lanzamientos frecuentes. Comenzando con el uso de ramas git y terminando con estrategias de implementación, desde formas de proporcionar comentarios hasta prácticas de prueba automatizadas, todo esto requiere un enfoque especial.
Las prácticas que utiliza en las diferentes etapas del ciclo de desarrollo de software muestran qué tan rápido se está desarrollando. Cuando trabaje con sucursales, utilice el enfoque “comprometerse temprano, comprometerse a menudo, perfecto más tarde, publicar una vez”. Si trabaja sin ramas, use las funciones de alternancia. Esto eliminará la pérdida de tiempo.
He estado usando TDD por años. A menudo la gente se queja de que TDD afecta negativamente la velocidad de desarrollo.
Joe Rainsberger compartió sus pensamientos sobre TDD en Twitter : “
¿Te preocupa que TDD desacelere a tus programadores? No es necesario Probablemente necesiten reducir la velocidad ".
TDD es más refactorizante que prueba; más pensamiento que codificación; Más simplicidad que elegancia. Es por eso que TDD conduce a una mayor calidad. Cuando use TDD, solo tendrá el número mínimo suficiente de pruebas y un diseño simple.
¿Alguna vez ha logrado una cobertura del 100% del código con las pruebas? Lo alcancé en un proyecto de tres meses, cubrí cada línea de código de producción con pruebas. En ese momento, me sentí como un héroe con superpoderes. Pero cuando implementamos el sistema en preproducción para las pruebas de aceptación, notamos que las cuatro funciones no funcionaban. Escribí pruebas de integración y funcionales para encontrar y corregir errores. En ese momento, me di cuenta de que las pruebas unitarias no garantizan un buen diseño y funcionalidad funcional. Deje de contar el porcentaje de cobertura del código como pruebas. Esta métrica no muestra nada.
Corrija los errores de inmediato si demora 30 minutos o menos. Además, use el 20% del tiempo para eliminar la deuda técnica.
Como regla general, escribimos código sin la intención de cambiarlo en el futuro. Al diseñar un sistema, elegimos de manera similar tecnologías y herramientas, planificando no cambiarlas en el futuro. Pero estamos equivocados. La refactorización debería ser posible en cualquier etapa del proyecto. Como dice Kent Beck, necesitamos hacer cambios fáciles para que otros cambios sean fáciles. Para hacer esto posible, almacenamos el código de todos nuestros microservicios en un mono-repositorio. Esto hace que la refactorización sea fácil y realmente necesaria.
Cualquier decisión en el diseño es errónea si se toma antes de lo necesario. Debe esperar el último momento aceptable para tomar una decisión. Utilizamos la arquitectura "Puertos y adaptadores" para lograr un bajo acoplamiento y una alta cohesión a nivel de diseño de todo el sistema. Debido a esto, obtenemos monolitos perfectamente diseñados.
Un monolito no es malo, el mal es un mal diseño. Siempre comenzamos con el desarrollo de un monolito y, gracias a la arquitectura de "puertos y adaptadores", extraemos partes de la funcionalidad en microservicios. Como dijo Martin Fowler
en su primer artículo de Monolith : “Comenzar con la arquitectura de microservicios de inmediato es arriesgado, es mejor comenzar con un monolito. Dividir en microservicios solo cuando y si es necesario.
Disminuir la velocidad para acelerar como un acercamiento a la vida
Andreas Möller
compartió sus sentimientos sobre el desarrollo de software en un tweet : "No quiero escribir código que simplemente funcione. Quiero escribir código que sea limpio, fácil de mantener, fácil de entender y bien probado ".
Para lograr esto, debemos centrarnos en tres áreas: personas, procesos y productos. Disminuyendo la velocidad del trabajo de las personas, nos esforzamos por aumentar la profesionalidad y la habilidad. Al ralentizar el proceso, nos esforzamos por aumentar la flexibilidad y la eficiencia. Y al ralentizar el trabajo en el producto, nos esforzamos por aumentar el nivel de automatización y el nivel de calidad. Cuando nos enfocamos en estas tres áreas, comenzamos a cultivar una cultura que hace posible un rápido desarrollo.
Debemos recordar lo siguiente:
- Un sistema de trabajo no está necesariamente bien escrito
- Solo los verdaderos profesionales pueden crear un sistema bien diseñado
- Solo un sistema bien diseñado le permitirá lanzar una nueva funcionalidad lo más rápido posible
Sobre el autor
Lemi Orhan Ergin es
un asistente de desarrollo de software que busca elevar el nivel de excelencia en su industria y compartir su experiencia con la comunidad.
Cofundador de Craftbase y fundador de
la Comunidad Turca de Artesanía de Software . Ha estado involucrado en el desarrollo de software desde 2001. Practica y asesora activamente en áreas como Scrum, programación extrema, metodologías de desarrollo y tecnologías web.