Rescaté este interesante hilo de discución existente en XING.
Lo traigo a mi blog más que nada para poder recordar en cualquier momento, todo aquello que pensé y aún hoy sostengo. También para disfrutar del sarcazmo de mis colegas:
Juan Carlos
Esta resumen detalla las malas practicas que se pueden aplicar a un proyecto de manera que ni el coste ni la calidad sean aceptables. Obviamente la lectura debe hacerse con tono sarcastico.
La garantía es completa. Siguiendo minuciosamente mi plan será imposible que vuestro proyecto se ajuste a las necesidades de presupuesto, calidad o plazos. Este manual de malas prácticas consta de los siguientes apartados:
- Relación con el cliente. Tenemos dos alternativas de trato para fracasar estrepitosamente. La primera es tratar al cliente de ESTUPIDO y la segunda creer que es DIOS y poseedor de la verdad absoluta. Ambas nos harán profundamente desgraciados y nuestros proyectos subirán en coste.
- Especificaciones funcionales. Tenemos tres alternativas: No escribirlas nunca, escribirlas al final o en el otro extremo detallar hasta el último detalle más insignificante.
- Planificación del proyecto. Para cumplir nuestros objetivos es mejor no planificar. Es más, cuando alguien pregunte sobre el tema disimilemos y hablemos de otra cosa. Como si no hubiera dicho nada. Cuando alguien de la tenga prisa ya correremos.
- Arquitectura y diseño. ¡!Que nadie pierda su tiempo con esto por dios!! Esta actividad puede generar grandes beneficios que revertirán en el coste, no solo del proyecto en curso si también de otros. Una actividad a evitar siempre que sea posible.
- Revisiones. Cuantas menos mejor. Todo el mundo debe ser capaz de hacer las cosas mal a la primera. No necesitamos que nadie empeore nuestro trabajo.
- Análisis Estático y Estándares de codificación. Esta actividad la podemos realizar completamente automatizada, siempre que no asignemos ningún responsable de supervisarlos ni ninguna actividad asociada. Así gastaremos dinero en una herramienta que no aportará beneficios.
- Pruebas unitarias. Aquí surgen otra vez dos opciones. Una es no hacerlas, claro, pero otra mejor es hacer development driven testing, es decir, escribir el código y luego los test unitarios que NO fallen.
- Integración continua. No hacerlo bajo ningún concepto. Es una actividad muy rentable. Mejor esperar al final del proyecto, juntarlo todo y disfrutar de los fuegos artificiales (pum, pom, plas, runtime,…)
- Test funcional. Solo hay una cosa mejor que no hacerlo. Hacerlo después de entregar la versión y luego ignorar los defectos que se encuentren ya que el cliente no los ha visto (aún). A ser posible no decirle nunca al equipo del test las nuevas funcionalidades y en caso de que nos fuercen a ello hacerlo en las relase notes (o lo más tarde posible).
- Mantenimiento. Poner a un becario a mantener todo el código si es que después de todo conseguimos llegar hasta aquí.
Esta presentación tiene como objetivo defender las buenas practicas desde la perspectiva del absurdo. Algunas de las exageraciones comentadas nos parecerán un disparate, pero nos harán reflexionar sobre nuestras actuaciones, decisiones o planificación de los proyectos y sobre todo incidir en los costes que resultan de aplicar las malas prácticas y como la calidad ayuda a reducirlos.
José
Enhorabuena Juan Carlos, se lo pasaré a mi jefe de proyecto, a ver si lo aplica del todo (le faltan sólo un par de puntos para conseguir aplicarlo enteramente) 
P.S.
Especialmente bueno el término “development driven testing”. ¡¡¡Como la vida misma!!!
Oscar
Una aportación al “manual del buen desarrollador” de Juan:
Los requerimientos:
Al igual que los clientes, los requerimientos son casi una leyenda. Pocos los han visto, y quienes los han visto o han resultado con una sicosis post traumática por ello o no los han entendido. Preventivamente, usted evítelos todo lo que sea posible.
Recuerde siempre que el único requerimiento que siempre se cumple es el que no se escribe (a esto los matemáticos le llaman prueba por vacuidad).
Si su cliente es uno de esos necios que insiste en escribir requerimientos, no se espante, igual puede conjurar a esas quimeras.
Primero, léase un par de leyes para que entienda lo que quiere decir “decir mucho sin decir nada”. Ya con el estilo jurídico en la cabeza, póngase a escribir un tratado kilométrico sobre la funcionalidad del software poniendo mucho cuidado en que no quede claro ni de qué software está hablando ni cuál es la tan mencionada funcionalidad. Use palabras técnicas, términos en inglés, nombres de archivos y bibliotecas, palabras inventadas y uno que otro periplo en pseudocódigo.
Haga uso de diagramas complicados en un UML muy personalizado, así, si el cliente tiene la desgracia de entender UML, usted puede presentarse como un reformador y modernizador del UML.
Un tip básico es:
Nunca use términos de dominio, son confusos. Por ejemplo, a los usuarios puede llamarles “userEntity”, o mejor aún, desaparézcalos y hable de “userName” y “userModuleAPermision”. Puede decir algo como:
[...]
Un userName especificado puede estar linkeado con un userModuleAPermision que indicará de manera especializada un comportamiento del sistema en cuanto al usuario asociado al userName en cierto módulo del mismo.
[...]
Escribir requerimientos de este modo es casi un arte, por eso existe gente que presta sus servicios como analistas de requerimientos, tanto para interpretarlos a conveniencia como para escribirlos.
Javier
Cuan importante es valorizar nuestra actividad individual para reconocer el esfuerzo grupal y sentir orgullo de lo que hacemos. Tan simple como entender que no se puede improvisar o mejor dicho, no se debe, pues de poder siempre se pudo y se hizo:
“La garantía es completa” y “Relación con el cliente”Esta frase me recuerda a cuando fui vendedor de seguros de retiro. La muletilla era “te lo pudo garantizar, decime a donde firmo. Pero mi firma va con la tuya”. Fantásitica técnica de venta agresiva, donde lo único que no va es la firma del vendedor.
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías? Personalmente opino que lo segundo. Si estuviera interesado en las garantías, sería el principal conocedor de nuestro proceso y el mejor crítico. Y pensar que desde un principio los proyectos tienen una alta garantía de fracaso!!!.
Recuerdo que algunos expresaron una envidia sana cuando en un hilo de Neurona expuse “Capacitar al cliente para …” . Algunos dijeron que era imposible contar con un cliente maduro. Solo expreso hoy que si tenemos un cliente al que podemo tildar de ignorante, estúpido, o simplemente inmaduro, quiere decir que nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen. También sugiero que estos tildes son puestos por los sectores operativos que se contraponen a la visión del cliente como un dios.
Por otro lado si nuestro cliente es “dios”, estoy seguro de que estamos hablando de una condición impuesta por nuestros superiores, nuestros comerciales o ambos y suelen ser un factor de presión al nivel operativo, principalmente a los Líderes de Proyectos y/o Analístas de Requerimientos o Funcionales, quienes expondrán las limitaciones de los requerimientos, del dominio del sistema y del negocio y en primeras instancias mostrarán las dificultades que serán inmediatamente tildadas de “visionarios de incendios y muertos en la puerta de un hospital” o de “solicitantes del postre cuando no se sabe ni comer”.
La mayoría de las veces puede darse que los costes ya están definidos y las variaciones sean mínimas o no significativas, pero el esfuerzo de comunicación, entendimiento y satisfacción serán absolutamente diferentes, según la madurés del cliente.
>”Especificaciones funcionales”
Este punto es casi para discutir de procesos y metodologías. Agile o RUP, RUP Agile, algún pseudo proceso a modo de proceso propio basado en….
No escribirlas me parece la peor opción. Sucede? si, todo el tiempo en mayor o menor escala, en proyectos, en defectos o incidentes, en mesa de ayuda o soporte. Siempre algo falta y en algún momento se necesita esa información.
Lo interesante de cualquiero proceso o metodología o combinación, es como construimos y administramos nuestra base de conocimientos.
>”Arquitectura y diseño”
Realmente dificil provocar la existencia de estos artefactos. Lo prácticamete imposible es hacer entender a La Gerencia lo importante de esta actividad y demostrar los beneficios fuera del proyecto, cuando estamos en fases de Garantías, justo cuando el cliente comienza a solicitar cambios significativos. Cómo explicarle a los niveles superiores que esos artefactos se deben considerar si o si en la presupuestación pues restarle arquitectura y/o diseño a un sistema es restarle FLEXIBILIDAD, ESTABILIDAD, ESCALABILIDAD y también merman los CRITERIOS DE SATISFACCIÓN AL CLIENTE.
>”Revisiones” (Evitar revisiones, “nunca lo hice ni lo volveré a hacer”)
En mi vida como profesional SQA, he sido partícipe necesario de los recortes de procesos por demanda de La Gerencia y me he sentido víctima, victimario e indiferente ante esta situación.
Al principio sentí la impotencia de la víctima de quien debe cumplir un rol, una función y no tiene el marco necesario. Este mismo modo me vinculó con el rol de Victimario, pues así me he sentido al ser complice sin otras chances más que la de expresar con cierta peligrosidad mi desacuerdo. Hasta sentí el impulso de renunciar. Y finalmente mi instinto de supervivencia me hizo volverme indiferente aunque más no fuera de manera temporal, pues mi naturaleza me impide cambiar la vista a otro lugar cuando tengo una importante obligación.
Hacer las cosas bien a la primera. Bueno, no es una locura y mucha gente pionera en Ágile explica el por qué. Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.
>”Pruebas unitarias”
Como lo explicaron en otro hilo de discución, debe existir un justo balance entre Testing Unitario, Testing de Integración y Pruebas de Sistemas. Lo que le hace mal a todas estas actividades es la falta de planificación, no contar con el tiempo de dedicación necesario y no atesorar la experiencia dejándo de lado las métricas, lecciones aprendidas y otros elementos que puedan ayudarnos a mejorar para próximos proyectos.
>”Integración continua”.
Integrar los componentes en iteraciones cortas suele dar resultados muy favorable para ejecutar testing en ciclos más contínuos, aún sin haber logrado efectivizar técnicas formales de Integración contínua.
>”Test funcional”
Quien no ha sufrido la entrega forzada de un producto no ha conocido la presión de esta industria particular.
En algunas ocaciones la estrategía ha sido no notificar a Calidad del despliegue del sistema en producción, luego de meses el cliente encuentra fallos de gravedad importante y “se tira la bomba a Calidad con una mecha encendida”, situación ante la cual solo sirve tener una gran conciencia o rastreabildad de lo que sufrió el proceso de calidad o morir callado asumiendo que el estallido puede costar muy caro.
Yo prefiero rastreabilidad antes que conciencia, pero necesito de las dos cosas.
>”Mantenimiento”.
No opino sobre este concepto pues al considerarlo de gran importancia y relacionarlo con los acuerdos de servicios, entonces prefiero que se abra un nuevo hilo de discusión al respecto.
En un nuevo posteo me uniré al sarcazmo.
Juan Carlos
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías?
Supongo que dependerá del cliente, pero me cuesta imaginar un cliente que quiera que su proyecto se ponga en riesgo a no ser que tenga algún tipo de razón maliciosa. Normalmente el cliente lo que quiere es pagar menos por más y eso es común a todos los compradores. Otra cosa es que la cesión comercial sea siempre a costa de la calidad o falta de funcionalidad encubierta (se le dice al cliente que si cuando sobradamente se sabe que no va a ser a si).
…nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen…
Más que nuestro proceso yo diría que se alimentan desde una posición de competencia feroz y a veces poco profesional que hace difícil competir diciendo la verdad (y si, ya se lo del largo plazo, pero dilo cuando presentas la cuenta de resultados….)
…Arquitectura y diseño
Realmente difícil provocar la existencia de estos artefactos
No es necesario un detalle impresionante, pero un mínimo de planteamiento se debe hacer, al menos si el proyecto tiene un tamaño considerable y sobre todo si es una plataforma nueva o un desarrollo nuevo completamente.
…Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.
Completamente de acuerdo. Cuanto antes se detecte el problema mejor.
…Yo prefiero rastreabilidad antes que conciencia, pero necesito de las dos cosas
La trazabilidad es mi seguro de vida. El avisar de los riesgos de la no ejecución de determinados procesos es nuestro deber, pero la decisión de asumirlos no. Puedo entender que si el producto no está disponible hoy, se llega tarde al mercado. No somos los guardianes de la calidad, sino que ayudamos a tomar decisiones respecto a calidad del producto.
El sarcasmo ayuda a digerir y tomarse con humor las situaciones más complejas.
Javier
¿El cliente esta interesado realmente en las garantías o en los problemas que provocan los incumplimientos de las garantías?
Supongo que dependerá del cliente, pero me cuesta imaginar un cliente que quiera que su proyecto se ponga en riesgo a no ser que tenga algún tipo de razón maliciosa. Normalmente el cliente lo que quiere es pagar menos por más y eso es común a todos los compradores. Otra cosa es que la cesión comercial sea siempre a costa de la calidad o falta de funcionalidad encubierta (se le dice al cliente que si cuando sobradamente se sabe que no va a ser a si).
Juan Carlos, ¿El cliente puede expresar que quiere evitar todos los riesgos posibles en su proyecto y no interesarse en tu proceso? ¿o evitar su involucramiento tan solo para sentarse a esperar desde una postura rigurosa de “ya pactamos los términos del contrato ahora quiero que cumplas en tiempo y forma”?.
Siendo esta situación posible, como proveedores ¿no adoptaremos todos los recuados necesarios para controlar todos los riesgos posibles y cumplir en tiempo y en forma? si respondemos que si a esta última pregunta, ¿podemos hablar de proyectos con pocos elementos de control en los procesos o en los que se sacrifique alguna parte de el, por ejemplo la calidad? ¿Podemos realmente ser rentables para nuestra organización y para el cliente si entregamos “encubiertamente” funcionalidad recortada? ¿Podemos seguir adoptando proyectos mal definidos y trabajar contra End_Lines mentirosos?
…nuestro proceso tiene muchos elementos que alimentan esa condición especial de nuestro cliente y la sostienen…
Más que nuestro proceso yo diría que se alimentan desde una posición de competencia feroz y a veces poco profesional que hace difícil competir diciendo la verdad (y si, ya se lo del largo plazo, pero dilo cuando presentas la cuenta de resultados….)
Juan Carlos, yo sugiero que busquemos clientes mejores, no los que solo pretenden el engaño de “pagar menos por más”.
Un cliente que aprecie la calidad será el que nos haga ganar dinero a grandes escalas, no solo por que nos pagará lo que valemos, sino que nos recomendará, nunca nos abandonará y será nuestro aliado para mejorar nuestros procesos y nos hará verdaderamente competitivos. Si somos fieles a nosotros mismos y trabajamos con lealtad, permaneceremos y trascenderemos.
Arquitectura y diseño
Realmente difícil provocar la existencia de estos artefactos
Juan Carlos, los procesos agilistas no desdeñan estos artefactos y cuando más agilista pretenden ser, más lo incorporan, aunque a su modo. Lo interesante es generarlos en el momento en que deben aparecer. Son la base para nuestros SLA y la garantía para lo que el mercado exige tan competitivamente, la evolución.
Pero sin ser Ágilista, siguiendo un modelo en V, cuanto antes se haga mejor, doblemente mejor para las fases de revisión, exponencialmente mejor para el proceso, el producto, la empresa.
Completamente de acuerdo. Cuanto antes se detecte el problema mejor.
Juan Carlos, estoy plenamente de acuerdo con vos en estos puntos.
El sarcasmo ayuda a digerir y tomarse con humor las situaciones más complejas.
Juan Carlos, también me pongo de acuerdo con vos en tomarse las cosas con humor.
Extraido de XING
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=96fa5292-c850-4053-914f-4039a4d50385)
