Fabricación vs Desarrollo de Software [cerrado]

A menudo se dice que la industria del software es inmadura en comparación con la fabricación. Específicamente con respecto a ser impulsado por el proceso.

Pregunta : ¿Podemos nosotros, como desarrolladores, aprender de los procesos de la industria manufacturera? ¿La adopción de sus procesos puede aumentar la tasa de éxito del desarrollo de software?

Mi opinión : en la fabricación, la creación de un producto depende en gran medida del proceso. Puede tener una fábrica donde cada persona tiene un conjunto específico de tareas que sigue. Un trabajador (o robot) puede apretar un tornillo todo el día. Luego, la siguiente tarea en el proceso la realiza el siguiente especialista. Los trabajadores (y los robots) no disuaden del proceso ni inventan algo "sobre la marcha". Las partes se mueven durante todo el proceso y la salida es un producto terminado. Funciona bien y las empresas logran 99.99966% de productos libres de defectos. Las empresas resuelven las ineficiencias con el tiempo. Esto es impresionante y muy bien puede ser el signo de una industria madura.

En la fabricación, un proceso definido puede crear literalmente el producto terminado. No creo que este sea el caso en el software. Es posible que tengamos procesos para el control de la fuente, la revisión del código, las hojas de verificación, la recopilación de requisitos, el SDLC, etc. Pero ejecutar esos procesos no crea en sí mismo un producto terminado. Estos procesos pueden ser beneficiosos, pero son ortogonales a la creación real.

Supongamos que su empresa está contratada para crear un software que buscará millones de imágenes para encontrar los rostros de los delincuentes. A pesar del pesado entorno impulsado por el proceso, el desarrollador debe participar en la creación de cosas "sobre la marcha". Hacer cosas sobre la marcha va en contra del espíritu de fabricación. Un buen proceso de fabricación puede ejecutarse sin pensarlo un robot.

Para la creación de algoritmos complejos que aún no se han concebido en la mente de un humano, es una necesidad crear cosas sobre la marcha. El desarrollo de software no es el seguimiento de un proceso, sino la creación de un proceso para ser ejecutado por una computadora. Esa es una diferencia fundamental. No importa cuántos procesos ortogonales realizamos en torno al desarrollo, siempre recurriremos a hacerlo "sobre la marcha" cuando se trata de la creación.

Todos con los que hablo parecen estar de acuerdo con la mentalidad de fabricación. ¿Estoy solo en mis pensamientos?

La diferencia fundamental entre el desarrollo y la fabricación de software es que para el software, la fase de diseño es prácticamente todo. La producción real (parte de la línea de ensamblaje en la fabricación tradicional) es una cuestión de copiar algunos archivos. En software, el diseño del producto es el producto.

Entonces, sí, podemos aprender de los procesos de fabricación, pero solo si tenemos en cuenta que tenemos que mirar la fase de diseño, no la fase de producción, y que muchos procesos de fabricación están diseñados para hacer frente a las limitaciones específicas de una cadena de producción costosa. , que simplemente no se aplica al software.

Un ejemplo de un modelo de proceso que funciona muy bien en software, pero que a menudo falla horriblemente en el diseño del producto, es el diseño iterativo: comienza con un prototipo mínimo y agrega características con cada iteración. Construir un prototipo de automóvil para ver cómo se ve el nuevo diseño del pomo de la ventana trasera es ridículo, pero en el software tiene sentido (simplemente presione F5 y espere unos segundos, listo, listo para probar).

Si observamos los procesos de diseño de productos, las mejores industrias a considerar se dividen en dos categorías:

• aquellos en los que la producción puede realizarse a tasas de productos básicos; por ejemplo, la industria discográfica (el 1% o menos del precio de un CD es hornear e imprimir), medios gráficos, etc.
• aquellos donde las cantidades son tan bajas que la fase de diseño es el factor de costo más destacado (artículos de lujo, productos altamente personalizados, nichos de mercado ...)

Es un error fundamental intentar y aplicar procesos desde la fabricación física hasta el desarrollo de software: el desarrollo de software no es repetitivo (si es en su trabajo, vaya a buscar otro trabajo), solo es parcialmente predecible, solo hay muy pocas limitaciones físicas ( la velocidad del hardware es una), y tanto el enfoque adoptado como los resultados pueden ser muy personales. La aplicación de filosofías de línea de ensamblaje a lo que es básicamente una cuestión de pensamiento analítico y creativo puede (y a menudo lo hace) tener efectos devastadores.

Si desea escribir el mismo software exacto una y otra vez (en lugar de simplemente copiarlo), puede hacerlo de manera muy eficiente a través de una línea de montaje.

