Creación rápida de prototipos y refactorización

A veces, cuando comienzo un proyecto pequeño (como una aplicación de Android), no sé qué enfoque funcionará al final, y solo voy por un enfoque y lo pruebo. Pero si nunca he usado este enfoque antes (para un tipo de aplicación que nunca he programado antes) es como entrar en un terreno desconocido. No sé qué bibliotecas usar (tal vez tenga que probar varias bibliotecas) y hay muchas incógnitas (como: cómo obtener datos de audio sin formato en Android)

Entonces mi proceso de desarrollo es así:

• Escriba un código para ver si el enfoque tiene una posibilidad. (Cuanto más incierto es el enfoque, más feo se vuelve el código)
• Si funciona, refactoriza mucho hasta que esté hermoso

Creo que podría ser una pérdida de tiempo si planificara mi diseño de software en detalle en este punto, sería como planificar un viaje sin un mapa.

¿Es esto parte del desarrollo aglie? ¿Cómo lidiar con terreno desconocido en el desarrollo de software?

Eso no tiene nada que ver con ágil, pero la gente asume que sí, porque eso es lo que creen que es ágil; desarrollo del pollo sin cabeza en una comuna hippy.

Lo que está haciendo es evaluar las tecnologías porque actualmente no tiene la experiencia suficiente para hacer un juicio. Esto es bueno y nunca termina porque nuevas bibliotecas, marcos, lenguajes y plataformas aparecen casi a diario.

La forma en que lidias con lo desconocido es una muy buena pregunta en realidad y se trata de investigar las alternativas, evaluarlas y luego seleccionar una.

Las habilidades que tienden a asociarse con Agile que ayudan aquí implican crear un código que sea tan fácil y seguro de refactorizar. TDD es un buen ejemplo. Lo alienta a considerar su desarrollo en términos de resultados. "Este código debería producir este resultado", que enfoca la mente y reduce la cantidad de código que no contribuye a resolver el objetivo.

Si escribe código siguiendo los principios de SOLID (Acrónimo), estará en una buena posición más tarde para reemplazar una biblioteca si tomó la decisión incorrecta o, como sucede a menudo, supera su elección.

Es bueno que hagas este tipo de preguntas. Hay demasiados desarrolladores que por diversas razones no se arriesgarán a parecer "ignorantes" al tomarse el tiempo para seleccionar la tecnología correcta. Cometer errores al principio del proyecto, no tarde. La experimentación es clave, no un desperdicio, así que creo que lo estás haciendo de la manera correcta.

¿Es esto parte del desarrollo aglie? ¿Cómo lidiar con terreno desconocido en el desarrollo de software?

Lo que has descrito no es ágil. El desarrollo ágil se trata más de promover la planificación adaptativa, el desarrollo evolutivo y la entrega con un enfoque iterativo de tiempo determinado. Ágil fomenta una respuesta rápida y flexible al cambio. Por lo tanto, volver a factorizar su código a medida que avanza el desarrollo tiene piezas de metodología ágil.

Tratar con piezas desconocidas del proyecto comienza con la recopilación de los requisitos conocidos, con un diseño de alto nivel. Una vez que tenga la mayoría de los componentes disponibles, puede buscar la solución correcta. Dicho esto, la construcción de una pequeña prueba de concepto antes del desarrollo completo es el enfoque que sigue nuestro equipo.

Hay un principio de desarrollo de software llamado SOLID . En mi experiencia, aplicarlos en problemas / problemas siempre es un paso adelante para mejorar la base de código de su proyecto.

Depende del proyecto, si está trabajando solo en un proyecto pequeño, podría tener mucho sentido realizar su investigación e investigación tecnológica como parte del desarrollo. Y aunque no es parte de Agile, por supuesto, se podría usar una metodología Agile para agregar algo de control a esto. Sin embargo, esto hace que el proceso sea muy difícil de predecir / o caja de tiempo. Podría estar bien, incluso más rápido, si trabaja solo en un pequeño proyecto que es totalmente suyo, deje que sus requisitos se desarrollen a medida que los aprende. Use buenos principios en el camino, y sea consistente y no debería necesitar re-factorizar tanto.

