Get best of the week

Por qué los desarrolladores son tan lentos: problemas comunes y sus soluciones

Hola Habr! Les presento la traducción del artículo Por qué los equipos de desarrollo son lentos: problemas y soluciones comunes de software de Eric Elliot.



Si le gusta escuchar más que leer, entonces, en formato de audio, la traducción está disponible en Yandex.Music y Apple Podcasts.

Veamos qué causa las interrupciones en el proceso de desarrollo de software y qué puede hacer usted como gerente al respecto. Puede haber muchas razones, por lo que nuestra lista, por supuesto, estará lejos de ser exhaustiva. En cambio, nos centraremos en algunos de los problemas más comunes :

  • Expectativas irrealistas
  • Demasiados boletos abiertos
  • Alcance incontrolado de tareas
  • Revisión del código de acumulación
  • Mala preparación
  • Desarrolladores de Burnout
  • Loco
  • Rotación de personal

El desarrollo lento no es la raíz del problema. Este es un síntoma de los otros problemas enumerados. En el 100% de los casos, si el equipo de desarrollo trabaja demasiado lento, es culpa del líder. Pero la buena noticia es que puedes arreglarlo. Miremos cada uno de los elementos con más detalle para comprender qué podemos hacer con cada uno de ellos.

Expectativas irrealistas


La mayoría de los problemas con la productividad de los desarrolladores generalmente no afectan el desarrollo en sí. Es más bien un problema de nuestra percepción del proceso de desarrollo como gerentes y partes interesadas.

La parte más difícil del trabajo de un gerente es comprender que escribir código toma tanto tiempo como sea necesario y tratar de acelerar este proceso solo lo ralentizará y aumentará la cantidad de errores. La paciencia es nuestro todo.

Muy a menudo, el problema con la velocidad del trabajo no es que el equipo no sea lo suficientemente productivo, sino que se enfrenta a altas expectativas. Y esto es completamente su responsabilidad. Si la presión proviene de un liderazgo superior, entonces no ha formado su visión correcta de la situación. Si la presión viene de ti, sigue leyendo.

A menudo olvidamos que el software que creamos es algo fundamentalmente nuevo. Si ya tiene un software que hace lo mismo, cómprelo, úselo, importe el módulo, etc. No es necesario volver a escribirlo desde cero. El nuevo software es único. Hace algo nuevo o hace algo diferente. Es entonces cuando lo creamos. Y como todavía no lo hemos hecho, ¿cómo sabemos cuánto tiempo llevará?

Los constructores construyen muros prefabricados al mismo ritmo y, por lo tanto, pueden proporcionar estimaciones más o menos precisas basadas en observaciones. Los desarrolladores de software no tienen datos confiables en los que confiar. Este problema se ve exacerbado por las diferentes velocidades de los diferentes desarrolladores, y puede variar en un orden de magnitud.

Como Steve McConnell, autor de The Perfect Code, escribe: “La conclusión de que existe una diferencia significativa entre la productividad de los diferentes programadores ha sido confirmada por muchos estudios realizados por desarrolladores profesionales (Curtis 1981, Mills 1983, DeMarco y Lister 1985, Curtis et al. 1986, Card 1987 , Boehm y Papaccio 1988, Valett y McGarry 1989, Boehm et al. 2000). No tenemos suficientes datos para predecir cuánto tiempo llevará completar nuestro proyecto. Descubriremos qué escala y complejidad ya está comenzando a funcionar y este proceso a menudo está lleno de muchas sorpresas. "El desarrollo no es solo planificación, sino también investigación, sin importar cuán cuidadosamente tratamos de prever todo".
« 90 10 , . 10 90 »
— , Bell Labs

Hay varias razones para las altas expectativas que un gerente puede controlar. Una de las razones fundamentales es medir las cosas equivocadas.
Es posible que esté familiarizado con el famoso dicho de Peter Drucker: "Lo que se mide se controla".

Y, por supuesto, este es un gran consejo. ¡Por supuesto que debemos medir! Pero echamos de menos la esencia de esta cita, además, damos la vuelta a su significado.

La idea es: "Lo que se mide se controla, incluso si se mide y tratar de controlarlo es completamente inútil, incluso si perjudica los objetivos de la organización".

