Comentado: Ingeniería de Software Ágil de E.M. Jimenez

Compré este libro en Bubok (http://www.bubok.es/libro/detalles/170715/Ingenieria-de-Software-Agil) y he de decir que me presenta opiniones contrapuestas. Como siempre advierto, lo que yo he entendido, y comento, y lo quiere decir el autor no tiene porqué ser lo mismo y su opinión será tan buena o mejor de lo que puede ser la mía. Para que uno se haga su criterio, que se compre el libro y lo valore. Para mi gusto, escribir un libro y hacerlo público (con la consiguiente posibilidad de crítica) ya es merecedor de respeto.

Una de las cosas que más me ha gustado es la linealidad y facilidad de lectura. El autor (del que no se nada ni lo he encontrado en su Web) va estableciendo unas bases bien documentadas (que no todas comparto) sobre las que se va apoyando para llegar a algunas conclusiones. Otra cosa que me ha gustado mucho es la amplia referencia bibliográfica.

Algunos de los conceptos que podemos encontrar:
1 – La calidad no es negociable. no es un lujo. La no-calidad es un desperdicio.
2 – No se deben comparar a los programadores como albañiles. No son recursos reemplazables.
3 – La programación no es una labor de construcción sino de diseño.
4 – Las metodologías formales no tienen mucho valor porque son el reflejo de la ley de Parkinson (máxima ocupación del tiempo en entornos burocráticos).
5 – Las estimaciones de software son ciencia ficción al alegar que la programación no es una actividad predictiva. Además requieren un gran esfuerzo de análisis.
6 – Los diagramas de gantt no son adecuados para representar estimaciones.
7 – Describe las metodologías ágiles, la programación extrema, los patrones de refactorización y diseño, repositorios distribuidos, herramientas tipo make y ant, depuración, estándares de codificación.
8 – Defiende el uso de lista de correo y wikis para documentar. Del mismo modo que la separación del contenido y el formato de la documentación con herramientas tipo TeX. Valorar la utilidad y simplicidad de los editores Vi (me suena a un tema de moda)
9 – Comenta muchos principios relacionados con la calidad total (tipo Kaizen) y el toyotismo en contraposición al taylorismo.

El libro me parece un buena recopilación de ideas de distintas obras. El fondo me parece bueno, criticar la situación actual pero me faltan unas conclusiones o soluciones.
Estoy seguro que a muchos técnicos descontentos les puede gustar. Es lo que muchos querrían oír.

Bueno, hasta aquí solo la parte de descripción, ahora paso a la valoración. Realmente no voy a valorar la obra, sino lo que creo que es una visión generalizada e incorrecta de la situación.
Advierto que, como no voy a decir lo que gustaría oír, es puramente a título personal porque seguro que los otros socios de Autentia y/o empleados tendrán su propio criterio.

La visión de la gente buena, trabajadora e interesada por la profesión, por desgracia, no suele ser muy realista y, como pasa a los superdotados en el colegio, tienen un índice de fracaso muy elevado.

Los técnicos, además de leer a Fowler (como ejemplo de referente técnico), deberían leer a Kotler (como referente de marketing y empresa) para saber como encaja la vocación con el dinero en el mundo. Si no te importa el dinero ni la visión industrial/empresarial, no sigas leyendo.

Me explico comentando algunos puntos:

La calidad tiene un coste y es admisible distintos niveles de calidad:
————————————————————————————————-
Todo producto tiene gamas. Y cada gama un mercado objetivo. Las tendencias inciden sobre las gamas y se crean nichos que se pueden aprovechar.
El Corte Ingles tiene: Caviar iraní en la boutique del gourmet, una marca de huevas reconocida en su hipercor y su marca blanca propia de huevas. Obviamente, la calidad del producto y el precio, pues serán distintas.
Por ejemplo, la ropa. El éxito del modelo de Zara/Sprinfield/Pull&Bear o similares es haber entendido que a la gente prefiere cambiar de ropa barata, de calidad cuestionable, todos los años, que tener una ropa de calidad. La moda cambia y no se quiere como antes que un jersey dure años. Otro ejemplo puede ser Ikea.

En el mundo del software parece para mucha gente que, o trabajo elaborando caviar iraní o rompo la baraja. Pues no es así.
No todo el mundo es tan vocacional, no todo el mundo tiene tanto celo profesional, no todos los clientes requieren una calidad total y es más, tampoco se necesita….

Una pyme puede requerir un desarrollo Web para tener presencia en Internet y puede hacérselo perfectamente en html y php un chaval recién salido de FP con los conocimientos cogidos con alfileres e importa nada los patrones, la refactorización y el TDD. Le van a pagar 300 Euros por un Web (que le costará cobrar) y probablemente cuando lo cambien, contratarán a otro 100 euros más barato, no se aproveche nada de lo anterior, ni merezca la pena.

Ahora bien, también existirá el punto contrario. El cliente celoso de su profesión, profesional, con sistemas que deberán durar años y con medios, que quiere que su desarrollo, a parte de funcionar sea mantenible y fiable, con unos estándares de calidad altísimos.
Ese, tendrá que elegir bien a profesionales de élite y saber que tiene un coste alto. En este segmento es en el que yo quiero competir con los maestros. Este segmento es el que entre unos pocos estamos intentando crear/potenciar.

Luego están aquellas empresas cliente que han entrado en la política de concursos, de exprimir al proveedor, y que se creen que da igual quien te lo haga, desmereciendo las habilidades y conocimientos y que quiere todo por un precio ínfimo y ver a 20 personas hasta las 9 en un proyecto…

Es el cliente el que define la gama que desea. Si eres hábil podrás instruirle en la diferencia entre lo bueno y lo malo (si eres el que ofrece lo bueno, claro).

Pero, hay mercado para todos y lo que hay que tener es una estrategia coherente para saber en que tipo de empresa estás trabajando. Es decir, la gama de tu empresa y la gama tuya como profesional.
Si eres de los que te crees bueno, intenta hacer que se valore lo bueno para potenciar tu mercado (que es lo que echo de menos en el libro). Las empresas de carnaza, se encargarán de vender el valor de la externalización masiva y el desvío de proyectos a otros países …. como si en la India no hubiera becarios mediocres, con rotaciones infinitas y deseando irse a occidente y solo hubiera gurús de las matemáticas y el ajedrez.

Los programadores, deber ser recursos reemplazable
————————————————————————–
De nuevo, mucha gente proyecta y no se acuerda de cuando empezó a trabajar.

En cualquier empresa hay gente experta, senior, junior y becarios. No todo el mundo nace enseñado y, por desgracia, la universidad no forma al personal para las necesidades de la empresa.

Una empresa de nicho de élite, podría tener solamente personal experto. Poca gente muy especializada pero ¿como entonces se incorporan al mercado laboral los nuevos titulados? ¿para que valen?

Pues porque el mundo tiene muchos nichos distintos y necesidades generalistas.

Una empresa de calidad también tendrá que ofrecer una tarifa competitiva, tendrá que utilizar el personal más barato capaz de desempeñar una tarea. Esto no significa compararlos con albañiles (sin desmerecer).

Una empresa generalista hará un proyecto con una persona senior y alguna persona junior. De tal modo que la junior vaya avanzando y el mix sea competitivo.

¿Acaso en Toyota todos son doctores y titulados superiores con 20 años de experiencia?

¿Por qué un programador debe ser un recurso reemplazable? Si el proyecto está bien hecho, bien documentado, tiene un diseño sencillo, hay comunicación, está orientado a pruebas (anda, principios ágiles) cualquiera, con un nivel de conocimientos, podría modificarlo. El senior, de echo, podría valorar el cambio y el junior podría ejecutarlo. Incluso si se equivoca, eso formará parte de su aprendizaje.

Si además no trabajas en 50 tecnologías distintas y hay una buena gestión del conocimiento, los participantes de un proyecto deberían rotar porque estar en el mismo proyecto toda la vida es un coñazo.

¿Pero acaso no funciona el universo así? O un abogado recién salido de la carrera esta defendiendo casos vitales el primer día ¿le contratarías?. Supongo que tendrá que aprender de los senior y hacerles a estos labores auxiliares hasta que adquiera en bagaje para ser autónomos. El se convertirá en el senior y otro junior tomará su trabajo.

Diseñar consiste en definir como se van a hacer las cosas antes de hacerlas
——————————————————————————————————–
A ver si resulta que el único diseño válido va ser el código. El TDD y las técnicas ágiles son estupendas y apuesto por ellas pero, los proyectos ágiles también definen una fase 0 donde especificar y diseñar la solución.

Es más, lo único que aportaría una regulación de la profesión informática es la obligación de que el cliente pagase un análisis y un diseño en condiciones.

Otra pregunta interesante es si ¿el UML o similares es tan malo o es que somos demasiado torpes para no sacarle partido?

Los patrones de diseño se definen y discuten con diagramas de clases y secuencia. Son artilugios indispensables para cualquier experto. Un experto los dominará y aplicará cuando proceda.

No entiendo como explicar a un grupo de compañeros lo que quieres hacer de un modo más ágil que con UML o ¿nos ponemos a programar directamente?.

Si lo entiendo realmente: El problema es que hasta ahora, la gente que está empujando, trabaja de un modo muy individualista y apasionado. Lo que no se encuentra con facilidad es un grupo de 10 personas deseosas de dejarse los cuernos en aprender incondicionalmente y conseguir entre todos un modo sistemático de trabajar.

Las metodologías son vitales en cualquier organización y, antes de adaptarlas hay que seguirlas formalmente
——————————————————————————————————————————————————
Cuando se habla de Scrum, una buena recomendación es tratar de seguirlo formalmente para luego, adaptarlo a tu realidad. Evitar inicialmente el Scrum but…

Una cosa que digo a la gente que se incorpora en nuestra empresa es: Aprende a trabajar con nuestras técnicas y, cuando lo hagas mejor que nosotros, propón los cambios que quieras (esto creo que lo leí en el libro “la pastilla roja” relativo a hacer aportaciones en una comunidad).

De nuevo, volvemos a la mentalidad de proyectos pequeños e individuos expertos y heroicos. El trabajo requiere homogeneidad y disciplina. La metodología, sea la que sea, es fundamental.

Los proyectos hay que estimarlos para que te los contraten
———————————————————————————
Somos muchos lo que trabajamos por convencer a los clientes sobre el valor de los contratos ágiles pero, eso normalmente se consigue cuando el cliente tiene una buena experiencia contigo y/o el propio cliente es muy maduro (entiende que todo el mundo tiene que ganar en un trato).

Normalmente, cuando alguien te llama para hacer un proyecto quiere que figure en un contrato lo que tienes que hacer y por cuanto dinero. Entonces, o espabilas haciendo estimaciones y acotando con una información muy parcial o tienes un grave problema. Si te quedas corto, palmas dinero. Si te pasas, contratan a otros.

El Vi(m) y las herramientas
————————————-
Hay una frase de Ivan Zaera que me gusta mucho “la potencia de ayer hoy”. A mi, personalmente me parece surrealista. ¿El autocompletar, depurar paso a paso, ver la cobertura visual de las pruebas en el código, la ayuda en linea, la navegación por los registros de la base de datos, etc de herramientas tipo Eclipse entonces no valen para nada? Se alega que con un entrenamiento en Vim la productividad es muy elevada. Pues con un entrenamiento en Eclipse o similares me da que va ser muy superior.

Y de nuevo, como no todo el mundo es un dios con 15 años de experiencia y maestro en todas las artes, les ayuda.

¿Y que pasa con las APIs, frameworks, etc.?
——————————————————-
Parece que usar xUnit es algo vital (cosa que comparto). ¿Y las otras decenas de APIs y Frameworks estándares de facto en el mercado?.
Además, muchos proyectos son primos hermanos. Requieren SSO, caches, registro de trazas, control de navegación, etc… De nuevo, me da la sensación que, como una sola persona es difícil que pueda controlar de todas estas cosas, se desmerece su valor.
Trabajar en Java y no saber de Spring, JPA, SSO, Cache, etc ¿no parece un mínimo lógico para una organización? o lo inventamos siempre desde cero …

En un grupo de gente potente, tiene que haber un conocimiento mínimo como refleja este libro. De echo, yo creo que se queda corto (aunque hay que cortar en algún sitio). Cada persona, tiene que especializarse en un conocimiento de más alto nivel para ser efectivos o para por lo menos tener capacidad de criticar las cosas. Me explico: Que alguien me diga sin saber Liferay que es mejor hacer un portar sin usarlo, sin haber hecho uno nunca antes con él, no tiene para mí ningún valor. Tiene valor el que me lo dice habiendo construido uno (ya os digo que no es ni blanco ni negro) … pero el tiempo y las capacidad son es finitos ….

Para terminar
——————–
En el fondo, estamos parcialmente de acuerdo pero, creo que hay que ser realistas y casar los deseos y frustraciones con las realidades del mundo.

Lo importante, es saber elegir a nuestro cliente, poner en valor nuestro trabajo y convencerles de lo irrisorio de los modelos actuales pero sin forzar extremos idealizados para el grueso de las necesidades.

Hay que ir dando pasitos.