Metodologías ágiles como Scrum en proyectos de desarrollo no software

Hay dos principios principales de Scrum que, en mi opinión, lo definen y le dicen el valor que tiene para cualquier proyecto o producto. Esos dos son: requisitos cambiantes y versiones iterativas.

Hay muchas publicaciones excelentes en este sitio sobre Agile vs. Waterfall. La conclusión es que Waterfall es increíble si puede reunir todos los requisitos por adelantado, y no cambiarán mucho. La parte difícil es obtener esos requisitos correctamente, en papel, antes de realizar cualquier trabajo.

Esto significa que la cascada se aplicaría muy bien a industrias como la automotriz, la atención médica, la aeroespacial, etc., donde es más fácil aclarar por adelantado qué es exactamente lo que necesita.

Por otro lado, los lanzamientos iterativos son muy, muy útiles, incluso con requisitos fijos y sin cambios. Teóricamente podrías hacerlo, pero no veo qué beneficio obtendrías de ello.

En su lugar, me centraría en otras partes útiles de Scrum, como:

• Estimar las tareas en unidades más vagas (puntos de la historia) en lugar de tiempo, si los requisitos son desconocidos o están cambiando.
• Dividir el trabajo en unidades pequeñas que se pueden completar en una o dos semanas, o menos.
• Comunicarse diariamente con todo el equipo para decir "esto es lo que hice ayer, lo que voy a hacer hoy y en qué me quedé atascado".

Su experiencia puede ser diferente. Diría que mire Scrum/Agile y comience a aplicar esas prácticas que puede ver que lo beneficiarán.

De hecho, Ken Schwaber publicó un libro llamado Agile Project Management with Scrum que analiza una serie de estudios de casos en industrias fuera del desarrollo de software.

Es completamente posible aplicar principios ágiles y el proceso Scrum fuera del software y se está haciendo en una variedad de entornos.

La reciente conferencia Scrum Beyond Software celebrada en Phoenix en septiembre de 2010 exploró este tema con gran detalle en un formato de espacio abierto. Como asistente, estuve entre varias personas que compartieron sus experiencias con Scrum en diferentes entornos, incluidos educación, marketing, ventas y gobierno. He asesorado personalmente a una organización de marketing para que aplique el marco Scrum en la planificación e implementación de sus campañas, y conozco al menos un equipo de ventas que aplica activamente Scrum (y utiliza herramientas de gestión de proyectos de software de manera efectiva al hacerlo).

Además, estoy personalmente al tanto de dos sesiones que han sido aceptadas para la conferencia Agile 2011 relacionadas con la aplicación de Scrum más allá del desarrollo de software. Uno se aplica a Scrum en Ventas y el otro se aplica a Agile en Académico . Puede haber muchos otros que no he notado.

(Nota: no estoy seguro de la longevidad de estos enlaces después de que se cierre el proceso de presentaciones para Agile 2011. Como ambos son aceptados, los informes de experiencia finalmente se publicarán en las actas de la conferencia, que publica el IEEE)

Esta es una pregunta bastante abierta en este momento y, a medida que Agile evoluciona, creo que podemos esperar ver un mayor uso fuera de la configuración de desarrollo de software.

Consulte esta discusión para ver un buen paso a paso: https://stackoverflow.com/questions/1702128/can-i-use-agile-in-a-non-development-project

Por cierto, voy a ser pedante: scrum es una herramienta ágil. Además, Agile fue diseñado para proyectos de software; no hay cambio de enfoque como sugieres.

Cuando pregunta sobre Agile fuera de la industria del software, lo que vuelvo a mencionar es el trabajo realizado por W. Edwards Deming en la fabricación. Uno de sus principios fundamentales fue el ciclo Plan-Do-Check-Act. También conocido como el ciclo de Deming. Este ciclo junto con sus 14 pintas y 7 pecados capitales son la base de gran parte del proceso de fabricación moderno y fueron clave para el renacimiento y el éxito de la fabricación en Japón después de la Segunda Guerra Mundial.

Con su énfasis en un proceso iterativo y su enfoque en la calidad del producto, en lugar del control de calidad posterior a la producción, el trabajo de Deming es el punto de partida lógico para aplicar Agile fuera del desarrollo de software.

Al tomar el trabajo de Deming y agregarle los principios Agile en torno a los sprints, la velocidad, la frecuencia y las retroacciones, obtiene un híbrido funcional para aplicaciones que no son de TI. Además, obtiene 60 años de experiencia acumulada en procesos de fabricación que funcionan.