Dos ejemplos de cosas que no vale la pena medir:

  1. Gráficos predictivos de consumo que muestran un gráfico del número de tickets abiertos que predicen la fecha de finalización de un proyecto en función de mediciones recientes de la velocidad de trabajo;
  2. El número de tickets cerrados por el desarrollador, que muestra cuántas tareas completó un desarrollador individual.

Medir estas dos cosas le cuesta a innumerables compañías enormes pérdidas debido a la pérdida de productividad, empleados y otros costos.

Diagramas de progreso de tareas


Muchas herramientas de software intentan predecir la fecha de finalización del proyecto, en función de la escala actual de tareas y la velocidad del trabajo. El problema es que ninguno de ellos tiene en cuenta el volumen inexplorado de tareas. Además, esto es imposible, porque el tiempo que lleva cerrar una tarea puede variar en un orden de magnitud para diferentes tareas, lo que puede distorsionar significativamente los valores promedio que se calcularon para tickets ya cerrados.

Si establece un plazo basado en la fecha del cuadro, considere que no ha cumplido los plazos. Lo único que puede salvarlo es eliminar la mayor cantidad posible de tareas en el futuro.

Cuando basa sus calificaciones en información incompleta, usted y su equipo definitivamente pagarán por ella. Las estimaciones poco realistas crean expectativas poco realistas. Esto puede ser un verdadero desastre si también comparte estas calificaciones con el equipo de marketing, los clientes y la prensa.

No todas las cartas son malvadas. Los que no intentan predecir el futuro pueden ser útiles. Pueden advertirnos sobre la propagación del proyecto y las explosiones combinatorias cuando vea que el número de boletos aumenta en lugar de disminuir o moverse hacia arriba y hacia abajo. Los diagramas de tareas útiles demuestran tareas ya cerradas de manera realista, en lugar de tratar de predecir el futuro.

Un buen indicador es una curva que tiene altibajos, pero en general se mueve hacia abajo, lo que muestra una disminución en el número de tareas abiertas al final del proyecto.

Programa del proyecto donde se reduce el número de boletos

Un proyecto que sufre un alcance de crecimiento excesivo estará representado por una curva que se dobla hacia arriba.

Programa de un proyecto que se ahoga en nuevas tareas

Tenga en cuenta que el punto de observar esta curva no es tratar de cambiarla, sino reconocer y resolver los problemas subyacentes. No queremos que los programadores simplemente dejen de abrir nuevos boletos.

El objetivo es la transparencia de los procesos, no una hermosa curva descendente.

Tenga cuidado con el principio de Goodhart : "Si una dimensión se convierte en una meta, entonces deja de ser útil".

Ningún pronóstico es dañino. Cuando tiene una fecha límite difícil (por ejemplo, está tratando de lanzar un juego antes del Black Friday), puede controlar sistemáticamente el alcance en función de la velocidad promedio del trabajo, para que sepa cuándo comenzar a recortar el alcance. Si el pronóstico te dice que terminarás no antes de diciembre, confía en él. Ha llegado el momento de priorizar y reducir.

La regla general para las predicciones de este tipo es:
"Si la predicción dice que puedes hacer algo en una fecha determinada, no lo creas, si dice que no puedes hacerlo, créelo.

Entradas cerradas por un programador


La idea de contar todas las tareas realizadas por un programador y luego comparar esta cifra con el valor promedio es muy tentadora. Pero te insto a resistir esta tentación. Hay toneladas de mejores formas de recopilar datos de productividad del desarrollador.

Hay dos fallas fundamentales en el cálculo de tareas cerradas. En primer lugar, las tareas no son idénticas entre sí en complejidad e importancia, y de hecho, el valor del trabajo depende de la ley de poder. Un pequeño puñado de tareas representa un orden de magnitud más significativo que el "promedio". Es como la diferencia entre la base de un rascacielos y el último clavo obstruido. Por lo tanto, simplemente contando el número de tickets cerrados, es imposible saber exactamente el valor de un empleado.



Hace muchos años, trabajé en una cesta de compras para un líder minorista global. Una vez dejé de escribir código y de cerrar tickets en Jira y agregué otro ticket: "Estudio de usabilidad".

Llevo más de un año trabajando en un rediseño de la canasta y la fecha de lanzamiento se acerca rápidamente. Hasta ese momento, el usuario no realizó pruebas de usabilidad del nuevo proceso de pedido, por lo que tomó una semana. Le dimos acceso temprano a los mil seguidores más leales y los entrevistamos para obtener comentarios.

