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

• Bosquejar el proyecto antes de iniciar. Este punto es muy importante, ya que nos permite tener una idea más clara del proyecto. Por ejemplo, un diseñador puede crear el modelo en hoja y papel incluso antes de tocar el equipo; a un desarrollador le permite planear el código con diagramas de flujos o esquemas.

• Estar a tope de la información. Muchas veces nos pasa que no podemos recordar algo, el mezclar varias tecnologías ocasiona que no recordemos las sintaxis o las confundamos. Este punto recomienda que utilicemos hojas de referencia. Lo importante es que cada quien tenga las hojas de referencia de las tecnologías de acuerdo como uno las requiera y ademas utilizarlas. Otra forma de estar a tope de la información es mantener a la mano la información que el cliente proporciona ya sea en papel o en alguna herramienta de gestión de proyectos.

• No empezar desde cero. Este punto recomienda el uso de plantillas o frameworks de desarrollo, ya sean creados por nosotros o por otras personas, creo que es una mejor manera de iniciar a partir de una base en lugar de invertir tiempo en hacer lo mismo para cada proyecto.

• Conocer bien las herramientas. La comunidad web es tan asombrosa que prácticamente para cada necesidad hay una aplicación. La parte difícil es que hay mucho para elegir, y cada vez hay nuevas versiones y nuevas herramientas. Es importante estar al tanto de las herramientas, sin tener que gastar tanto tiempo eso. Una estrategia es dedicar algún tiempo cada semana para vigilar por las nuevas herramientas y tecnologías. Otra es navegar en internet y cuando se vea algo que vale la pena añadir a nuestra colección de favoritos.

• No olvidarse de tomar descansos. Es importante tener en cuenta los descansos calculados; cuando uno comienza a sentir esa sensación de aburrimiento, el cuerpo nos está diciendo que es hora de tomar un descanso. Levantarse, estirarse, tomar aire fresco y luego volver hace que uno se sienta mucho mejor y se puede trabajar mucho más rápido. Un vaso de agua helada es tan asombroso para potencializar nuestra mente. Si estas trabajando eficientemente, entonces no te detengas, pero si ya perdiste el enfoque, no tienes nada que perder y si mucho que ganar. Es importante ser persistente pero no estar tan sujeto a no tomar un descanso cuando lo necesites.

Redondeando, la productividad no es sólo conseguir que se haga algo rápidamente, es utilizar el tiempo de manera eficiente para producir un trabajo de calidad sin prisa. Una de las cosas más trágicas es que cuando un diseñador con talento (o desarrollador) tiene que comprometer la calidad de su trabajo y no hacerlo lo mejor posible a causa de un plazo. Mediante la adopción de estos cinco hábitos, se puede hacer más cosas en menos tiempo, y disfrutar más tiempo para uno mismo.

A continuación una lista de ligas recomendadas:

• Cheat Sheet Round-Up: Ajax, CSS, LaTeX, Ruby…
• столове30 Handy Cheat Sheets and Reference Guides for Web Professionals
• Cheat Sheets for Web Designers
• 15 Sites Web Developers and Designers Should Know
• 35 Online Tools That Make Your Freelance Career Easier
• The Online Toolbox: 100+ In-Depth Resource Collections
• Massive Compilation of Designer Tools

Ligas relacionadas:

1. Web developer’s library: What you should have
2. Predefined Variables in PHP: For complete beginners
3. 30 jQuery Tutorials for Complete Beginners
4. 10 Ways to Find Motivation to Blog
5. Conducting Collaborative Design Sessions – Part 1: Prepare

Compartir/guardar

• Navegación fácil y ligera

Los enlaces de navegación juegan un papel muy importante lo cual determina el tiempo en que un visitante permanece y explora el sitio.

• Diseño del sitio limpio

Un diseño limpio con suficiente espacio en blanco mejora la apariencia del sitio. Tratar de mantener la atención en su contenido, utilizar una plantilla para ello. Utilizar fuentes que estarán disponibles en cualquier equipo para evitar un mal estado del sitio.

• Optimización de tiempos de carga
  

Asegurar que el tiempo de carga de las paginas sea bajo. Para esto es recomendable hacer

• Minimizar gráficos, scripts y peliculas (flash).
• коли под наемOptimizar el contenido HTML y codigo script.
• utilizar archivos Server Side Include (SSI) tando donde sea posible.

• Diseñar para todo tipo de resoluciones de pantallas
  

Un sitio que es fácil de utilizar siempre alienta a los visitantes a permanecer y leer su contenido. Para sitio con mucho contenido es muy importante que el desplazamiento requerido sea reducido.  El diseño de una página que se ajuste a cualquier tipo de resolución asegura de que todos los visitantes aprecien un sitio profesional y atractivo.

