Hace unos días un lector del blog me hizo la siguiente pregunta:
|
| 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:
