¿Qué debe suceder al inicio del inicio de un proyecto de software?

7

Una introducción rápida

Mis semestres universitarios incluyen un proyecto de 8 semanas que trabaja para una empresa real con una necesidad de software para obtener una experiencia práctica muy necesaria. Acabo de comenzar un proyecto de este tipo con otros 5 estudiantes. Estamos obligados a gastar aproximadamente 40 horas a la semana por estudiante en este proyecto. Estamos trabajando con SCRUM como método de desarrollo de software, esto fue asignado por nuestros maestros.

La pregunta

El primer día del proyecto acaba de terminar, lo que me ha generado algunas preguntas sobre cómo iniciar un proyecto en el "mundo real". Nuestro primer día incluyó trabajar en un documento de planificación de proyecto (no estoy seguro de cuál es el término en inglés), crear una cita con la compañía para una introducción y la oportunidad de comenzar a especificar los requisitos y establecer algunos estándares para el comportamiento dentro del grupo.

Sin embargo, estos elementos no tardaron tanto en terminar. Hemos hecho algunos planes concretos para mañana y al día siguiente nos reuniremos con la empresa. Esto todavía deja varias horas de "tiempo de trabajo" sin gastar. ¿Es habitual no poder llenar cada hora del día para el trabajo al inicio de un proyecto o simplemente somos demasiado inexpertos para ver qué trabajo se debe hacer en esta etapa del proyecto, o tal vez estamos pasando? la lista anterior es demasiado rápida?

¿Cómo funciona esto en el 'mundo real'? ¿Pasa su tiempo preguntándose 'qué debo hacer ahora', o tiene una visión clara de lo que se supone que debe hacer en ese momento?

    
pregunta Willem 10.04.2012 - 16:11

5 respuestas

17

Para el proyecto específico, no hay mucho que puedas hacer hasta que descubras lo que quiere el cliente. Sin embargo, hay algunas cosas que puede hacer ahora para que su equipo esté listo para comenzar.

  1. ¿Cómo vas a manejar el control de versiones?
  2. ¿Harás revisiones de código?
  3. ¿Cuándo se llevarán a cabo las reuniones diarias de pie? ¿Cuáles son las reglas?
  4. ¿Qué papel juegan todos?
  5. ¿Cómo se manejan las construcciones?
  6. ¿Dónde colocar los documentos para que todos puedan tener acceso?

Haga que el grupo trabaje en un proyecto muy simple para probar todo esto en un idioma requerido o seleccione uno que sea familiar para el equipo.

    
respondido por el JeffO 10.04.2012 - 16:26
12
  1. Configure su sistema de control de versiones y documente su configuración
  2. Configurar un sistema de compilación automatizado
  3. Configure pruebas unitarias automatizadas que se integren con el sistema de compilación
  4. Configure un servidor web para ofrecer contenido estático como documentos e informes generados automáticamente desde su Sistema de integración continua.
  5. Configure un servidor de integración continua para ejecutar sus compilaciones y pruebas y publicar los resultados
  6. Configure un Wiki para usarlo para la documentación "en vivo" del proyecto y otras cosas.

  7. Determine lo que va a utilizar para administrar su acumulación de funciones y tareas

  8. Determine quién es el propietario del producto y responsable de realizar un seguimiento de todo el trabajo
  9. Determine quién se asegurará de que el equipo se mantenga enfocado en el trabajo comprometido
  10. Determine con qué frecuencia se lanzarán las compilaciones al propietario de su producto y respete este programa.
respondido por el Jarrod Roberson 10.04.2012 - 16:39
5

Mi alarma interna está sonando cuando veo the opportunity to start specifying the requirements y these items didn't take that long to finish juntos. Mientras que otras respuestas brindan excelentes maneras de establecer un ambiente saludable, asegúrese de que uno de los mayores peligros esté bajo las especificaciones. Así que podrías pasar algo de tiempo en esta fase. Puede ser una semana (a tiempo completo) en su proyecto de 8 semanas.

