He estado pensando en escribir este post desde hace unas semanas cuando empecé una reflexión sobre que tan rígidos somos (o debemos ser) al intentar aplicar metodologías agiles, y todo empezó con este dialogo con un amigo que trabaja fuera de Perú:
Amigo: tudo bem?
Yo: tranqui...tratando de introducir Scrum por aqui...
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio.... y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y... usan planning poker para estimar?
Amigo: no idea....
hay jefes de proyecto en varios niveles....no se como hacen sus pronosticos del tiempo.
Yo: pero ... hacen retrospectivas?

Amigo: no tengo vision global

Yo: me refiero, retrospectivas a nivel de equipo
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm.... entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno... antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso... todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible....o como lo quieras llamar, para un purista, no aplica
Yo: pero... alguna vez el equipo hizo retrospectiva? veamos... hay cosas en q si puedes ceder y cosas en que no...las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de "nada interrumpe" al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace... eran del jp con el cliente, ahora... tu puedes indicar cuanto t puede tomar....y en base a eso el jp... trata de decir si va o no va... o si va, cuanto les va a costar.
Yo: veamos.... se negocia el orden del backlog y siempre hay repriorizaciones...
Amigo: para eso esta el jp
Yo: veamos... tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo... pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace...etc
el jp, del jp de desarrollo, seria el scrumMaster... mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint... este permanece inamobible?
Amigo: todo depende del jp de desarrollo....el evalua en que casos se pueden hacer cambios
Yo: uhmm... los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio....
Amigo: no hay nada q hacer.... q eres un purista

Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.

Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar "Scrum" en un proyecto:

1. Queda bien de cara al mercado decir que se usa
2. Hay una necesidad de mejorar la manera de hacer software (problemas de tiempos, alcance, calidad o todo junto)
3. Se escucho en alguna conferencia y se decidió ir por ello, o algún "guru" que paso por ahí lo recomendó
4. Se desea mejorar la organización y se pensó que Scrum seria un buen componente dentro de ese proceso

No conozco mas detalles, pero si bien cualquiera de esas razones puede llevar a la situación planteada, solo las "pares" dan un punto de partida razonable, pero aun así son incompletas si no tienen como base el asumir la "filosofía" detrás del Manifiesto Agil, y se paso directamente a querer implementar la "metodologia" y luego a "adaptarla".

Adaptar... interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba "uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización", lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de "equipos autoorganizados" o "propiedad colectiva" del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.

Como es evidente, poco de eso ha sido tomado en cuenta en esta implementación de Scrum, quedando solo las iteraciones, pero lo peor es que no ha sido asimilado por el Equipo, el cual puede llegar a ver todo lo demás como "purista", y si, caer en el purismo a rajatabla es un riesgo, por lo cual hay cosas que se pueden ajustar en cierto punto como el mapeo de roles a algo mas cercano a la realidad organizacional,

Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos... Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo... lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar "baby steps" como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.

Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de "nada interrumpe el  Sprint".

Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo "compre" la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible.... lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara "scrum flexible".

Y uno al leer el título podría pensar que se esta incurriendo en un desprecio hacia el cliente que nos ha encargado el desarrollo de un software, pero nada más lejos de la realidad, la reflexión viene a algo que aun sigue siendo mal entendido por quienes estamos involucrados en el desarrollo de software.

No cuento nada nuevo que tradicionalmente (modelo “cascada”) el desarrollo de software tiene un historial de fracasos totales o parciales, ya sea en funcionalidad incompleta, sobrecostos de tiempo y dinero, lo cual lleva como consecuencia en que los aun medianamente exitosos tengan la presión por conseguir entregar “lo que se pide” “a tiempo”, y claro muchas veces sin importar el “cómo” que es a lo que nos lleva el título de este post, el cómo la obsesión por entregar algo que el cliente pueda usar hace que se pierda la perspectiva global del problema.

