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

12

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?

BobIsNotMyName
fuente
3
Escribir código desechable es algo peligroso. Si funciona, ¿por qué debería importarle a la empresa que sea así? Siempre sucede a menos que no se lo muestres. Nunca comprometo la calidad de mi código, incluso cuando ingresé a los hackatones. Podría poner el extraño truco aquí y allá, pero nada que sea "desechable". Cuando realice prototipos, concéntrese en las historias que hacen una buena demostración.
Dave Hillier
3
"gran empresa, que dicta el uso de ágil" : la divertida combinación de palabras "dicta" y "ágil" me recordó de alguna manera el Manifiesto Ágil Medio Arsed . Individuos e interacciones sobre procesos y herramientas ... y tenemos procesos y herramientas obligatorios para controlar cómo interactúan esos individuos (preferimos el término 'recursos')
mosquito

Respuestas:

11

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 :-)

Sklivvz
fuente
En mi opinión, esta es la peor respuesta hasta ahora, me cuesta entender de dónde provienen todos esos votos. La creación de prototipos para obtener retroalimentación temprana no es inusual, es nativa del desarrollo ágil.
Martin Maat
@MartinMaat ¿Por "prototipo" quiere decir "una versión temprana del producto entregado al cliente que evoluciona gradualmente en el producto de forma iterativa"? En este caso, por supuesto, tiene razón en que es nativo de cómo funciona ágil y los tres puntos que explico explican exactamente cómo. Sin embargo, eso no es lo que la gente pretende con esa palabra.
Sklivvz
8

¿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í.

Robert Harvey
fuente
De acuerdo, Python no es un lenguaje de juguete ... Sin embargo, muchas de las organizaciones de mi empresa usan Java ampliamente, y tendremos que interactuar con su código, y por lo tanto, es un requisito que traigamos a personas con una sólida experiencia en Java. . Además, lo que preocupa no es tanto la percepción de las personas que entienden el software, sino la percepción de quienes no lo entienden. Esas son las personas que quieren un nombre que hayan escuchado antes, y ese nombre es "Java" ... Me encantaría que creáramos un equipo comprometido con Python como idioma principal, pero eso será difícil.
BobIsNotMyName
1
Incluso si crea un prototipo en Python y reescribe parte o todo en Java, eso no es necesariamente algo malo (python no tiene el perfil de rendimiento que necesitan algunas aplicaciones). Haber "escuchado" de un idioma no es exactamente un respaldo contundente. Dada la elección, personalmente elegiría otro idioma que no sea Java, pero otras fuerzas a menudo dictan la elección del idioma.
Robert Harvey
@Robert Harvey: "¿No es la creación rápida de prototipos (es decir, el desarrollo iterativo e incremental) el objetivo de Agile?": Por lo que entiendo, la creación rápida de prototipos significa hacer un prototipo rápido y desechable y, después del cliente lo ha aprobado para construir un producto real (con un diseño adecuado, etc.). En ágil tiene un compromiso entre los dos: siempre tiene un prototipo que es técnicamente "suficientemente bueno" (probablemente no tan bueno como un sistema que se ha diseñado por adelantado, pero lo suficientemente bueno para la producción) para que pueda entregarse como un producto tan pronto como el cliente esté satisfecho con él.
Giorgio el
1
@Giorgio: Eso está bien, pero los clientes no saben lo que quieren hasta que se lo enseñas y dicen "no, eso no es lo que quiero, quiero esto " . Ya sea que lo hagas en código o en un papel No me importa, siempre que identifique lo que el cliente quiere.
Robert Harvey
2

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.

Borjab
fuente
1

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.

JeffO
fuente
1

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.

Toronjil
fuente
0

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.

Ethan Teng
fuente
0

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).

Huimin
fuente
0

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.

Martin Maat
fuente