Diferencias entre las metodologías WaterFall y Agil/ Differences between WaterFall and Agile Methodologies.

To see the differences between this two methodologies lets see their features.

Waterfall Methodology

-The documentation is very important , all the document referents to architecture must be done before the coding start

-Waterfall suppose that there will not be change along the development of the final product

- Start up whit the requirements gathering

- Are based on the contract, for that reason the requirements of the client and the documentation is so important

-Its development is document driven

-The integration of different modules occur and the end

-The communication with the bussines people only occur at the beginning of the project

-It’s focused on analysis and design for that reason relies on the architects and designers

- The final product is not only composed by the software itself  but can include  the documentation , the user manual and others.

-Each developer is in charge of one different area of the development

Agile Methodology

-It’s based on iteration, each iteration must release a end to end functionality

- It’s focused on time, at the end of each iteration the application should be production ready

- It’s designed to high degree of change

- Its  flexible process allow introduce change in a reliable way along the development

- Architecture and documentation are incremental during the project

-The development is based on the completion of functionalities in short iterations

-Required knowledgeable developers in all the technologies used

-Relies  on developers

- Make use of engineering practice like TDD , refactoring and others

-The integration is continuous

-The bussines people are part of the project , they provide continuous feddback for developers and management

How you can see Waterfall could be a alternative for projects where documentation are very important , there will not be changes on the requirements and software must comply with certain regulations. On the other hand  Agile is more suitable for projects where the time is crucial , could exist several changes and documentation is not part of the final product. Agile is not a closed process, it is more like a philosophy which foundations are the Agile Manifesto.

Para ver las diferencias entre estas dos metodologías veamos sus características.

Metodología Waterfall

-La documentación es muy importante, todos los documentos referentes a la arquitectura  deben hacerse antes de comenzar el desarrollo

- Waterfall supone que no habrá cambios a lo largo del desarrollo del producto final

-Empieza con la recopilación de los requisitos

- Se basan en el contrato, por eso los requisitos del cliente y la documentación es tan importante

-Su desarrollo está dirigido por la documentación

-La integración de los diferentes módulos se producen al final

-La comunicación con las personas que conocen la lógica del negocio sólo se producen al inicio del proyecto

-Esta centrado en el análisis y el diseño para ello se apoya en los arquitectos y diseñadores

- El producto final no está compuesto únicamente por el propio software, sino que puede incluir la documentación, el manual de usuario y otros.

-Cada desarrollador está a cargo de un área diferente del desarrollo
Metodología Ágil

-Esta basado en la iteración, cada iteración debe liberar una nueva funcionalidad completa

- Se centra en el tiempo, al final de cada iteración la funcionalidad desarrollada debe estar lista para ponerse en produccion

- Está diseñada para soportar altos grados de cambios

- Su proceso flexibles permiten establecer cambios de forma fiable a lo largo del desarrollo

- La Arquitectura y la documentación son incrementales durante el desarrollo del proyecto

-El desarrollo se basa en la realización de funcionalidades en iteraciones cortas
- Se requerido desarrolladores con altos conocimientos en todas las tecnologías utilizadas
-Se soporta en los desarrolladores

- Hacer uso de prácticas de ingeniería como TDD,  refactorización y otros

-La integración es continua

-El los conocedores de la lógica del negocio (gerentes, directivos, etc) son parte del proyecto y proporcionan feddback continuo hacia los desarrolladores.
¿Cómo se puede ver la WaterFall puede ser una alternativa para proyectos en los que la documentación es muy importantes, donde no  habrá cambios de los requisitos y el software debe cumplir con ciertas normas. Por otra parte Agile es más adecuado para proyectos en los que el tiempo es crucial, podrían existir varios cambios y la documentación no es parte del producto final. Agile no es un proceso cerrado, es más  una filosofía fundamentada en el Manifiesto Ágil.

TRELLO en mi trabajo, como emplearlo para mejorar mi proyecto.

Hace un tiempo ya, y realmente, el día que salió, yo ya tenía una cuenta de Trello. Era simple, era bonito, era rápido, pero no veía el gran poder que tenía. Es porque, como muchas cosas, hay que saber utilizarlas.

Hoy es para mi una herramienta fundamental en mi organización (personal y laboral) y me ha vuelto más productivo y ha evitado muchos de esos momentos de “¿y ahora qué?” o “¿en qué estaba?“. Voy a compartirles el como para que sepan cómo lo hago yo, y espero comentarios de cómo lo hacen ustedes. 