Y el problema (deuda técnica) ya es conocido: métodos de más de 400 líneas de código, código muerto y/o duplicado, lo cual deriva en poca mantenibilidad, bugs como consecuencia de la extensión de la funcionalidad, pobre performance, etc; síntomas que hacen que el que hereda un código desee ir corriendo tras el que hizo el código originalmente, (y un cliente pagando resignado los costos de implementar un parche o una mejora menor).

En este punto se nos podría decir que esto ocurre porque el equipo de desarrollo no aplicó un buen patrón de diseño, que no siguió los principios S.O.L.I.D., lo cual si bien tiene algo de cierto no es sino la segunda capa de un problema mayor que veremos en breve.

Se pensaría que con la irrupción de las metodologías ágiles la situación ha estado cambiando, pero no, la realidad no es tan hermosa, pues si bien ahora tenemos más visibilidad sobre los elementos (historias de usuario) que se están desarrollando no debemos de olvidar que las metodologías imponen un proceso de priorización, en el cual lamentablemente las historias funcionales (si, las que “dan valor”) toman precedencia siempre sobre las técnicas, las cuales tienen que rogar para hacerse un lugar en el sprint o en el flujo del Kanban, y muchas veces nunca logran entrar por la sencilla razón de que “no hay como justificar ante el cliente algo que no se ve que le reporte valor”. Así pues, se cumple con la entrega de funcionalidad continuamente, pero seguimos acumulando deuda técnica pues, a pesar de seguir perfectamente el proceso, sólo nos estamos enfocando en entregar un software que funcione sin fijarnos en qué es lo que hay detrás de este software que se entregó perfectamente en plazos pues lo importante es que funcione, ¿no? ¿qué hay deuda técnica? tranquilos, eso lo solucionamos con una refactorización circunstancial (léase: arreglamos cuando podamos y no nos quite mucho tiempo).

Recomiendo leer este interesante articulo de Lucas Ontivero donde nos cuenta como las cosas han seguido yendo mal en el lado técnico a pesar del agilísimo.

Adicionalmente tenemos el factor del QA (Quality Assurance), uno podría creer que en empresas grandes este equipo tendría una visión integral de la calidad del producto, lo cual debería incluir tanto la verificación de la mantenibilidad y calidad del código como de la validación de la arquitectura, pero no, al parecer su visión va sólo al lado funcional, o sea a lo “visible” del gráfico anterior, siendo que temas como la mantenibilidad “lo ve el equipo de desarrollo”, así pues por un lado se exige un cumplimiento funcional (muchas veces sin entender las razones por las que “la gente de desarrollo” opto por implementar de una manera diferente a como QA lo pensaba) estricto pero por otro lado se omite la validación de la calidad de lo técnico, pues claro… no es lo que ve el cliente de manera directa, por más que este sea el que luego tenga que pagar los “intereses” de la deuda técnica(*). No se ustedes pero si un equipo que se supone se encarga de la “calidad” durante el ciclo de desarrollo ignora la parte técnica de la implementación (¿alguien dijo auditorías?) , le esta haciendo un flaco favor al proyecto y al cliente.

Así pues mucho del problema viene dado por la importancia que se le quiere dar al elemento técnico del proyecto, el cual viene tradicionalmente es relegado por debajo del administrativo, siendo que muchos profesionales hacen gala de haber tocado muy poco los elementos correspondientes a la programación en su formación profesional, lo cual en mi opinión generalmente (he conocido excepciones) ocasiona que no se sepa (debido a que a veces no se entiende) el impacto de una decisión técnica que se tome en cualquier etapa del desarrollo, razón por la cual prime el componente funcional/visible a la hora de definir prioridades en el desarrollo.

Afortunadamente hay caminos de solución, uno de ellos es tratar de entender qué es lo que ha derivado en la creación del Manifesto for Software Craftsmanship como una evolución del Manifiesto Agile (esto lo explica muy bien Edson en esta presentación); y por otro lado, dentro del marco de las metodologías ágiles, reconocer de manera visible el rol que deben de jugar los componentes técnicos, en ese sentido me sorprendió muy gratamente como en su reciente conferencia "Lean from the Trenches" Henrik Kniberg indicó claramente cómo dentro de su proceso ágil (basado en Kanban) había reservado, dentro de su tablero, el espacio necesario para las historias técnicas, de esta manera