Pero la creación de software no es una tarea repetitiva, cada módulo es único. Es por eso que la comparación con la fabricación no es válida.

Creo que la respuesta que está buscando es aplicable o realista aquí. Lo que siento que quieres saber es cómo podemos configurar nuestros procesos para que se parezcan más a la industria manufacturera. En cambio, creo que la verdadera pregunta se convierte en "Saber qué hacen la fabricación y otras industrias para construir productos de calidad, ¿qué podemos aprender?" o "¿Qué puede hacer la industria del software para mejorar la calidad?"

Lamentablemente, la respuesta a esto no está clara porque la industria del software en sí aún no sabe la respuesta. Para poder responder a esto, la industria del software debe investigar qué funciona y por qué. Por ejemplo, se han realizado estudios que demuestran que el diseño de prueba de manejo (TDD) conduce a una mejora en la calidad. Aunque la cuestión de la productividad todavía parece no tener respuesta o al menos aún no se comprende completamente. En cuanto a lo que la evidencia muestra hasta ahora:

• Las revisiones de código son excelentes, y se muestra que encuentran la mayoría de los errores, pero la efectividad de una revisión cae bastante bruscamente después de la primera hora de revisión. Dado que la persona promedio solo puede leer unos cientos de líneas de código por hora, sugiere que los desarrolladores deberían dividir los cambios en partes más pequeñas.
• Cuanto más tiempo tarde en encontrar un error, más costoso (tiempo y dinero) será solucionarlo. Entonces, si un desarrollador lo encuentra mientras escribe el código, decimos que el costo es 1. Si una unidad de prueba lo encuentra más tarde, el costo es 10, si EVT lo encuentra, el costo es 100 y así sucesivamente.
• Existe alguna evidencia que sugiere que cuanto más complejos son los requisitos, más compleja es la solución y cuanto más compleja es la solución, más probable es que haya errores.

Hay un hombre llamado Greg Wilson que dio una excelente charla sobre esto hace unos años. Aquí hay un enlace a la charla: Greg Wilson Talk

Además de esto, diría que revises tu propio trabajo y encuentres los temas con los tipos de errores que introduces y con qué partes luchas. Compile estos resultados y luego cree una lista de verificación para insertar en su proceso en diferentes lugares para ayudarlo a hacer un mejor trabajo. Personalmente, eché un vistazo a los últimos años de mi trabajo y descubrí que hay algunos temas comunes a los problemas que presento. Específicamente he encontrado que

• No recuerdo a menudo construir todas las variantes que me llevan a romper la construcción.
• Muchas veces no pienso en lo siguiente para cada cambio. El buen caso, el mal caso y los casos excepcionales.
• Todos los escenarios posibles que podrían suceder. Tenga en cuenta que esto es realmente difícil porque hay muchos de ellos.

Dado que he encontrado algunos temas para mis errores, he creado listas de verificación que uso automáticamente, debido a su inserción en mis scripts, que me ayudan a solucionar estos problemas. Había un libro escrito sobre esta llamada, el "Manifiesto de la Lista de Verificación", que detalla cómo se les puede dar un buen uso. Personalmente lo encontré muy perspicaz.

No se trata de adoptar "sus" procesos. Se trata de adoptar "algunos" procesos, que no tienen los inconvenientes habituales y bien apreciados de usar procesos de línea de ensamblaje para esfuerzos creativos. Lo más importante a tener en cuenta aquí es la idea de que la calidad de los procesos se traduce directamente en la calidad del producto.

Los mejores procesos, o productos para el caso, son los que se ajustan al escenario de uso previsto como una mano en el guante. Lo que hay que pensar es que la parte de escritura de código real es la única que es, al menos a nivel macroscópico, no repetitiva. Todas las demás facetas, como el control de versiones, el seguimiento de errores, la planificación, las estimaciones, las mediciones, etc., y el uso de un proceso estándar, personalizado y probado pueden ayudarlo al menos en estas áreas.

Entonces, no, el proceso de desarrollo de software no puede compararse con la producción de la línea de ensamblaje y, como tal, "sus procesos" no están bien, pero la fase de diseño de producción / diseño de producto del producto en una industria manufacturera puede ser la fuente de inspiración.

Pregunta: ¿Podemos nosotros, como desarrolladores, aprender de los procesos de la industria manufacturera? ¿La adopción de sus procesos puede aumentar la tasa de éxito del desarrollo de software?