Analicé los resultados y encontré una tendencia alarmante en las encuestas y los registros: la frecuencia de usuarios que abandonaron el sitio en la etapa de canasta era demasiado alta y se expresó en un número de dos dígitos. ¡Se acercaba un verdadero desastre! Así que me puse a trabajar y planeé grabar nuevas pruebas de usabilidad con presencia personal. Me senté a los novatos detrás de nuestra nueva canasta, les di algunas tareas y los dejé solos con el sitio. No dije nada, solo los vi usar la nueva interfaz.

Noté que en el proceso de hacer un pedido, las personas tienen dificultades con los errores en los formularios. Con estos datos, corregí ligeramente nuestro proyecto de código abierto en el github (sin notar nada en la Gira). Después de un tiempo, realizamos otra prueba. Es mucho menos probable que los usuarios abandonen la página de la canasta: la diferencia de ingresos para la empresa es de $ 1 millón por mes.

Mientras tanto, mis colegas cada uno cerró 10-15 boletos. Se podría argumentar que podría obtener más tickets de prueba de usabilidad para reflejar la realidad. Pero luego tendría que hacer mil boletos adicionales, lo que solo crearía ruido y requeriría mucho tiempo.

Otra razón por la cual contar boletos cerrados es ineficaz es que los miembros más efectivos del equipo también son las personas a las que todos recurren en busca de ayuda. Saben más sobre la base del código, o son grandes desarrolladores, o tienen habilidades de comunicación sobresalientes. Lo ayudan a superar la acumulación de solicitudes de extracción, revisar el código de otros programadores, capacitar y guiar a sus compañeros de equipo. Son los más productivos del equipo, porque ayudan al resto del equipo a duplicar la velocidad del trabajo. Quizás los tickets que cierran son la creación de marcos o bibliotecas que aumentan la productividad de todo el equipo. Ellos hacen la mayor parte del trabajo mientras que el resto recibe reconocimiento.

Si no tienes cuidado, luego vea la contribución de sus desarrolladores más productivos. La mejor manera de averiguar qué están haciendo los programadores para un proyecto es preguntarles. Pregúntele al equipo quién creen que es su colega más útil.

Por lo general, la información que se refleja en esta retroalimentación es muy diferente de los datos que se pueden obtener simplemente contando el número de tickets.

Recopile datos de rendimiento, pero no se acerque a cada desarrollador con una sola medida. El desarrollo es un deporte de equipo y cada participante en el proceso juega un papel en él. No existe un método mágico único que sea adecuado para evaluar todo, sin excepción.

Demasiadas tareas abiertas


Parecería simple: abrir un ticket en el rastreador y seguir adelante. Pero cada tarea en el rastreador requiere un ciclo de procesamiento completo.

Deben clasificarse, priorizarse y asignarse un artista antes de que los desarrolladores puedan comenzar a implementarlos. Este trabajo se repite cada vez que los desarrolladores cierran una tarea y eligen la siguiente. Si tiene un gerente de proyecto o un maestro de scrum, lo hacen cada vez que vuelven a priorizar la lista de tareas (que generalmente ocurre al comienzo del sprint o solo una vez cada dos semanas).

Luego, el desarrollador necesita profundizar en el contexto de la tarea, comprender la esencia del problema, descomponer las tareas complejas en subtareas, y solo entonces finalmente puede comenzar a ejecutar.

Crear y leer boletos es mucho trabajo, pero es como un trabajo falso. Esta es una meta tarea. Ella es necesaria para comenzar tareas reales. Por sí mismos, tienen valor cero. Y esto lleva tiempo cada vez que los programadores eligen la siguiente tarea. Cuantas menos entradas haya al mismo tiempo en el rastreador, mejor. Mientras menos tareas de baja prioridad se encuentren en la cartera de pedidos, mayores serán las posibilidades de que el desarrollador elija una tarea de alta prioridad.

Si hay un error que solo un usuario ha mencionado, ¿qué importancia tiene para nosotros? Tocó a una persona, pero ¿tenemos errores que más personas notaron? ¿Hay alguna característica nueva que sea más útil que corregir este error?
Probablemente si.

Elimine el ruido del trabajo atrasado. Elimine lo que no planea hacer en el futuro cercano.
Si esto es realmente importante, agregue más tarde cuando haya tiempo para esto.

Tamaño de tarea no controlada