Es que como Henrik dijo, en un mundo ideal sólo habría historias de negocio, pero no estamos en un mundo ideal, los problemas técnicos existen y no podemos pretender seguir ignorándolos, o creer ingenuamente que efectivamente lo “solucionaremos después”, o ya en el lado extremo seguir en la ilusión de que cualquier programador podrá implementar algo si le damos una especificación funcional completa y detallada.

Entonces, regresando al título de este post, creo que debe de quedar claro que no es que no tengamos como meta el entregar funcionalidad y software, sino también validar el cómo llegamos a ese entregable, procurando (entre otras cosas):

• Dar el espacio a las historias técnicas cuando corresponda, y no relegándolas a cuando “haya tiempo”.
• Sospechar del programador que defiende una mala implementación con un “pero funciona”.
• Ser consciente de los riesgos que significa ir por el camino rápido en aras de entregar la funcionalidad pedida.
• Que todo el equipo (y no sólo el que implementa) sea consciente de lo que hay en la implementación (arquitectura, algoritmos, etc) y de como eso condiciona los tiempos de desarrollo, especialmente cuando se trata de agregar una nueva funcionalidad.
• Valorar el factor técnico, procurar la mejora de las habilidades técnicas de los desarrolladores: mentorship, revisión por pares, dojos, etc.

Claro que mucho de esto tendría que ir de la mano con un reconocimiento dentro de las organizaciones al rol que juegan las TI en su crecimiento como negocio, pero por ese lado la cosa esta bien complicada.

(*) Se entiende como “intereses” de la deuda técnica al hecho de que conforme pasa el tiempo será más difícil corregir las malas decisiones o malas implementaciones de código, ya sea porque el desarrollador que implementó algo de manera críptica ya no se encuentra en el equipo, porque nueva funcionalidad superpuesta generó más dependencias o simplemente porque por el tiempo que pasó ya es más difícil acordarse el porque se tomó esa decisión que “parecía buena en su momento”.

Durante un tiempo he estado siguiendo entusiastamente las metodologias agiles, y recientemente he practicado algo de Kanban, y si bien me han terminado gustando algunos de sus enfoques me he sentido frustrado por la impedancia entre el hecho de que el backlog se manejara por un lado usando un Excel y por otro la visibilidad de las tareas en progreso (WIP: Work in progress)unicamente mediante postit's en la pizarra.



Si a esto le sumas el hecho de que el TFS solo se usa como repositorio de código fuente y no como la herramienta de ALM que es la decepción es mayor, pero en este caso se puede entender los reparos si es que no se incluye de entrada un soporte para el modelo Kanban, como si que lo incluye para CMMI y SCRUM.

Al parecer esto va a cambiar pues gracias a Ulises me vengo a enterar de que en CodePlex los Visual Studio ALM Rangers estan desarrollando la Practical Kanban Guidance con Team Foundation Server y Visual Studio, dentro de este proyecto (para TFS 2010 y el inminente TFS 2012) se incluye la nueva plantilla Microsoft Kanban 1.0 Process Template así que con esto se abre un nuevo capitulo para consolidar el uso de TFS en las diversas metodologías ágiles, tratando de demostrar que su uso incrementa (y no reduce) el ancho de banda en la comunicación del equipo.

Queda ver si es posible usarlo desde la nube via TFS Preview

De la mano de mi regreso al Perú decidí volver a acercarme a mi universidad, y aparte de colaborar como Jefe de Practica el ciclo pasado desde hace unos meses estoy participando en el Proyecto Consejeros de Carrera de la Bolsa de Trabajo (BTPUCP), es en ese marco que soy contactado por la BTPUCP para una entrevista sobre mi experiencia profesional, mercado laboral y consejos para los jóvenes estudiantes de Ingeniería Informática, entrevista llevada a cabo por Reiner Diaz durante el mes de Agosto, la cual quiero compartir con ustedes a la espera de sus opiniones.

Mi agradecimiento a Reiner y a la Bolsa de Trabajo por esta oportunidad de compartir mis puntos de vista especialmente con las nuevas generaciones de nuestra universidad.

Gracias al blog de Lucas Ontivero, leo esta graciosa nota:

Muy gracioso, sigue siendo 1+1 = 2 (que nunca = depende como dirían los abogados) pero ahora queda mejor pues es mas difícil de entender, y es que esa es la realidad concreta en las publicaciones de la IEEE y lo digo por experiencia.

Estuve afiliado a la IEEE con membrecía en la Computer Asociation, por lo cual recibía las revistas Spectrum y Computer, era un plan interesante, pues la nomina anual no me costaba tanto al ser (entonces) egresado reciente, pero la verdad sea dicha el nivel de abstracción de la mayoría de los artículos de Computer era demasiado lo cual lo hacia poco practico dedicarle tiempo.

Claro, se me dirá que una revista así de por si es complicada, pero no, no era eso sino que deliberadamente usaban un lenguaje árido en la mayoría de los casos, lo cual contrastaba con p. ej. Software Development Magazine, una revista dedicada a metodologías y practicas para el desarrollo de software, en la cual se notaba que los autores estaban de veras interesados en que los lectores se hicieran con los conceptos planteados, y claro si bien no era un tema para el publico general, al menos había la intención de exponer los contenidos de manera razonablemente simple (pero no mas simple) y hasta amena. (*)

En algún momento sospeche que era practica deliberada de las revistas académicas (pues a pesar de definirse como asociación profesional, el enfoque tendía mas hacia el lado académico), lo cual me quedo corroborado cuando una amiga me dijo que parte de los requisitos para publicar papers en ciertas instituciones era escribir de tal manera que la idea fuera difícil de seguir ya no por graduados profesionales, sino aun por graduados de master, pues de esta manera se lograría que el debate solo sea seguido por cierta clase de publico, iniciado en ese metalenguaje y ese estilo.

Entonces, la pregunta que nos debemos hacer es si ¿el conocimiento debe tener barreras de comprensión mas allá de su propia dificultad intrínseca?, ¿se justifica ese hablar “en difícil” a fin de acotar tu auditorio y que el debate solo sea entre los elegidos?, ¿será que en el fondo son como Sheldon Cooper rechazando la divulgación y popularización del conocimiento?(**).

Parte de la razón puede estar en al naturaleza no-democratica de la ciencia, si, pues como es sabido para establecer algo como “ley” (en teoría) no es necesario consenso ni votaciones, sino demostrar de manera repetible y verificable lo que se esta planteando, el problema es que (creo) eso lleva algo que Miguel Angel Sabadell comento hace tiempo en Muy Interesante, de que la comunidad científica espera apoyo de la sociedad (y el estado) para sus actividades, pero no esta dispuesta a que esta tenga injerencias sobre el rumbo que deban seguir sus investigaciones, puesto que si la sociedad interviniera en lo que se debe investigar se dedicaría mas tiempo en cosas menos “glamorosas” como mejorar los sistemas de calefacción y ventilación de las casas.

Así que en parte se puede explicar esa ´tendencia casi natural a querer volver el conocimiento como coto de caza privado a cargo de la elite intelectual.

 

(*) En honor a la verdad debo reconocer que fue en Computer donde tuve conocimiento por primera vez de lo que eran las metodologías agiles, ya que excepcionalmente los autores se preocuparon por ser lo suficientemente claros para plantear esa idea (entonces) novedosa.

(**) Aunque en honor a la verdad su adorado Richard Feynman era un conferencista bastante claro y ameno.