Trello por default

Trello se compone de boards (pizarras) que a su vez se componen lists (listas), que a su vez contienencards (tarjetas).

Cuando crean un board por primera vez, verán esto como su contenido.

(Puede que se vea distinto si su resolución de pantalla es menor, en ese caso pasará al modo mobile.)

El flujo ya es bastante apropiado en la forma en la que se presenta, y es ideal para grandes grupos de gente (ah, es multiusuario). Básicamente, las cosas se van dando de alta en la lista To Do, al momento en que comienzan a trabajarse, se mueven a Doing, y al momento de terminarlas se pasan a Done.

Preguntas respondidas

La simple disposición de tareas de esta forma ayuda a responder muchas preguntas.

Cuando las cosas están en To Do es porque es importante ver cuáles son todas las cosas pendientes. Responde preguntas como “terminaremos para hoy/mañana?” o “cuando termines con esto estás libre?“.

La lista de Doing ayuda a ver qué progreso se está haciendo. Responde preguntas como “En qué está trabajando José?” o “Qué estaba haciendo yo?” (especialmente útil para los que lidian mucho con interrupciones).

La lista de Done ayuda a ver qué se terminó. ¿Qué sentido tiene esa lista? Ayuda a responder preguntas como “¿Qué porcentaje de tareas terminamos?“, “¿Avanzamos mucho?“, “¿Qué está presente en esta versión?“.

Mi variante: el día a día

Mis cambios a ese esquema por default no han sido radicalmente distintos, pero lo suficiente como para mencionar. Este es el caso de mi trabajo, tengo distintos esquemas para distintos tipos de proyectos personales (y creo que esa es una de las cosas que hace a esta herramienta tán versátil). Estas son mis listas y para qué se usan:

To Do: Igual que siempre este es el listado de todo lo que se tiene que hacer, o que algún día tiene que ser resuelto. Puede ser mañana, puede ser la semana entrante, puede ser “algún día” indefinido.

Get Done Today: Al principio del día, luego de checkear mis correos y verificar qué cosas tengo pendientes que no sabía antes, elijo desde To Do un listado de ítems que obligatoriamente tengo que terminar el día de hoy. Puede basarse en prioridad, en tiempo disponible, en urgencias, en la dirección del viento. La forma de elegirlas no importa, lo que importa es que esas tareas son mi compromiso del día. Me sirve también para reportar en nuestra scrum meeting qué es lo que voy a estar haciendo.

Doing right now: Como su nombre lo dice, el listado de cosas que estoy haciendo ahora mismo. Si no tengo nada acá, probablemente esté almorzando. Si tengo más de tres tarjetas aquí, seguramente algo saldrá mal. Cuando me llaman por teléfono, me buscan en la oficina o me interrumpe un email, este es el lugar al que vuelvo a mirar y resumo mis tareas.

Waiting for feedback: Este es el listado de cosas que comencé pero estoy bloqueado y requiero que alguien más intervenga. Es porque la tarea depende de alguien más o porque estoy esperando respuesta de alguien para poder continuar. Siempre les agrego un comentario a esas tarjetas para poder leer cuál fue la última vez que la actualicé y para saber qué estoy esperando que me respondan o hagan. Puede que una vez que me respondan las tarjetas se muevan de aquí a To Do, o, si tengo suerte, a Done.

Done: Nuevamente, aquí es donde vienen a morir las cosas que ya hice. Mantengo este listado hasta el fin del día, en donde lleno mis timesheets (mi empresa requiere que llene un listado de qué actividades realicé cada día). Las tarjetas me ayudan a recordar, y el tener que limpiar esa lista me hace recordar llenar el timesheet.

Este es un ejemplo con mi día de hoy (exitosamente cerrando la semana):

Probablemente lean mis ítems y no entiendan en qué estoy trabajando, porque los títulos no son muy explicativos. Ese es otro beneficio: no tienen que serlo. Sólo tienen que decir lo suficiente como para que yo recuerde de qué se trataba todo. Si necesito más detalles uso los comentarios o las descripciones de las tarjetas (que, dicho sea de paso, soporta Markdown). Si necesito varios puntos intermedios agrego una checklist (como el primer item en la imagen), y es todo a gusto.

Espero que esto haya sido útil para quién lo lea. Si tienen sugerencias, estoy encantado de oírlas, sería muy útil para mi también aprender de alguien que sepa organizarse mejor.