Ahora que cada empresa es una empresa de software, las discusiones recientes con la gente que me rodea (incluidas las que no están en el negocio del software) me hicieron redescubrir el estado abismal en el que se encuentra la entrega de software en muchos lugares.

Este artículo compartirá algunas de mis reflexiones al respecto, y también me permitirá presentar algunos consejos de alto nivel no concluyentes que creo que pueden formar una base sólida sobre la cual tales organizaciones problemáticas podrían reconfigurarse en organizaciones de software reales.

Tenga en cuenta que cuando escribo sobre organizaciones y empresas, por lo tanto, no serán empresas tecnológicas puras, es decir, Meta, Google, Spotify o similares, sino la larga lista de organizaciones (es decir, empresas heredadas mejoradas por TI) que lamentablemente han tenido que adaptarse al software como parte de su producción y producto.

Desde donde escribo esto

Un poco de contexto primero. Tengo experiencia y aprendizajes de varios "mundos", actualmente como líder de estándares técnicos en Polestar , siendo un fabricante de código abierto , siendo un ávido lector de tecnología en general y siendo el fundador de una pequeña empresa tecnológica nueva . Finalmente, junto con un viejo colega mío, también estoy planeando activamente establecer un servicio de CTO fraccionado local y gratuito para organizaciones jóvenes impulsadas por el valor.

Empecé a codificar HTML y CSS en 1997, he explorado bastantes áreas desde entonces, y mientras tomaba muchos viajes y desvíos en la vida, mi estricta carrera profesional comenzó en 2016. Ya el primer puesto era complejo, desordenado y yo Me encantó tener posiciones en las que tengo que equilibrar los lados duros y blandos, arriba y abajo desde el nivel C hasta otros desarrolladores. Dirigí dos pequeñas empresas en diseño y tecnología, quizás sin mucho éxito, pero tengo experiencia con todo lo que implica. Mi experiencia con clientes va desde las súper pequeñas hasta las empresas más grandes de Suecia, y desde bienes de consumo cotidianos hasta los servicios más especializados. He tenido la suerte y estoy muy feliz de ayudar a innovar y crear una plataforma sobre cómo la entrega de software puede o al menos debería funcionar en muchas organizaciones. con diversas necesidades y profundidades de habilidad en tecnología en muchos dominios. Para terminar, son muchas oraciones que comienzan con "Yo...".

OK, entonces, ¿por qué escribo lo anterior? Singularmente porque quiero ser completamente transparente en cuanto a que lo que atacaré proviene de haber experimentado el dolor y, a menudo, la "falta de naturalidad" del software en muchas organizaciones: ¡simplemente no parece encajar en la mayoría de los lugares! Hay una tonelada métrica de lectura, lo suficientemente buena como para ocupar su vida útil y más allá, si desea profundizar en ideas, conceptos y filosofías de software, incluso antes de llegar al lado comercial, cómo operar nuevas empresas, cómo hacer MVP , cómo abordar el software de calidad, etc. Para ser justos, ninguno de nosotros tiene tiempo para asimilarlo todo , y no sería una buena gestión del tiempo si no podamos nuestras fuentes de inspiración y la ingesta de nuevas ideas hasta cierto punto.

Entonces, con esta narración fuera del camino, voy a escribir sobre tres cosas en particular:

• Que tenemos un problema con el software en organizaciones que no son de software.
• Por qué los propios desarrolladores no pueden convertir su organización en una empresa de software.
• Cómo se verían algunos cambios reales de la vida real para volver a hacer crecer una base.

Ingeniería de software, desde una perspectiva orbital

Somos una nave espacial alienígena que se cierne sobre la Tierra, mirando hacia abajo a todas esas organizaciones aspirantes (es decir, TI).

Algunos datos que nuestros instrumentos han recopilado junto con las reflexiones de nuestro principal científico humano-alienígena:

• La tecnología (especialmente Big Tech) ha estado sobreempleando en gran medida . El objetivo parece ser, un tanto cínicamente, no poner a la gente a trabajar, sino sacarla de la producción de otra persona.
• Esto va a la consecuencia natural de hacer más que posible tener múltiples trabajos al mismo tiempo . Irónico pero cierto, dado que ahora tienes dos cheques de pago por hacer el doble de nada.
• A escala de empresa, como escribe Victor Ronin, “ puedes despedir al 80% de los ingenieros de software y la empresa sobrevivirá ”. No es tan extraño dado que nadie trabaja en primer lugar, o que la típica organización de TI tiende a ser un atolladero incluso si lo intentaran.
• La experiencia laboral personal dice claramente que la "inflación de títulos" es severa (al menos en Suecia, pero parece ser un fenómeno global ). No puedo probar esto, pero si ha estado en (o ayudado con) reclutamiento o contratación lo más probable es que hayas visto esto. En efecto, la gente quiere más dinero por mano de obra a veces menos calificada .
• A nivel nacional, en Suecia, el grado de candidatos calificados en programas orientados a TI/CS ha estado disminuyendo durante algún tiempo. Sin embargo, parece que algunos de los programas de educación vocacional no teórica obtienen algunos candidatos. Ergo, el mercado no parece aumentar con el tiempo, se está reduciendo , al menos en términos de los jóvenes más calificados.
• Podemos generalizar y decir "antes era más fácil", ya que TI era un centro de costos y, esencialmente, en muchas empresas estaba relegado a vender licencias de software comercial (que alguien más construyó) y garantizar que su impresora y correo electrónico funcionaran. Ahora, de alguna manera, desafortunadamente, cada empresa es una empresa de software . En realidad, esto no ha funcionado muy bien, ya que requiere una reestructuración y un replanteamiento, probablemente el hueso más difícil de romper para la gente normal.
• La TI está deprimentemente sobregestionada y poco cualificada. Lo más probable es que haya una larga historia (o muchas de ellas) que respalden esa afirmación, pero está bastante claro que TI está atrayendo una gran cantidad de talento e ideas no calificados, a menudo (pero no solo) en las partes de (mala) administración. Los roles de gerente parecen estar explotando en las vides del gran árbol jerárquico, mientras que hay menos (buenos) resultados para administrar en primer lugar. Necesitamos tener algo que ponga el producto (¡y por supuesto a las personas!) en primer lugar, no la gestión o las ideas almacenadas en estantes de "escala" de gestión de productos que simplemente no funcionan .
• El pensamiento de producto, el pensamiento lateral y las personas en forma de T son difíciles de encontrar. Debemos asegurarnos de contar con mecanismos que fortalezcan a nuestra gente tales habilidades, tanto en la inmersión del día a día como con la capacitación regular y esperada . Pero no deberíamos aceptar a aquellos que carecen de todos ellos en primer lugar.
• El proceso no es el enemigo, al contrario de lo que los fanáticos ágiles quieren que creas. El proceso es excelente si mantiene a los empleados efectivos y felices de manera significativa mientras mantiene la producción a un nivel competitivo, tanto en términos funcionales como interfuncionales. El problema es que las organizaciones tradicionales no están adaptando los procesos en torno a la cadencia mucho mayor de la entrega de software.
• ¿Qué parece estar ocupando el tiempo de los ingenieros de software en muchos lugares? Parece estar relacionado con preocupaciones de integración relativamente modestas, automatización de procesos y mantenimiento del sistema. Casi como un fontanero digital … interesante…

— Usuario “denton-scratch”https://news.ycombinator.com/item?id=33961785

• Qué suerte para esas pobres almas de gerentes que haya algún tipo de respuesta a ese escenario de plomero digital: Sin código/código bajo es un enfoque que es profético en el sentido de que reconoce que no hay suficientes ingenieros de software competentes disponibles, ya sea en capacitación o en el mercado. Hay algunos productos increíbles como Zapier , Autocode , AppSheet , AirTable , Webflow , Retool y Carrd . Demonios, level.fyi escaló a millones de usuarios con solo Google Sheets como backend ...
• …pero aún no está maduro para todas las áreas de negocios, y todavía requiere una cierta mentalidad de ingeniería para que funcione bien . Así que todavía parece que necesitamos que esos ingenieros/desarrolladores usen la herramienta "sin código", cuando la gerencia y el resto están horrorizados por el hecho de que todavía tiene que ver con el software.

