Con base a lecturas en Wikipedia y analizando procesos de desarrollo de algunas empresas encontré que típicamente el proceso de desarrollo de software tradicional y de Web no varían, es decir, generalmente pasan por requerimientos, diseño, implementación, pruebas e implantación. En particular, coincido con G. Engels, M. Lohmann & A. Wagner (2003), quienes señalan que los programadores de aplicaciones web se enfrentan con más frecuencia a nuevos requerimientos (o cambios en estos) que los desarrolladores de sistemas de software tradicional. Por lo tanto el proceso de desarrollo de software tradicional tiene que ser adaptado cuando se desarrolla una aplicación para web de acuerdo a las siguientes aspectos.

• La duración del proyecto en ciclos de desarrollo son cortos, es decir, de tres a seis meses promedio comparado con las aplicaciones tradicionales que son de 12 a 18 meses.
• Los requerimientos para aplicaciones web cambian o emergen durante el desarrollo del proyecto.
• Las liberaciones a plazos fijos conduce a una metodología de desarrollo basada en prototipos.
• Se presta para el desarrollo paralelo en diferentes versiones, es decir, que muchas actividades en el diseño, implementación y pruebas pueden trabajarse en paralelo para diferentes versiones.
• La reutilización e integración es necesaria porque la presión por el tiempo conduce a que se desarrollen componentes reutilizables y que se puedan integrar en otros proyectos.
• Los niveles de complejidad en el desarrollo web es de menor en las primeras etapas, y conforme se van integrando mas perspectivas la complejidad aumenta.

De acuerdo a lo anterior, considero que no se recomienda que los especialistas del proceso de desarrollo de software desarrollen una aplicación web porque esta demanda grupos multidisciplinarios, mucha comunicación y coordinación, además de que los grupos son más pequeños y con semejante expertis.

Fuentes consultadas:

G. Engels, M. Lohmann & A. Wagner.(2006). Web Engineering: The Discipline of Systematic Development of Web Applications. (pp 197-218). John Wiley & Sons.

Wikipedia. (2010). Wikipedia, the free encyclopedia. From http://en.wikipedia.org/wiki/Software_development_process, http://en.wikipedia.org/wiki/Agile_web_development y http://en.wikipedia.org/wiki/Software_development_methodology

Outsource2india. (2010). Application Development Process. From http://www.outsource2india.com/software/process.asp

B. Alexander. (2010). Macronimous. Site Development Process. From http://www.macronimous.com/resources/web_development_life_cycle.asp

Compartir/guardar

El objetivo de Scrum es evitar las fallas comunes que se tienen en el típico proceso de desarrollo, tales como:

• Caos debido a los cambios en los requerimientos. Los requerimientos de un proyecto normalmente pueden cambiar drásticamente desde que el producto se ha diseñado para cuando se lance. En la mayoría de métodos de desarrollo de productos, todo el diseño se realiza al comienzo del proyecto y, a continuación, no se permiten los cambios al cambiar los requerimientos.

• Estimaciones de tiempo, costo y calidad del producto poco realistas. La gestión de proyectos y los desarrolladores tienden a subestimar cuánto tiempo y recursos tomará el proyecto, y cuánta funcionalidad se pueden producir dentro de esas limitaciones. En realidad, esto normalmente no se puede predecir con precisión al comienzo del ciclo de desarrollo.

• Los desarrolladores se ven obligados a mentir sobre el avance del proyecto. Cuando se subestima el tiempo y el coste necesarios para alcanzar un determinado nivel de calidad, los desarrolladores deben, ya sea mentir acerca de cuánto se ha progresado en el desarrollo del producto, o indignarse.

Cualidades de Scrum

• Este proceso ágil se centra en ofrecer el más alto valor comercial en el menor tiempo.
• Permite inspeccionar el trabajo real del desarrollo (cada mes).
• El Dueño del producto establece las prioridades, y el Equipo se auto-organiza para determinar la mejor manera de entregar los elementos del producto con mayor prioridad.
• Entre las dos semanas y el mes, quien sea puede ver el trabajo real y decidir si entregarlo así como está o continuar incrementándolo en otro Sprint.

Scrum se ha empleado con éxito en cientos de diferentes empresas en diferentes ámbitos, con resultados destacables. Hay muchas similitudes entre Scrum y Extreme Programming (XP), pero uno de las principales diferencias es que Scrum tiene un conjunto de directrices que rigen el proceso de desarrollo de un producto. Por esta razón, es a menudo utilizado como un “envoltorio” para otras metodologías, como como son XP o CMM (Capability Maturity Model), es decir, se utiliza para guiar el proceso general de desarrollo al utilizar estas otras metodologías.

Compartir/guardar

En su presentación señala que los proyectos ahora son cada vez más exitosos pero que aún hay muchas personas están atrapadas en sus problemas y nunca se han detenido a pensar en el costo de esos problemas y sus reacciones a ellos. No son conscientes de que su cuerpo responde a lo que ellas están pensando y que el estrés disminuye su capacidad para tomar buenas decisiones. Sabiendo que todo el mundo tiene problemas proporciona cierto alivio. Quizás es hora de que los administradores de proyectos tomen conciencia de que se gasta mucho tiempo en quejarse de los problemas en lugar de la planificación de acciones.

Para tener el control de un problema, hay que usar el proceso de Rita para resolver problemas (Rita’s Problem-Solving Process):

