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

Estoy en medio de la coproducción de un documento de "enfoque de desarrollo" para recursos extraterritoriales a medida que avanzan en nuestro proyecto.

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

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 alguna guía decente sobre este tema?

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

En una de las compañías en las que trabajé, teníamos todo este enfoque orientado al proceso con muchos documentos (la mayoría de los cuales fueron solicitados por el Gerente de Proyecto). 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 desarrolladores reales.

Así que decidí ponerme en práctica con el objetivo específico de "ayudar a los desarrolladores". Lo más importante que comencé es recopilar las preguntas más básicas: las preguntas frecuentes reales .

Lo que aprendí es que seguir a la mayoría de las personas es importante cuando desean adoptar cierto proceso, y muchas cosas que pueden no tener una idea previa, pero que agradecerían de inmediato si comprenden 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 se debe organizar, compilar y publicar el código (en forma de archivos 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 un check-in aceptable y cuándo no, cuando 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 la liberación se declara hecha

3. Ejecución de la metodología: ¿somos ágiles, hacemos un diseño inicial y qué metodología utilizamos? Ahora dado esto, podría ser un arreglo para una empresa determinada. Ahora, para la mayoría de las personas, quieren saber cómo lo implementaremos para el proyecto en cuestión. 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, nos gustaría indicar "validar siempre los algoritmos críticos antes de construir sobre él" en una envoltura retráctil. Me centraría en la corrección e importancia de las características.

4. Responsabilidades de comunicación: definir cómo se hace la comunicación formal; esto no se hace si las personas específicas pueden hablar entre sí, sino que las personas deben tener una idea de lo que es lo suficientemente importante (problemas, decisiones de diseño, congelación de características) para anunciar o incluso debatido antes de proceder con la implementación.

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

Desearía comenzar cada proyecto con dichos documentos; sin embargo, no es del todo fácil. Pero lo importante es abordar todos los problemas relacionados con el comportamiento diario y las elecciones de los desarrolladores. Esto es muy útil cuando es necesario entregar múltiples lanzamientos al mercado.

Finalmente, también sugeriría que trate de ser lo más informal posible. Por lo general, a los chicos orientados al proceso no les gustan los documentos informales que potencialmente pueden malinterpretarse fuera del contexto. Sin embargo, debe hacerse de tal manera que conecte a los desarrolladores.

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 existen. Como mencionaron Victor Hurdugaci y Donal Fellows, el Plan de gestión de proyectos de software que escriba se (1) adaptará a sus necesidades y (2) se actualizará como un documento vivo a medida que evolucione la situación. Dicho esto, escribir uno desde cero puede ser difícil si nunca antes has escrito uno y no sabes qué más debería incluir.

Existe alguna orientación 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í . Creo que este plan es bastante pesado, pero es un lugar decente para obtener ideas, y es posible que necesite el peso extra 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 al que recurro con bastante frecuencia para proyectos de software tradicionales (no ágiles): Quality Software Project Management de Futrell, Shafer y Shafer.

Un documento de aproximación es un documento 'Ni aquí ni allá' . Este es un documento generalmente solicitado por los Gerentes de Proyecto (Gerentes de Proveedores) de organizaciones empresariales a los Gerentes de Proyecto (Gerentes de Desarrollo de Software) de las Organizaciones de Desarrollo de Aplicaciones de Software.

El propósito de este documento varía en función de las necesidades de la organización empresarial PM.

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.

de nuevo, la lista anterior es variable en función de las necesidades .. :)

Todavía no he visto literatura formal sobre dicho documento. si hay alguno de los autores estándar, Pressman, etc. comparte.

O me estoy perdiendo algo.

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

Como ya tiene algunos documentos, ese es su punto de partida. Pregúntese:

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

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

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

Solo una pista: querrá ajustar este documento con el tiempo, así que no escriba demasiado;)

Las prácticas de desarrollo cambian con el tiempo a medida que cambian sus requisitos y a medida que cambia el conjunto de idiomas, bibliotecas y marcos que utiliza. Este cambio es inevitable y significará que todo lo que ponga en papel quedará desactualizado (casi) de inmediato. ¿La forma de lidiar con esto? Guárdelo todo en una wiki y anime a todos los miembros de su equipo, tanto internos como externos, para ayudarlo a mantenerlo actualizado y relevante.

Una vez que ha dado el paso de un documento muerto a uno vivo, el debate sobre qué poner se vuelve menos urgente: simplemente pone lo que puede pensar ahora y vuelve a él más adelante. (Lo bueno es que no tendrá que entender todo para escribir el documento en primer lugar). También es posible que desee sembrar todo con el contenido desactualizado del antiguo documento de 80 páginas; eso te dará una gran cantidad de material de contorno, si nada más, evitando que tengas que pensar en escribir enormes cantidades de cosas aburridas.

Mantenga el documento corto. Use la estructuración de estilo de periódico: comience con detalles de alto nivel y siga con detalles. En lugar de incluir prácticas estándar, solo consúltelas y detalle las desviaciones del estándar.

1: Si ya está haciendo proyectos dentro de su empresa, participe en ese proceso. Tal vez incluso subcontratarles la gestión del desarrollo de su proyecto. No reinventes la rueda.

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

Confiar pero verificar. Estás tratando de eliminar la basura a largo plazo. Así que no dejes que hagan nada, sigue cualquier proceso que solo se pueda entregar al final. Insista en que se realice la entrega anticipada y se verifique antes de continuar.

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