2009-09-04 12 views
15

Tenemos un proyecto entregado desde el equipo de tierra a nuestro equipo (fuera de la costa) no hace mucho tiempo. Sin embargo, estábamos teniendo dificultades para el proceso de transferencia.¿Cómo entregar un proyecto sistemáticamente?

  1. No podíamos pensar en alguna pregunta que deben hacerse durante su recorrido a través del diseño, porque estábamos abrumados por la gran cantidad de información. Queríamos preguntar, pero no sabíamos qué preguntar. Como no nos cuestionaron, la gerencia piensa que el proceso de traspaso se realizó con éxito.

  2. Hemos intentado revisar toda la documentación de la página wiki de nuestra compañía antes de asistir a la presentación de entrega, pero hay demasiados documentos, ni siquiera sabemos por dónde empezar.

Me pregunto, ¿existen normas o mejores prácticas que podemos seguir, para asegurar el éxito del proyecto de traspaso, ya sea de nosotros, o para nosotros.

Gracias.

+1

Fuera de interés ¿por qué es este Wiki de la comunidad? Es una buena pregunta. –

+0

¿Alguna idea de cómo hacerla wiki no comunitaria? No puedo encontrar ninguna opción para hacer eso. – janetsmith

+0

Esta pregunta no está relacionada con el tema porque no está dentro del alcance de las preguntas apropiadas para este sitio, tal como se define en [¿Qué temas puedo preguntar aquí?] (Http://stackoverflow.com/help/on -topic). también vea: [¿Qué tipos de preguntas debo evitar preguntar?] (http://stackoverflow.com/help/dont-ask) Puede obtener ayuda en [otro sitio de Stack Exchange] (http: // stackexchange. com/sites # name). – Makyen

Respuesta

4

Como inicio, defina los criterios de salida para el traspaso. Esto debe discutirse, negociarse y acordarse con ambas partes y garantizar que la alta gerencia lo sepa. Luego escriba una lista de verificación de todas las cosas necesarias para lograr los criterios de salida y persíguelos.

11

Mi proceso básico para la recepción de una transferencia sería:

  1. Obtener una visión general de la aplicación, documentarla
  2. Obtener una lista de todos los trabajos futuros que el cliente espera
  3. ... todos los problemas conocidos
  4. ... cualquier implementaciones específicas
  5. documentación tanto arriba-hasta la fecha tienen
  6. Si es posible, haga que escriban algunas pruebas para los componentes críticos del sistema (o al menos conseguir que estén completamente documentados)

Si hay demasiada documentación (posible) acaba de confirmar que es todo hasta la fecha, y asegúrese de averiguar a través de ellos dónde comenzar, si no está claro.

Haga la mayor cantidad de preguntas posible; cualquier cosa que se te venga a la mente, porque es posible que no tengas otra oportunidad.

33

En cuanto a la lectura de la documentación, en lo personal me gustaría ir por este orden:

  1. Reciba una breve descripción de la función básica de la aplicación - ¿qué es la intención de lograr. El caso de negocios es probablemente el mejor documento que ya existirá.

  2. A continuación, la especificación funcional. En este punto, no está tratando de comprender cómo o qué tecnología, solo qué debe hacer la aplicación. Si es masivo, pregúnteles cuáles son los procesos clave del negocio y concéntrese en ellos.

  3. Luego, la descripción técnica de alto nivel. Esto debería incluir un diagrama de arquitectura, plataformas requeridas, versiones, configuración, etc. Haga una lista de preguntas que tenga.

  4. Luego revise cualquier otro documento técnico de aspecto útil, sin duda una pregunta frecuente si hay alguno, los scripts de prueba también pueden ser buenos ya que describen escenarios detallados de "cómo hacerlo". Tal vez soy solo yo, pero me parece leer documentos técnicos antes de ver el sistema como un desperdicio: es demasiado académico y, por lo general, está escrito de manera escandalosa. Ciertamente es un área en la que limitaría el tiempo que pasé si no sintiera que estaba obteniendo un rendimiento razonable por el tiempo que estuve gastando.

Si hay varios de ustedes arrage opiniones estructuradas entre usted y discutir los documentos que ha leído, asegurándose de que usted tiene lo que necesita para salir de ella. Si el sistema es grande, cada uno toma un área y se los presenta a los demás: dense una razón para aprender tanto como sea posible y saber que van a ser interrogados es una buena motivación. Haga una lista de preguntas donde no entienda algo. Tener revisiones estructuradas entre usted enfocará sus mentes y lo convertirá en una tarea más interactiva, en lugar de simplemente buscar páginas tras páginas de documentos tediosos.

Una vez que obtenga cara a cara con ellos:

  1. de inicio con una demostración completa del sistema. Haga preguntas a medida que surjan, no permita que lo engañen con respuestas poco claras: si no pueden responder algo, escríbalo y prepárelas para obtener la respuesta.

  2. Ahora obtenga el código verificado y en funcionamiento en sus máquinas. Haga esto en al menos dos máquinas: una que lideren y otra que lidere. Documente todo el proceso: este es el paso más importante. Si no puedes ejecutar el código, estás jodido.

  3. Pase por el proceso de compilación. Asegúrese de que pueda compilar la aplicación (incluidas las compilaciones automatizadas y las pruebas unitarias que puedan tener). Tenga en cuenta que todas las pruebas unitarias deben pasar; si no lo hacen o si dicen "oh, esa siempre falla", entonces deben arreglar eso antes de la aceptación final.

  4. Pase por el proceso de instalación. Haga esto al menos dos veces, uno que ellos lideren, una vez que lidere. Asegúrate de que esté documentado.

  5. Ahora presente un conjunto de funciones comerciales comunes llevadas a cabo con la aplicación. Use esto para recorrer el código con ellos. La base del código será demasiado grande para cubrir todo, pero asegúrese de cubrir una muestra representativa.

  6. Si hay una base de datos o una API, haga un ejercicio similar. Proponga algunos datos estándar que pueda necesitar extraer o algunas tareas básicas que pueda necesitar llevar a cabo utilizando la API y dedique un tiempo a trabajar con ellos.

  7. Pregúntales si hay algo que ellos piensen que debes saber.

  8. Asegúrese de que cualquier pregunta que haya escrito en otro lugar sea respondida.

  9. Puede considerar que vale la pena revisar la lista de errores (abierta y cerrada) - comience con las de mayor prioridad y hable sobre cualquier aspecto especialmente preocupante. Incluso si lo han solucionado, puede apuntar a un código un poco problemático.

  10. Y, por último, si existe la oportunidad, si hay errores o cambios pendientes, vea si puede emparejar un par de programas.

No finalmente aceptar la aplicación a menos que esté 100% seguro de que puede:

  1. Obtener el código para compilar
  2. obtener el código para construir (incluyendo la base de datos)
  3. Get la aplicación instalada

No aceptar el traspaso está completo hasta que tengan:

  1. documentado todo lo recogido en la que no estaba cubierto a su satisfacción
  2. respondió a todas sus preguntas - una pregunta que no responderán cuando se le pidió repetidamente grita de algo están ocultando

Y obtenga sus direcciones de correo electrónico y números de teléfono. Aunque solo sea informal, probablemente estén dispuestos a ayudar si la mierda realmente golpea al fan ...

Buena suerte.

+0

¿Conseguir que el equipo original se quede y documente su trabajo? Estoy contigo, pero realmente, buena suerte con eso. –

+0

@Bernard Dy - Estoy de acuerdo en muchos proyectos, pero en términos de la pregunta formulada dice que hay documentación. –

1

Consulte "Software Requirements" y Software Requirement Patterns para obtener ideas sobre las preguntas que debe hacer al recopilar información sobre un proyecto. Creo que así como trabajarían para un nuevo desarrollo, también lo ayudarían a llegar a un acuerdo con un proyecto existente.

5

La mayoría de las entregas, quizás todas ellas, causarán la pérdida de mucha información. La única forma efectiva de realizar un traspaso que he visto es hacerlo gradualmente. Una forma de hacerlo es permitir que algunas personas clave de la fase uno permanezcan en el proyecto hasta la Fase Dos.

La solución extrema es deshacerse de todos los traspasos y comenzar a utilizar una mentalidad Ágil.

+0

A menos que todos los agitadores sean asesinados en un accidente automovilístico durante una fiesta en toda la compañía. –

+2

Esa es exactamente la razón por la cual los jugadores clave nunca deben viajar juntos :-) – Kasper

+3

¿Cómo te ayuda la agilidad mental a evitar los traspasos? – Bohdan

Cuestiones relacionadas