Me gusta pedirles a los desarrolladores de mi equipo que dividan el trabajo en tareas que pueden completar en un día. Esto es más complicado de lo que parece, porque requiere la capacidad de dividir tareas complejas en pequeñas, que también se pueden probar por separado del resto de la aplicación.

Ejemplo: está realizando un nuevo proceso de pago en un sitio. No necesita mezclar componentes de IU, administración de estado y comunicación con el servidor en un compromiso gigante que involucra 13 archivos, todos profundamente relacionados con la base de código actual, porque el resultado será una gran solicitud de extracción que es difícil de revisar y fusionar.

En su lugar, comience con un módulo de estado de la cesta del lado del cliente probado de forma independiente y haga una solicitud de extracción para esto. Luego construya la API del servidor y haga un RP por separado para él también. Luego, escriba un componente de la interfaz de usuario que importe el estado del módulo y se comunique con la API del servidor. Cada una de estas tareas se puede dividir en tareas separadas, aunque todo esto es esencialmente una gran característica. Como beneficio adicional, las tareas se pueden distribuir entre varios programadores y acelerar el desarrollo, aprovechando el tamaño del equipo.

El conmutador de características hará que este proceso sea más fácil y seguro, permitiéndole desactivar la funcionalidad desarrollada hasta que esté lista para su inclusión en la producción.

Nota:No intente hacer esto sin una buena cobertura de las pruebas de humo. Debería poder asegurarse de que no ha roto nada mediante la implementación de funciones semiacabadas. Asegúrese de verificar cómo funciona tanto dentro como fuera.

Acumulación de tareas por revisión de código


Cuando los desarrolladores muerden más de lo que pueden tragar, el resultado es una gran solicitud de extracción en espera de revisión y verificación.

Esta es la fase de integración en "Integración continua" (CI). El problema es que cuanto más tiempo permanezca abierto el RP, más tiempo se dedica a él. Los desarrolladores lo abrirán para ver si pueden ayudar a frenarlo. Dejarán comentarios, solicitarán cambios y la solicitud volverá al autor para realizar cambios y aprobarlos aún más. Mientras tanto, toda esta solicitud de extracción se alejará del maestro.
Cuando varios desarrolladores tienen la costumbre de realizar confirmaciones muy grandes, el número de solicitudes de extracción comienza a crecer como una bola de nieve y la integración se vuelve cada vez más complicada.

Ejemplo: Bob realiza cambios en un archivo que Jane también gobierna, pero que aún no ha hipotecado. La solicitud de extracción de Bob se lleva a cabo primero y PR Jane se convierte en una confirmación más del maestro. Ahora no puede mantener su rama hasta que arregle todos los conflictos con el código de Bob. Multiplique esta situación por la cantidad de programadores que trabajan con el mismo código en su proyecto. Tales "embotellamientos" dan lugar a un exceso de acciones.

Calculamos el número de tales acciones en el escenario estándar:

  • Bob y Jane comienzan a trabajar en la misma rama (0 acciones)
  • Bob hace cambios y se compromete con su rama. Jane hace lo mismo (2 acciones)
  • El código de Bob va al maestro. Jane descarga los cambios de Bob y descubre un conflicto. Ella lo corrige y compromete el resultado a su hilo. (3 acciones)
  • Jane abre una solicitud de extracción. Bob señala que sus cambios en su código romperán algo que ella no tuvo en cuenta. Jane realiza cambios basados ​​en los comentarios de Bob y confirma el código nuevamente (4 acciones)
  • PR Jane finalmente se fusionó. Solo 4 acciones.

Ahora considere una situación en la que las confirmaciones serían menores y las solicitudes de extracción parpadearían más rápido:

  • Bob hace un pequeño cambio y su código cae en el maestro (1 acción)
  • Jane descarga la nueva versión del asistente y escribe su código teniendo en cuenta los cambios de Bob. (2 acciones)
  • Dado que cometer a Jane también es pequeño, se lo retiene rápidamente en el maestro. Total solo dos acciones.

Cuando creamos pequeños RP, reducimos significativamente la necesidad de rehacer el código, que es causado por conflictos y la complejidad del código.

Mala preparación


La industria de TI es terrible en términos de capacitación y soporte. Los algoritmos de enseñanza en profundidad de las universidades que ya están integrados en bibliotecas estándar y solo unos pocos programadores los escriben desde cero.