En el entorno industrial existe la clásica pelea entre el área de ventas y el área de producción: “No están cumpliendo con el plazo que le hemos ofrecido al cliente” “Los de ventas ponen plazos y metas imposibles”, dilema que casi sin variantes se traslada al desarrollo de software, y muchas veces creemos que es un callejón sin salida, pero escarbar un poco lo que paso podría ayudarnos a reducir esta clase de situaciones.
Parte del problema viene de la teoría de “si a los programadores les damos la especificación bien detallada, las cosas saldrá en tiempo y reduciremos problemas” , pero claro, por mas que se  detalle, al momento de construir pasan cosas y vemos que esta idea no es tan simple como parece, y si le añades conceptos como “pool de programadores”… desastre garantizado, en ese sentido es conveniente citar a lo que afirma Rodrigo Corral:

Habitualmente, la réplica suele ser del estilo: "eh!!! Pero si el desarrollador solo tiene que 'poner ladrillos' nuestros analistas se lo darán mascado'. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados'. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que 'poner ladrillos'. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Pude comprobar en carne propia cuando tuve mi primera responsabilidad de gestión técnica, el equipo de análisis nos había dejado especificaciones bien detalladas sobre la funcionalidad de las pantallas a desarrollar, y así emprendimos el camino con mi equipo de programadores, el problema llego cuando nos topamos con dos pantallas en que no nos poníamos de acuerdo sobre como implementar el flujo de acciones de usuario, así que las conversaciones fueron a mas con la analista, resultando que al final llego una contraorden, las 2 pantallas se cancelaban (teniendo que tirar todo el trabajo avanzado) y se reemplazaban por una completamente nueva, mas aun siendo que había dudas sobre lo escrito en la (nueva y detallada) especificación hubo que dedicarle tiempo de conversación de lado a lado con la analista. Así que en este caso bien podríamos haber intentado ajustarnos a la especificación y entregar “algo” que evidentemente luego seria rehecho, pero no, nos correspondía avisar que esa especificación no era consistente y alertar a tiempo (es mas, visto en retrospectiva debimos avisar días antes).

La misma sensación la tuve hace unos meses cuando en una sesión de planeamiento, la Analista/Product Owner propuso un cambio de funcionalidad que entre otras cosas involucraba hacer severos ajustes a la integridad referencial de algunas tablas, el equipo estaba dispuesto a acometer la tarea, pero preferí indicar que los cambios tenían potenciales consecuencias que debían determinarse por anticipado, por lo que cancele la sesión de planeamiento y nos derivamos a una sesión de brainstorming para ir cubriendo las posibles implicancias, para de esta manera ofrecer dos alternativas, con sus pros y sus contras. Para la siguiente semana con ese documento y el apoyo de otro analista técnico la PO pudo decidir totalmente informada y asimismo ser consciente de que el tiempo no era tan corto como ella suponía.

Es que de eso se trata, si como desarrolladores percibimos que la especificación no esta clara o tiene implicancias no previstas, no debemos callarnos, debemos avisar antes de que sea tarde, y por lo mismo reconocer que esa comunicación e interacción de ida y vuelta se va a dar, y no esperar que todo se haga siguiendo ciegamente la especificación.

¿Y tu? ¿Alertas de los riesgos de una especificación a tiempo?

Hay lecciones que uno las recuerda como si hubieran sido ayer, y esta si bien ocurrió hace como 18 años, la tengo siempre en mente cuando surge algo nuevo, pero… empecemos desde el principio.

Era una clase de Lenguajes de Programación 1, la dicto el profesor Alejandro Muñoz (un Ing. Civil con bastante pasión por los temas de informática) y el tema que tocaba era C++, para ese entonces ya habíamos aprendido Pascal (algunos laboratorios habían sido bien largos), Fundamentos de Programación y algunas cosas muy interesantes en Algoritmos y Estructura de Datos, pues bien, la primera sesión no se trato de explicarnos que incorporaba C++ sobre su antecesor C (el cual habíamos visto en la primera parte del curso), sino para plantearnos como surge la Programación Orientada a Objetos, como una respuesta a la Creciente Complejidad del Software, el cómo los programas tenían cada vez mas y mas líneas de código, por lo cual la Programación Estructurada ya había tocado su techo, siendo la OOP la respuesta al ser una nueva forma de ordenar los proyectos, así como para enfocar el código hacia entidades mas cercanas al mundo real.

