computer

No se estadísticas: cómo guardar sus iniciativas de desarrollo de software fallidas


Comencemos con lo obvio. En la actualidad, es muy probable que su organización tenga problemas para entregar software de alta calidad a tiempo y dentro del presupuesto. Alcance, costo, cronograma: le han dicho que puede controlar dos, pero probablemente tendrá problemas para cumplir con cualquiera de ellos.

Y no estás solo. De hecho, más del 70 por ciento de los proyectos de TI fracasan. Este fracaso destruye carreras y corporaciones, causando una salida colectiva de más de $ 196 mil millones por año para la economía mundial, una suma aparente que excede el PIB de todos menos nueve países.

Aunque todos sabemos que un proceso de prueba continuo reduce drásticamente el riesgo de falla, muchas organizaciones todavía tienen problemas para introducir pruebas continuas . Entonces, ¿cómo puede asegurarse de que su equipo combate los errores y no otras estadísticas?

Sigue leyendo para descubrir cómo manejar algunos de los obstáculos y dificultades más comunes.

Los requisitos y la planificación adecuados tienen la máxima prioridad.
La razón principal del fracaso de los proyectos es la falta de requisitos procesables.

Por el momento, una gran cantidad de sus tickets de solicitud son probablemente solo una breve oración resumida en el título. O tal vez alguien ha adjuntado una presentación monolítica de PowerPoint a un solo ticket para documentar nuevas características en múltiples sprints. ¿Quizás en su lugar tenga un par de miles de errores generados automáticamente de una auditoría de accesibilidad completada hace dos años? No importa Independientemente del formato que adopten, los requisitos inconsistentes obligan a los desarrolladores a confiar en gran medida en sus propias interpretaciones subjetivas de los elementos que se crean. Esto afecta su productividad y reduce significativamente sus posibilidades de éxito.

¿Cómo hago eso bien?
Para tener éxito, los requisitos deben ser y deben ser exigibles y deben probarse . Esto puede ayudarlo a evitar lo siguiente:

  1. Desarrolladores que crean algo diferente a lo previsto,
  2. tiempo perdido en reuniones de personalización,
  3. tiempos de producción dramáticamente más lentos,
  4. horarios perdidos, porque tuvieron que ser reconstruidos durante la UAT y
  5. un aumento de los problemas que permiten a sus clientes en la producción.

Para reducir el riesgo, mantenga sus requisitos al mínimo y desarrolle MVP . Y al menos asegúrese de tener una historia de usuario, criterios de aceptación y un plan de prueba para realizar un seguimiento.

El objetivo de los requisitos debe ser tener suficiente información en cada ticket que cada desarrollador pueda recuperar y ejecutar. No tiene que perder tiempo descifrando hilos de correo electrónico u organizando reuniones para comprender las preguntas. Tener un buen conjunto de plantillas de requisitos y una guía de documentación de flujo de trabajo consistente para todo el proyecto ayudará a todos a saber cómo funciona su proceso.

Optimice los requisitos antes de crearlo. Todos los nuevos requisitos deben ser revisados ​​por sus arquitectos, desarrolladores (idealmente las mismas personas que hacen el trabajo) y sus equipos de garantía de calidad. Asegúrese de tener suficiente tiempo para hacer preguntas y dar su opinión. También es importante incluir a alguien de su equipo de control de calidad durante el proceso de planificación para crear planes de prueba, escribir guiones de prueba e identificar los registros de prueba requeridos. Los gerentes y los equipos de ventas simplemente transmiten los requisitos a los desarrolladores sin ponerse a discutir, o alientan a los desarrolladores a proponer mejoras. Esta es una forma de trabajo terriblemente desactualizada (que casi garantiza el fracaso).

Crea una fuente unificada de verdad para tus necesidades. Asegúrese de que todos los equipos que tocan el código funcionen de la misma manera para lograr un enfoque en toda la empresa sobre lo que significa "hecho" y el proceso para llegar allí. Con demasiada frecuencia, los "escuadrones de construcción" y los "escuadrones de mantenimiento" tienen su propia forma de trabajar, sus propios requisitos o herramientas de seguimiento de errores, o sus propios flujos de trabajo de implementación. Esta inconsistencia trae caos a tu proyecto.