1. Listar tus problemas
2. Listar lo que anda bien para obtener en mejor estado de ánimo para la solución de problemas.
3. Seleccionar los problemas que vale la pena tratar, no desperdiciar el esfuerzo.
4. Para cada uno de los problemas, volver a la historia desde una nueva perspectiva.
5. Llegar a un punto de vista positivo en la nueva historia.
6. Reducir la historia.
7. Nombrar el problema.
8. Revisar tu capacitación en la administración de proyectos para encontrar la forma de prevenir o tratar el problema.
9. Investigar opciones con otros.
10. Eligir una solución.
11. Ejecutar la solución.
12. Revisar que la solución se lleve a cabo.

Este proceso ayudará a obtener los siguientes resultados:

• Hará que te sientas más en control.
• Despejará tu cerebro para que puedas pensar.
• Reducirá la conexión emocional del problema.
• Te permite ver que tu problema particular es común.
• Te ayudará a encontrar soluciones.

Así que ahora puedes imaginarte la situación que te gustaría. Tal vez ha llegado el momento de ser el jefe de proyecto que quieres ser, más que estar esperando a que alguien más te de la oportunidad.

No esperar a que los problemas ocurran! La siguiente es una lista de los problemas comunes en los proyectos que ayuda a nombrar tus propios problemas y también a prevenirlos.

Problemas comunes en los proyectos

• No involucrar propiamente a todos los interesados
• Planes poco realistas
• Gastar demasiado tiempo en hacer frente a los problemas
• Realizar reuniones donde cada uno va al rededor de la sala a reportar
• Excesiva deformación del alcance
• Sentirse fuera de control
• No estar razonablemente seguro de que puede cumplir con el tiempo y el coste necesarios
• La falta de tiempo cerca del final de un proyecto
• Demasiadas reuniones
• Demasiados cambios
• Gastar demasiado tiempo reportando
• No llevar la administración de riesgos
• Planificación sin el aporte de todo el equipo
• El no gestionar las expectativas de los interesados
• El no ser capaz de tomar tu tiempo de vacaciones
• Equipo no cooperativo (poco equipo)
• Malabarear con las demandas de los interesados
• La falta de seguimiento a través de los miembros del equipo
• Pobre definición de los objetivos del proyecto (mal definidos)
• Coordinación de multiples proyectos
• No conseguir una buena y fiable información

¿Por qué no utilizar el mismo razonamiento para motivarte a planificar tu día? Imagina un gran día – verlo, sentirlo, imaginarlo como si este ha ocurrido. A continuación, disfruta cada vez más de tus días, que en realidad, resultan como tu los imaginas.

Compartir/guardar

• Eliminar código duplicado
• Colocar comentarios en el código
• Quitar los Code Smells (código que tiene indicios a que algo pueda fallar)
  
• Conservar el código ordenado
• Tener cuidado con la Herencia
• Manejar referencias apropiadas
• Separar las bases de datos, interfaces de usuarios, y la lógica del dominio
• Conducir proyectos de software con User Stories
• Diseño orientado a objetos con CRC Cards
• Hacer pruebas de aceptación
• Hacer pruebas unitarias
• Test Driven Development
• Desarrollo en equipo con control de versiones (CVS)
• Comunicación
• Programación en pareja

Para mayor detalle puedes descargar y consultar el libro: Essential Skills for Agile Development

Compartir/guardar

Estos son algunos métodos que están específicamente diseñados alrededor del Desarrollo Ágil:

DSDM es probablemente el original método de Desarrollo Ágil. DSDM ha estado incluso antes de que el término Desarrollo Ágil fuera inventado, pero está basado absolutamente en todos los principios del Desarrollo Ágil.

SCRUM es también un método de Desarrollo Ágil, el cual se concentra particularmente sobre cómo administrar tareas dentro de un ambiente de desarrollo basado en equipo.

XP (eXtreme Programming) es la metodología Ágil más radical, se enfoca en el proceso de desarrollo de software y dirige las fases de análisis, desarrollo y pruebas aspirando en lograr la calidad en el producto final.

DSDM es probablemente la metodología Agil más completa, sin embargo SCRUM y XP son más fácil de implementar y complementarias porque ellas afrontan diferentes aspectos de los proyectos de desarrollo y están fundadas sobre los mismos principios del Desarrollo Ágil.

En la actualidad, no hay una caja mágica para el desarrollo de software. El truco está en conocer varios métodos y seleccionar una mezcla de los mejores enfoques que sean los más apropiados para cualquier situación dada. Para hacer esto exitoso se requiere de mucha experiencia y habilidad.

En proyectos de Desarrollo Ágil, la Administración de Proyectos toma una forma diferente, se basa más en las habilidades de los administradores para la comunicación, facilitación, coordinación, y con menor énfasis en la planeación y control.

El Desarrollo Ágil puede ser un enfoque muy excitante y muy energizante, aunque algunos proyectos se prestan más al Desarrollo Ágil que otros. La colaboración y visibilidad pueden proporcionar mayor riqueza y una experiencia más gratificante a los equipos para desarrollar grandes productos de software. El Desarrollo Ágil puede ser mucho más agradable que el enfoque en Cascada que requiere de mucho más documentación y es menos flexible por naturaleza. Y cuando las personas disfrutan su trabajo, es asombroso lo que se puede lograr!

Introducción del Desarrollo de Software Ágil

Scrum, metodología ágil para el desarrollo de software

Metodologías Ágiles y Extreme Programming

Compartir/guardar