La velocidad de la innovación en el sector del software y el desarrollo está ardiendo en este momento. Estoy escribiendo esa declaración como una disculpa en parte y una carta de amor en parte para abordar cuán fácil y "democratizada" puede ser la tecnología para las empresas y organizaciones, sin importar su madurez técnica o competencia. Disculpe porque, en mi realidad, es muy difícil hacer que las grandes empresas cosechen los beneficios de nuestro tiempo , y una carta de amor , ya que sé y valoro el impacto que pueden tener los desarrolladores y los empresarios, si se les da el contexto de la organización "correcta".

Para una nueva empresa emergente, esto nunca ha sido tan cierto como lo es hoy en día dada la plétora de herramientas que funcionan bien y cuentan con una buena experiencia de usuario que pueden crear experiencias y aplicaciones que, no hace mucho tiempo, eran solo responsabilidad de los maestros. de lo arcano.

Parece que todavía no ha arraigado lo suficiente en muchas organizaciones que necesitan definir (y estratificar en consecuencia) si son una organización con mejoras de TI o si son una empresa de software con su mentalidad de desarrollo de productos de ciclo rápido. software al frente y en el centro de las operaciones. El culto de carga en torno al softwarey cómo todos piensan que es fundamental ser uno significa que hemos invitado a lobos y charlatanes a organizaciones con grandes visiones. Grandes visiones con líderes inexpertos y nerviosos, en organizaciones que no siempre pueden cumplir con los elevados castillos en el cielo, dados los límites y restricciones inherentes o arraigados que podrían hacer que sea fundamentalmente imposible reestructurar en torno al software, en lugar de, digamos, automóviles, envíos, rodamientos de bolas. , productos médicos o lo que sea...

Nuestro ansia por adaptarnos a los tiempos ha llevado claramente, en muchos casos, a una mala toma de decisiones y condiciones de mal funcionamiento que no logran ofrecer software de alta calidad, estable y seguro... ¡Está bien ser una empresa que no es de software ! Ser un poser es mucho peor.

Recordatorio : la supervivencia no es obligatoria . Alguien siempre tendrá que hacer el papel del dodo .

Un separador clave entre las organizaciones tradicionales y las organizaciones de software es que el software es el producto . Duh. Al afirmar eso, se supone que también hemos llegado a algunos entendimientos:

• El software como extremadamente maleable (modificable, adaptable);
• La tasa de cambio en el software es significativamente mayor que en el mundo material;
• La competencia en software es global por defecto y ultra antagónica por naturaleza;
• El software se mejora continuamente, no es un artefacto entregable con una fecha estampada en él.

El problema es, inevitablemente, en algún lugar, en algún momento, su suerte se acabará si no puede mejorar esta situación. Su principal competencia no proviene de sus conocidos competidores heredados mapeados: proviene de un chico o una chica que escribe su obituario en código en su subarrendamiento en un país completamente diferente. Y no lo verás venir antes de que sea demasiado tarde.

Una organización centrada en el software atiende, se adapta y optimiza para tales hechos, al ser interfuncional, al tener ciclos cortos en el ciclo de desarrollo del producto, al comprender el resto del panorama digital (desde la legislación hasta los patrones de usuario, etc.). ), y tener al usuario como parte interesada, no una bolsa de dinero abstracta y sin sentido escondida fuera de la vista. Una empresa de software no está protegida de la realidad, el mercado o cualquier otra cosa, pero se adaptan haciendo que sus clientes estén cerca, una forma de Oracle of Delphi algo poco confiable.

Los desarrolladores no salvarán una mala organización

Se sabe que soy controvertido, así que seguiré adelante y dejaré que ese pensamiento satánico salga a la luz de inmediato, para que podamos desempacar esto juntos... Probablemente no deberías conseguir (más) desarrolladores, porque :