Lleva a todos a la misma página. Considere si desea dar a todos en su organización acceso a su sistema de planificación de requisitos y capacítelo. Las ideas pueden venir de todas partes, y mantener los sistemas transparentes y abiertos le permite obtener información importante más rápido. Tener las personas adecuadas para comunicarse directamente elimina el tiempo innecesario y el riesgo asociado con una complicada cadena de mando.

Cree plantillas de problemas consistentes. Una vez que todos estén familiarizados con el proceso y las herramientas (¡asegúrese de incluir esto en su proceso de incorporación!), Puede crear plantillas de problemas consistentes. Simplemente comience con "Nueva función", "Mejora" y "Error". Es probable que algunos problemas no tengan todos los detalles requeridos. Por lo tanto, se les puede pedir a los desarrolladores que mejoren los problemas con sus suposiciones antes de la codificación. Sin embargo, asegúrese de que todos sepan sobre su proceso de "hacer-para-hacer", y asegúrese de que sea culturalmente aceptable en su organización que las personas usen tickets no conformes para obtener más detalles. Devuelve el creador.

Siempre solicite comentarios. Cada equipo tiene necesidades y requisitos ligeramente diferentes. Por lo tanto, es importante recibir comentarios sobre sus plantillas. Asegúrese de documentar lo que todos necesitan, y si su software necesita pasar por pruebas de accesibilidad, pruebas de seguridad u otras pruebas de conformidad, asegúrese de que estos requisitos se especifiquen de antemano para que todos puedan cumplir con esos estándares. Además, asegúrese de que sus estándares de codificación, licencias aprobadas y procesos de revisión de códigos estén actualizados y actualizados.

Ahora que tiene un conjunto de plantillas de requisitos con las que su equipo está satisfecho, configure un proceso para el ciclo de vida del desarrollo. Todos estamos familiarizados con las columnas de metodología Kanban "To-Do", "In Progress", "In Review" y "Done". Agregue una columna "Planificación" y asegúrese de que nada se mueva a "". Tareas pendientes "hasta que se haya revisado y todos en el equipo estén contentos con eso. De esa manera, sus tickets "en progreso" se eliminarán de la cartera de "tareas pendientes" y todos saben que la lista de tareas pendientes se puede editar.

Automatizar la implementación, las compilaciones y la generación de datos para automatizar las pruebas [19659010] La implementación continua requiere automatización cuando se mueve el código entre entornos. Es importante desarrollar un plan con su equipo de DevOps para garantizar que los entornos se puedan aprovisionar automáticamente y que se proporcione el código para las pruebas. A medida que la industria mejora en general, demasiadas empresas de clase empresarial todavía tienen un proceso de construcción manual y pudieron crear " construcciones diarias " hace 20 años para centrarse más en la pregunta: "¿Se puede construir una compilación según sea necesario con un comando?"

Estas compilaciones no requieren solo un entorno y un código. También deben probarse en cada paso del camino para que pueda identificar los problemas temprano y en el origen. Las pruebas requieren acceso a datos de pruebas de calidad y con demasiada frecuencia se realizan pruebas en pequeños conjuntos de datos que solo prueban los buenos resultados de la ruta.

Espera lo inesperado
Las pruebas de pista perfectas dejan mucho al azar. ¿Qué sucede si falla una API de la que depende? Si no sabe, o no ha instalado la copia de seguridad correcta o los mensajes de usuario, tendrá clientes desafortunados. Así que asegúrese de tener un proceso para crear datos de prueba ricos y realistas o recuperar datos de producción limpios que pueda usar como parte de las pruebas. Las pruebas realistas, las pruebas de ruta interrumpida o incluso algunas pruebas de caos realmente pueden ayudarlo en esta fase.

Además, tenga en cuenta que los sistemas modernos son complicados y a menudo están interconectados. No solo creamos una aplicación independiente. Estamos creando algo basado en numerosos sistemas de back-end e integraciones de terceros que pueden tener o no un modo sandbox para las pruebas. Esto significa que, además de los datos de prueba "internos", también puede necesitar servicios virtuales simulados o "simulados" si no puede probarlos con producción o un servicio de terceros. Al introducir servicios simulados, puede escribir pruebas unitarias que incluyan Haga pruebas negativas o pruebas de caos para asegurarse de saber cómo se comporta su código en una variedad de circunstancias del mundo real. ¿Suena complicado? No es así si usas las herramientas adecuadas . Si su organización tiene dificultades para cubrir las pruebas de componentes, concéntrese en las pruebas de punto final de API.

