Cómo ejecutar un proceso de desarrollo exitoso (incluso si no eres técnico)

¿No sería eso bueno? (Office Space, 1999)

Laurence Peter formuló el principio de que "los gerentes alcanzan el nivel de su incompetencia" en 1969. En particular, los líderes no técnicos se han ganado una mala reputación con los desarrolladores de software.

Office Space representa al gerente no técnico en Bill Lumbergh, en la foto de arriba. Dilbert ofrece el clásico "Jefe de pelo puntiagudo".

Este artículo es para cualquier persona que quiera organizar de manera efectiva un proceso de desarrollo sin convertirse en el blanco de los chistes de enfriadores de agua de su equipo. Compartiré lo que aprendí a lo largo de los años administrando procesos de desarrollo y lanzamiento como gerente y arquitecto de software en UCLA y la Universidad de Stanford.

La mayor lección que aprendí es que la clave para mantener lanzamientos exitosos de software es completamente no técnica.

Se trata del proceso.

Algunos aspectos de un proceso de desarrollo se benefician de los conocimientos técnicos, pero no es obligatorio. La liberación exitosa de software en producción es mucho más una cuestión de arquitectura de proceso robusta que el diseño o el código solo.

A los fines de este artículo, asumiremos que ya ha acordado comenzar a construir algo. La tubería de aprobación del producto es un proceso diferente. Hoy nos estamos centrando en llevar el producto acordado desde el concepto hasta la producción.

Que construir

Su equipo necesita armar una hoja de ruta clara para su código. Los arquitectos y fabricantes usan planos. Tu también deberías.

¿Debo usar estos planes o simplemente usarlo? Hmm ... (fuente)

Su hoja de ruta debe incluir un conjunto de esquemas que cumplan un propósito diferente. Estos esquemas difieren para aplicaciones individuales. Una maqueta de interfaz de usuario, un diagrama de arquitectura de aplicación y un modelo de proceso de negocio son comunes. Los diagramas de componentes más detallados, como los diagramas de lenguaje de modelado unificado (UML) y los modelos de flujo, a menudo también son útiles.

La experiencia técnica le permite usar estos esquemas para criticar la arquitectura de su equipo y asegurarse de que estén en el camino correcto. Incluso sin habilidad técnica, estos esquemas serán críticos.

Puede usarlos para generar conversaciones productivas sobre la finalización del producto. Ya no tendrás que sacar un "% completado" de la nada o la mejor suposición del equipo de desarrollo. Puede realizar un seguimiento del estado de cada elemento en el diagrama para determinar qué tan cerca está la aplicación de completarse. También puede proyectar la velocidad futura en función de la rapidez con que el equipo completó componentes anteriores.

No hay una cantidad "correcta" de documentación previa al desarrollo, pero hay una cantidad incorrecta: ninguna. Trabaje con su equipo lo que constituye una hoja de ruta aceptable antes de que comiencen a codificar. El primer punto de control en su proceso de desarrollo será revisar esta documentación y asegurarse de que cumplan con este acuerdo.

Que no construir

Tu equipo no puede construir todo. Tampoco deberían ellos. Debe asegurarse de que sus desarrolladores tengan un enfoque láser en lo que realmente necesitan construir.

¿Por qué estás creando esta aplicación en primer lugar? Definir la diferenciación clave de los productos existentes. El 80% del tiempo de su equipo debe destinarse a apoyar esa diferenciación.

Los esquemas que debería tener ahora serán útiles aquí. ¿Su aplicación incluye un componente de registro? ¿Un proceso de registro e inicio de sesión? Ya existen excelentes marcos de software de código abierto (FOSS) en la mayoría de los idiomas para estos componentes. Algunos están disponibles bajo licencias extremadamente permisivas.

Tesla proporciona una gran ilustración de este concepto. Su primer diferenciador clave fue usar una batería de iones de litio para hacer que los autos eléctricos fueran competitivos con el gas. El ion de litio logró esto al reducir el peso de la batería y aumentar el alcance.

Finalmente, Tesla pasó a construir infraestructuras enteras para soportar sus autos, como esta estación

El primer prototipo de Tesla simplemente convirtió un auto deportivo eléctrico preexistente de baterías de plomo-ácido a litio. Su primera producción fue principalmente un roadster Lotus Elise (un auto deportivo preexistente) que tenía una batería y un motor Tesla.

La lección para su equipo es usar lo que ya existe siempre que sea posible. Si puede usar o adaptar un paquete FOSS, hágalo. Incluso si necesita licenciar el código de pago de otro lugar, casi siempre vale la pena.

Coloque todos los andamios en su lugar rápidamente para que pueda probar su "batería de iones de litio". Luego, puede iterar y reemplazar lo que sea que ayude a diferenciar aún más su producto sin preocuparse por retrasar la preparación de la producción.

El segundo punto de control de su proceso de desarrollo es revisar la arquitectura planificada con su equipo e identificar qué parte muy limitada tienen la intención de construir desde cero.

Si suena como algo que ya existe y no es el enfoque principal de su producto, desafíe a su equipo a ver por qué creen que necesitan volver a hacerlo.

No lo tires por la pared

Con demasiada frecuencia, los equipos de desarrollo

Una vez que haya identificado qué tecnologías preconstruidas usará, asegúrese de revisarlas con su grupo de soporte de producción.

Los administradores de bases de datos y servidores deberán planificar la instalación y el soporte de cualquier tecnología nueva. Este es el tercer punto de control en su proceso de desarrollo: preparación para operaciones.

Mantener al equipo de soporte de producción al día es el 90% de la salsa secreta conocida como "DevOps". Si no ha oído hablar de esto, DevOps es la idea de que los equipos de operaciones de desarrollo y producción de software deberían unificarse bajo objetivos comunes.

Los beneficios propuestos incluyen lanzamientos mucho más rápidos, código más confiable y más tiempo dedicado al desarrollo debido a la automatización. Todos estos son grandes beneficios, pero se derivan de un fuerte proceso de comunicación. La automatización sigue, no reemplaza, la colaboración.

Implementación y Pruebas

Ahora su equipo escribe el código. Colabore con su equipo de implementación para diseñar un proceso para dividir el trabajo entre ellos. No existe un enfoque único para todos, y aquí es donde las "habilidades blandas" del liderazgo superan dramáticamente cualquier habilidad técnica.

Algunos desarrolladores querrán acaparar todo el trabajo "interesante" e ignorar cualquier trabajo pesado. Pueden creer que son la persona más inteligente en la sala y deberían elegir sus tareas. Otros pueden resistirse al cambio y solo quieren hacer el mismo tipo de trabajo que antes.

Dirija a su equipo hacia una distribución equitativa del trabajo. Desafíe a todos a crecer apropiadamente y a compartir y colaborar.

Un aspecto técnico más de la implementación es que el código debe incluir suficientes pruebas automatizadas. Estas son pruebas definidas por código que un sistema de prueba puede ejecutar.

Si el código va a fallar, ¿no quieres que los currículums de estos chicos estén en la línea en lugar de los tuyos? (dominio público: foto del gobierno de EE. UU.)

Los “guiones de prueba” manuales en los que un humano interactúa con el código para ver si funciona son insuficientes y reflejan una deuda técnica. Su equipo técnico debe incluir al menos pruebas unitarias. El desarrollo basado en pruebas es un enfoque popular para garantizar que el código crítico siempre se pruebe.

Puede conducir una conversación no técnica con su equipo sobre su "cobertura de prueba" (la parte del código que se prueba). Es bastante simple: pídales que enumeren sus suposiciones. Luego pregunte dónde y cómo prueban estos supuestos.

El punto de control en el que los desarrolladores creen que el código está completo se denomina dev-complete en mi tienda. Significa que el proceso de desarrollo primario (dev) ha terminado, pero se puede escribir código adicional para abordar los problemas que surgen en el proceso de revisión.

En un proceso de desarrollo ágil, normalmente dividirá el proceso de implementación en múltiples puntos de control en lugar de una fecha límite de todo o nada. Estos se suelen llamar iteraciones.

