Lean Management

Fruto de una mayor demanda que oferta, el desarrollo de software de gestión empresarial se beneficia de un estatuto particular. No existió presión para el cambio que fuera suficiente para imponer en este sector una cultura de la Calidad Total, como se impuso hace más de 50 años en la producción industrial.

El Scrum es un concepto que procede de entornos industriales Lean^[1]. Sin embargo, la mayoría de los conceptos que probaron su eficacia en la producción industrial (en particular, en el sistema Toyota de producción) no transitaron ni se acogieron por la industria del software.

Y, claramente, deberían haber sido considerados.

Aquellos que la producción de software debería adoptar, y no adoptó, son demasiados para estas notas, pero dejamos aquí algunos conceptos para inspiración.

Lean, para una mayor calidad en la producción de software

Gemba o el lugar real. La más grave de todas las faltas de la calidad, en la producción tradicional de software, es el proceso de verificación de errores. En la producción de software tradicional, la detección de errores (bugs) es hecha por testers^[2] y al final del desarrollo. Lo que viola el tercero de los 14 puntos para la gestión de la calidad total de Edward Deming^[3]. Es cierto que el control de calidad sólo al final es mejor que ningún control de calidad^[4]. Pero la dependencia de los inspectores es fuertemente desaconsejable. Los errores son detectados fuera del contexto en que fueron producidos y, no estando en el local, es mucho más difícil percibir su causa y actuar sobre ella. Se añade trabajo (y equipos) a fases posteriores de la producción, cuando se pudo haber detectado el problema tan pronto como fue introducido en el software. La responsabilidad se diluye y no se crea la cultura de la calidad de ser una tarea de todos los que participan en la producción de software.

Kaizen o mejora continua. La fragilidad de la producción de software tradicional, dependiente de programadores y de sus habilidades específicas y, hasta, el humor, se refleja en la forma en que el software se va construyendo. El software tradicional no resulta de una línea de producción que se va afinando. Cada programador escribe una parte del código, lo une al de otros programadores y da su tarea por finalizada. Una vez terminado el software, se entrega. No se sigue mejorando. Sólo será mejorado, si posteriormente se encuentra algún defecto. Si cumple los mínimos (funcionar) no hay ningún esfuerzo para hacerlo más eficiente, más robusto o más adecuado para el uso.

Jidoka o automatización inteligente. La producción de software tradicional no se automatiza. Pero en Quidgest, la máquina (el ordenador) detecta automáticamente errores y la intervención humana tiene fuerza para detener el proceso de producción, reparar el problema y encontrar la causa, con el fin de eliminar la hipótesis de sucesos posteriores. La producción no se reanudará mientras no se ejecute este ciclo.

Poka yoke, es decir, «a prueba de errores» o «previniendo errores inadvertidos». Es un concepto bien ilustrado y entendido por la forma de una pila, de una tarjeta de memoria o de un microchip, que impide que estos objetos se coloquen incorrectamente.
Cabe señalar que, al igual que las demás dimensiones debatidas en la conferencia Q-Day 2018, Lean IT se aplica a organizaciones de producción de software autónomas y descentralizadas y a redes de equipos colaborativos. Requiere una cultura propia, compartida por todos los que participan en la producción de valor, lo que conduce nuevamente al Gemba.

La contribución de Quidgest

En Quidgest, el software resulta de una línea de producción automatizada, Genio. La producción de software adopta, así y mucho más fácilmente, la lógica de una industria. La identificación de patrones permite la utilización de máquinas en tareas que antes realizaban los humanos. Su reutilización crea una masa crítica de casos y de contextos de aplicación que invitan a un perfeccionamiento continúo.

Genio, como una línea de producción industrial automatizada, tiene un componente de modelado / concepción y un componente de creación de código.

El modelo es un espacio adicional, que abre oportunidades excelentes para la implementación de la Calidad Total. A partir de los conceptos Jidoka, Poka-yoke y Kaizen, Quidgest integró en Genio formas innovadoras de garantizar la calidad no solo de los productos que fabrica, sino del proceso de producción.

El ya mencionado anteriormente Scaled Agile / SAFe^[5] es una corriente que suma Agile y Lean IT y es, probablemente, el movimiento al que debemos estar más atentos. Se une a la modelación y generación automática de software y tenemos el ambiente de calidad existente en Quidgest, que consideramos ideal.

Pero Quidgest es todavía una excepción. No conocemos ninguna otra empresa de sortware, presente en el mercado internacional (esto es, excluyendo investigaciones de ámbito más reducido al nivel académico), en el que el modelo defina de manera inequívoca la totalidad del sistema de información (especialmente los más complejos ERP) de un proceso industrializado.

_________________
[1] The New New Product Development Game, Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, January 1986
[2] Existe uma dinâmica Associação Portuguesa de Testes de Software https://www.pstqb.pt/. Do mesmo modo, há, nas comunidades meetup, inúmeros grupos focados em testes de software, espalhados por todo o mundo. E muitas ofertas de emprego como Test Engineers, mesmo em empresas consideradas Agile  https://jobs.jobvite.com/farfetch/job/oCSF3fwW
[3] http://asq.org/learn-about-quality/total-quality-management/overview/deming-points.html
[4] Joel Spolsky, uma voz reconhecida no desenvolvimento de software, representa bem a linha de raciocínio que prevaleceu, durante anos neste setor: https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/
[5] https://www.scaledagileframework.com/