¿Qué debe incluir en un documento de enfoque de desarrollo? [cerrado]

8

Estoy a punto de coproducir un documento de "enfoque de desarrollo" para recursos marinos a medida que avanzan hacia nuestro proyecto.

El documento más reciente (similar) que nuestra empresa ha utilizado tiene más de 80 páginas, y eso no incluye los estándares de codificación / documentos de convenciones.

Mi preocupación es que este documento no será consumible y, por lo tanto, fallará.

¿Qué debería estar en un documento de enfoque de desarrollo? ¿Hay directrices decentes sobre este tema?

EDITAR: el documento de enfoque de desarrollo debe detallar las prácticas y técnicas que los desarrolladores de software utilizarán mientras el software se diseña, construye y prueba.

    
pregunta Liggy 07.09.2011 - 14:00

7 respuestas

5

En una de las compañías en las que trabajé, tuvimos este enfoque orientado a todo el proceso con muchos documentos (la mayoría de los cuales fueron solicitados por el Project Manager). Sin embargo, a pesar de la extensión y las explicaciones, me di cuenta de que apenas servía para ayudar a las personas, los verdaderos desarrolladores.

Así que decidí retirarme con el objetivo específico de "ayudar a los desarrolladores". Lo más importante que comencé es recopilar la mayoría de las preguntas básicas: las preguntas frecuentes real .

Lo que aprendí es que seguir a la mayoría de las personas es importante cuando quieren adoptar cierto proceso y muchas cosas que quizás no tengan una idea previa pero que apreciarían de inmediato si entienden la lógica.

Estos son los temas clave que tal documentación debería ayudar:

  1. El proceso de desarrollo a implementación - ¿Cómo debe organizarse, compilarse, publicarse el código (en forma de DLL, bibliotecas, ejecutables, instaladores, páginas web y cómo se implementarán y probarán)?

  2. ¿Cómo debemos hacer el control de versiones? (y por qué si hay novatos). Comprenda cómo la estructura del repositorio, el código de conducta: cuándo es aceptable un check-in y cuándo no, cuándo se anuncia una versión / etiqueta, cómo se aplicará el parche, las fusiones y cuáles son las expectativas de limpieza cuando un parche o el lanzamiento se declara hecho

  3. Ejecutando la Metodología - ¿Somos ágiles, hacemos diseño por adelantado, qué metodología utilizamos? Ahora dado esto, podría ser una solución fija para una compañía determinada. Ahora, para la mayoría de las personas, quieren saber cómo lo vamos a implementar para el proyecto dado. Esto es muy específico sobre el proyecto que permitirá a las personas visualizar diferentes hitos y lo que es potencialmente importante. En un proyecto orientado a la investigación, desearíamos indicar "validar siempre los algoritmos críticos antes de construir sobre ellos" en un envoltorio de contracción. Me enfocaré en la corrección y la importancia de las características.

  4. Responsabilidades de comunicación - Definir cómo se hace una comunicación formal, esto no se hace si las personas específicas pueden hablar entre sí, pero la gente debe tener una idea de lo que es suficientemente importante (problemas, decisiones de diseño, congelación de funciones) para ser anunciado o incluso debatido antes de continuar con la implementación.

  5. Finalmente, todos debemos tener un entendimiento común de la calidad del código, el estándar de codificación y, en general, lo que consideramos correcto o por debajo del nivel de higiene.

Desearía comenzar cada proyecto con dichos documentos, sin embargo, no es muy fácil. Pero lo importante es abordar todos los problemas que se relacionan con el comportamiento cotidiano y las elecciones de los desarrolladores. Esto va más allá cuando se deben entregar múltiples lanzamientos al mercado.

Finalmente, también sugiero que trate de ser lo más informal posible. Por lo general, a los individuos orientados a los procesos no les gustan los documentos informales que pueden malinterpretarse fuera del contexto. Sin embargo, debe hacerse de tal manera que se conecte a los desarrolladores.

    
respondido por el Dipan Mehta 17.11.2011 - 08:54
1

Lo que usted llama el "documento de enfoque de desarrollo" generalmente se denomina Plan de gestión de proyectos de software . (También he oído que se llama Plan de proyecto de software o Plan de desarrollo de software .) Con esos términos, debería poder buscar en Google algunas muestras que están disponibles. . Como lo mencionaron Victor Hurdugaci y Donal Fellows, el plan de gestión de proyectos de software que usted escriba (1) se adaptará a sus necesidades y (2) se actualizará como un documento vivo a medida que la situación evolucione. Dicho esto, escribir uno desde cero puede ser difícil si nunca lo has escrito antes y no sabes qué más debería hacer.

