¿Proyectos exitosos usando métodos ágiles?

Question

He estado interesado en métodos ágiles últimamente y he encontrado muchas prescripciones y descripciones detalladas de muchas prácticas. Aún así, recuerdo mis mejores proyectos como picos de ejecución completa, seguidos de algunas depuraciones y pruebas mínimas antes de lanzarlos.

Me he estado preguntando, ¿Flickr utilizó métodos ágiles? ¿Facebook practica TDD? ¿Gmail se hizo en intervalos de 25 minutos seguidos por 5 minutos de ensoñación?

En otras palabras, antes de escuchar más a fondo la predicación y saltar a los manuales, ¿qué evidencia tengo de que esta es la manera de tener éxito en un proyecto exitoso en una empresa exitosa?

Por supuesto, estoy pidiendo esto porque quiero leer las respuestas, no porque quiero descartar un argumento.

Answer 1

Aquí es un proyecto exitoso mío: http://www.sky.com

• se puso en marcha después de unos meses.
• Se entregó una nueva funcionalidad al CMS y a los servidores detrás del sitio semanalmente - con implementaciones típicamente cada semana más o menos.
• Todo hecho con todas las disciplinas de programación extremas.
• Demostraciones semanales al cliente para ir con las iteraciones semanales.

Aquí hay otro proyecto ágil (también hecho estrictamente con XP), también un gran éxito: http://showbiz.sky.com/

También he trabajado en otros dos proyectos XP exitosas:

• Banca Un sistema para limpiar y distribuir datos de ingresos fijos en los sitios de bancos de inversión en Nueva York, Londres, París y Tokio. Creo que todo el proyecto solo tuvo un incidente de producción en el transcurso de algunos años.
• Datos móviles Un sistema para configurar teléfonos móviles y PDA para redes móviles y fabricantes de dispositivos.Construimos el producto principal de manera gradual durante varios años y coordinamos el trabajo en tres sitios en todo el mundo. Todo hecho usando programación extrema. Los clientes eran algunas de las compañías más grandes en el negocio móvil. Nuestras aplicaciones proporcionaron soporte global para algunos de estos clientes.

Realmente no volvería a la forma antigua de hacer las cosas, y tampoco lo harían los clientes que patrocinaron los proyectos que he mencionado anteriormente.

Answer 2

Por lo que entiendo StackOverflow es un sitio web exitoso construido con prácticas ágiles y TDD.

Answer 3

En la mayoría de las grandes compañías (IBM por ejemplo), la metodología no es siempre la misma, Agile o Rational o Waterfall. Eso depende en gran parte de la historia de los proyectos y la experiencia de las personas actuales y los gerentes de proyectos.

Si planea desarrollar algo siempre es bueno verificar todos los lados antes de decidir qué es lo mejor para su plan.

Así que la respuesta corta es: Depende.

Answer 4

Una pregunta relacionada es, ¿cuántos proyectos no -Agile (cascada, "Big Design Up Front", etc.) son exitosos? En mi experiencia, no muchos. De hecho, acabo de lanzar un proyecto de dos fases en el que la primera fase era Waterfall tradicional y falla bastante significativamente, pero la segunda fase era de naturaleza iterativa y arrojaba resultados sustancialmente mejores (a tiempo, muchos menos defectos, el resultado final era más cercano). a las necesidades reales del cliente que las especificaciones originales).

He estado haciendo desarrollo Ágil durante algunos años y, en general, he encontrado que es superior a la alternativa. Algunas cosas que he notado:

1. Agile! = "No process". Agile se trata de tener solo el proceso que necesita y de perfeccionar continuamente ese proceso.

2. Agile requiere disciplina. No solo tiene que tener un proceso, tiene que seguir.

3. Agile no convertirá un proyecto fallido en un éxito. Es puede ayudarle a identificar que el proyecto está fallando más temprano que tarde, y ayudarle a averiguar por qué está fallando. Se trata de acortar el ciclo de retroalimentación para que tengas la oportunidad de retomar el rumbo antes de que sea demasiado tarde.

Microsoft Research recientemente posted an article en el que evalúan empíricamente algunos métodos ágiles. Vale la pena leerlo y podría proporcionarle la información que está buscando.

Answer 5

En otras palabras, antes de escuchar más a fondo la predicación y saltar a los manuales, ¿qué evidencia tengo de que esta es la manera de tener éxito en un proyecto exitoso en una empresa exitosa?

Hay empirical evidence que la mayoría de los proyectos de TI no son exitosos (donde el éxito significa a tiempo, dentro del presupuesto y completamente funcional aquí). Dada esta evidencia, parece razonable preguntarse si un enfoque determinista (la cascada) es adecuado para proyectos de software.

"La definición de locura es hacer lo mismo una y otra vez y esperar resultados diferentes". - Albert Einstein Rita Mae Brown

Si un proceso determinista produce fallas una y otra vez, es probable no aplicar el proceso adecuado para proyectos de desarrollo de software y métodos ágiles son una alternativa. La teoría detrás de estos métodos es que la mayoría de los proyectos de software no son deterministas, son proyectos creativos (como en el arte) y complejos (según lo definido por Ralph Stacey) y no podemos predecir todo. Entonces, en lugar de intentar predecir todo y luego luchar contra el cambio, debemos usar un proceso adaptativo. Y de esto se tratan los métodos ágiles.

Ahora, usar un método Ágil nunca garantizará el éxito sistemático (y alguien que afirme que el inverso es un mentiroso) pero le dará un mejor control sobre los riesgos. Y, si su proyecto tiene que fallar, al menos fallará rápidamente.

Actualización: En realidad, esta cita parece estar misattributed a Albert Einstein. La ocurrencia más temprana conocida y el origen probable se citan en Rita Mae Brown.

Answer 6

Mi producto (el Sophos Email Appliance) se desarrolla utilizando métodos ágiles. La Programación industrial extrema, como propuso Joshua Kerievsky, se usó durante los primeros años de desarrollo. Recientemente comencé a mover más al equipo hacia Kanban, visualizando el flujo de trabajo y usando la programación basada en el pull en lugar de las iteraciones de time-boxed.

Answer 7

Creo que Doublefine acaba de producir Brutal Legend usando Scrum.