Consulte la hoja de ruta que definió en el primer paso. Antes de comenzar con los nuevos componentes, asegúrese de que lo que ya comenzó sea al menos completo para desarrolladores. Esto le proporciona una visión precisa de la velocidad de desarrollo y reduce el riesgo.

A medida que completa las iteraciones, puede empujar el código a un entorno para "pruebas de aceptación". Esto implica usuarios piloto o de prueba (o un equipo interno que desempeña ese papel) que interactúan con el producto parcial. Prueban para asegurarse de que cumple con las expectativas de diseño y brindan comentarios sobre cómo podría ser mejor.

Las pruebas de aceptación no son un sustituto de las pruebas unitarias mencionadas anteriormente. Tiene un propósito diferente. Permitir que su equipo de desarrollo se apoye en las pruebas de aceptación para detectar errores funcionales básicos es una receta para el desastre.

Los comentarios de los evaluadores de aceptación se pueden incorporar en la próxima iteración. Esta es otra buena razón para no morder una gran parte del producto de una vez. Desea dejar espacio para cambiar de rumbo una vez que las personas comienzan a jugar con el producto.

Una vez que haya acumulado suficiente código probado para constituir una versión de producto suficiente, estará listo para comenzar el proceso de administración de versiones.

Buscando errores en todos los lugares correctos

El error tiene que estar aquí en alguna parte ... (fuente)

Su desarrollador o equipo ha llegado a un punto en el que creen que el código está hecho. Los evaluadores de aceptación están satisfechos con la forma en que funciona el producto. El siguiente punto de control en el proceso es validar la creencia de que tiene un código listo para convertirse en un producto. ¡Comencemos a revisar el código!

Es posible que no se sienta cómodo o que no tenga los conocimientos técnicos suficientes para revisar el código del equipo usted mismo. ¡Está bien! No tienes que hacerlo. Tu proceso tiene que hacerlo.

Trabaje con su equipo para identificar un proceso de revisión de código que funcione para ellos. Si tiene más de un desarrollador, la revisión del código de pares funciona muy bien. Si no lo hace, ¿hay otros desarrolladores en su organización fuera de su equipo? Trabaje a través de los límites del equipo para establecer un programa de revisión de código de pares.

Si realmente solo hay un desarrollador, siéntate con ellos y haz que te guíen por el código. Use sus esquemas como punto de referencia y pídales que le digan cómo el código logra los objetivos del esquema.

Al finalizar el proceso de revisión del código, el desarrollador y los revisores deben sentirse cómodos con la responsabilidad del código.

La revisión del código también es un buen momento para revisar otros dos puntos críticos: documentación y seguridad.

Ya he escrito sobre una arquitectura de documentación sostenible. ¡Compruébelo si está interesado!

La revisión de seguridad debe ser parte de cualquier revisión de código. En general, esto implica echar un segundo vistazo al código para detectar debilidades en las que un atacante podría explotarlo para revelar datos privados o obtener el control del servidor. Debe hacerlo una persona técnica.

El Proyecto de seguridad de aplicaciones web abiertas (OWASP) publica una guía completa y gratuita para la revisión de seguridad.

Su desarrollador puede hacer esto si es el único en el equipo, incluso si solo ejecuta una herramienta automatizada de análisis de código de seguridad. Existen herramientas gratuitas para ayudar con este proceso que están vinculadas a través del wiki de OWASP.

Expulsar, expulsar, expulsar!

El código ha pasado el proceso de revisión. Está listo para convertirse en un producto. Pero eso no significa que esté listo para la producción.

El último punto de control para borrar es la preparación para la implementación. ¿Está su código en un estado donde es fácil de implementar en producción? Esto debería implicar la menor cantidad posible de pasos manuales.

También significa que debe tener un plan para revertir el cambio en caso de que el código no funcione según lo planeado. Esto se llama un "plan de reversión".

No todo el código de producción permanece en producción ... (fuente)

Si tiene un equipo de operaciones de software separado, aquí es donde vuelven a aparecer. Deben revisar la documentación de implementación y reversión y hacerle saber si es suficiente.