En el trabajo utilizamos Kanban, Scrum y otros enfoques de cascada más tradicionales. Dependiendo del proyecto, creo que los desarrollos complejos con requisitos iniciales bien definidos no son los más adecuados para ágil, aunque muchos estarán en desacuerdo.

Antes de comenzar a trabajar incluso en un proyecto ágil (todo menos el más simple), creamos algo de documentación. Tenemos una maqueta (si está enfocada en la interfaz de usuario), un conjunto de requisitos y una especificación funcional.

Se le pedirá al desarrollo que cree la especificación técnica a partir de la especificación funcional, y durante este proceso especificaremos la tecnología y realizaremos cualquier investigación inicial que necesitemos. Este proceso me parece muy importante, ya que brinda la oportunidad de ver lagunas en los requisitos / especificaciones funcionales, y brinda las grandes decisiones tecnológicas por adelantado a las personas con la experiencia y el conocimiento del sistema para tomar tales decisiones.

Sin embargo, lo importante es que la especificación funcional podría ser una lista de viñetas, y la especificación técnica generalmente será un modelo, con algunas viñetas y guías tecnológicas, tal vez solo 3 o 4 páginas en algunos casos.

Incluso cuando se ejecuta un proyecto ágil, creamos documentación:

• Toda la documentación tiene un costo.
• Desarrollar contra requisitos de alto nivel en movimiento y mal definidos tiene un costo.
• El equilibrio correcto de lo anterior depende de su proyecto, la cultura y las personas.
• Documentamos Justo a tiempo, los documentos no están actualizados.
• Documentamos apenas lo suficiente / lo suficiente.
• No mantenemos ni actualizamos estos documentos, no ponemos mucho esfuerzo en ellos. Ellos son pequeños. Esperamos tirarlos a la basura.
• Eliminamos las grandes incógnitas, como las decisiones tecnológicas, los requisitos confusos y la arquitectura por adelantado.
• Sabemos lo que estamos desarrollando antes de comenzar.
• Confiamos en que los desarrolladores tomen decisiones informadas sobre la documentación y discutan cualquier problema.
• Valoramos la comunicación sobre la documentación, por lo que esperamos que todos los involucrados se comuniquen a menudo.
• Documentamos sistemas (descripción general) después del desarrollo, no durante ni antes.

Usted ve que hay una pequeña cascada en nuestro proceso ágil.

Si trabaja solo, cree un modelo inicial (¡diagrama!), Juegue y elija la tecnología, y luego, cuando tenga este concepto de los requisitos de alto nivel, avance y desarrolle de manera ágil e iterativa, pero considere buenos principios y consistencia a medida que avanza y necesitará re-factorizar menos, más re-factorizar a medida que avanza.

Pero en general, si hay un costo real involucrado (no un pasatiempo), sepa lo que está desarrollando antes de escribir el código, pero no pierda demasiado tiempo escribiendo documentación que se volverá redundante rápidamente, ya que cambiará de opinión y debería cambie de opinión durante el desarrollo a medida que se informa mejor. Y su proyecto podría cambiar enormemente de rumbo, pero comenzar desde una base buena y bien definida.

Así es más o menos como comienzo nuevos proyectos y funcionó bastante bien, suponiendo que estamos hablando de proyectos pequeños. Por ejemplo, no seguiría esta ruta si estuviera escribiendo un ORM o algo de esa magnitud. De vez en cuando recurriré a una investigación más formal cuando realmente esté fuera de mi alcance. Pero en su mayor parte solo comienzo a escribir código y veo qué sucede. Sin embargo, debes estar preparado para tirar mucho código cuando hagas esto.