Si bien se pasan por alto los conceptos básicos del desarrollo, como los principios de abstracción, conectividad y compromiso, modularidad versus diseño monolítico, trabajar con módulos, composición de funciones, composición de objetos, diseño de marcos y arquitectura de aplicaciones. Debido al crecimiento explosivo de la industria, aproximadamente la mitad de los desarrolladores tienen menos de cinco años de experiencia y el 88% de los especialistas creen que la capacitación no los perjudicaría.

Los equipos trabajan lentamente porque no comprenden bien lo que están haciendo y nadie quiere enseñarles.

Nuestra tarea como gerentes es contratar especialistas experimentados que puedan guiar a nuestros equipos y asignarles tiempo para que hagan esto.

Qué se puede hacer:

  • Revisión de código: los desarrolladores aprenden mucho al aprender el código de los demás
  • Creación de pares de ingenieros senior y junior: no es necesario crear pares permanentes, una unión única para resolver un problema específico funciona bien.
  • Tiempo especial dedicado a la tutoría: contrate a profesionales experimentados que adoren aprender y comunicarse y deles tiempo para compartir experiencias con desarrolladores junior, esto ayudará a estos últimos a comprender cómo desarrollan sus habilidades.

Agotamiento


Hacer que su equipo se agote es un gran revés para el líder que no cumplir con los plazos.

El agotamiento es un problema grave que puede conducir a la pérdida de desarrolladores, rotación de personal, costos enormes, aumento del factor de graves ( Factor de bus: una medida de la concentración de información entre los miembros individuales del proyecto; el factor significa el número de participantes del proyecto, después de la pérdida del cual el proyecto no puede ser completado por los participantes restantes) .

Pero, lo que es más importante, el agotamiento conduce a problemas de salud. Las consecuencias del agotamiento pueden conducir a la desestabilización del cuerpo e incluso a la muerte por un ataque al corazón o un derrame cerebral. En Japón, este fenómeno está tan extendido que incluso tienen una palabra especial: "karoshi".

El líder puede quemar a todo el equipo, anulando por completo su productividad. El problema de quemar equipos enteros es especialmente común en la industria de desarrollo de juegos de computadora, donde el Black Friday es casi siempre una fecha límite difícil.

Desafortunadamente, "morir, pero hágalo" es un principio común de organizar el trabajo de estos equipos, aunque los gerentes rara vez se dan cuenta de los peligros de este enfoque.

En lugar de obligar a los desarrolladores a trabajar más, los gerentes deben reconocer que el 100% de la responsabilidad de cumplir con los plazos recae en la gerencia, no en los desarrolladores.

La fecha límite es más fácil si utiliza las siguientes técnicas:

  • Priorice mejor las tareas y reduzca los ámbitos
  • Agilizar procesos
  • Reconocer y refactorizar la confusión del código

Rotación de personal


Los datos recopilados por Linkedin en 2018 mostraron que la rotación del personal de TI es superior a la de cualquier otro negocio. Y esto es malo, porque causa el riesgo del factor bajo, el riesgo de que pierdas especialistas clave de tu proyecto.

Muchas empresas no otorgan importancia a la retención de especialistas. Echemos un vistazo más de cerca a cuánto cuesta la rotación de personal.

La colocación de vacantes cuesta 15-30 mil dólares. El tiempo del ingeniero cuesta un promedio de $ 90 por hora. Multiplique esto por aproximadamente 50 entrevistas y muchas, muchas horas para responder las preguntas del novato y ayudarlo a acostumbrarse al equipo. Por lo tanto, ya hemos gastado 50 mil dólares, pero eso no es todo.

Puede tomar hasta un año para que un nuevo empleado alcance el nivel del desarrollador al que reemplazó, con la primera vez que cometerá muchos errores y pasará mucho tiempo reparándolos.

Por lo tanto, contratar y capacitar a un nuevo desarrollador, los costos de oportunidad y la pérdida de productividad de un equipo que tiene que capacitar a un principiante durante algún tiempo y al mismo tiempo llevar a cabo parte de su trabajo es casi el 90% del salario de un desarrollador fallecido. Encontrar un reemplazo puede llevar varios meses, y luego tomará más tiempo para que el principiante logre su plena efectividad.

Todo esto lleva mucho tiempo y los grandes equipos sufren constantemente el trabajo continuo, porque según una encuesta de 2019 realizada por Stack Overflow, el 60% de los desarrolladores cambiaron de trabajo en los últimos dos años.

Cuando el desarrollador finalmente comience a trabajar con la máxima eficiencia, lo perderá.

