En mi opinión, la elección suele ser entre Agile y Process Driven, en lugar de entre diferentes sabores de agile. Alistair Cockburn tiene una visión interesante (lo siento, no estoy seguro de un enlace) donde mapea el tamaño del proyecto en un eje y las consecuencias del fracaso en el otro, desde “inconvenientes” hasta “muerte en masa”. A medida que los proyectos se mueven de tamaños más pequeños a más grandes, y a medida que las consecuencias del fracaso se vuelven más severas, más procesos y controles se vuelven más apropiados.
Entre metodologías ágiles particulares, estaría más a favor de encontrar algo que funcione bien para su equipo que un sabor exacto. Personalmente, prefiero una versión ligera de Scrum, pero Extreme puede ser excelente siempre que a su equipo no le importe trabajar de una manera más estrecha (literalmente).
Un peligro al adoptar cualquier proceso ágil es la posibilidad de que comiences a seguir el proceso PARA seguir el proceso. Recuerde que el proceso no tiene un valor inherente en sí mismo, su único valor está en cuánto ayuda a sus esfuerzos de desarrollo. Nunca tenga miedo de doblar, romper o cambiar ninguna de las reglas de un proceso ágil para adaptarse mejor a su equipo y circunstancias, y tenga mucho cuidado con cualquiera que trate el proceso como prescriptivo.
- ¿Qué tan peligroso es el virus WireLurker y cómo podemos mantener nuestros Macs / iPhones a salvo de él?
- ¿Debo asistir a UChicago o UIUC si planeo estudiar informática?
- Si tuviera 100 petaFLOPS de energía de la computadora a su disposición durante un día, ¿para qué la usaría?
- Si el problema de detención es indecidible, ¿cómo hacen las personas los programas?
- ¿Cuándo aplicamos el método BIG M para la investigación operativa?
