sábado, 23 de diciembre de 2017

Acerca del uso de las metodologías de desarrollo en la empresa

Hace unos días un lector del blog me hizo la siguiente pregunta:

Me he estado preguntando que metodologias del desarrollo de software utilizas? Sería interesante conocer ese tipo de detalles para los ingenieros que apenas estamos comenzando nuestra etapa profesional
Me he estado preguntando que metodologías del desarrollo de software utilizas? Sería interesante conocer ese tipo de detalles para los ingenieros que apenas estamos comenzando nuestra etapa profesional

La verdad es que de manera inadvertida, la respuesta a esa pregunta creció mucho y decidí convertirlo a una entrada del blog sobre el uso de metodologías en el empresa, para ofrecer un opinión desde un punto de vista personal a la vez que profesional. En los siguientes párrafos esta mi respuesta.

Es una pregunta muy interesante la que planteas. Aquí hay un tema importante; no siempre vas a poder usar la metodología que quieras o incluso la adecuada para el tipo de problema planteado, porque a veces viene establecida por la empresa encargada del desarrollo directamente.

Cuando comencé a trabajar formalmente dentro de equipos de desarrollo de software, teníamos que usar metodologías tradicionales y pesadas, en las que pasábamos por cada fase en estricta secuencia y había que documentar cada paso (c-a-d-a p-a-s-o). Las metodologías agiles estaban todavía muy verdes (en implantación) y no ofrecían confiabilidad con respecto a la forma de desarrollar software que llevaban vigente durante décadas.

En lo personal a mi no me gustaba mucho esa forma de trabajo, era algo bastante frustrante, que enaltecía el análisis y el diseño frente a la codificación, a la que prácticamente nulificaba en cuanto a importancia.

He de decir que no creo que ningún problema pueda ser comprendido en su totalidad hasta que no está resuelto y eso quedaba patente en el desarrollo de software, cuando muchos elementos deben volver al análisis (una y otra vez), porque su conclusión es insatisfactoria. Aquí comienzan los problemas, porque siempre hay una fecha de entrega, y muchas veces no definida por el tamaño y complejidad del sistema, sino por cuestiones de mercado y contractuales. En este punto lo más frecuente es que se empiecen a saltar partes del proceso para llegar cuanto antes a la finalizaciones. Pero saltarse partes de la metodología de desarrollo, sea la que fuera, solo lleva el desastre.

Recuerdo como anécdota ir a una serie de conferencias de PMI (Project Management Institute ) y pensar "Esta gente debe ser genial construyendo edificios, pero no han hecho un software en la vida". Mi comentario no es del todo objetivo y justo, incluso se pudiera decir "erróneo", pero realmente es lo que sentí en ese preciso momento.

Afortunadamente ya mediados de los 2000, se comenzaron a aceptar de forma empresarial a las metodologías agiles (aunque existan desde muchos antes).

Ahora intento usar Programación Extrema (XP) y Scrum.

  • XP nos da una pauta para poder desarrollar (programar) software con calidad y rapidez, valorando las capacidad del software frente al cambio (si un software puede cambiar fácilmente, es que está bien construido), que el seguir un plan cerrado sobre el producto.
  • Scrum abarca otras partes del proceso de manera más global, ya considerando iteraciones con diversos elementos del equipo de una forma adecuada.
En lo que posible, fomento la comunicación verbal, y disminuyo a lo mínimo necesario la documentación y la comunicación por escrito, sobre todo cuando no aportan ningún al sistema.

Aquí es importante la situación real por la que pase el equipo de trabajo. Comentaba en otro post, que cuando mas maduro y capaz de comunicarse sea el equipo (de desarrollo) más éxito tendrá una metodología ágil, mientras que si el equipo es "novato", o tiene fricciones es mejor una metodología mas pesada y documental.

No hay que confundir la falta de documentación, con el desorden y el caos. Scrum propone mecanismos muy claros sobre cómo tiene que ser la comunicación en el equipo, el seguimiento y la asignación de tareas.

Comentar que igual que he tenido éxitos, también he tenido fracasos por aplicar determinadas metodologías en momento y con equipos inadecuados (para dichas metodologías). Hay que considerar que el éxito no es que un software llegue a estar productivo (cosa que siempre suele llega a pasar, porque es raro que se deje una necesidad de negocio sin suplir), sino que se haya desarrollado en el tiempo y la calidad requerida, además de al le equipo haya quedado satisfecho con el resultado y no exhausto después de hare maratónicas sesiones de codificación.

En cualquier caso es posible que otras áreas que no tengan que ver con el desarrollo de sistemas tengan procesos más pesados y documentales, generalmente es porque su proyectos son (en cuanto tiempo) de más corto alcance, con lo que no tiene la necesidad de "agilidad" propia de un desarrollo software. En este caso puede haber "rozamiento" entre áreas, por las diferentes metodologías. En este punto hay que llegar a la forma correcta de comunicación entre una área y otra, afectando lo mismo posible la metodología de desarrollo "de puertas para adentro".

Algunos artículos relativos a este tema son:

sábado, 16 de diciembre de 2017

Regla N°14 de la Ingeniería de Software: Evita la ceguera voluntaria


La ceguera voluntaria es ignorar de forma deliberada situaciones que si bien son perjudiciales, no suponen un daño inmediato, con lo que no se hace nada para corregirlas, convirtiéndose en una posible situación catastrófica a futuro.


Ejemplo de ceguera voluntaria en la serie Silicon Valley, Capítulo 03x05.

Aunque pudiera parecer absurdo intentar ignorar o omitir posibles problemas dentro del desarrollo de software (o realmente en cualquier tipo de proyecto) es algo bastante común.

Cuando aparecen problemas en mitad de un desarrollo y no son atacados y mitigados cuando son pequeños, aumentaran de forma progresiva hasta ser de tal tamaño que afecte al tiempo, calidad o costo del proyecto.

Lo elementos que más se suelen ignorar son:

  • Retrasos en el desarrollo del software: El producto saldrá claramente después de la fecha estimada, sin embargo ninguna alerta es disparada, haciendo creer al cliente que tendrá su sistema cuando se le indico. Aparentemente nadie quiere decir la palabra "retraso" en voz alta, aunque es algo claramente palpable.

  • Problemas tecnológicos: El equipo no tiene la capacidad técnica suficiente para llevar a buen término el sistema, ya sea por una sobreestimación de sus posibilidades, o porque directamente se construyo un equipo sin la preparación necesaria.

  • Problemas de recursos: No hay algún factor tal como dinero, tecnología necesaria (teléfonos, tablet o computadores) o gente disponible.

  • Problemas de integración de equipos: Aquí simplemente el equipo (de personas), no puede trabajar juntos, ya sea porque no tiene una buena relación o porque tienen una idea del trabajo tan individualizada que no son capaces de entender el concepto de trabajo en equipo.


Hay que entender que la ceguera temporal es algo que se da en todos los niveles, el programador puede omitir datos críticos, pero un buen líder de proyecto debe detectar omisiones y faltas al plan de desarrollo y buscar la forma de mitigarlos y sobretodo que emerjan a la luz, y estén claros, es decir asegurarse que hayan sido comprendidos (al nivel jerárquico que corresponda). Un líder de proyecto que ignora lo que ocurre en su equipo y en la construcción de un sistema, es un mal líder de proyecto y posiblemente un irresponsable que echarla la culpa del fracaso de "su" sistema a otras personas.