Si no tiene este personal, puede realizar este paso usted mismo. Asegúrese de que haya instrucciones claras y simples para implementar el producto. Debe haber muy pocos pasos manuales, ya que cada paso manual presenta una posibilidad de error humano.

Debe haber un plan claro y suficiente para volver al estado anterior de las cosas si el despliegue no tiene éxito. Esto puede ser tan simple como restaurar una copia de seguridad o puede implicar la comunicación con el cliente o la conversión de datos.

Si el plan es suficiente depende de cuán exhaustivamente su equipo haya probado el código y cuán ampliamente se esté lanzando el producto. Considere también cualquier riesgo asociado con el producto o con esta versión en particular.

Una vez que haya pasado este punto de control, ¡introduzca ese código en producción!

Posteriores a la liberación

Tener éxito o fracasar, es importante regresar y revisar cómo fue el proceso.

¿Su equipo calculó con precisión el esfuerzo requerido para lanzar un producto? ¿Las pruebas modelaron adecuadamente el escenario de producción? Revise los puntos de verificación de implementación y prueba, y revise qué tan bien se desempeñó el equipo.

¿Cómo funciona el producto en producción? Es una buena idea visitar al personal de operaciones y obtener sus comentarios. Esto crea aún más confianza entre los equipos de desarrollo y operaciones, y dará lugar a más beneficios de DevOps en el futuro.

¿Dónde están los vacíos restantes en su producto? Si están en código de terceros, ahora es el momento de considerar si personalizar sus paquetes o volver a implementarlos desde cero. De lo contrario, ahora tiene información sobre qué compilar para la próxima versión.

Sobre todo, responsabilícese a usted mismo y a su equipo de los resultados de su esfuerzo.

La rendición de cuentas facilita la independencia y promueve el crecimiento individual. A medida que su equipo se acostumbre a ser responsable de cada paso en este proceso, ajustará su desempeño en consecuencia.

Conclusión

No tiene que ser el más mínimo técnico para ejecutar un proceso de lanzamiento de software exitoso. La habilidad técnica puede ayudar, pero también puede convertirse en una muleta.

La clave para el lanzamiento exitoso del software es un proceso bien documentado y bien entendido para mover el software a través de la tubería desde la idea hasta el producto. Ahora tiene un punto de partida para redactar su propio proceso de lanzamiento de software.

Lo más importante es que participe con su equipo para completar los espacios en blanco y crear un proceso repetible que funcione para todos ustedes.

No tiene que ser perfecto para nadie, pero debe ser entendido por todos.

También debe asegurarse de que la velocidad de su producto a través de estos puntos de control coincida con la demanda del producto. Ninguno de estos elementos debe ser un espectáculo de varios días. Podría ser una simple lista de verificación de una página. Debe definir un proceso que se ajuste a su entorno.

Como con cualquier proceso, también debe iterar. Al igual que con el código, su primer borrador no probado probablemente no sea perfecto. Ajusta el proceso en cada ejecución y terminarás con una ruta de lanzamiento de software suave y predecible.

Y recuerda cepillarte el pelo. No quieres que se vea ... puntiagudo.

Si te gustó este artículo y te gustaría leer más como este, ¡por favor, házmelo saber! Si desea obtener más información sobre los procesos de desarrollo de aplicaciones empresariales, responda a continuación. ¡Estoy feliz de compartir lo que aprendí en el viaje de mi equipo!

También puede disfrutar de mis otros artículos sobre el proceso comercial del desarrollo de software:

  • Lo que te estás perdiendo al omitir la lista de verificación
  • Cómo nos reorganizamos en una tienda de desarrollo más profesional cuando perdimos a nuestro solitario lobo gurú

Jonathan es el Subdirector de Arquitectura y Operaciones en el departamento de Sistemas de Información de Investigación de la UCLA. Obtuvo un título de Física en la Universidad de Stanford y desde entonces ha pasado más de 10 años trabajando en arquitectura de sistemas de información, mejora de procesos comerciales basados ​​en datos y gestión organizacional.