1. No se puede externalizar el negocio y "conocer el plan" a los ingenieros . No porque sean tontos, sino porque ese es un instrumento más en la gran orquesta. Dado que su negocio no está profundamente arraigado en el desarrollo, no es ahí donde encontrará a los que impulsan el negocio. Comience por establecer el plan y la visión de su organización y (posible) producto. ¡Sin embargo, invita a los desarrolladores!
2. El misterio y la magia que rodea a los desarrolladores tiene que desaparecer . Los desarrolladores no son superhéroes, ni tampoco son todos del tipo mítico 10x . El valor final de crear cualquier cosa, dentro del contexto del negocio, es que respalda el valor percibido por el cliente. Los desarrolladores no son las personas ideales para comprender completamente cuál es ese valor. El desarrollo a menudo se impulsa de forma reactiva y después del hecho , lo que se traduce directamente en que el código es solo una medida de producción en lugar de una medida de valor . Si esto es lo que está haciendo, entonces no, más desarrolladores no es la forma correcta de hacer negocios.
3. Probablemente esté confiando en la creencia de que convertir ese software en algo tangible (incluidos todos los procesos no digitales, etc.) funcionará bien en su jerarquía heredada . La experiencia dice que casi nunca es así y que LinkedIn está lleno de chacales que no dicen la verdad. O cuando lea que una victoria fue "ganada con esfuerzo" (es decir, una victoria pírrica ), pregúntese si quiere saber qué significó realmente eso.. Muchas veces es probable que se traduzca en un proyecto hecho pedazos por marketing, diseño, desarrollo, negocios y administración que tenían ideas completamente contradictorias sobre cómo proceder y de qué se trataba incluso. Además, una organización grande se tomará su tiempo para hacer que los paquetes de trabajo pasen de la idea a la realidad, por lo que esto solo sucederá una vez cada luna azul. Y el resto del mundo quizás ya haya avanzado cuando la luz del día brille sobre ese proyecto en forma de carga. A menos que el software se diseñe y construya como una porción vertical que incluya a todas las personas y los procesos necesarios, es casi seguro que falle o tenga un desempeño deficiente dado el costo y el esfuerzo involucrados.

Sé que puede doler, pero en realidad estoy tratando de ser tu amigo aquí.

¿Gran organización? Probablemente grandes problemas. Si las personas son el problema, ¿cuál es la solución? Lógicamente la respuesta es Menos y mejor calificados . En consecuencia, el número de empleados es una forma muy pobre de hacerlo y la escala probablemente no sea tan importante como crees. En su lugar, apunte a un número menor de desarrolladores altamente calificados y motivados que participen en una organización que valore la transparencia y las interacciones multifuncionales.

Crecimiento explosivo en lo que un desarrollador competente puede hacer con las ofertas tecnológicas contemporáneas

Las mejoras en la tecnología significan que las personas competentes pueden producir significativamente más que los desarrolladores que carecen de habilidades de vanguardia . Desde servicios individuales hasta la nube pública, existen innumerables historias de empresas que funcionan con el trabajo de solo 1 a 5 desarrolladores, en gran parte gracias al paradigma sin servidor y sus antepasados.

Para las empresas más tecnológicas, estoy viendo (y he visto) cómo uno o un pequeño número de desarrolladores pueden crear cosas que eran imposibles de hacer sin contratar lo mejor que el mercado tenía para ofrecer y pagar con sus órganos. Una gran parte de esto proviene de la carrera armamentista entre las grandes nubes, pero también de que otras compañías tecnológicas, a menudo especializadas en su propio campo, están echando gasolina al fuego. Como “consumidores” de los servicios, somos claros ganadores. No utilizar el impulso dejará a su organización muy atrás muy rápidamente.

¿Cuándo simplemente no debería contratar desarrolladores en absoluto?

Si es una pequeña empresa o se encuentra en un contexto que no está profundamente afectado por lo digital. Estoy pensando en restaurantes y similares. Si los márgenes son demasiado bajos y tiene una idea lo suficientemente decente de los requisitos de su negocio, entonces podría estar mejor atendido por algo como Carrd, Webflow, Retool o algo más orientado a código bajo/sin código y nadie puede culparlo por ello. dado que tiene un poco de habilidad para pensar en términos programáticos. No sería el primero ni el único en impulsar su negocio con éxito con estas herramientas fáciles de usar y disponibles en el mercado.

Mejor entrega de software ahora

Hemos visto que el verdadero problema en las organizaciones de TI tiene menos que ver con la tecnología y mucho más con las personas y los procesos. Por lo tanto, aunque algunos de los siguientes serán sobre tecnología , muchos no lo son.