La mayoría de los métodos ágiles son metodologías de desarrollo. Si toma la programación extrema, por ejemplo, es obviamente imposible aplicarla en otro dominio que no sea el desarrollo de software.

Scrum, por otro lado, es una forma de organizar un equipo de proyecto. Es muy adecuado para equipos de desarrollo de software, pero no hay ninguna razón por la que no sea adecuado para equipos de proyecto en otros dominios que no sean el desarrollo de software.

Editar: acabo de descubrir Jugaad, que podría ser relevante para su interés. Echa un vistazo a la página web oficial: http://jugaadinnovation.com/

También hay un libro: http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118249747.html

Jugaad es una forma de considerar la innovación de una manera frugal y ágil.

Agile funciona mejor cuando se opera en el dominio Complejo.

Cynefin Framework clasifica los proyectos en cuatro dominios: Simple, Complicado, Complejo y Caótico. Agile funciona mejor cuando trabaja en el dominio complejo.

En el dominio Simple, está trabajando con un área bien entendida y puede completarla simplemente siguiendo un conjunto de reglas y procedimientos. Por ejemplo, ensamblar muebles de Ikea sería un proyecto en el dominio Simple; solo estás siguiendo las instrucciones en la caja.

En el dominio Complicado, está tratando con incógnitas conocidas, y puede producir un resultado averiguando cuáles son y luego poniéndose a trabajar. Gran parte del trabajo de ingeniería está en el dominio Complicado, y Waterfall funciona bien para los proyectos aquí.

En el dominio Complejo, usted está lidiando con incógnitas desconocidas, y necesita ser capaz de cambiar su curso de manera flexible para adaptarse a ellas, razón por la cual Agile funciona mejor aquí. La ingeniería de software cae principalmente en este dominio, por lo que Agile es tan popular en ese campo, pero es posible que otros proyectos también lo hagan.

En el dominio Caótico, te enfrentas a una situación en la que no puedes establecer la información de manera cohesiva y tienes que actuar para imponer el orden; un ejemplo serían los bomberos que atienden un edificio en llamas o la policía que atiende un motín.

Entonces, para responder a su pregunta real, simplemente vuelva a enmarcarla como tal: ¿Son complejos los problemas en la industria automotriz?

Además de la gran respuesta de Ashes999 , hay una mención más notable de cómo introducir Agile en una organización o equipo que no sea de TI. Realmente me gusta la parte de no usar todas las palabras de moda y trabajar principalmente desde la perspectiva de los valores ágiles.

Hay un método de 5 pasos según esta publicación: https://teamhood.com/agile/agile-for-non-it/

1. Educar a las personas sobre los valores ágiles
2. Definir roles y responsabilidades.
3. Cree una acumulación de trabajo centralizada
4. Formar y practicar hábitos ágiles (técnicas/ceremonias/etc.)
5. Hacer ciclos Agile (sprints) predecibles y de éxito repetible

Ejemplo de lenguaje sin opiniones de TI para Agile

Una pregunta abierta esto es de hecho. Además, no hay una buena respuesta para eso. Todo lo que puede hacer es confiar en la opinión de los demás sobre si esto funcionará, o probarlo usted mismo y ver cómo funciona. Recomiendo este último. Habiendo dicho esto, puedo asumir el papel del "otro" y recomendar una lectura rápida sobre por qué los métodos ágiles funcionarán para cualquier negocio: https://kanbantool.com/blog/bringing-agile-into-non-tech-environments Ya sea si acepta scrum o kanban es otra cuestión: en mi experiencia, kanban es más fácil para los principiantes, pero scrum puede aportar más estructura al flujo de trabajo si esto es lo que necesita, pero no comenzaría con eso de inmediato.

Bueno, "habiendo dicho todo lo anterior", ahora aprecio la sabiduría de un libro electrónico llamado "Administrar el mecanismo", que hizo la observación de que el software de computadora es "una máquina autónoma y autodirigida ".

La tarea del "equipo" es, por supuesto, "producir software de computadora". Pero, cuando "el software de computadora que han producido" finalmente se pone en uso, "el equipo que lo produjo" es ... impotente. Se han visto obligados a retirarse al vestuario mientras los robots que han creado realmente juegan.

Nunca he visto este pequeño libro electrónico en papel. Pero fue un cambio de perspectiva revelador para mí. Ni "un abrelatas bien diseñado" ni "un robot de línea de producción" se espera que sean... "autónomos".