Digamos que mi empresa iba a desarrollar una réplica de MS Word (solo como ejemplo). ¿Cuál sería el cuello de botella para el proceso de desarrollo, suponiendo que uno tenga efectivo infinito disponible y una organización como Microsoft? En otras palabras, ¿cuáles son los obstáculos más habituales para desarrollar dicho software rápidamente? Supongamos que todas las especificaciones están en su lugar y que la organización funciona perfectamente, por lo que nos enfocamos en el desarrollo de software hasta que el producto esté listo para ser enviado. Algunas alternativas pueden ser: - Escribir el código - Escribir pruebas - Probar manualmente el producto final - Reescribir el código debido a un diseño deficiente en primer lugar - Diseñar el código - Revisar el código realizado por desarrolladores experimentados - Diseñar GUI - Rediseñar GUI basado en alfa / comentarios de usuarios beta - Procesando comentarios de usuarios - Esperando comentarios de usuarios alfa / beta
Utilice referencias en su respuesta o indique su experiencia en el tema.
Respuestas:
En mi experiencia, el principal "cuello de botella" es el proceso de aprendizaje . Cuando su compañía hipotética se propone desarrollar el próximo Microsoft Word, hay una gran brecha entre lo que necesita saber y lo que realmente sabe. El tamaño de la brecha depende de muchos factores, puede ser en tecnología o en el dominio. Ha abordado algunos de estos temas en su pregunta, por ejemplo, diseño, comentarios de los usuarios, etc. Microsoft Word ha estado en desarrollo durante más de 30 años, por lo que entre la historia, el código, las herramientas y las personas hay mucho conocimiento detrás.
Entonces, si intentara hacer esto, trataría de contratar a las mejores personas con experiencia en el dominio, tanto técnico como administrativo. Pruebe y lea cualquier literatura disponible en el campo. También trataría de obtener comentarios de los clientes lo antes posible. El mayor problema son las cosas críticas que no sabes y que puedes descubrir muy tarde en tu proceso.
Esto, por cierto, no es exclusivo de los proyectos de software. Es cierto para cada proyecto a gran escala en el que intentas hacer algo nuevo. Por ejemplo, mira el Boeing Dreamliner. Hay muchos libros escritos sobre esto. El mes del hombre mítico es uno.
fuente
Has asumido que los dos mayores "cuellos de botella" en los procesos de desarrollo de software no existen (según mis experiencias personales).
fuente
Incluso en su mundo hipotético y perfecto, hay algunos problemas que puedo ver:
Probablemente lo más importante, desde mi punto de vista, es tratar con los clientes. Según mi propia experiencia, el negocio tiene que tratar con clientes que frecuentemente intentan cambiar el proyecto mientras se está desarrollando. En algunos casos, han tratado de enviar una solicitud de cambio como una corrección de errores para evitar tener que pagar dinero. Esto puede conducir a una gran cantidad de burocracia que puede retrasar un proyecto o conducir a piratas rápidos en el código que se convierte en deuda técnica más adelante. He leído y escuchado sobre equipos que se ocupan de estos problemas tan fácil como respirar, y desearía estar en uno de ellos :)
El segundo problema es la falta de un modelo de dominio adecuado. Eric Evans ofrece una buena cobertura sobre esto en su libro: Diseño impulsado por dominio . La falta de un buen modelo de dominio lleva a algunos de los problemas resaltados en la respuesta de Glenn, como intentar localizar un error. Sin un modelo de dominio limpio, puede llevar mucho tiempo recorrer / depurar el código para aislar y solucionar un problema. Yo diría que un buen modelo de dominio hace que la vida y la depuración sean mucho más fáciles, incluso más cuando se mantiene y extiende la aplicación más adelante.
Los problemas que mencioné anteriormente no producen problemas inmediatos, pero si necesita mantener este producto durante un largo período de tiempo, pueden volver a perseguirlo a usted y a su equipo.
fuente
No estoy seguro de lo que quiere decir con "la organización funciona perfectamente", pero incluso en una organización fantástica, el mayor cuello de botella en cualquier proyecto importante es la comunicación. Mythical Man Month señala cómo, a medida que crece un equipo de proyecto, las combinaciones de comunicación explotan, casi garantizando errores e información perdida.
fuente
Por lo que he visto hasta ahora en el trabajo, una gran fuente de cuello de botella proviene simplemente de los errores y del error humano que los creó. Solo piense en el tiempo que lleva depurar el código, encuentre una solución para el problema y luego vuelva a probar la nueva solución. Ahora imagine si esa solución causó otro error sutil. Puede ser una gran corriente de dolor y, por lo tanto, ralentiza el desarrollo en general.
fuente
Creo que Brandon Moretz tiene la mejor respuesta. Pero quiero agregar que sacar la primera versión de un proyecto grande no es tan difícil. Yo personalmente nunca he fallado en hacer eso.
Lo que no he podido hacer es crear la primera versión de tal manera que la segunda, tercera versión, etc. y / o correcciones de errores y / o mejoras menores de las características también se puedan entregar de manera oportuna.
fuente
Sí, estaré de acuerdo con las cosas anteriores y debo seguir los modelos de software. Según mi conocimiento, las cosas principales son:
1. Gestión del tiempo 2. Eficiencia del equipo y gestión del equipo 3. Coordinación en equipo y 4. Mejor comprensión con el cliente
Si tenemos los cuatro anteriores, podemos movernos a un nuevo mundo con éxito y muchas mejoras en términos de personalidad y software. Esto lleva a una buena relación con el cliente y el cliente dará las órdenes sin pensar en nosotros.
fuente
Defectos latentes, en requisitos, diseño, implementación, implementación ... Como en cosas que están rotas pero aún no lo has encontrado. Imagine el desarrollo del software donde cada nuevo error fue causado por los cambios más recientes.
fuente