La parte difícil es encontrar la especificación faltante y las cosas que no funcionan en las especificaciones actuales. Es realmente difícil criticar tu propio trabajo. Lo que debes hacer es jugar un poco o un rol. Algunas personas son el cliente y las otras miembros del proyecto. El cliente es alguien que juzgará su trabajo (maestro, mentor ...). Podría ser un miembro externo del proyecto (encuentre a alguien con alguna experiencia con este tipo de proyecto). La iteración debe ir de esta manera:

  • el cliente lee los requisitos
  • el cliente hace preguntas sobre requisitos faltantes, especificación de características, evaluación de posibles fallos, organización de pruebas, elección de marco ...
  • el equipo del proyecto responde & actualizar los documentos

Una vez que sepa lo que quiere hacer, puede comenzar a configurar un flujo de trabajo para su equipo.

Al final de este trabajo, debe tener un conjunto de características con un desglose de tareas básicas para cada una de ellas. Establezca los hitos (la semana 3 necesitamos haber finalizado el hito 1 y 2, la semana 6 necesitamos tener un código fuente estable para probarlo en las semanas 7 y 8 y cumplir con la corrección de errores pequeños + escritura de documentación ...). Cuando comience un hito, publique una lista de tareas en algún lugar (puede usar una hoja de Excel o incluso un rastreador de errores para esto) y acuerde quién comienza con qué. Cuando alguien termina su tarea, toma otra (y se comunica al respecto). Antes de eso, alguien más debería echar un vistazo rápido a lo que ha hecho para verificar si es correcto y completo.

Configurar todo este flujo de trabajo es algo difícil para los principiantes, pero es mucho más importante que tener un buen servicio wiki. Debe tomar por lo menos una semana para pensar cómo trabajará. No es necesario que aplique la organización que describí aquí (esto es realmente un ejemplo), pero debería tomarse un tiempo para pensar en cualquier cosa que funcione con usted y configurar las herramientas necesarias. El objetivo es involucrar a todos. Siempre debe haber una respuesta fácil a la pregunta "¿qué debo hacer ahora?".

    
respondido por el Simon 10.04.2012 - 17:44
0

Sí, comenzar un proyecto es lento y con frecuencia no se llena todo el día debido a la necesidad de concertar con otros que pueden tener su propio calendario. (Algunas otras preguntas han propuesto cosas que tal vez desee considerar, pero el socio de la empresa en su proyecto también puede tener requisitos para ellas, hablar sobre ellas y estar listo para proponer algo si no les importa).

Volviendo a lo que creo que es el núcleo de tu pregunta. En mi práctica, el inicio de un proyecto se realiza de forma incremental, solo una parte del equipo comienza a trabajar en el nuevo proyecto y solo una parte del tiempo, mientras se completa el anterior.

    
respondido por el AProgrammer 10.04.2012 - 17:25
0

¿Qué debería suceder al inicio de un proyecto de software? ¿Cómo funciona esto en el 'mundo real'? ¿Pasa su tiempo preguntándose 'qué debo hacer ahora', o tiene una visión clara de lo que se supone que debe hacer en ese momento?

Lo que busco hacer al inicio de un proyecto de software es dedicar tiempo a conocer a las personas con las que trabajo.

Me gusta desarrollar y modificar las prácticas y los procedimientos del equipo a lo largo del tiempo, sin embargo, el inicio de un proyecto o un equipo puede ser un buen momento para acordar algunas reglas básicas iniciales o "charter".

Busque la manera de trabajar juntos que funcione para el equipo para cualquier situación y combinación de miembros que tenga, y encuentre las mejores herramientas para correo electrónico, im, seguimiento de tickets, wiki, etc. para la situación actual. Siéntase cómodo con el uso y la adaptación de estas herramientas para satisfacer sus necesidades específicas, de modo que, cuando llegue el momento de realizar cambios rápidos, tenga la habilidad de hacerlas.

    
respondido por el Michael Durrant 09.07.2014 - 03:03

Lea otras preguntas en las etiquetas