Me comentaba el otro día un compañero que estaba ya harto de escuchar absurdos consejos de compañeros de trabajo que se dedicaban a la arquitectura, la de edificios, sobre cómo se resolverían los problemas de los proyectos software. Consejos que, cómo no, se basaban en aplicar al software los modelos de gestión que utilizan ellos, los arquitectos, los de edificios sí.
Mi visión está muy alejada del anterior consejo. Es más, creo que los principales errores de gestión en proyectos software vienen, justamente, de intentar aplicar modelos de gestión copiados de arquitectos, a ingenieros de caminos, de hardware, etc.
Pensar que construir software sigue principios de construcción de cosas físicas ha provocado los mayores errores en la gestión software, valgan estos 5 tan horrorosos como reales ejemplos:
1 – Medir el avance el proyecto en función del número de líneas de código. Recuerdo una empresa que medían la productividad de sus desarrolladores en función de sus líneas de código por mes. Un clásico, una de las prácticas más absurdas e incompetentes gestionando un proyecto software. Lo curioso es que, aún hoy, la encuentro en algunas empresas. Supongo que a cualquiera le parecerá razonable que si un edificio está más avanzado es porque tiene más metros de ladrillos construido, pero… ¿qué un software esté más avanzado por tener más líneas de código?. Absurdo total.
2 – Los requisitos deben ser inamovibles. Un día me comentó un arquitecto que nuestro problema con el software era que “empezábamos los proyectos con requisitos no cerrados”. Yo le contesté que en su mundo, el de los edificios, cierran requisitos porque pueden, porque los requisitos para hacer un edificio no cambian. Pero lo que demanda un nuevo modelo de negocio no es que cambie… es que nadie lo sabe, y por ello es difícilmente especificable. En software implementamos ideas y no edificios, y las ideas cambian, evolucionan y se matizan. Además, el software puede cambiarse, un edificio no, y eso es una ventaja a saber aprovechar.
3 – El ciclo de vida en cascada. Nunca olvidaré aquella empresa en la que jamás fui capaz de que entendieran que el software se puede construir “por partes” (incrementalmente) e iterativamente. Nadie construiría un puente tomando unos pocos requisitos, haciendo un poco de puente, tomando otros pocos requisitos, haciendo otro trozo del puente, etc. Pero el software si se puede construir así… y eso le otorga una gran ventaja a saber aprovechar.
4 – Para que un proyecto ya comenzado vaya más rápido… hay que añadir más gente al equipo. Otro clásico, en charlas siempre comento varias situaciones reales relacionadas, como la de aquel software llevaba ya más de un año de retraso y el pobre cliente aún se empeñaba en que la solución era meter más programadores. Hasta estaba dispuesto a pagarlos él. El software no funciona así, porque es una actividad intelectual, no física, y añadir gente a un proyecto retrasado lo retrasa más. Por no extenderme, te dejo este post sobre el tema.
5 – El contrato cerrado o llave en mano. Ya solo lo del “llave en mano” suena a la entrega de llaves del nuevo piso. Este punto es un compendio de los anteriores, al igual que se subcontrata una obra, cerrando requisitos y plazos antes de empezar… igual debe hacerse el software, pero, si los requisitos del software no siempre pueden cerrarse, simplemente porque descubrimos nuevas ideas para el producto según lo construimos… ¿cómo puede funcionar ese modelo? Te dejo aquel post de contrato cerrado, ¿el peor enemigo del software o mal necesario?
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Pingback: Bitacoras.com
Sobre medir la productividad a través de LOC no lo veo mal. Si medir el avance.
Medir el avance, a ver… si yo estimo que este sistema lleva 1000 LOC y estimo bien, y tengo hechas 900 entonces me faltan 100 para llegar a las 1000. Si progamo 100 LOC x semana estoy a una semana de terminar. La trampa está en 2 puntos, a) que tan buenas son mis estimaciones y b) Medir el avance por esas estimaciones. En realidad el avance lo debería medir por funcionalidades terminadas.
Ahora en etapas tempranas, cuando tengo que poner precio a mi producto y firmar un contrato, lo más absurdo que he visto es no estimar por LOC (ojo que es lo más dificil). Llevando el paralelo a la construcción, la construccion estima por M2 (metro cuadrado) para sacar costos y demás.
solo eso.
Saludos.
Cuidado, porque si mides productividad con LOC puedes incentivar el mal código, el copy paste, el que una funcionalidad que se puede implementar en 5 líneas se implemente en 50, que al tener más código del necesario incurras en gastos de mantenimiento innecesarios (cada línea de código cuesta dinero), etc.
Estoy de acuerdo javier, pero convengamos que si sumamos otras prácticas (convenciones – buenas prácticas – validaciones y verificaciones) y herramientas de análisis de código estático, no solo estaremos detectando errores, sino homogeneizando.
Además, reitero, no hablo de medir avance con LOC, hablo de usar las LOC para estimar horas de trabajo. Así me parece mejor práctica ESTIMAR en base a TAMAÑO (no medir avance), porque se puede constatar en la práctica, que en base a esfuerzo (porque es mucho más complicado medir cuanto tiempo real me llevó una función). Y para ajustar las estimaciones, es mejor constatarlo con datos reales.
Para medir el avance, creo que lo mejor son horas hombre o puntos de historia de usuario si usamos scrum, (analizadas en conjunto con historias de usuarios completadas o «deliverable» de en una EDT (WBS) entregados, o casos de uso testeados). Digo esto porque decir que me quedan 2 historias de usuario de 10 , me dice cuanto avancé pero no cuanto me falta, al menos que tenga estimado que la duración de las 2 historias de usuario que me faltan tienen los Story Points que entran en un sprint y ahí si se que me falta solo un sprint.
Igualmente muy interesante el artículo y la discusión.
saludos.
Imposible saber las líneas de código de un proyecto, a no ser que sea algo muy chico (¿un «hola mundo» tal vez?), o huyamos de otras mejores prácticas y vayamos a contar líneas hasta que nos cuadre el numerito
Gracias Javier:
Totalmente de acuerdo en tus puntos.
No obstante comentar que las similitudes tambien son muchas. En mi caso, tambien me gusta aclararlas a mis clientes, pues tanto las similitudes como las diferencias son importantes para comprender.
Por ejemplo.
1. Tener siempre de antemano, un objetivo claro de lo que se quiere hacer.
Muchas veces se dice, quiero un modulo de sw, cuando en realidad se desea un erp. De esto le digo, es como que diga quiero una casa con relacion a un centro comercial. Las necesidades de uno y otro son distintos, los cimientos, los recursos, la genialidad, etc.
2. Puede medirse el avance. No por ladrillos, sino por partes terminadas.
En construccion, regularmente son pisos. En SW son modulos funcionales y probados.
3. Puede estimarse costos.
En construccion, son regularmente horas y costos fijos.
En SW es propiedad intelectual. Relacionado a los diferente metodos de costeo, el que considero mas ajustado a la realidad los puntos funcion que ya se han mencionado en tus post.
4. Y el mas importante. Puede ser tangible.
En construccion, puedes ver las paredes, los pisos, la gente trabajando, algo hacia adelante.
En SW tambien, puedes ver las pruebas, las funciones, rutinas, la gente pensando diagramas x, etc. No es que por arte de magia de la noche a la mañana (o al año) aparece un sw y el cliente no sabe lo que es. Si se debe mostrar los avances al cliente.
Saludos y muchas gracias por recordarme.
Milton Rafael Beltrant
MBS
El Salvador
Hola, Milton:
Sin ánimo de ofender, creo que no has captado el artículo. Y además tu argumento es justamente el criticado en el artículo, así que ed defender argumentos con los mismos argumentos.