Archivo para abril 2009

Metodologías Ágiles (parte 1)   5 comments

Mucha gente tiene la duda de qué es “Agile”, de principio es confuso porque no se parece a lo que nos enseñan en las universidades, no tiene pasos específicos, tampoco cronográmas ni procesos a la vista como los tienen las metodologías tradicionales p.e. la Cascada o el Proceso Unificado.

waterfall_modelrup_model

¿Cuál es el problema de éstos modelos?

En los modelos lineales es necesario tener los requerimientos bien especificados desde el comiendo, el análisis, diseño deben estar completos en las primeras fases y no hay manera de pasar a la implementación ántes de éstos; el testeo se hace al final (gran error) lo cuál trae problemas de integración, males que podrían ser evitados desde el principio se encuentran (a veces no) faltando poco antes del lanzamiento del producto, en éste punto la adaptabilidad del producto a cambios y nuevos requerimientos es practicamente nula, lo unico que puede hacer el desarrollador es asegurar su trabajo mediante la firma de un papel sellando los requerimientos, al final sólo asegura el pago por el trabajo, no asegura la satifacción del cliente y la calidad del producto.

En un modelo del tipo RUP, iterativo – incremental y demás, las fases siguen estando bien definidas, en cada fase se realiza un poco del trabajo, análisis, diseño, implementación, prueba y despliegue, dandole más énfasis a cada parte o conjunto de partes a medida que transcurre el ciclo; todo ésto está muy bien pero lamentablemente la metodología se vuelve un monstruo porque exige demasiada carga en la documentación, todo el detalle exigido es una perdida de tiempo, se produce monton de material muchas veces inservible gastando tiempo y recursos valiosos (diagramas hasta para ir al baño), otro punto es la especialización de los profesionales, para cada fase un determinado tipo de profesional dando puntos cruciales de la información a algunos y con el riesgo de pararse el proyecto si ellos se ausentan por algún motivo; la separación de ramas y jerarquía entre el equipo (enorme equipo) hace que muchas veces exístan diferencias e imposiciones de ideas.

Agile

Agile no son pasos, gráficas elaboradas, o un plan maestro; Agile son consejos, buenas prácticas que muchos entendidos en software han puesto a nuestra disposición para usarlas, en otras palabras comparten su experiencia en una manera ordenada y sencilla de aplicar.

Éstos conceptos se pueden ver en el Agile Manifiesto que resume éste pensamiento:

Individuos e interacciones sobre procesos y herramientas

Software que funciona sobre documentación exhaustiva

Colaboración con el cliente sobre negociación de contratos

Responder ante el cambio sobre seguimiento de un plan

La gente nos importa, las personas son el recurso más valioso que se tiene, ellos son los que desarrollan el software no las herramientas ni los procesos, un programador feliz rinde mejor que uno con estrés, un cliente contento es mejor que uno disconforme.

No nos interesa crear 100.000 diagramas en herramientas super cargadas si sólo queremos tener una idea clara, nos basta un lápiz, una hoja de papel, o una pizarra y una camara fotográfica o celular para preservarla. Además ¡queremos Software ya! necesitamos que el cliente esté seguro que lo que pide es lo que necesita, para ello un demo rápido del producto nos da un feedback excelente; un demo cada cierto tiempo corto permite muchas cosas:

  • Adaptabilidad a los cambios de requerimientos.  Los diagramas de Gantt y Pert son OBSOLETOS, si alguien realiza un modelo predictivo por pasos NO ES AGILE, dar muerte a MS Project. No se puede predecir cómo serán los cambios de requerimientos en medio del proyecto, menos al final.
  • Predictibilidad a corto plazo, el cliente nos guiará, el mercado nos guiará y en un plazo cercano, dias, las funcionalidades tomarán forma.
  • Calidad, el testeo debe ir a la par del desarrollo, los bugs se encontrarán, reparán y documentarán a medida que el software tome forma, exísten muchas técnicas ágiles para ello, una es TDD (Test Driven Development).
  • Compartición y reutilización de código. Nuestra filosofía siempre ha de ser COMPARTIR, preservar conocimiento y reutilizarlo, ahorrar tiempo y esfuerzo, evitar trabajo excesivo y distribuir la carga mental entre todo el equipo y más (todos los participantes informáticos o no).

Metodologías Ágiles

Hay varias implementaciones de metodologías ágiles:

Cada cuál sigue sus propias tendencias pero siempre respetando los principios descritos anteriormente; algunas son muy simples, otras refuerzan documentación y procesos pero la mayoría puede adaptarse al ritmo del proyecto que se vaya a ejecutar.

scrumlargelabelled

400px-es_three_layers

Agile Software Buildings   Leave a comment

I’ve posted a little paper about the Agile Architect and the Software Buildings development, is an essay which gives an idea about real development and the rol of the people on the process, please read it and post your comments.

http://docs.google.com/Doc?docid=df728hnw_57zggk4hcf&hl=en

Contributions are always welcome 🙂

Publicado abril 14, 2009 por Sergio D. Rodríguez Inclan en General

De vuelta… otra vez…   2 comments

Sí he conseguido hacerme de internet por segunda vez en el año ya que es mi segunda mudanza, sólo que esta vez vivo bastante lejos y tenía poco tiempo para ir a contratar al ISP y demás; como sea acá de nuevo aunque con muy poco tiempo para escribir.

Una cosa que DEBO hacer es pedir disculpas a muchas personas a las que les comprometí mi tiempo y alguna tarea, lo siento muchísimo debí ausentarme por muchas razones: salud, trabajo, cambio de domicilio, falta de tiempo y más; espero que no se molesten mucho conmigo, sigo tratando de estabilizarme y ordenar mis ocupaciones para hacer tanto mi trabajo y mis tareas como voluntario del Software Libre (que es lo que me gusta más :D)

Bueno, espero poder seguir escribiendo seguido y comunicarme con todos, por lo menos de vez en cuando. 🙂

Publicado abril 1, 2009 por Sergio D. Rodríguez Inclan en General