No quiero ser duro, pero esa también es una buena razón para preguntarse: "Si no puedo evitar afectar o cambiar esos aspectos, ¿cuáles son las probabilidades realistas de que mi empresa sea buena en la entrega de software?". Apostaría bajo. Lo siento no lo siento.

Hagámoslo.

Preocupación por el cliente/usuario

Este es sin duda el número 1 en tu lista.

Nunca he trabajado en una empresa (no, nunca; ni hoy, ni antes) donde la empresa se haya preocupado verdaderamente por el cliente o usuario. No seas así.

Sin la perspectiva del cliente, eventualmente, tienes que joder todo. Esa es la verdad.

Es una regresión más allá de la estupidez que la organización de su producto no tenga contacto directo con los usuarios (como y cuando sea apropiado). ¡Asegúrese de que tiene tales capacidades!

Ética

Lea lo siguiente, independientemente de su posición:

• Forsgren, Humble y Kim's Accelerate: la ciencia del software Lean y DevOps: creación y ampliación de organizaciones tecnológicas de alto rendimiento
• Artesanía limpia de Robert C. Martin : disciplinas, estándares y ética
• Ingeniería de software moderna de Dave Farley : hacer lo que funciona para crear mejor software más rápido

Escuchamos mucho sobre el empoderamiento, como empoderar a los equipos con las responsabilidades verticales en un rol de DevOps, pero con la libertad viene la responsabilidad, también del resto de la organización hacia los equipos de ingeniería. DevOps no funcionará en una fábrica de características . En una nota relacionada, lea Producto vs. Equipos de características .

Su objetivo número 2 debe ser aumentar la eficiencia de la organización mediante ciclos más cortos desde la idea hasta la implementación. Esto se ve impedido por grandes grupos o estructuras, procedimientos rígidos que no agregan valor y no confiar en grupos más pequeños para hacer su trabajo de forma autónoma. Cuanto más corto e intenso sea este ciclo, mejor.

Tenga una visión clara y comunicada de su producto, servicio o lo que sea que esté haciendo su organización . Deje en claro lo que todos pueden hacer para llegar allí. “Mayores ventas” no cuenta como la visión o la guía de un adulto, pero ciertamente es bueno en el contexto de una caricatura de Scrooge McDuck.

Transparencia en los objetivos y verdadera propiedad y toma de decisiones: sin visión, dirección y propiedad, puede tener todas las DevOps que podría tener, pero será literalmente por nada . Tener un interés y una responsabilidad significativos y concretos en el producto aumenta la satisfacción laboral, el sentido de propósito y muchos otros factores . En el mundo del desarrollo, esto sería algo así como DevOps bien engrasado que también funciona mejor en equipos más pequeños con alcances más estrictos y claros .

No construya, apoye, invierta ni financie una capa de administración . Todos deben tener una participación en el producto. La gerencia no suele reducir ese requisito.

Tener un concepto claro de cómo funcionan la rendición de cuentas y la responsabilidad . Si bien es común en muchos países ser duro con los trabajadores, en países como Suecia, de hecho, es al revés: puede ser increíblemente difícil ejercer una presión clara cuando no se cumplen las expectativas. No me tome como una dominatriz o capataz aquí, pero si le da la vuelta al guión y se inspira en cualquiera de los numerosos libros de psicología disponibles o en los hallazgos de, por ejemplo, DORA , verá que la alta inversión y el cuidado son consecuencias naturales de un equipo que funciona bien simplemente haciendo su trabajo diario. Entonces, paradójicamente, al ser transparente, claro y trabajar juntos (en lugar de solo como individuos, es decir, uno contra el otro), creará las condiciones para equipos de alto rendimiento.donde la rendición de cuentas tiende a venir automáticamente.

Comprometerse e invertir en el trabajo. Permitir el trabajo remoto . Las personas no harán trampa si son bien seleccionadas, dedicadas y se enorgullecen de su trabajo.

Primero: Confianza, expectativas y objetivos elevados... luego viene el empoderamiento.

Contratar a las personas adecuadas

Consiga algunos desarrolladores, pero muy entusiastas, con experiencia en la realización de sus propios proyectos (o de otras empresas) en la nube . Asigne a estos nuevos ingenieros una tarea inicial para migrar o cambiar la plataforma de algunas aplicaciones heredadas que pueda tener. No debería pasar mucho tiempo antes de que pueda comenzar a usar esas cláusulas de salida para cualquier miembro del personal que no esté a la altura.

No contrate a personas en LinkedIn con cometidos poco claros o títulos de jardín de infantes como "Orador principal" o "Visionario".

No contrate desarrolladores “a granel”/”por volumen”, independientemente del tamaño de su propia empresa.

No contrates a nadie mientras tomas un café. Permítales ser examinados en todos los niveles : competencia técnica, pensamiento de producto, habilidades de resolución de problemas laterales, inteligencia emocional, trabajo previo demostrado y claridad de sus propios objetivos. ¿Qué ganan ambos trabajando juntos? (¡no “para usted”!) Deje que se reúnan con los equipos y trabajen juntos durante una o dos horas antes de apretar el gatillo y comprometerse.

No dirija una escuela. Invierta en personas con habilidades fundamentales sólidas o sufra las consecuencias . La tardanza conceptual es probablemente una de las razones clave por las que los equipos y las organizaciones nunca llegan a ser "grandes". Por ejemplo, enseñar integración continua en una organización en 2023 no la prepara para el éxito; deberíamos esperar ese conocimiento como una competencia central básica. Lo mismo ocurre con las organizaciones de innovación, donde ocurre lo mismo, pero la novedad de los conceptos es radicalmente mayor. En resumen, construya una organización a partir de personas que ya están bien establecidas en la base fundamental de sus operaciones, o de lo contrario, seguramente estará condenada.

Mantenlo ágil y delgado

Vea si esto resuena con usted primero:

De todos modos... Probablemente no conozcas Agile , pero es posible que tengas muchas opiniones al respecto. Todo el mundo parece tener! Para un poco de realineación, recomendaría Clean Agile: Back to Basics de Robert C. Martin o al menos el video a continuación con él presentando la historia de ágil y dejando que se hunda primero.

¿Planificación? Continúe y use algo como los proyectos de GitHub ; lo que sea que esté cerca del código. Evite que Jira y la administración por el bien de la administración sucedan fuera del generador de dinero real: el código.

¿Escalada? Agile no está destinado a escalar : debe desescalar el problema y hacerlo más tangible. Agile no es la respuesta a todo, pero si recurre a parte de la literatura básica y tira cualquier material de SAFe que tenga en la estantería, al menos tendrá un comienzo real. Además, consulte la presentación de Gojko Adzic sobre Descaling Agile . Descalcifique su organización si es necesario.

No compre en un marco . Empezar literalmente desde nada: sin reuniones, sin ceremonias, sin nada. Luego agregue algunas chispas según sea necesario. Evite las ceremonias que no agregan nada; por ejemplo, tal vez mantenga una breve reunión matutina de 10 minutos para poner el día en orden (¡o al final del día!). Eche a los consultores de SAFe si tiene la mala suerte de tenerlos dando vueltas. Además, busque modelos operativos que tengan más sentido en un entorno de rápido movimiento, como Topologías de equipo .

Tener reuniones que “no sean reuniones” . Las reuniones deben estar orientadas a los resultados y, por lo tanto, solo deben hacer una de las siguientes cosas, pero nada más:

• Decidir o planificar : También necesitamos hacer ciertas metaactividades. Mientras sean procesables y todos tengan un contexto, vale la pena tenerlos. ¡Pero tenga cuidado con las reuniones de planificación mal planificadas! :)
• Trabajo : ¡Sí! Trabajar. Establecer un bloque de trabajo ininterrumpido de pareja/grupo durante algunas horas es una excelente manera de usar una "reunión que no es una reunión".
• Aprende o comparte : Aprendizaje entre pares, grupos de competencia, retrospectiva…
• Socializa : Dispara la brisa, conoce nuevos colegas, ayuda a las personas a encontrar su camino...

¿No confías en mí? Vea la presentación de Dave Farley sobre Agile y Kanban.

Si bien hay varios modelos con variaciones de los anteriores, algunos factores decisivos deberían eliminar toda la basura innecesaria.