Y claro, aun faltaban pocos años para que el boom de Internet nos cogiera por sorpresa, pero ahí nos quedamos con esa idea, la OOP como respuesta a todo, pero por otro lado vemos la aparición de Visual Basic y su enfoque RAD, en el cual (¡oh herejía) la OOP brillaba por su ausencia, pero aun asi permitió el desarrollo rápido de soluciones que si las hacias en C++ hubiera sido recontra complejo, claro que luego a alguien se le ocurrió una buena idea: mezclar el RAD de Visual Basic con el orden de la OOP y surgió Delphi, y asi hemos visto una sucesión de nuevas respuestas (nuevos retos, recuerden), como comente hace un tiempo , pero quien lo expone mejor es Esteban:
La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo…..
…..pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.
No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

Efectivamente, esos han sido los vaivenes y trends por los que hemos pasado los desarrolladores en los últimos 15 años, es que efectivamente una vez que nos terminaron de convencer acerca de la OOP, eso no fue suficiente, tocaba programar basado “en componentes” y de ahí todo lo que cuenta Estaban en su post.

Y si, si bien esa historia puede ser descorazonadora para quienes producimos software debemos recordar algo:
• Siempre se nos pedirá mas y mas funcionalidades, y mas funcionalidades significan mas líneas de código, osea mayor complejidad.
• El entorno donde correrá tu aplicación cambiara, no tiene sentido pensar en tu web como la antigua aplicación de facturas hecha en Fox, porque ahí entran diversos factores que por mas que la funcionalidad sea “similar” a lo que ya había, cambian totalmente la forma en que la tendrás que desplegar y por ende estructurar el proyecto, baste mencionar el tema de seguridad y todas las consideraciones de zona militarizada que eso conlleva.
• Es impredecible saber con que interactuaran nuestras aplicaciones en el futuro, pero está claro que aun a la clásica aplicación de facturación se le puede pedir integración con Google Maps para que te ayude a ubicar la dirección del cliente.
• No puedes estar seguro de cuánto tiempo vivirá tu aplicación, pero alguien tendrá que mantenerla, por lo que hay que tener consideración con el que le toque hacerlo.

Llegados a este punto debemos reconocer algo, muchas de estas modas, surgieron para afrontar los retos que iban surgiendo progresivamente ante problemas que antes no había, o que terminaron volviéndose mas repetitivos terminandose al final conceptos ya asumidos "por defecto": OOP, Web, BD relacionales, SOA, etc; ahora bien, eso no quita que hubo muchas soluciones para necesidades inventadas, por lo que pasaron sin pena ni gloria (¿alguien recuerda los “behaviours” en IExplorer 5?).

Ahora bien, el problema que debemos afrontar es saber cuándo seguir o no una tendencia (ya me paso a mí con LINQ 2 SQL, pero pese a ello era claro que los ORM habían venido para quedarse) y sobre todo si esta aporta real valor a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions Driven Development. Es que es así, implementamos por inercia cierta arquitectura (de moda) sin tener en cuenta cual es el escenario real para la cual esta tiene sentido, o porque esperamos que cierta condición se cumplirá en el futuro y para ello “hay que estar preparados”, y como bien se apunta en el articulo esas condiciones nunca terminan de cumplirse pero en el camino ya hemos agregado complejidad innecesaria a nuestro proyecto.

No es sencillo, la verdad, pero como dije al final algunas cosas vinieron para quedarse: OOP, aplicaciones distribuidas, nuevas interfaces de usuario mas ricas, interconectividad, y ante ello no queda sino tener la suficiente cabeza fría de saber si la novedad que estamos queriendo implementar en nuestro proyecto agrega valor o no al producto a ser entregado, si los retrasos y complejidad añadidos son superados por las ventajas futuras (a veces puede que no ), la cosa es no temer a la respuesta de un análisis hecho a conciencia.

