Tengo un proyecto para la universidad que no comenzaré de inmediato, pero he estado pensando durante un período de tiempo razonablemente largo. Entiendo que el desarrollo de proyectos universitarios no es como la industria (actualmente soy un interno), por lo que la situación que señalaré en este momento probablemente parezca algo ridícula para los desarrolladores de software reales. ^^ '
El proyecto en sí mismo requiere que documentemos mucho de nuestro trabajo. Entonces, además de entregar el código, que cuenta para algunas de las marcas, tenemos que entregar documentos que incluyen:
- Un documento de análisis de requisitos
- Un plan de proyecto
- Una lista planificada de casos de uso, objetos y modelos dinámicos y pruebas de aceptación
- Documentación del proceso de prueba y el éxito de las pruebas.
- Algunas otras discusiones y análisis del uso del tiempo, etc.
Estos entregables se entregarán de la siguiente manera:
- RAD primero
- Seguido por el plan del proyecto, casos de uso, modelos y pruebas (aproximadamente 3 semanas después)
- Por último, la documentación del programa real, el proceso de prueba, etc. + la programación real en sí (aproximadamente 5 semanas después)
Entonces, por lo que entiendo, esto realmente está orientado hacia un enfoque de estilo Cascada para el proyecto. El único problema (en mi opinión) es que este es un proyecto universitario, y los estudiantes ya tienen suficiente presión como para tratar de desarrollar proyectos al final del semestre durante la semana del proyecto. Realmente no quiero estar codificando / desarrollando / probando todo al final del semestre, cuando entraré en pánico con las muchas otras evaluaciones con las que tengo que lidiar.
Al menos me gustaría intentar y hacer algún tipo de ciclo de desarrollo iterativo que significa que podemos comenzar a codificar / crear prototipos temprano, tener un ciclo de desarrollo continuo que no se centre en hacer todo en el último minuto y no tener tanta presión en Al final del semestre para terminar este proyecto. Y ahora viene mi pregunta real:
- ¿Puedo conciliar de alguna manera tener que entregar toda esa documentación con un ciclo de desarrollo rápido, iterativo / creación de prototipos?
- ¿Existen estrategias para generar documentación de manera iterativa?
- ¿Estoy siendo completamente irrazonable preguntando esto y esperando que sea factible en la Universidad?
Además, entiendo que esta pregunta está extremadamente localizada, por lo que me gustaría hacer las mismas preguntas que hice anteriormente en términos de industria, y si muchos de estos problemas que enfrentan los procesos ágiles son diferentes para cada equipo o empresa
De todos modos, perdón por cuánto tiempo es esto, y si has terminado de leer hasta el final, ¡gracias! Si pudieras tomarte el tiempo de responder, te lo agradecería mucho. ¡Gracias!
fuente
Respuestas:
La principal preocupación (tengo un problema similar con mi trabajo) es que si "El Proceso" exige que entregues ciertos artefactos en ciertos momentos, y nadie puede desafiar al todopoderoso "El Proceso", entonces si lo intentas, se perderá! No es solo una simple cuestión de que sea una mejor manera (¿Qué es el desarrollo iterativo de documentos?).
Entonces, lo que debe hacer es trabajar dentro del proceso, pero también encontrar la manera de trabajar de la manera que desee. Por ejemplo, ¿su proceso permite la modificación del documento una vez enviado? Si no, entonces no es posible el desarrollo iterativo. Si es así, debe pensar en el costo de la entrega (en términos de su tiempo, su credibilidad, etc.) y administrar ese costo. Si, por ejemplo, es una copia de un archivo y nada más, entonces hazlo. Si (como yo) es una revisión por pares, publicación de revisión, impacta a docenas de personas y cuesta miles de dólares, entonces piense cuidadosamente y asegúrese de que el nuevo documento realmente agregue valor.
Una forma común de trabajar es un documento básico esencial, mínimo, que satisface las necesidades de "El proceso" al principio, seguido más tarde por una actualización final "tal como está construida" que no solo refleja la realidad, sino que tiene los detalles donde sea necesario y está breve donde el código habla por sí mismo.
fuente