• Asegurar la escalabilidad del sitio web
  

Asegurar que el código y diseño sea escalable dado el avance constante de la tecnología en plataformas.

• Compatibilidad con los browsers
  

Revisar que el sitio se pueda navegar desde Internet Explorer 5+, Firefox 1.0, Opera 7.0 y Netscape Navigator 6+ ya que ellos conforman el 95% del total de browsers del mundo.

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

Compartir/guardar

• Tiempo del proyecto
  • Considerar siempre el calentario y los milestones.
• Costo del proyecto
  • Considerar siempre el esfuerzo de trabajo, el presupuesto real, y el espacio.
• Alcance del proyecto
  • Considerar siempre las metas, los requerimientos y los entregables.
• Requerimientos
  • Nunca hacer cambios en los requerimientos sin ajustar el tiempo, costo y alcance.
• Riesgos
  • Identificar riesgos y realizar planes de respaldo.
• Etapa de diseño
  • Nunca saltar la etapa de diseño, esta ahorrará tiempo en el futuro.
• Codificación
  • Realizar una buena documentación de código.
• Comunicación
  • Conservar el equipo, ventas y clientes enlazados.
• Productividad
  • Regularmente evaluar y mejorar la productividad.
• Trabajo en equipo
  • Trabajar en equipo es una habilidad, aprendela, enseñala y mejórala.
• Buscar ayuda
  • Cuando estes estancado en algo, para ahorrar tiempo, pregunta a otros para obtener ayuda.
• Pruebas del desarrollador
  • Probar tu implementación antes de que la liberes al equipo de pruebas.
• Lecciones aprendidas
  • Realizar un documento de lecciones aprendidas del proyecto y mantenerlo actualizado.

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

1. La activa intervención del usuario es necesaria.
2. El equipo debe estar facultado para la toma de decisiones.
3. Los requerimientos evolucionan pero el tiempo (escala) es fija.
4. La captura de requerimientos es en alto nivel; ligeros y visuales.
5. Desarrollos pequeños, liberaciones incrementales e iterativas.
6. Se centra en la entrega frecuente de productos.
7. Completa cada característica antes de pasarse a la siguiente.
8. Aplica la regla 80/20, algo así como Mínimo Esfuerzo Máximo Avance (MEMA).
9. Las pruebas se integran durante todo el ciclo de vida del proyecto.
10. El enfoque colaborativo y cooperativo entre todos los involucrados es esencial.

Fuente: http://kw-agiledevelopment.blogspot.com

Compartir/guardar

1. Comenta tu código como lo hace una persona inteligente

Es obvio. Si escribes un procedimiento y en pocos meses después falla al ejecutarlo, y entonces revisas el código para retrabajarlo y si no lo tienes comentado te costará tiempo. Este tiempo es un recurso tan valioso que nunca puede ser recuperado.

2. Usar el #define

La mayoría de los programadores sabemos hacer cosas como esta. Pero se requiere de disciplina para hacerlo. Cada vez que definas una constante deberías definirla en un lugar centralizado. Por ejemplo, si tu quieres que el área del layout de tu pagina web sea de 800 x 600 pixeles:

#define PIXEL_WIDTH_LAYOUT	800
#define PIXEL_HEIGHT_LAYOUT	600

Si después decides cambiar el tamaño, solo lo tendrías que cambiar aquí y no tendrías que buscarlo en todo tu código y también, no tendrías que componer errores causados por las referencias perdidas.

3. No usar nombres de variables que te puedan burlar después

Si alguien no tiene idea la leer un nombre de variable, no puede entender lo que está haciendo. Una buena estrategia es dar nombres descriptivos a las variables, procedimientos, clases, etc.

4. Hacer verificación de errores

Cuando alguien crea un procedimiento/función debería siempre pensar, “Suponer a alguien malévolo, que por ejemplo use valores extraños, ordene los datos al revés, introduzca valores inválidos, etc; ¿cómo podemos proteger el código y defenderlo para conservar el sistema de que no truene?”

5. Optimización prematura es la raíz de todo mal

La regla es codificar claro y que trabaje bien. Tu tendrás el tiempo para optimizarlo después. Pero no lo hagas hasta que estés seguro de lo que lo que estas haciendo es lo correcto.

6. No ser demasiado listo, en gran parte

Cada quien tiene su propia tolerancia para la complejidad del código. En la codificación de programas, la regla es buscar que se gaste menos tiempo en tratar de comprenderlo, tanto para ti como para las personas que lo lean.

Compartir/guardar