Estimación de Proyectos de Software: Factores Clave
•Télécharger en tant que PPTX, PDF•
2 j'aime•705 vues
La cara oculta de las diferencias en la estimación de proyectos
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Estimación de Proyectos de Software: Factores Clave
Similaire à Estimación de Proyectos de Software: Factores Clave (20)
Plus de Daniel Laco
Plus de Daniel Laco (8)
Estimación de Proyectos de Software: Factores Clave
- 1. Estimación de Proyectos de Software La cara oculta de las diferencias Patricia Scalzone Presidente - VEMN SA patricias@vemn.com.ar Daniel Laco Director Ejecutivo - VEMN SA daniell@vemn.com.ar
- 2. Temario • El problema • Técnicas • … y las diferencias? • Contratos
- 3. Se acuerdan?
- 4. El problema “endémico” de la industria • Sobreestimación • Subestimación • Imposible de estimar
- 5. Registros de Estimación de la Industria Tamaño en Puntos de Función A Fallados (y Aprox. Líneas de código) Temprano Tiempo Tarde (Cancelados) 10 FP (1.000 LOC) 11% 81% 6% 2% 100 FP (10.000 LOC) 6% 75% 12% 7% 1.000 FP (100.000 LOC) 1% 61% 18% 20% 10.000 FP (1.000.000 LOC) <1% 28% 24% 48% 100.000 FP (10.000.000 LOC) 0% 14% 21% 65%
- 6. Qué es estimación? Es una predicción de cuán largo es un proyecto o cuánto va a costar
- 7. Pero... • Tenemos los objetivos del negocio: – Necesitamos tener la Versión 2.1 lista para la Expo de Mayo – Necesitamos tener la Release estabilizada para las ventas de vacaciones. – Necesitamos tener las funciones listas para el 1 de Julio para cumplir con requisitos de regulaciones del gobierno. – Debemos limitar el costo del próximo Release a 2$ millones, porque es el presupuesto máximo que tenemos. • Son deseables o imperativos, pero no necesariamente alcanzables
- 8. Definiciones de “Buena Estimación”
- 9. Técnicas de Estimación • Abordajes Tradicionales – Líneas de Código – Function Points – Use Case Points • Abordajes Ágiles – Planning Poker – Story Points
- 10. Ballpark Figure O “el rango del proyecto” (método oscilante)
- 12. Proyecto: Feliz Daniel Cliente: El Mejor Estimadores Maxi Andres Total Estimadores 3 Ronda 1 Ronda 2 Grupo Tarea Subtarea Detalle Daniel Maxi Andres Daniel Maxi Andres Sección 1 2 1 Categorías 2 2 2 Ítems Attachs 100 100 40 SeccionAtributos ABMs CategriasAtributos Atributos Back End Usuarios 4 2 8 Niveles de Autorización 8 13 8 Usuarios / Niveles de Admin de Seguridad 13 20 3 Autorización Pantalla de publicación de Proceso de publicación Manejo de Archivos 20 20 13 producto Niveles de autorización 13 20 8 Productos 3 2 5 Soluciones de producción 3 2 5 Recursos de Venta 3 2 5 UI Visualización Visor MHT 3 2 3 Front End Árbol de navegación de 3 3 5 productos Búsqueda Rápida 3 3 5 Buscador de productos Búsqueda Avanzada Filtro Genérico 13 13 20 Localización Multi-idioma 20 20 20 Totales 212 226 151 0 0 0 Ronda 1 Ronda 2 Daniel 212 0 Maxi 226 0 Andres 151 0 Mínimo 151 0 Promedio 196 0 Máximo 226 0
- 13. Story Points (Dog Points)
- 14. Módulo Tipo Nombre Complejidad DIAGNOSTICO Competencia / Posición competitiva Evualuacion (Criterios) ALTA DIAGNOSTICO Menú Principal Diagnóstico Diagnostico Interactivo ALTA Diagnóstico / Resumen del Diagnóstico / DIAGNOSTICO Conclusiones Conclusiones MEDIA DIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (1) BAJA DIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (2) BAJA Icono en el formulario FrmDIA002 DIAGNOSTICO (Gráfico) Grafico de Ventas y Rentabilidad (3) ALTA Activación de Indicadores, Reglas e DIAGNOSTICO Informes Activacion de Indicadores, reglas e informes MEDIA Diagnóstico / Resumen del Diagnóstico / DIAGNOSTICO Resumen Resumen de diagnostico - Puntos clave MEDIA Diagnóstico / Resumen del Diagnóstico / DIAGNOSTICO F.O.D.A Analisis F.O.D.A ALTA DIAGNOSTICO icono en el formulario FrmDIA002 (lupa) Informe de indicadores estrategicos (PivotTable) MEDIA Administración del Sistema / Carga de DIAGNOSTICO Preguntas del Diagnóstico Ingreso de CheckList ALTA ARQUITECTURA ALTA Ponderación Complejidad Baja 4 Media 5 Alta 20 Testing % 30 Gestión de Proyecto % 10 Implementación % 30 % Riesgo 30
- 15. … y las diferencias dónde están? • En la administración de riesgos • En Ítems que se pierden en las estimaciones
- 17. Cómo seguimos?
- 18. Requerimientos Funcionales Factor Baja Media Alta Setup/Instalación Conversiones de datos Interoperabildiad del Individual Otros sistemas de la misma Heterogéneo. Proyecto tecnología Sistemas de diferentes tecnologías Procesamiento complejo interno
- 19. Requerimientos No Funcionales Factor Baja Media Alta Interoperabilidad Mantenibilidad Performance Poco exigentes o Exigencia de rendimiento Exigencia de rendimiento muy sin relevancia estandar exigente Portabilidad Confiabilidad Código que debe ser rehusado Seguridad Capacidad de Supervivencia Facilidad de uso Sistema Distribuido Nro potencial de usuarios < 10 usuarios 10 a 50 usuarios > 50 usuarios Concurrencia
- 20. Requerimientos No Funcionales Factor Baja Media Alta Características especiales de seguridad Tecnología Estandar, probada Probada, pero nueva en la Novedosa, sin antecedentes y conocida en la organización. organización Testeabilidad Ambiente Ambiente con interacción de Redes y conexiones Client/Server varios servidores. Ej: complejas. SO dispares, Arquitectura SOA organización del cliente restrictiva. Tecnologia nueva y sin experiencia. La Seguridad como un factor del ambiente de prueba (Ej. X509) Afecta a Sistemas en No Si, pero hay franjas de tiempo El sistema es critico, de 7 x 24 Producción donde se pueden hacer actualizaciones con parada del sistema
- 21. Temas del Proyecto - I Factor Baja Media Alta Estabilidad de los Estables y Relativa variacion y definición Inciertos y con mucha requisitos definidos pobre variación Tiempo de Entrega Menos de 3 meses 3 a 9 meses Más de 9 meses Procesar los pedidos de cambios. Administrar el seguimiento de Bugs Corregir los bugs Coordinación de la Gestión. Reuniones
- 22. Temas del Proyecto - II Factor Baja Media Alta Creación de datos de test Instalación de versiones de prueba en locaciones del cliente Interactuar con Clientes o Usuarios. Revisar planificaciones, estimaciones, arquitectura, diseños, planes de puesta en marcha, casos de test, etc.
- 23. Temas del Proyecto - III
- 24. Temas del Equipo Factor Baja Media Alta Grupo de Trabajo Con experiencia y Poca experiencia y Sin experiencia en proyectos capacitación en capacitación en proyectos similares proyectos similares similares Mejora de la Pruductividad Mentoring de nuevos miembros.
- 25. Temas del Cliente - I Factor Baja Media Alta Facilidad de entrenamiento de usuarios Cliente Conocido y con buenos Cliente nuevo, con buenas Desconocido, o conocido con antecedentes referencias o relaciones conocidas problemas en proyectos anteriores Interlocutores del Buena formación técnica y Formación Media y regular en Desconocido, o conocido con Cliente en gestión de proyectos. gestión de proyectos. Regular problemas en proyectos anteriores Buena actitud de ayuda y asistencia en resolución de servicio. problemas Impacto en Mínimo. Cambios moderados en Cambios significativos en Organización organización, cultura, métodos de organización, cultura, métodos de trabajo trabajo
- 26. Temas del Cliente - II Factor Baja Media Alta Usuarios Pocos usuarios Un Departamento o Unidad Varios Departamentos o Involucrados de Negocio Empresas Impacto Externo Afecta principalmente Afecta moderadamente a Afecta a terceros no al Departamento otros Departamentos, involucrados, ciudadanos, afectado Organizaciones o Clientes organizaciones Tecnología Estandar, probada y Probada, pero nueva en la Novedosa, sin antecedentes conocida en la organización. organización Tiempo de Disponibilidad exclusiva El interlocutor tiene otros El interlocutor mantiene Respuesta del en el proyecto proyectos, pero este tiene muchos proyectos en Cliente prioridad simultaneo. El interlocutor no esta asignado al proyecto, solo colabora
- 27. Actividades de No Desarrollo Vacaciones Reuniones de la empresa Feriados Reuniones del Departamento Días de enfermedades Configuración de nuevos puestos de trabajo Entrenamiento Instalación de nuevas herramientas Fines de Semana Resolución de problemas de Software y Hardware
- 28. La planificación tradicional trata al desarrollo de software como una actividad predecible El desarrollo de software es una actividad de creación y transmutación de conocimiento.
- 30. Resumen • El problema • Técnicas • … y las diferencias? • Contratos
- 32. Muchas gracias por su participación Patricia Scalzone Presidente - VEMN SA patricias@vemn.com.ar Daniel Laco Director Ejecutivo - VEMN SA daniell@vemn.com.ar
Notes de l'éditeur
- The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
- The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
- 3.2 Details on the Software Industry's Estimation Track RecordThe software industry's estimation track record provides some interesting clues to the nature of software's estimation problems. In recent years, The Standish Group has published a biennial survey called "The Chaos Report," which describes software project outcomes. In the 2004 report, 54% of projects were delivered late, 18% failed outright, and 28% were delivered on time and within budget. Figure 3-2 shows the results for the 10 years from 1994 to 2004.Figure 3-2: Project outcomes reported in The Standish Group's Chaos report have fluctuated year to year. About three quarters of all software projects are delivered late or fail outright. What's notable about The Standish Group's data is that it doesn't even have a category for early delivery! The best possible performance is meeting expectations "On Time/On Budget"—and the other options are all downhill from there.Capers Jones presents another view of project outcomes. Jones has observed for many years that project success depends on project size. That is, larger projects struggle more than smaller projects do. Table 3-1 illustrates this point.Table 3-1: Project Outcomes by Project Size Size in Function Points (and Approximate Lines of Code)EarlyOn TimeLateFailed (Canceled)10 FP (1,000 LOC)11%81%6%2%100 FP (10,000 LOC)6%75%12%7%1,000 FP (100,000 LOC)1%61%18%20%10,000 FP (1,000,000 LOC)<1%28%24%48%100,000 FP (10,000,000 LOC)0%14%21%65%Source: Estimating Software Costs (Jones 1998).As you can see from Jones's data, the larger a project, the less chance the project has of completing on time and the greater chance it has of failing outright.Overall, a compelling number of studies have found results in line with the results reported by The Standish Group and Jones, that about one quarter of all projects are delivered on time; about one quarter are canceled; and about half are delivered late, over budget, or both (Lederer and Prasad 1992; Jones 1998; ISBSG 2001; Krasner 2003; Putnam and Myers 2003; Heemstra, Siskens and van derStelt 2003; Standish Group 2004).The reasons that projects miss their targets are manifold. Poor estimates are one reason but not the only reason. We'll discuss the reasons in depth in Chapter 4, "Where Does Estimation Error Come From?"How Late Are the Late Projects?The number of projects that run late or over budget is one consideration. The degree to which these projects miss their targets is another consideration. According to the first Standish Group survey, the average project schedule overrun was about 120% and the average cost overrun was about 100% (Standish Group 1994). But the estimation accuracy is probably worse than those numbers reflect. The Standish Group found that late projects routinely threw out significant amounts of functionality to achieve the schedules and budgets they eventually did meet. Of course, these projects' estimates weren't for the abbreviated versions they eventually delivered; they were for the originally specified, full-featured versions. If these late projects had delivered all of their originally specified functionality, they would have overrun their plans even more.One Company's ExperienceA more company-specific view of project outcomes is shown in the data reported by one of my clients in Figure 3-3.Figure 3-3: Estimation results from one organization. General industry data suggests that this company's estimates being about 100% low is typical. Data used by permission. The points that are clustered on the "0" line on the left side of the graph represent projects for which the developers reported that they were done but which were found not to be complete when the software teams began integrating their work with other groups.The diagonal line represents perfect scheduling accuracy. Ideally, the graph would show data points clustering tightly around the diagonal line. Instead, nearly all of the 80 data points shown are above the line and represent project overruns. One point is below the line, and a handful of points are on the line. The line illustrates DeMarco's common definition of an "estimate"—the earliest date by which you could possibly be finished.The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
- 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
- 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
- The answer to the question of what an "estimate" is still leaves us with the question of what a good estimate is. Estimation experts have proposed various definitions of a good estimate. Capers Jones has stated that accuracy with ±10% is possible, but only on well-controlled projects (Jones 1998). Chaotic projects have too much variability to achieve that level of accuracy.In 1986, Professors S.D. Conte, H.E. Dunsmore, and V.Y. Shen proposed that a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time (Conte, Dunsmore, and Shen 1986). This evaluation standard is the most common standard used to evaluate estimation accuracy (Stutzke 2005).Numerous companies have reported estimation results that are close to the accuracy Conte, Dunsmore, and Shen and Jones have suggested. Figure 1-6 shows actual results compared to estimates from a set of U.S. Air Force projects.Figure 1-6: Improvement in estimation of a set of U.S. Air Force projects. The predictability of the projects improved dramatically as the organizations moved toward higher CMM levels. [1]Figure 1-7 shows results of a similar improvement program at the Boeing Company.Figure 1-7: Improvement in estimation at the Boeing Company. As with the U.S. Air Force projects, the predictability of the projects improved dramatically at higher CMM levels. A final, similar example, shown in Figure 1-8, comes from improved estimation results at Schlumberger.Figure 1-8: Schlumberger improved its estimation accuracy from an average overrun of 35 weeks to an average underrun of 1 week. One of my client companies delivers 97% of its projects on time and within budget. Telcordia reported that it delivers 98% of its projects on time and within budget (Pitterman 2000). Numerous other companies have published similar results (Putnam and Myers 2003). Organizations are creating good estimates by both Jones's definition and Conte, Dunsmore, and Shen's definition. However, an important concept is missing from both of these definitions—namely, that accurate estimation results cannot be accomplished through estimation practices alone. They must also be supported by effective project control.[1]The CMM (Capability Maturity Model) is a system defined by the Software Engineering Institute to assess the effectiveness of software organizations.
- 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1 Distinguish between estimates, targets, and commitments.
- …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
- http://msdn.microsoft.com/en-us/library/bb738695.aspx
- …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
- …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
- …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
- http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil¿En cuantos negocios tiene un coste similar la producción de una unidad que la de un millón? ¿Cuantos negocios tienen un 99% de margen de beneficio en la venta de sus productos? ¿En cuantos negocios las empresas que desarrollan productos terminan incluyendo prestación de servicios, tanto si les gusta como si no? (proporcionando cierta configuración del producto, y servicios técnicos como integración del sistema y mantenimiento). ¿En cuantos negocios los mejores empleados son diez o veinte veces más productivos que los peores? ¿Cuantos negocios toleran como habitual que el 75 o el 80% de los proyectos de desarrollo de productos terminen tarde o desbordando el presupuesto? ¿En cuantas empresas, quienes desarrollan los productos se autoconsideran artistas, y no científicos o ingenieros, y presentan temperamentos difíciles e inestables? ¿En cuantos negocios los clientes terminan siendo cautivos de un determinado proveedor a raíz de las decisiones que alguien tomó diez años antes y que no se pueden eliminar fácilmente?."
- Algunos intentan otro tipo de contratos… …”Ante el problema de tener que detallar todo prematuramente, el cliente suele adoptar una posición defensiva que es contraria a sus intereses. El cliente tratará que el sistema sea lo suficientemente flexible para poder cubrir las necesidades que pudieran surgir o cambiar. Por este motivo el sistema implementará ciertas funcionalidades no se llegaran a utilizar.” … “En proyectos reales la aplicación de las metodologías ágiles se enfrenta en muchas situaciones a problemas que la teoría no contemplaba. El principal problema que nosencontramos en los proyectos reales es que los tipos de contratos no encajan con algunas de las prácticas. Estos contratos suelen ser de dos tipos: · Contrato de Alcance Cerrado: Que nos obligan a cerrar los requisitos en la primera fase (Metodologías tradicionales)· Subcontratación de personal: Que no podemos clasificarlo como proyecto, ya que suele ser el cliente el que dicta en qué se emplea ese esfuerzo. Una solución que hemos utilizado en proyectos ha sido definir un nuevo tipo de contrato, en el que especifiquemos la funcionalidad que se va a desarrollar, pero en elque el alcance podrá ser modificado durante la duración del contrato. Este alcance podrá ser modificado porque lo que se ofrece es un esfuerzo que es el que se estima que van a llevar los requisitos acordados, pero que podrán ser intercambiados por otros requisitos de igual dificultad técnica.” http://www.willydev.net/descargas/prev/metodologiasagiles.pdf