¿Cómo evitar la fluidez? Aquí hay algunos consejos de varias fuentes:

  • Paga honestamente
  • Aumenta tu salario regularmente
  • Deja que la gente se vaya de vacaciones
  • Ofrecer trabajo remoto
  • Mantenga expectativas realistas
  • Proporcionar tareas que serán de interés para el desarrollador.
  • No dejes que la pila de tecnología envejezca demasiado
  • Proporcionar capacitación y oportunidades profesionales.
  • Proporcionar beneficios para la salud
  • No obligue a los desarrolladores a trabajar más de 40 horas a la semana.
  • Proporcionar a los empleados equipos modernos.

Loco


Si crees que no tienes tiempo para implementar un proceso de desarrollo de alta calidad, entonces realmente no puedes prescindir de él.

Según Evaluating Software Engineering Technologies (David N. Card, Frank E. Mc Garry, Gerald T. Page, 1978), los procesos bien optimizados pueden reducir los errores sin aumentar los costos. La razón principal es que, según otro libro, "Evaluaciones de software, puntos de referencia y mejores prácticas" (Casper Jones 2000), la detección y corrección de defectos es una de las tareas de desarrollo más costosas y que requieren más tiempo.

Los errores son conocidos por causar la necesidad de procesar el código, y cuanto más tarde los encuentre, más costoso será repararlos. Cuando un desarrollador recibe instrucciones de corregir un error que ya se descubrió en la producción, esto a menudo lo desgarra de lo que estaba haciendo. En el libro "A Diary Study of Task Switching and Interruptions" (Mary Czerwinski, Eric J. Horvitz, Susan Wilhite) dice que una tarea de la que estamos distraídos puede tomar el doble de tiempo y contener el doble de errores, lo que sugiere que los errores de alta prioridad son de alguna manera contagiosos: arreglando uno, es probable que generemos nuevos.

Los errores en la producción también requieren que prestemos más atención al soporte y son usuarios muy molestos y agotadores, lo que finalmente le costará dinero. Tendrá que invertir en arreglar la funcionalidad anterior en lugar de crear una nueva.

Un error encontrado en la etapa de desarrollo se puede solucionar en un par de minutos, mientras que un error encontrado en la producción pasará por muchas fases adicionales: informar un error, verificar, priorizar, nombrar a un artista y finalmente desarrollarlo.

Pero eso no es todo. Este error tendrá su propia confirmación, su solicitud de extracción, código de revisión, integración y posiblemente incluso su propia implementación. Y en cualquier etapa puede caer alguna prueba y el ciclo completo de CI / CD deberá comenzar de nuevo.

Como ya se mencionó, un error en la producción le costará mucho más que un error encontrado durante el desarrollo.

Los siguientes consejos ayudarán a mejorar la calidad del proceso.

  • Reduzca la velocidad para acelerar. Lento significa ininterrumpido, ininterrumpido significa rápido.
  • Realizar una revisión de diseño. La combinación de verificación de código y requisitos le permite detectar hasta el 70% de los errores.
  • Revisión del código postal. El código bien probado es 90% más fácil de mantener. Una hora de revisión le ahorra 33 horas de soporte. Los programadores que realizan revisiones de código son un 20% más productivos.
  • Utiliza el enfoque TDD. Reduce la cantidad de errores en un 30-40 por ciento.
  • CI/CD. , , . , . CI/CD .
  • Aumentar la cobertura de la prueba . Su proceso de CI / CD debe ejecutar pruebas y detenerse si al menos uno de ellos falla. Esto ayudará a evitar el despliegue de errores en la producción y le ahorrará mucho dinero y tiempo. Su objetivo es al menos el 70% de cobertura, pero trate de mantenerse cerca del 80%. A medida que se acerque al 100%, notará que la cobertura de procesos de usuario importantes con pruebas funcionales le proporcionará más que un aumento adicional en las pruebas unitarias.

Conclusión


Hay muchas formas de influir en el rendimiento del equipo, que incluyen:

  • Establecer expectativas realistas
  • Rastrea y controla el número de tareas abiertas
  • Controlar tamaños de tareas
  • No permita que las tareas se acumulen mediante la revisión de código
  • Desarrollar desarrolladores
  • Proporcionar un buen equilibrio entre trabajo y ocio.
  • Implementar procesos de desarrollo efectivos
  • Presta atención a la retención de empleados

More articles:


All Articles