¿Cómo puedo averiguar qué metodología de programación (si hay alguna) que estamos usando?

Question

Mi grupo se mudará pronto a Team Foundation Server. En realidad, estoy encabezando el esfuerzo.

Una de las cosas que puede decidir es qué metodología está utilizando: Agile, CMMI, etc.

La cosa es que no tengo idea de qué metodología usamos. Con lo que quiero decir, no estamos usando activamente uno. Y no estoy lo suficientemente familiarizado con Agile u otros métodos para saber qué, si alguno, se aplica a la forma en que lo estamos haciendo.

¿Existe alguna metodología predeterminada? Como en el caso, si pasamos por un proceso muy contundente (obtener requisitos, código, prueba, pasar a control de calidad, tener prueba de control de calidad, pasar a producción) ¿hay algún nombre para eso?

Y como beneficio adicional, con TFS, ¿cuál es la penalidad por elegir el equivocado desde el principio? ¿Qué tan difícil es cambiar de marcha más tarde si decidimos volvernos ágiles o algo así?

Answer 1

No hay una penalización importante por cambiar las metodologías de método: simplemente elige una predeterminada cuando la instala, y puede elegir la que usará para cualquier proyecto dado. De hecho, solo tiene que ver con cómo TFS configura inicialmente la página del proyecto Sharepoint: puede agregar lo que quiera a su página una vez que se haya creado, por lo que si decide cambiar la metodología de un proyecto, no es difícil de hacer.

Para los dos que TFS ofrece de inmediato (Agile y SCCM / Waterfall), realmente es una cuestión de su proceso: ¿libera '' temprano y a menudo ``, con paquetes más pequeños que se lanzan a medida que los errores entran, o lo hacen ejecuta sus proyectos en iteraciones grandes, con un lanzamiento mucho más infrecuente, pero con lanzamientos de hitos obvios?

Una pregunta que hacer (aunque no es exactamente precisa, pero siempre me ayuda): ¿El producto tiene números de versión que sean significativos para los usuarios finales? Por ejemplo, muchos sitios web son ágiles, ya que constantemente lanzan mejoras y parches, y no suelen tener grandes mejoras / revisiones, mientras que un producto como MS Office tiene un número de versión significativo (2003, 2007, etc.), que es más probablemente SCCM.

Si no tiene una metodología establecida, es un buen momento para desarrollarla: decida qué ciclo de lanzamiento tiene sentido para usted, cree un proyecto en cada una y revise qué TFS configura para usted automáticamente. Haga los indicadores de progreso y ¿Las páginas de Sharepoint tienen sentido? ¿Falta algo obvio?

Answer 2

Si no puede discernir una metodología, está utilizando una metodología ad-hoc. Puede ser similar a una metodología existente (por accidente). Sin embargo, tenga en cuenta que seguir una metodología no es lo mismo que tener éxito. He visto una gran cantidad de proyectos pesados ??de metodología que fallaron, y un montón de "asiento del pantalón". los proyectos serán éxitos rotundos (si tal vez necesiten un poco de refactorización cuando el polvo se haya asentado).

Cambiar las metodologías depende de su cultura más que nada. Las instituciones tienden a resistir el cambio y a algunos individuos. Sin embargo, nuevamente depende de la situación: si la situación existente obviamente se rompe, una institución a veces puede hacer cambios rápidos que sorprenden a todos.

Algunas metodologías son "más pesadas" que otros: es más difícil cambiarlos de un lado a otro. Incluso Test Driven Development es `` pesado '' porque adoptarlo después del hecho significará agregar un lote de pruebas al código anterior. La mayoría de las transiciones del mundo real simplemente agregan las pruebas a medida que los archivos se editan por otros motivos. Del mismo modo, pasar de TDD a un estilo en cascada requeriría documentar un lote de código en grandes carpetas en desuso.

Answer 3

El método más básico tiende a ser su método iterativo o "método en cascada". porque solo vas de un paso a otro. Sin embargo, ya no parece ser muy popular.