Por ejemplo, estoy convencido que ciertas capas de las aplicaciones pueden beneficiarse muchísimo del uso de pruebas unitarias, componentes algorítmicos puros, formulas matemáticas, financieras, su determinismo es tan alto que una prueba unitaria de veras se luciría para probar el código, pero de ahí a querer una cobertura del 100% o plantearse el TDD como panacea para mejorar la calidad de los programas... me lo tomo con pinzas, a riesgo de que me llaman hereje indicando que he “missed the point”.

Ojo, nótese que prudencia no es pasividad ni conformismo, pues de lo contrario estaríamos como las empresas que siguen usando mainframes.

Si, es complicado, pero es mejor tener las cosas claras y no renunciar al análisis para saber separar la paja del trigo.

La verdad es que no habia pensado en el tema, a pesar de tener una posición clara sobre ello, hasta que hoy en la mañana vi unos twitts que remitian a este twitt: "¿Debería ser el jefe de proyecto tu mentor? ¿Q figura es la q debería acompañarte en tu desarrollo profesional?", lo cual me llevo a pensar en dos experiencias personales respecto a la figura del mentor...

Hace unos años di un cambio profesional, y con ello fue introducido a la figura de Career Manager, un profesional de rango mas avanzado en la organización, el cual debería ayudarte a identificar tus puntos de mejora para seguir avanzando, realizar la evaluación de desempeño (preguntándole a tus jefes, pues ojo a esto, el CM, salvo excepciones, no puede estar en el mismo proyecto que el supervisado), a la vez que proveerte de información de como se esta moviendo la organización, ademas de ser una figura informal de "abogado" en las relaciones con tus superiores.

Lógicamente que todo esto forma parte de un proceso mas o menos burocrático dentro de las organizaciones, pero que en el fondo tiene mucho sentido, pues gracias a mi primer CM pude aprender diversos detalles de la cultura de la organización, y conseguir apoyo para los planes de formación y sobre todo algo que siempre recordare, el como intercedió por mi cuando un responsable de proyecto quiso hacer una jugada con la imputación de horas.

Durante ese tiempo, también tuve ocasión de trabajar con colegas en las que su mentor era precisamente el Jefe de Proyecto, lo cual me intrigo haciéndome conversar informalmente con ellos a fin de saber que opinaban de la figura, sacando la conclusión de que si bien en este modelo el mentor, al ser tu jefe, tiene la información de "primera mano" sobre tu desempeño, no permite generar la suficiente confianza como para que haya una relación fluida en la que el mentorado pueda confiar totalmente sobre los problemas directos de la marcha del proyecto.

Tuve ocasión de comprobar eso directamente, pues al final se me designo sucesivamente como CM de dos programadores junior, así que ante el reto trate de ganarme la confianza de mi mentorado, explicándole lo que había visto en la organización, el enfoque de hacer las cosas y lo que se esperaba de nosotros, calculo que debí darle suficiente confianza, pues un día me llama prácticamente desesperado ¿qué había pasado? un analista se retiraba a otro modulo de su proyecto, dejandole a él parte de sus responsabilidades técnicas, lo cual le asustaba pues eran temas que solo había visto ligeramente, y claro, le asustaba decirle eso a su jefe de proyecto, por lo que luego de tranquilizarlo procedí llamar tanto al responsable de los CM como a su jefe para saber lo que había pasado, la cosa era sencilla, eran necesidades de negocio, estaban alerta de que era un reto, así que no habría tanta presión en un primer momento mientras se adecuara; así que con esa información me toco transmitirle un mensaje tranquilizador, lo cual funciono pues unos meses despues, cuando me toco proceder a la evaluación, me confeso que no era tan fiero el león como se lo pintaba.

Así que por esta experiencia directa, creo que un mentor o CM no debería (salvo coyunturas) ser directamente el jefe del mentorado, siempre queda un conjunto de cosas en la cual se necesita cierta confianza que tal vez no se pueda tener dentro del propio proyecto. Dicho esto, soy consciente de que cuando se avanza en la pirámide no hay tanto margen para asignar responsables que no sean los jefes directos, pero es algo que se debería procurar en la medida de lo posible.