Reducir, reutilizar, reciclar
Si bien la automatización puede ayudar, su equipo puede optimizar y reutilizar el código para reducir la carga de trabajo general. Esto reduce la cantidad de pruebas requeridas y la sobrecarga para corregir errores y realizar mejoras.

Mire las áreas generales, por ejemplo. Por ejemplo, inicie sesión en las páginas de los usuarios o administre formularios de perfil, y asegúrese de reutilizar la validación y el manejo de errores. Esto contribuye a una experiencia de usuario coherente y simplifica la cantidad de código que admite. Teniendo en cuenta que el 70% de las pruebas siguen siendo manuales, pequeños pasos como estos pueden aliviar a sus ingenieros de control de calidad y darles más tiempo para trabajar en tareas de automatización.

¿Por qué automatizar?
Debe haber suficiente tiempo disponible para crear prioridad de prueba automatizada. Una vez que haya creado una prueba, solo necesita tocarla nuevamente si el código subyacente para la prueba ha cambiado. Por lo tanto, es infinitamente reutilizable con un gran ROI. Los ahorros en costos generalmente se amortizan en un sprint; imagine los ahorros que puede obtener durante un año o la vida útil de ese código.

La automatización no solo ahorra tiempo. También aumenta la calidad considerablemente. Incluso una simple actualización de dependencia puede afectar otras partes del sistema y puede tener implicaciones de largo alcance. Cuanto más automatice, más fácil será ejecutar pruebas completas del sistema para asegurarse de que su "cambio fácil" logre el resultado deseado (sin extras no deseados).

Se pone aún mejor: con muchas herramientas modernas puede grabar pruebas de frente. Detenga las pruebas de IU e intente nuevamente. Con las herramientas adecuadas, puede crear de forma económica las pruebas automatizadas infinitamente reutilizables en lugar de probarlas manualmente una vez. Eso es una brisa.

Trabaja de manera más inteligente, no más duro.
Si tiene requisitos limpios, otro gran beneficio es la capacidad de generar automáticamente sus casos de prueba. La creación y gestión manual de casos de prueba ahorra una enorme cantidad de tiempo, y rara vez se realiza a fondo. Sin embargo, con las herramientas y los requisitos correctos, puede reducir el esfuerzo en uno o dos tamaños.

Durante su transición de automatización, probablemente estará experimentando con una variedad de herramientas, y el costo de las herramientas de código abierto las hará atractivas. Pero cuando esté listo, busque herramientas comerciales que le permitan importar cualquier prueba que haya creado. Cuando puede reutilizar cosas que ya tiene, es mucho más fácil mantener el impulso.

¿No quieres crear todo tú mismo desde cero? Muchos frameworks y plataformas tienen excelentes herramientas para verificar sus propias mejores prácticas o un conjunto de pruebas funcionales predefinidas. Aunque estas herramientas no siempre se adaptan a sus necesidades específicas, la cobertura de prueba es mejor que ninguna. Para proyectos web, Lighthouse es una gran herramienta que se puede agregar fácilmente a su proceso de construcción para revisar páginas web e informar problemas generales de rendimiento, seguridad o usabilidad.

Lleve herramientas a los desarrolladores [19659010] Durante el desarrollo, el costo de corregir un error es significativamente menor que intentar solucionarlo cuando entra en producción. Un truco en el tiempo ahorra nueve (o en este caso 1000 veces, según algunas cuentas, puede costar 1000 veces ). Errores recientes de Boeing y Samsung ilustran el daño que puede tener la falta de pruebas apropiadas para la reputación de su negocio.

No es difícil ver cómo ocurren tales problemas. Con el viejo enfoque en las fases lineales aisladas las pruebas no tendrían lugar hasta que los desarrolladores hayan terminado. Dado que las pruebas generalmente tenían un límite de tiempo, era raro que se ejecutaran todas las pruebas. Además, los datos resultantes pueden no ser devueltos a los desarrolladores hasta el próximo sprint. Estos retrasos implican un alto grado de riesgo, y hay suficiente tiempo para que el desarrollador original olvide el contexto o entregue el proyecto por completo a alguien que no conoce los requisitos.