Respuesta: sí, por supuesto. Hay muchas lecciones que los desarrolladores de software pueden aprender de la fabricación a pesar del hecho de que el desarrollo de software es un proceso creativo. El desarrollo de software es en sí mismo un proceso e incluye muchos otros procesos. Cuanto mejor pueda definir y controlar esos procesos, mejor podrá controlar el proceso de desarrollo de software en general. Eso no significa que deba prescribir cada pulsación de tecla que haga un desarrollador; solo significa que, como desarrollador, naturalmente realiza tareas en un cierto orden, y esas tareas a menudo se pueden administrar. Aquí hay unos ejemplos:

• seguimiento de defectos: cuando se observa o informa un error, ¿qué le sucede? ¿Lo escribes en un trozo de papel y lo pegas en una espiga de 'investigar'? ¿Luego eliminas esos restos de uno en uno, los investigas y eventualmente los mueves a la espiga 'resuelta'? Si lo hace sin falta cada vez que recibe un informe de error, tiene un proceso bien definido y medible, y probablemente esté mucho mejor que alguien que tenga un sistema de seguimiento de defectos elegante y de alta tecnología que es tan oneroso que algunos miembros del equipo rastrean errores de otras maneras, o no lo hacen en absoluto.

• Control de versiones: existe una buena posibilidad de que use el control de versiones donde trabaja, y el control de versiones es obviamente mucho más útil cuando todos lo usan de la misma manera.

• diseño del producto: ¿Decide qué características implementar al lanzar dardos en una pared cubierta con notas adhesivas? Si es así, tienes un proceso. No creo que nadie pueda argumentar que es un gran proceso, pero al menos es un punto de partida. Si cambia el proceso, ¿cómo puede saber con certeza que su cambio fue realmente una mejora a menos que mida antes y después? No puedes

• revisiones de código: ¿sería útil una revisión de código si el proceso de revisión y los criterios de codificación cambiaran para cada revisión? Por supuesto no.

• ciclo de vida de desarrollo de software: todo el análisis -> diseño -> implementación -> prueba -> ciclo de mantenimiento es un proceso que debe definirse claramente.

En cada uno de estos casos, tener un proceso en funcionamiento le permite medir entradas y salidas y determinar si los cambios que realiza tienen el efecto deseado. No tener procesos establecidos significa que solo estás adivinando cuando intentas mejorar tu forma de trabajar. Esto es realmente de lo que se trata la fabricación, y solo tiene sentido tomar prestadas las sucesivas herramientas de refinamiento de la fabricación cuando son apropiadas.

Hay un campo completo dedicado a definir y mejorar los procesos utilizados para crear y mantener software; Se llama ingeniería de software . No sorprende que tenga preguntas sobre el proceso de desarrollo mientras lee sobre CMMI: CMMI es un producto del Software Engineering Institute .

El desarrollo de software ya ha adoptado muchos conceptos de fabricación:

• Es difícil no ver la influencia de las partes intercambiables de Eli Whitney en OOP y el desarrollo basado en componentes .

• Las técnicas de gestión de proyectos utilizadas en el desarrollo de software no son muy diferentes de las desarrolladas para la fabricación. Como solo dos ejemplos, el mundo del software adoptó recientemente el concepto Kanban que se desarrolló hace décadas en Toyota, y los gráficos de Gantt se utilizaron en la fabricación mucho antes de que se construyera la primera computadora electrónica.

• Las metodologías de gestión de calidad como Six Sigma que se desarrollaron para la fabricación se han adaptado al desarrollo de software.

A pesar del pesado entorno impulsado por el proceso, el desarrollador debe participar en la creación de cosas "sobre la marcha".

¿Me está diciendo que alguien decidirá por sí mismo agregar un parche al paquete de reconocimiento facial, y lo agregará a la compilación de producción sin crear primero un problema en el sistema de seguimiento, teniendo el diseño revisado, ¿Verificando el código en el control de versiones, o haciendo que la gente de prueba lo vea primero? Nuestro proceso requiere esas cosas por muy buenas razones. Si por "sobre la marcha" quieres decir "fuera del proceso", eso es inaceptable.

Hacer cosas sobre la marcha va en contra del espíritu de fabricación.

Nuevamente, si "sobre la marcha" significa "fuera del proceso", tiene razón. Pero si cree que la fabricación no requiere pensar rápidamente y desarrollar soluciones creativas a los problemas, está equivocado. En el proceso de fabricación surgen todo tipo de problemas: los bizcochos no tienen suficiente relleno de crema, las superficies pintadas dejan de pasar la prueba de rayado de QA, el 20% de las piezas terminadas carece de un anillo de retención importante, el sistema de mezcla de la masa se ha roto parte critica...