¿Cómo encaja la creación rápida de prototipos en una metodología ágil?

Trabajo para una gran empresa, que dicta el uso de procesos ágiles. Por ejemplo, para nuestros proyectos, utilizamos servicios basados ​​en la nube que están específicamente dirigidos a gestionar el desarrollo ágil.

El grupo de ingeniería específico para el que trabajo no ha desarrollado software tradicionalmente (en cambio, ayudamos a impulsar proyectos desde un punto de vista mucho más amplio), pero eso está cambiando. Tenemos una amplia gama de proyectos de software futuros / planificados que se centran principalmente en los datos, por ejemplo, realizaremos monitoreo, recopilación, agregación y algunos informes de datos. Otras tareas implican la automatización con hardware especializado y varios tipos de arquitecturas cliente / servidor (multinivel). Debo ayudar en el proceso de contratar a varias personas y formular muchos de nuestros planes para avanzar.

Mi pregunta es si hacer prototipos rápidos (código desechable) se ajusta a una filosofía ágil. Por ejemplo, me encanta Python y su amplia gama de paquetes. Veo la posibilidad de implementar muchas de nuestras ideas muy rápidamente con un flujo de trabajo basado en Python. Sin embargo, creo que habrá muchas percepciones de que Python no es de "calidad empresarial", y gran parte de este trabajo debería reescribirse en Java o tal vez C ++.

Sin embargo, la creación de los prototipos de Python nos daría mucho dinero para permitirnos entregar rápidamente resultados reales.

¿Ha podido incorporar la creación rápida de prototipos, con suerte en Python, en un flujo de trabajo sólido y ágil en un entorno empresarial?

El concepto de "creación de prototipos", como se pretende en RAD , es un poco extraño para el desarrollo ágil. Esto no significa que no se pueda hacer, pero es inusual.

Hay diferentes casos que deben explorarse:

1. ¿Es el prototipo una "carcasa vacía", una maqueta o una demostración, creada para dar una idea de cómo se vería un producto? Ciertamente puede hacerlo con una o más historias; sin embargo, está construyendo algo con su propia imaginación, no construyendo un producto con comentarios reales. Las personas no evalúan una demostración como evalúan un producto. Por ejemplo, vea los comentarios sobre nuestro prototipo de barra superior versus nuestra implementación real de barra superior .

2. ¿Es el prototipo algo que debe construirse para comprender mejor el espacio del problema? Entonces debe cubrirse como un pico , y solo se deben mantener sus resultados (el código fuente es transitorio).

3. ¿Es el prototipo una versión 0.x? ¿Un producto mínimo viable ? Luego use el proceso ágil de su elección para ello. Si necesita reconstruirlo en otro idioma, es probable que esté mejor si lo trata como un producto diferente. Tenga en cuenta que a veces esto se trata como una forma de atajo al escribir una especificación ("¡debería hacer lo mismo que el prototipo!"). Esa es una forma realmente pobre de documentar un producto, pero esto probablemente se explica mejor como una pregunta y respuesta por separado :-)

¿No es la creación rápida de prototipos (es decir, el desarrollo iterativo e incremental) una especie de punto central de Agile?

Parece que tiene problemas con "la percepción es la realidad" en su organización. Es posible que desee recordarles a todos que Agile no significa "descartar todos los planes", como tampoco lo hace Desarrollo Test-Driven: "descartar toda la arquitectura".

Y Python no es (si alguna vez lo fue) un lenguaje de juguete. La NASA y sus contratistas usan Python , y si es lo suficientemente bueno para ellos, es lo suficientemente bueno para mí.

Hay una práctica bastante establecida en la programación extrema llamada Spike . Esto significa que es un código desechable. No hay nada especial en ello. Es solo un Sprint en el que el resultado esperado es el conocimiento sobre el código desechable.

El enlace de arriba tiene suficiente información sobre las buenas prácticas, las trampas de los picos.

Su caso de uso específico parece un buen ejemplo: puede ser útil diseñar la interfaz, validar la utilidad y mostrársela a algunos usuarios.

Vas a tirar el código a la basura y no lo pondrás en producción (dejárselo perfectamente claro a TODOS), por lo que ser ágil o no realmente no importa. Cualquier práctica ágil es puramente opcional para los prototipos: sprints, quemaduras, pruebas, programación de pares o cualquier otra cosa que planee usar.

Si principalmente va a construir modelos funcionales en Python para ayudar a los propietarios de productos y otros tomadores de decisiones a conceptualizar el proyecto, no necesita estar preparado para la empresa. Sin embargo, si está creando una prueba de concepto o tratando de ver si puede manejar ciertos niveles de rendimiento, probablemente deba atenerse al lenguaje de producción. Eso no significa que no puedas probarlo en Python.

De todos modos, va a tirar el código, pero tiene el conocimiento de poder hacer que esto funcione junto con una mejor idea de lo que quieren los propietarios. Ahora puede usar cualquier metodología que desee.

Añadiría que los prototipos son cruciales para el aprendizaje, y también en el espíritu ágil. Si el prototipo le permite aprender, especialmente dentro de ciclos de retroalimentación más rápidos, entonces hágalo. Se trata de maximizar el aprendizaje y compartir los aprendizajes con el equipo.

En términos de aprendizaje, agregaría que la creación de prototipos lo lleva a aprender más rápido. De esa manera, puede validar si las personas se preocupan por el problema que está tratando de resolver, y si la solución que tiene en mente es lo que están buscando, sin perder mucho tiempo creando una solución completa que pueda , al final, no resuelve un problema lo suficientemente doloroso o no lo resuelve de la manera correcta.

El verdadero espíritu de Agile se trata de interacción y comunicación. Diría que si el prototipo funciona bien como una herramienta para ayudar a la comunicación, no hay nada malo en usarlo en el mundo ágil. En nuestro equipo (hemos practicado Agile durante más de 5 años) lo usamos de vez en cuando. Y hay algunos beneficios que puedo ver de eso

1) ayudar a la comunicación

2) Haga que los usuarios participen en entrevistas de solución y obtenga comentarios anticipados

Consideración:

La comunicación directa entre UX y los ingenieros NUNCA debe reemplazarse por artefactos de creación de prototipos. Si es posible, el emparejamiento con el ingeniero funciona mucho mejor que la comunicación a través de un mediador (prototipo).

Otros ya mencionaron el propósito de aprendizaje de los picos. Lo que falta es el principio ágil subyacente que falla rápidamente .

Uno de los pilares en el desarrollo ágil es reconocer las partes difíciles y buscar pruebas de conceptos, ver si puedes hacerlo. La forma clásica de avanzar en todas las tareas en un orden "lógico" puede resultar muy costosa si descubre que no puede hacer algo al final del proyecto. Todo lo hecho hasta ahora podría ser un desperdicio.

Si tiene que terminar de esa manera, quiere saber lo más rápido posible. Luego, las partes interesadas pueden optar por dejar de quemar dinero mientras todavía no se ha quemado mucho y aceptar que lo que quieren no es factible o intentar un enfoque radicalmente diferente del problema que tendrá una nueva oportunidad de tener éxito. Si sus prototipos cumplen este propósito, son realmente ágiles.