En cambio, puede encontrar rápidamente herramientas que pueden integrarse fácilmente con los IDE de sus desarrolladores o ejecutarse desde la línea de comandos o en el código. Al integrar todas las herramientas juntas, puede eliminar el obstáculo de múltiples sistemas y variables de entorno, para que los desarrolladores puedan encontrar y corregir errores más fácilmente en su propio código. Sin embargo, para capitalizar estos beneficios, es importante que cualquiera que escriba código tenga acceso a las herramientas de prueba, sepa cómo usarlas y las use .

Construyendo una cultura de colaboración con retroalimentación rápida
El objetivo de pruebas continuas es crear ciclos de retroalimentación rápidos, pero esto no se limita al código. Dado que el desarrollo de software no termina con el lanzamiento, es importante mantener una cultura de retroalimentación continua. Abrir sus stand-ups de desarrollo a cualquiera que esté planeando un sprint asegurará que su equipo esté en mejores condiciones para obtener las respuestas que necesitan. Las revisiones de funciones cruzadas también ayudan a garantizar que sus iniciativas de pruebas continuas funcionen para todos, y puede ajustarlas según sea necesario. Si no tiene tiempo para involucrar a todos, puede enviar sus comentarios a través de un "cuadro de sugerencias" (puede hacerlo fácilmente usando un formulario de Google).

Recuerde, las retrospectivas no se tratan solo de recuperar cosas que deben mejorarse, sino que también son una gran oportunidad para llamar a las personas que están haciendo lo correcto. El trabajo en equipo es la clave y nada construye una mejor relación que la gratitud. Las cosas no siempre saldrán bien, pero una medida importante es qué tan rápido puede abordar los problemas que causan dolor. La forma más fácil es capturar el estado de ánimo durante una retrospectiva.

Adaptación a la nueva normalidad [19659010] Incluso con el apoyo de todas las partes interesadas, puede conducir al fracaso de sus iniciativas simplemente al requerir que todos cambien a usar pruebas continuas sin capacitación y tiempo. Las pruebas continuas no se pueden hacer solo para un equipo o para un equipo. Es un compromiso fundamental con la calidad que debe ser aceptado por todos en la organización. Sus equipos necesitan tiempo para adaptarse, adaptarse a nuevos procesos, aprender nuevas herramientas y hacerse preguntas, y eso lleva tiempo.

Debido a que la mayoría de las pruebas automatizadas y los datos de pruebas existentes generalmente se encuentran en equipos de garantía de calidad, es útil confiar en ellos para impulsar el cambio y compartir sus conocimientos de pruebas en toda la empresa. Los probadores e ingenieros de control de calidad también tendrán mucho que ofrecer, y al igual que nuestros entrenadores ágiles, podemos actuar como entrenadores de pruebas continuos en toda la empresa.

Toda la capacitación necesaria puede experimentar una desaceleración inicial en la productividad. Es importante no entrar en pánico. Muchas cosas contribuyen a la disminución de los puntos de la historia, pero es importante que los desarrolladores hagan un seguimiento de las tareas que no son tareas de desarrollo, como reuniones, capacitación y flashbacks, hasta el recuento de puntos de la historia, para que tenga una idea clara de cuánto El equipo se hace. Los cambios sucederán rápidamente, pero no de la noche a la mañana. Mientras tanto, es importante que todos se mantengan flexibles. [19659909] Conclusión
La mejor manera de garantizar que sus iniciativas de pruebas continuas sean exitosas es que su empresa,

  • se ocupe de manera proactiva de los requisitos,
  • para trabajar en el intercambio de conocimientos y el acceso entre equipos, 19659021] automatice tanto como sea posible (y asegúrese de que todos los equipos puedan reutilizar el trabajo).
  • Genere datos de prueba robustos Mejora y retroalimentación continua.

Finalmente, el desarrollo de software siempre será un proceso complejo que nunca será perfecto. Siguiendo estos pasos, puede estar seguro de que se va mucho mejor de lo que encontró.



Software almacen de Cea Ordenadores

Comentarios desactivados en No se estadísticas: cómo guardar sus iniciativas de desarrollo de software fallidas