Hay una guía a través del Estándar IEEE 1058 (Estándar IEEE para Planes de Gestión de Proyectos de Software, 1998). Hay una copia del estándar publicado aquí . Considero que este plan es bastante pesado, pero es un lugar decente para obtener ideas, y es posible que necesite el peso adicional si lo desea todo por escrito para un equipo que está en alta mar. También hay un esbozo bastante bueno, y una gran narrativa sobre cómo planificar proyectos de software, en un libro que recurro a menudo para proyectos de software tradicionales (no ágiles): Quality Software Project Management por Futrell, Shafer y Shafer.

    
respondido por el Kendrick 17.11.2011 - 03:32
1

Un documento de aproximación es un documento 'Ni aquí ni allá' . Este es un documento que generalmente solicitan los gerentes de proyectos (gerentes de proveedores) de organizaciones empresariales a los gerentes de proyectos (gerentes de desarrollo de software) de organizaciones de desarrollo de aplicaciones de software.

El propósito de este documento varía según las necesidades del PM de la organización empresarial.

Puede contener arquitectura hw, funciones del sistema, planes de comunicación, planes de configuración, planes de carga de recursos, pila de tecnología, arquitectura de aplicaciones, etc.

nuevamente, la lista anterior es variable según las necesidades ... :)

todavía no he visto literatura formal sobre tal documento. Si hay alguno de los autores estándar, Pressman, etc., comparte ..

o me estoy perdiendo algo.

    
respondido por el Hemant 22.03.2012 - 13:28
0
  

El documento más reciente (similar) que nuestra empresa ha utilizado tiene más de 80 páginas, y eso no incluye los estándares de codificación / documentos de convenciones.

Dado que ya tiene algunos documentos, ese es su punto de partida. Pregúntate a ti mismo:

  1. ¿Qué es útil en este documento?
  2. ¿Qué falta?
  3. ¿Por qué usaría (n't) este documento?

Después de obtener las respuestas, corte lo que no desea y agregue las partes faltantes.

El contenido real del documento depende de los recursos disponibles y creo que es difícil especular utilizando la información proporcionada.

Solo una sugerencia: querrá ajustar este documento a lo largo del tiempo, así que no escriba demasiado;)

    
respondido por el Victor Hurdugaci 09.09.2011 - 13:11
0

Las prácticas de desarrollo cambian con el tiempo a medida que cambian sus requisitos y a medida que cambian el conjunto de idiomas, bibliotecas y marcos que usa. Este cambio es inevitable y significará que cualquier cosa que ponga en papel quedará desactualizada (casi) inmediatamente. ¿La manera de lidiar con esto? Manténgalo todo en una wiki y anime a todos en su equipo, tanto internos como externos, para que lo mantengan actualizado y relevante.

Una vez que haya dado el paso de un documento muerto a uno vivo, el debate sobre qué colocar se vuelve menos urgente: solo ingrese lo que pueda pensar ahora y vuelva a él más adelante. (Lo bueno es que no tendrá que entender todo para escribir el documento en primer lugar). Es posible que también desee agregar todo el contenido desactualizado del documento antiguo de 80 páginas; eso te dará una gran cantidad de material de boceto, y te evitará tener que pensar en escribir enormes montones de cosas aburridas.

    
respondido por el Donal Fellows 08.11.2011 - 15:57
0

Mantenga el documento corto. Utilice la estructuración de estilo de periódico: comience con detalles de alto nivel y siga con detalles específicos. En lugar de incluir prácticas estándar, solo haga referencia a ellas y detalle las desviaciones de la norma.

    
respondido por el PenFold 02.12.2011 - 23:05
0

1: Si ya está realizando proyectos dentro de su empresa, póngase de acuerdo con ese proceso. Tal vez incluso subcontratar la gestión de su proyecto de desarrollo a ellos. No reinventes la rueda.

2: Si aún no realiza el desarrollo en su casa, insista en que el contratista que está utilizando tenga una buena metodología para los proyectos. Entonces usa esa metodología.

Confía pero verifica. Usted está tratando de eliminar la basura a largo plazo. Así que no dejes que hagan nada, sigue cualquier proceso con solo entregable al final. Insista en que se hagan y verifiquen las entregas tempranas antes de continuar.

Más allá de eso, básicamente lo hago en @Dipan

    
respondido por el Paul 06.12.2011 - 14:58

Lea otras preguntas en las etiquetas