En mi experiencia, la clave es describir su software de una manera que todos los interesados entiendan. Esto significa evitar los marcos técnicos formales rígidos que no son accesibles para usuarios no técnicos.
En nuestra empresa, donde creamos aplicaciones web y móviles para empresas, utilizamos las siguientes herramientas:
- Historias: alguna forma de describir lo que ciertos usuarios deben poder hacer en el sistema.
- Conceptos: Estas son las “cosas” en su aplicación. Usuarios, tarjetas de crédito, documentos, eventos, etc. Esto incluye una lista de las propiedades que tiene cada concepto, qué significa la propiedad, cómo se usa y qué se permite que sea. Nota: los conceptos generalmente se traducen en un conjunto de tablas de la base de datos: una tabla primaria con el nombre del concepto y tablas secundarias que describen las relaciones y los meta adicionales necesarios para que el concepto funcione.
- Mapa de páginas : enumere las páginas / interfaces que la aplicación necesita para cumplir con sus requisitos funcionales.
- Maquetas de páginas: páginas completamente diseñadas.
- Algoritmos / Procesos: Este es importante. Cree algún tipo de patrón de pseudocódigo simple para describir cómo funcionan los aspectos no estándar de su sistema. Asegúrese de que el pseudocódigo sea lo suficientemente claro como para mostrar a los usuarios no técnicos, porque si no es así, es probable que desarrolle correctamente lo incorrecto.
- Planes de integración: Similar a los Algoritmos / Procesos anteriores, pero con la advertencia de que las dependencias de terceros pueden ser su mayor riesgo, así que asegúrese de validar sus casos de uso previstos a fondo.
Todos los artefactos anteriores se pueden desarrollar en paralelo. Espere múltiples iteraciones para cada artefacto, posiblemente resultando en un reprocesamiento completo. A medida que se refina un artefacto, a menudo dará lugar a cambios o adiciones a otros artefactos. Este proceso puede consumir una gran cantidad de tiempo y energía.
- Llevo bastante tiempo evitando Java. ¿Esto afectará mi carrera como ingeniero de software?
- ¿Cuáles son algunas sugerencias y temas que debo considerar si voy a dar una charla sobre tecnología y desarrollo de software a un grupo local de no técnicos en mi comunidad local?
- ¿Qué tan fácil es cambiar una carrera de Ingeniería de Software a una carrera de Aprendizaje Automático? ¿Cuál debería ser mi primer conjunto de pasos de bebé?
- ¿Cuáles son las habilidades más importantes de un emprendedor TECH?
- ¿Qué debe saber todo programador de computadoras sobre las licencias de software de código abierto?
Una vez que se hayan desarrollado los artefactos anteriores, debe estar listo para proporcionar una estimación. No significará que su estimación sea precisa, pero significará que todos sabrán lo que se acordó.
¿Parece que esto es demasiado trabajo? Una cosa que puedo garantizar por experiencia es que no documentar ninguno de los artefactos anteriores dará como resultado un desarrollo fallido que resultará en la necesidad de volver a trabajar. La diferencia es que puede llevar 2 horas volver a trabajar el diseño de una página durante la planificación, puede llevar 2 meses volver a trabajar el concepto subyacente una vez que se ha desarrollado incorrectamente.
A menos que esté facturando por hora y no le importe la experiencia de sus partes interesadas, está demasiado ocupado para no planificar .