¿Cómo medir la integridad del proyecto? [cerrado]

Question

¿Hay medidas formales / informales de la comparación de la funcionalidad completa frente a los requisitos iniciales de un proyecto. En concreto, mi objetivo es identificar los requisitos perdidas desde el principio en un proyecto. Después de haber pasado por muchas ágil / artículos y libros de metodología scrum, una manera de hacer esto sería una revisión requisitos durante una "revisión del sprint", pero me preguntaba si había algún otro técnicas / herramientas por ahí.

Gracias,

Answer 1

¿Hay medidas formales / informales de la comparación de la funcionalidad completa frente a los requisitos iniciales de un proyecto.

La palabra (s) que busca es "Criterios de hecho". Tiene un significado más profundo que las propias palabras, en el mundo ágil. A menudo es el primero que debe ser fijado en una organización ágil, si se encuentra que falta. A continuación (al final) es un enlace a un artículo que lo explica con más detalle.

La mayoría de los equipos utilizan ágiles historias de los usuarios como sus "requisitos iniciales". La historia de usuario sería sus requisitos iniciales que sería suficiente para que el equipo comenzó. La medida utilizada, debe ser lo que la mayoría de los equipos de llamada, "los Criterios de hecho". Cada historia de usuario debe tener un criterio de hecho. Para, por ejemplo. Con el fin de llamar a un atraso hecho, éstas lista de cosas que necesitan ser hechas. Durante el ajuste de esto, no se preocupe acerca de cómo se llevaría a cabo, solamente Lo que hay que hacer.

Durante la Revisión del Sprint, el equipo haría un mostrar y contar del software de trabajo, y si cumple con los criterios hecho esto, el PO debería aprobar que sea oficialmente marcado hecho.

¡Por supuesto, a veces las historias de los usuarios han cambiado los criterios de hacerlo, especialmente para los nuevos equipos o proyectos, sino que es perfectamente normal, debido a que un signo de una buena historia de usuario es que es negociable. Los criterios pueden ser Hecho ligeramente modificados después de obtener la aprobación del equipo. Equipos rara vez se desaprueban estos, a menos que el cambio provoca un aumento dramático en la complejidad del trabajo a realizar.

Para resumir:

requisitos iniciales por ejemplo, historias de los usuarios necesitan tener un "qué" necesita ser Criterios hecho". Si algo se pierde y descubrió durante el Sprint del PO puede cambiar los criterios hechos de una historia de usuario después de obtener una aprobación del equipo.

durante las revisiones de Sprint el software de trabajo se puede medir según los criterios de hecho, y si está a la altura, la historia de usuario puede ser llamado hecho.

http://scrumalliance.org/articles/105- ¿qué-es-definición-of-hecho-DoD

Answer 2

En un enfoque ágil, se espera que los cambios en los requisitos y se considera saludable. La capacidad de respuesta al cambio se considera más importante que seguir un plan.

Una revisión de sprint es un lugar para el intercambio de ideas y los nuevos requisitos. Usabilidad pruebas también ayudan. Sin embargo, lo que ayuda a los más pesada es el uso del software por un equipo de control de calidad y / o usuarios reales.

Si le pasó a ser el uso de JIRA y GreenHopper para la gestión de sus necesidades (como cuentos), es posible encontrar una búsqueda muy útil para las historias creadas después de una fecha determinada. Encontrar los requisitos modificados sería más interesante.

Answer 3

Es el software nunca completa? Obviamente, el punto de referencia real para la integridad es una vista de la mente de alguien de lo que el software de debe do.

Tratar de medir contra la imagen mental de una persona está en última instancia, va a ser difícil y hay un método formal será siempre realmente hacerlo bien. Lo único que se puede medir en contra son los requisitos que le dan. Se puede ver en los requisitos de la ONU con su dirección, pero nunca se puede medir la distancia de lo que no te dije.

El mensaje que he recibido de la escuela de pensamiento ágil es que la medición de integridad es una especie de pérdida de tiempo -. Que es realmente la pregunta equivocada

Por ejemplo, con el scrum, que hacen un atraso prioritaria de todos los requisitos y acaba de empezar a trabajar en la lista. Cuando el dinero / el deseo de que acabe ... se detiene.

Answer 4

Si vas al ágil / scrum ruta que da a entender, a continuación, en general, usted querrá romper el proyecto en pequeñas unidades discretas de esfuerzo. Un proyecto contiene epopeyas (o es una epopeya), una epopeya contiene historias, una historia contiene tareas. (Una tarea debe ser idealmente de 4-8 horas de trabajo. Algo que alguien puede hacer en un día de trabajo.)

Como se ha completado cada historia, debe ser probado y verificado. En general, esto no se hace para tareas porque a menudo una sola tarea no puede ser probada por un usuario hasta que otras tareas de la historia se han completado. Un usuario no puede esperar a la prueba "Escribir un método para conservar un objeto de la base de datos", sino que en lugar de prueba "Cuando se hace clic en este botón, el orden se conserva a la base de datos y el usuario se muestra una cesta de la compra actualizado para incluir re-calculado impuestos y envío ".

Esta prueba / verificación es no hecho por el desarrollador. Se debe ser verificada mediante quien está a cargo del producto / proyecto o un delegado del mismo. El desarrollador de forma natural pondrá a prueba la forma en que él o ella lo escribió, esperando que funciona de esa manera. Si algo fue mal interpretado en los requisitos, que acaba de ser mal interpretado de nuevo.

A medida que cada historia se verifica tan completa, que es un paso discreto y apreciables para la finalización del proyecto. (Medible por cuántas tareas se trataba y por lo tanto la cantidad de trabajo se completó hacia la suma total.)

Tenga en cuenta que cualquiera de estas mediciones pueden cambiar de un sprint a la siguiente. Si la alta dirección está en busca de una sola hoja de ruta con los pasos completable en el camino todo el camino hasta el final del proyecto, pueden ser malentendido un concepto fundamental en el desarrollo ágil. Las historias más abajo de la línea no se han definido completamente todavía. Pueden implicar más o menos trabajo que originalmente estimado, basado en el desarrollo realizado sobre (y los cambios realizados a) las historias inmediatas.

Una forma de tratar de abordar el concepto de historias de fluidos y cambiantes requisitos es no pensar en términos de "proyectos", pero sólo epopeyas e historias. Estas unidades discretas deben ser totalmente viable y comprobable por su propia cuenta (aunque algunos, por supuesto, tiene otros como pre-requisitos). Cambios en las prioridades pueden mover las historias en torno a voluntad. no necesita un "proyecto" a ser "en suspenso" si las prioridades cambio, sus historias son simplemente trasladados a la cartera de pedidos en lugar de otras historias.

La idea es que la dirección es la dirección en la que va al lado, no sólo le da una lista de destinos y esperando, tiene acceso a ellos en el orden correcto.

En este sentido, la "integridad" de un "proyecto" pierde casi por completo su significado. ¿Cuánto es "completa" depende de quien posea el producto / proyecto. Estas pueden añadir a la misma o eliminar de ella a voluntad, las prioridades de cambio fácilmente, etc. Si quieren saber "cuándo vamos a llegar al destino A?" a continuación, que depende de ellos. Usted ha dado a las estimaciones de cuánto trabajo está implicado en cada paso del camino, que depende de ellos para guiarlo en lo que creen que es la mejor dirección para llegar allí, mientras se proporciona el trabajo.