Planear un proyecto (CMMI)
El resultado deseado de la planeación de un proyecto es un plan que incluya un ámbito, una programación, un presupuesto, un plan de administración de riesgos, y un compromiso y aprobación de todas las partes interesadas. Con un plan del proyecto acordado, lo que se desea es progresar con el análisis, el diseño, el desarrollo, las pruebas y, finalmente, la entrega.
Puede reducir riesgos utilizando un método de desarrollo iterativo. Las iteraciones permiten la demostración de un producto que funciona parcialmente al final de cada iteración y actuar en los comentarios derivados de esa demostración. Por lo tanto, el plan proporciona una forma general y está sujeto a revisión y perfeccionamiento antes del inicio de cada iteración.
Recopilar y modelar los requisitos
Esta actividad consiste en analizar lo que el sistema debe realizar con las partes interesadas del negocio, posibles usuarios y expertos en la materia. Es importante conocer el contexto del negocio. Si le han solicitado que escriba una aplicación para oficiales de policía, es de gran ayuda conocer su jerga, sus procedimientos y sus reglas.
Los modelos UML son una herramienta útil para expresar y pensar en relaciones complejas. Puede obtenerlas en Visual Studio y vincularlas a otros documentos y a elementos de trabajo de Team Foundation. Para obtener más información, vea Crear modelos de los requisitos de los usuarios.
Actualice y perfeccione el modelo de requisitos a lo largo del proyecto. Según se aproxime cada iteración, agregue más detalles a los aspectos del modelo que son relevantes para esa iteración. A partir del modelo, puede derivar pruebas de comprobación.
Para obtener más información, vea Desarrollar requisitos y Desarrollar pruebas en un modelo.
Crear requisitos del producto incrementales
Los requisitos que recopile de los clientes no son directamente adecuados para programar el desarrollo incremental. Por ejemplo, para clarificar el procedimiento que un usuario debe seguir al comprar un producto en un sitio web, podría haber escrito una serie detallada de pasos: el cliente examina el catálogo, agrega el elemento al carro de la compra, comprueba el carro, proporciona la dirección y paga; el almacén programa la entrega; etc. Estos pasos, o un diagrama de actividad equivalente, no son requisitos incrementales.
En su lugar, el primer incremento del sistema podría ofrecer solo un elemento para la venta, entregarlo solamente a una dirección, y realizar solo una transacción de prueba con el servicio de pago. El segundo incremento podría proporcionar un catálogo formado por una lista simple. Incrementos posteriores podrían agregar la opción de envolver para regalo la compra realizada o de solicitar catálogos proporcionados por diferentes proveedores. Algunos incrementos podrían estar relacionados con la calidad de servicio, como la capacidad de administrar 1000 clientes en lugar de uno solo.
En otras palabras, los primeros incrementos deben ejecutar los casos de uso principales de extremo a extremo y agregar gradualmente funciones a lo largo del proceso.
Si trabaja con un producto existente, el principio es el mismo, pero se empieza desde las funciones existentes. Si no está familiarizado con el diseño interno, puede que tenga dificultades para estimar el costo de las actualizaciones. Merece la pena ser liberal con las estimaciones de los cambios anteriores.
Para obtener más información, vea Desarrollar requisitos.
Escribir y editar los requisitos del producto
Registre los requisitos del producto incrementales como elementos de trabajo de requisito en Team Foundation y establezca el tipo de requisitos en Característica. Puede crear un trabajo pendiente de requisitos mediante TWA o Team Explorer. Si tiene varios elementos de trabajo que desee crear al mismo tiempo, puede utilizar Excel.
Estimar los requisitos del producto
El equipo de desarrollo debe estimar el trabajo necesario para desarrollar cada requisito del producto. La estimación se debe establecer en horas, en el campo Estimación original del elemento de trabajo.
En los primeros compases del proyecto, solo se necesita una estimación aproximada.
Divida los requisitos del producto en otros de menor entidad. Idealmente, cada requisito del producto necesitará solamente unos días de tiempo de desarrollo.
Asignar los requisitos del producto a las iteraciones
Los representantes de las partes interesadas del negocio y el equipo de desarrollo deben trabajar juntos para asignar requisitos del producto a las iteraciones. Normalmente, esto se realiza en una reunión, donde se comparte o se proyecta la vista de Office Excel de la consulta de requisitos del producto.
La asignación se completa utilizando la siguiente información:
Prioridad del requisito. Vea las notas de la siguiente subsección.
Costo estimado. Dados el número de miembros del equipo y la extensión de la iteración, cada iteración tiene solo un número fijo de horas disponibles para el desarrollo. Además, un número significativo de esas horas se utilizará para planear la iteración y para otras tareas no implicadas directamente en el desarrollo.
Dependencias entre los requisitos del producto. En una serie incremental de requisitos, los requisitos más simples se deben abordar antes de introducir mejoras en la misma área.
Se puede definir el requisito en un elemento de trabajo especificando otros tipos de información, tal y como se muestra en las siguientes ilustraciones:
.png "Requirement work item form")
Algunas instrucciones sobre asignación de prioridades
Existen muchos esquemas detallados para la asignación de prioridades. Examinaremos algunos de ellos al considerar la planeación de iteraciones. Por el momento, en el nivel de proyecto, se incluyen algunas instrucciones que pueden ser útiles para ayudar a administrar el riesgo y optimizar el valor añadido.
Dé prioridad a los escenarios de extremo a extremo mínimos.
Propóngase como objetivo lograr un escenario de extremo a extremo simple en la fase más temprana posible del proyecto. Posteriormente, agregue más características a las diferentes partes del escenario. Esta práctica garantiza que las principales funciones de la plataforma y las ideas principales en los requisitos se pongan a prueba cuanto antes.
En contraposición, no divida la programación en función de la arquitectura. Una programación que complete primero la base de datos, después la lógica comercial y, a continuación, la interfaz de usuario requerirá probablemente una gran cantidad de modificaciones para integrar las partes al final. Del mismo modo, no se recomienda una división horizontal como {componente de ventas; componente de almacén; componente de pago}. Probablemente generaría un sistema magnífico para la venta en Internet pero la falta de tiempo antes del negocio significa un medio para obtener dinero de los clientes. Solo se pueden programar componentes completos para iteraciones posteriores si son realmente complementos opcionales.
Dé prioridad al riesgo técnico.
Si un escenario incluye un elemento con riesgo técnico, desarróllelo en la fase más temprana de la programación. Contemple el riesgo de un "error temprano". Si hay algo que no se puede lograr, es preferible saberlo cuanto antes en el proyecto para que se pueda cancelar o reemplazar con un enfoque alternativo. Por lo tanto, conviene clasificar según su prioridad los requisitos con riesgo técnico en las primeras iteraciones.
Dé prioridad a la reducción de incertidumbre.
Las partes interesadas del negocio no estarán convencidas de algunos requisitos. No es fácil predecir qué comportamiento del producto funcionará mejor en el contexto del negocio. Dé prioridad al trabajo cuya probabilidad de reducir incertidumbres sea mayor. Esto se puede lograr desarrollando una versión más simple del escenario con que los usuarios pueden experimentar. Aplace el escenario completo a una iteración posterior, en que se puedan tener en cuenta los resultados de estos experimentos.
Dé prioridad a los requisitos de más valor.
Si es posible, intente establecer una función que relacione la oportunidad con el costo de aplazamiento para cada escenario. Utilice esto para determinar los requisitos que puedan aportar más valor a los clientes lo antes posible. Dé prioridad a estos requisitos en las primeras iteraciones. Esto puede proporcionarle la opción de lanzar pronto un producto parcial.
Agrupe los escenarios que sean comunes a varios roles.
Si tiene escenarios de utilidad para dos o más roles, agrúpelos. Clasifíquelos por el número de roles que requieren el escenario. Dé prioridad a los escenarios aplicables a un mayor número de roles en las primeras iteraciones.
Clasifique los roles.
Los roles representan segmentos de mercado o grupos de usuarios. El personal comercial o los propietarios del negocio deben poder articular la prioridad de dichos segmentos o grupos basándose en la utilidad que se va a entregar o en el valor del segmento. Si los segmentos o los grupos de usuarios se pueden clasificar en función de su prioridad, muestre esta característica enumerando los roles para cada segmento por rango. Identifique los escenarios para los roles con un rango superior y asígneles la correspondiente prioridad en las iteraciones más tempranas en la programación.
En general, es deseable dar prioridad a la reducción de riesgo por la posibilidad de error. Es deseable dar prioridad a la funcionalidad común porque es probable que sea necesaria e improbable que cambie. Es deseable dar prioridad a los requisitos de más valor. Es deseable habilitar la opción de un lanzamiento temprano del producto a un subconjunto de roles dando prioridad a todos los escenarios necesarios para satisfacer las necesidades de cualquier rol.
Planear las pruebas
La estimación de trabajo para cada requisito debe incluir el esfuerzo necesario para probar el requisito en cuestión, ya sea manualmente o mediante una prueba automatizada.
Antes de que se considere completado, cada requisito del producto se debe vincular a un conjunto de elementos de trabajo de caso de prueba que muestren en conjunto si se ha cumplido el requisito, y se deben superar las pruebas.
Al crear o revisar los requisitos del producto, debe actualizarse el correspondiente plan de pruebas.
Revisar los requisitos del producto
Revise esta actividad antes de cada iteración para tener en cuenta los requisitos nuevos y revisados, así como las prioridades y estimaciones revisadas. Habrá más revisiones en las primeras iteraciones.
Después de las primeras iteraciones, los miembros del equipo de desarrollo tendrán más confianza a la hora de realizar las estimaciones. Deben contemplar las estimaciones para las dos iteraciones siguientes y revisar los campos Estimación original de los requisitos asignados a esas iteraciones.