entregar continuamente

“La entrega continua mejora tanto el rendimiento como la calidad de la entrega, y también ayuda a mejorar la cultura y reducir el agotamiento y el dolor de implementación”.

– Acelerar: la ciencia del software Lean y DevOps: crear y escalar organizaciones tecnológicas de alto rendimiento

Entregar software continuamente. El modelo “ mínimo viable ” para eso requiere:

• Desarrollo basado en troncales
• El trabajo se integra al maletero como mínimo diariamente.
• El trabajo tiene pruebas automatizadas antes de fusionarse con el tronco
• El trabajo se prueba con otro trabajo automáticamente al fusionarse
• Todo el trabajo de funciones se detiene cuando la compilación está en rojo
• El trabajo nuevo no rompe el trabajo entregado

Y sí, use el desarrollo basado en troncos : es la estrategia de bifurcación más fácil de todas, está directamente relacionada con la entrega continua y evita las opiniones sin sentido sobre la bifurcación. Si cree que necesita bifurcaciones complejas, el problema no es la tecnología, es la forma en que plantea la situación. Combinar el infierno no es un problema real cuando se integra continuamente.

No realice solicitudes de extracción a menos que sea lógicamente significativo ; en su lugar, realice emparejamientos o mobbing, siempre que sea posible. Las revisiones asíncronas rompen el flujo y se basan en la desconfianza. Asegúrese de que las personas trabajen juntas y construyan las cosas correctas.

Utilice una buena plataforma de CI/CD lista para usar, versátil, como GitHub, GitLab, Harness o Azure DevOps. No ejecute su propia configuración de Jenkins ni reinvente esta rueda en particular. Realmente no puedo pensar en nada más inútil para gastar tu tiempo construyendo.

Sea iterativo. Cree algo que entregue de alguna manera o forma hoy. Ojalá muchas veces hoy, muchas veces mañana.

Utilice un solo entorno de producción y solo entornos de prueba efímeros y de corta duración (¡si alguna vez los necesita!). No haga las cosas demasiado complicadas como las ha aprendido en su carrera anterior.

Utilice la tecnología sin servidor como opción predeterminada y también las opciones SaaS predeterminadas: no invierta demasiado en lo que ya está disponible de forma fácil y económica. Es más seguro, más barato y más fácil si tiene personas que conocen la nube. Demasiados no lo hacen y se quejarán de que serverless es malo. No confíes en ellos. En su lugar, obtenga personas que conozcan la nube.

Use los conmutadores de funciones una vez que comience a necesitar segregar conjuntos de funciones, como funciones inacabadas, grupos de usuarios, probadores beta... Como escribe Charity Majors, " Las implementaciones son la forma incorrecta de cambiar la experiencia del usuario ".

Calidad

Mi tesis es esta, si un enfoque de ingeniería para el desarrollo de software no nos ayuda a crear mejor software más rápido, entonces está mal y no califica como "Ingeniería".

— Weblog de Dave Farley, ¿Qué es la ingeniería de software moderna?

Escriba pruebas, todas ellas , centrándose en pruebas unitarias y pruebas de integración. Está bien no tener una cobertura del 100 % el día 1, pero no deje que la deuda se apodere de él durante demasiados días.

No contrate ingenieros de control de calidad, evaluadores ni nada similar. Espere que sus ingenieros puedan cuantificar su calidad con pruebas y asegúrese de que tengan tiempo para hacerlo.

Aprende a usar la nube pública. No contrate a nadie que no tenga experiencia en la nube.

Establezca tareas para cada bit de deuda técnica.

No olvide los requisitos legales, de seguridad y otros requisitos multifuncionales. Deberían ayudar a informar su SDLC o criterios internos mínimos para la definición de hecho.

Para concluir

Mi intento aquí, inútil o no, ha sido ser lo más franco posible acerca de los problemas que usted, como organización tradicional que aprovecha "TI", tiene cuando intenta convertirse en una empresa más centrada en el software. De ninguna manera se dice o se escribe la última palabra, pero espero que tenga una idea de dónde recomendaría hacer algunos cambios, cómo se ven y cuáles son algunas de las diferencias culturales entre una organización de TI y un verdadero software. negocio.