JIRA: reglas para la preparación oportuna de software delicioso. TLDR 2: gestión de requisitos
Anteriormente en el artículo " JIRA: las reglas para la preparación oportuna de un software delicioso. TLDR 1: límites de posibilidades ”se intentó unificar los requisitos generales para el uso de JIRA en el caso de la gestión de varios proyectos para el desarrollo de software personalizado en uno de los departamentos de nuestra empresa . Al desarrollar el tema, este artículo se dedicará a las características clave del registro, la aclaración y el seguimiento de la implementación de los requisitos del cliente en el marco del modelo propuesto anteriormente . Cualquier crítica es bienvenida.FuenteCualquier producto terminado está determinado principalmente por la calidad de los ingredientes originales, y el software no es una excepción ( Garbage In - Garbage Out ). Si los ingredientes originales están ligeramente podridos o simplemente faltan algunos de ellos, es poco probable que pueda salvar la situación con la ayuda de un súper horno o una sartén maravillosa. En el caso del software, los componentes iniciales son las buenas intenciones (sueños) del cliente sobre un futuro brillante (cuando "los robots están trabajando duro, una persona es feliz "). Una de las paradojas de los contratos gubernamentales modernos es que el contratista a menudo tiene una influencia débil en el proceso de formación de requisitos, es decir. proceso de análisis de requisitos realesen el proyecto comienza después de la aprobación de la lista de estos requisitos. El hecho de que las recomendaciones del equipo del proyecto con respecto a la redacción de los requisitos no tuvieron ningún efecto en el texto del contrato, el gerente del proyecto generalmente se entera del representante alegremente entusiasmado del departamento de contratos, quien, con un sentido de deuda completa, informa que la tan esperada licitación finalmente se ganó y el acuerdo Sigue siendo pequeño. Al mismo tiempo, por un lado, el cliente de todas las formas posibles impide el cambio de requisitos en el documento aprobado (un sueño es sagrado) y, por otro lado, puede interpretar fácilmente de manera diferente el mismo requisito según la situación.En estas condiciones, es deseable asegurarse de que todos los requisitos del cliente se almacenen en su "cocina digital" de tal manera que, en la etapa de entrega del proyecto, evite la molestia severa de todas las partes interesadas del proyecto.Para resolver este problema, en el marco del enfoque propuesto anteriormente , se diseña un tipo especial de tarea: el “requisito”. El llamado trabajo atrasado del proyecto forma una lista de estos requisitos de tareas. En las versiones más recientes de JIRA, un análogo de este tipo de tarea es el tipo de tarea "épica". Sin embargo, como se verá más adelante, el tipo de "requisito" de tareas en nuestro proyecto no es solo fijar las formas de pensamiento conceptual del cliente, sino tareas que caracterizan los resultados de las actividades del gerente del proyecto y los analistas en la gestión de requisitos . Reglas para los requisitos de corte
Si el cliente recibe una lista de requisitos para finalizar el software (por ejemplo, términos de referencia aprobados), todas las actividades para registrar y mantener la lista de requisitos en JIRA pueden reducirse a dos escenarios fronterizos.En el primer caso, el gerente del proyecto simplemente envía la carta con los requisitos del cliente a los analistas con una nota "Registre los requisitos con respecto a la tangente con JIRA y garantice su implementación". Después de eso, el gerente del proyecto puede "martillar" el proyecto hasta el comienzo de las pruebas preliminares (lo único es asegurarse de que todos los requisitos encuentren a sus ejecutores responsables en JIRA). Si su equipo de proyecto está compuesto por analistas sanos, programadores ingeniosos, probadores adictos al trabajo y escritores técnicos grafómanos, el resultado de este enfoque no será diferente de la segunda opción, más problemática.En el segundo caso, el trabajo de gestión de requisitos se divide en varias etapas.Inicio de origen . Registro del documento fuente para el desarrollo / modificación de software en JIRA. Los materiales recibidos se cargan en el repositorio con el número de la tarea correspondiente indicada en el comentario de la confirmación.1. Basado en el documento fuente registrado, se planifica una reunión, cuyo propósito es determinar los límites de responsabilidad para cumplir con los requisitos, identificando los "puntos blancos" y los requisitos "esotéricos". La planificación de la reunión se lleva a cabo directamente en JIRA (para esto, se registra una tarea del tipo "implementación", la persona responsable de la tarea es el gerente del proyecto, los participantes se registran como observadores, los elementos de la agenda se registran en la descripción). Los analistas fijan de forma independiente el tiempo dedicado a un análisis preliminar de los requisitos en forma de subtareas para la reunión planificada. Si surgen preguntas durante el análisis, se reflejan en los comentarios en la agenda de la reunión.Durante la reunión, se toman decisiones sobre el nombramiento de los responsables de los "puntos blancos". Se evalúan los riesgos con respecto a los requisitos "esotéricos" y se proponen formas de superarlos. Se está formando la primera versión, aún muy aproximada, de la "hoja de ruta", según la cual se organizará el trabajo (teniendo en cuenta las prioridades y el empleo actual del equipo del proyecto).2. Después de que el analista sea nombrado responsable de la implementación de los requisitos, registra cada requisito con JIRA como una tarea separada relacionada con el documento fuente (el enlace "complementa"). El estado inicial de la reclamación es "calificación" .Una de las reglas básicas: cada requisito del cliente debe registrarse como una tarea separadaen JIRA Este enfoque, a su vez, permite evaluar el estado del proyecto desde el punto de vista de la implementación de cada uno de los requisitos del cliente, y no desde el punto de vista del número de tareas realizadas o la inversión de mano de obra. La redacción del requisito se registra en el campo "Descripción" palabra por palabra como en el documento del cliente.Además, el registro "atómico" de los requisitos posteriormente permite generar automáticamente documentación de informes cuando se emite una versión o actualización (protocolo de composición funcional y pruebas). 3. Dada la hoja de ruta desarrollada para cada uno de los requisitos en la etapa inicial de su implementación, el analista responsable debe resolver los siguientes problemas:- aclaración del contenido semántico del requisito;
- aclaración de los límites de implementación.
En el momento de la aclaración, el requisito puede transferirse al estado de "pendiente" , indicando el motivo correspondiente.Todos los materiales para la aclaración (interpretación) de los requisitos se adjuntan a la tarea correspondiente (cargados en el depósito de documentación). Los materiales resultantes deben provenir del cliente y deben permitir una respuesta clara a las preguntas anteriores. Es aconsejable que este sea un protocolo de la reunión para aclarar los requisitos, al menos un correo electrónico de la correspondencia.Después de eliminar los "puntos blancos", el requisito puede transferirse al estado de "asignado" .4. En el marco de la implementación de un área funcional (un caso de uso clave - caso de uso) el analista responsable debe formular tareas del tipo de "análisis" relacionadas con los requisitos pertinentes. 5. Si es necesario, el analista responsable realiza una encuesta de información del objeto de automatización. 6. Después de recopilar los datos iniciales necesarios para el diseño, el analista responsable toma la decisión de diseño. 7. Con base en los resultados de la decisión de diseño, el analista debe formar / aclarar la lista de componentes que están sujetos a desarrollo / modificación.8. La solución de diseño desarrollada es una condición necesaria y suficiente para crear tareas para el desarrollo, pruebas y documentación y pronosticar la complejidad de su implementación.Esto es a menudo donde se encuentra el principal obstáculo entre los administradores y desarrolladores. Uno deLos enfoques utilizados para reducir la incertidumbre en la resolución de este problema es evaluar la tarea propuesta por el desarrollador responsable, siempre que la complejidad total de la tarea individual no debe exceder las 16 horas. Alexei Kataev en su informe muestra convincentemente que si los costos de mano de obra para la implementación de la tarea exceden las 12 horas, la confiabilidad del pronóstico de la complejidad de dicha tarea se vuelve similar a la confiabilidad del pronóstico de las ganancias de los juegos de azar. Por lo tanto, para garantizar la calidad de planificación requerida, se recomienda descomponer las tareas. Por otro lado, desde el punto de vista de la administración, me gustaría lograr un resultado que sea significativo desde el punto de vista del cliente durante la ejecución de la tarea de desarrollo, que no siempre se puede lograr en 16 horas de trabajo. En nuestro caso, se decidió que si la complejidad de la tarea supera las 8 horas, el autor de la tarea debería dividirla en etapas separadas (lo que no siempre significa subtareas). Además, se determinaron listas formales de resultados particulares para cada una de estas etapas. Además, se crearon calculadoras en línea para aumentar la objetividad de los pronósticos basados en estas listas utilizando el método PERT .determinación de la complejidad total para tareas de diferentes tipos (se supone que se proporcionará una descripción más detallada del trabajo con estas herramientas durante la publicación de los siguientes artículos). Pero al mismo tiempo, se estableció una limitación de que la complejidad máxima proyectada de una sola tarea JIRA no debe exceder las 32 horas. En caso de que el contratista no esté de acuerdo con la complejidad proyectada de su tarea, como argumento, debe presentar su cálculo de la complejidad, realizado utilizando las mismas herramientas. El árbitro para resolver tales disputas entre el analista responsable de la implementación del requisito y los ejecutores es el gerente del proyecto (teamlead).9. Inmediatamente después del registro de requisitos asociados con el requisito para el desarrollo, prueba y documentación, el gerente del proyecto debe especificar la prioridad y el momento de la implementación de este requisito (teniendo en cuenta los costos laborales totales de las tareas relacionadas, las prioridades y el tiempo requerido para la implementación de otras tareas del proyecto). Dadas estas aclaraciones, a su vez, el analista responsable puede ajustar el tiempo de las tareas para el desarrollo, las pruebas y la documentación.10. La implementación de la solución de diseño se lleva a cabo en el marco de tareas del tipo de "desarrollo".Una vez que se pone en funcionamiento la primera tarea relacionada con los requisitos para el desarrollo de software, el requisito debe transferirse al estado "en el trabajo" (esto se puede hacer utilizando el complemento Automatización para Jira ).11. Según los plazos de implementación especificados, se toma la decisión de incluir la implementación del requisito en una u otra versión de software. El cliente debe ser informado de cualquier cambio en la composición o el tiempo de entrega del lanzamiento.12. Paralelamente al proceso de desarrollo, se forma una versión de la documentación del usuario sobre la base de la decisión de diseño.13. Después de completar las tareas de desarrollo, el programador debe aclarar la lista de componentes que se han desarrollado / modificado.14. La clarificación de la documentación del usuario debe realizarse como parte de una prueba fuera de línea. El cumplimiento de todos los requisitos relacionados con el requisito de desarrollo, documentación y pruebas es una señal para traducir este requisito al estado de "completado" y su inclusión en el lanzamiento.15. La revisión se incluye en la versión del software de acuerdo con la decisión de entrega realizada por el gerente del proyecto.16. Antes de llevar a cabo las pruebas, se llevan a cabo pruebas de integración repetidas de los requisitos implementados incluidos en la versión.17. La confirmación de la exactitud de los requisitos implementados puede llevarse a cabo durante las pruebas de software (preliminar, operación de prueba, aceptación). Los resultados de la prueba se registran en JIRA como parte de las tareas de tipo "implementación".Después de que se haya recibido un documento del cliente sobre la implementación correcta del requisito, se puede transferir al estado "cerrado" . En el caso de que se reciban comentarios del cliente con respecto al requisito, se devuelve al estado "asignado"(en el escenario número 8). Al mismo tiempo, los comentarios en sí mismos se pueden arreglar en JIRA como requisitos separados relacionados con el requisito principal utilizando el tipo de comunicación "Relacionado" .Permítame recordarle que el esquema descrito no refleja el flujo de trabajo de una tarea separada en JIRA, sino que implica la creación de un conjunto de tareas interrelacionadas de varios tipos (que se refleja en el esquema con los colores correspondientes). La secuencia dada ofrece una visión general del procedimiento estándar para implementar los nuevos requisitos del cliente. Al mismo tiempo, este esquema no excluye la posibilidad de desviaciones del mismo, por ejemplo, en el caso de prototipos preliminares antes de la decisión de diseño. Sin embargo, en nuestro proyecto, tales excepciones deben acordarse con el gerente del proyecto.Durante las pruebas o la operación comercial, inevitablemente se revelarán los comentarios de los clientes sobre el software creado. Estas observaciones se pueden dividir condicionalmente en los siguientes grupos:- nuevos requisitos;
- aclaraciones sobre la implementación;
- defectos
- errores
A pesar del hecho de que, de acuerdo con el enfoque propuesto inicialmente , los comentarios se registran en JIRA, así como los requisitos para el refinamiento del software (como tareas del tipo "requisito"), el proceso de su eliminación merece una consideración por separado. Reglas para colorear cucarachas
El que no hace nada no se equivoca.
Theodore Roosevelt
No hay software sin errores. Absolutamente. Incluso si no hay errores en el código, un usuario sofisticado los encontrará en la documentación o simplemente los descubrirá. De una forma u otra, no he visto proyectos donde no hubo incidentes de software. Análisis de mantenimiento de software por el Instituto Americano de Ingeniería de Software ( SEI)) a principios de los 90, mostró que el coeficiente de correlación entre el número de errores detectados durante la prueba de módulos individuales y el número de errores encontrados por los usuarios en el producto terminado es 0.91. En pocas palabras, si se detectaron 10 errores en la etapa de prueba, aparecerán otros 9 más durante la operación de prueba. El logro de la calidad requerida en el desarrollo de software para estaciones espaciales se logra, en particular, debido a la superioridad de diez veces del personal de pruebas sobre el personal de desarrollo, sin incluir el uso de técnicas avanzadas, por ejemplo, pruebas unitarias o automatización de pruebas GUI. En mi opinión, la confiabilidad de dicho software se logra debido a la mínima participación posible de los usuarios en vivo en su trabajo. Por supuesto, es genial cuando un equipo profesional de control de calidad trabaja en el proyecto . Sin embargo, en muchos proyectos de software no es posible implementar todas estas recomendaciones por varias razones objetivas y subjetivas.Por lo tanto, si el gerente del proyecto no administra el flujo de incidentes entrantes, muy pronto este hilo administrará dicho administrador (si no se "ahoga" en este hilo). Por otro lado, como lo demuestra la experiencia, una parte significativa de los comentarios del cliente que inicialmente fueron clasificados por él como un error de software no es un error. La aparición de comentarios de este tipo puede deberse a razones tales como:- violación de las condiciones técnicas de funcionamiento del software ("manos torcidas" de los administradores del sistema del cliente);
- restricciones a los derechos de acceso de los usuarios (los derechos de acceso de usuarios asignados no cumplen con sus expectativas);
- la falta de coincidencia de las expectativas funcionales del usuario con los requisitos implementados (si nada ayuda, ¿tal vez debería leer las instrucciones?);
- inconsistencia en la descripción de la implementación del software (una observación bastante rara, ya que los usuarios y administradores del cliente, por regla general, no leen los manuales después del primer conocimiento del software).
En este sentido, durante la correspondencia con el cliente con respecto a los comentarios sobre el software, se recomienda evitar palabras como "error" o "defecto", al menos hasta que se establezca de manera completamente inequívoca. Hasta este punto, se recomienda utilizar las palabras "comentario" o "incidente".El proceso unificado de llevar a cabo el trabajo para eliminar incidentes puede representarse como una secuencia de los siguientes pasos.Inicio de origen . Registre una solicitud de resolución de incidentes con JIRA. Esta etapa para diferentes proyectos se puede organizar a su manera. Puede, por ejemplo, registrar aplicaciones recibidas del cliente manualmente con JIRA, o puede usar un buzón especial, que JIRA verá y configurará tareas independientemente en función de las cartas entrantes. Si está desarrollando una aplicación web, puede usar el recopilador de tareas JIRA para recopilar comentarios de los usuarios . El campo de cómo el comentario de alguna manera resultó estar registrado en JIRA (en el estado de "calificación" ), es necesario procesarlo previamente.1. Aclaración de las condiciones del incidente. Como parte de esta acción, es necesario recopilar la información más completa sobre el comentario del software:- la secuencia de acciones durante las cuales ocurre el incidente, una combinación de datos de entrada;
- detalles y autoridad del usuario del comentario;
- ubicación de la estación de trabajo (servidor);
- capturas de pantalla de pantallas de usuario;
- protocolos de monitoreo;
- muestras de archivos generados incorrectamente (informes).
A menudo, una parte importante de los incidentes termina su viaje vital en esta etapa, ya que durante la recolección de artefactos resulta que el "error" detectado es el comportamiento estándar del sistema. Si la JIRA comienza a acumular requisitos para resolver incidentes que se resolvieron sin crear tareas de desarrollo, vale la pena prestar mucha atención a la facilidad de uso de la interfaz de usuario y la relevancia del manual del usuario.2. Desglose del incidente en requisitos "atómicos". A menudo, en una carta, el representante del cliente puede reflejar varios comentarios. Por lo tanto, si es necesario, en el segundo paso, basado en la carta registrada del cliente a JIRA, se forman tareas de requisitos separadas. Además, cada una de estas tareas está asociada con el requisito principal mediante la relación Cloners . Para cada una de estas tareas, se adjuntan los materiales recopilados en la etapa anterior (en parte con respecto a). Además, todo el trabajo se organiza con cada requisito por separado.3. Definición del marco contractual. Después de especificar los defectos identificados, se determina a qué tipo de relación contractual se puede atribuir el trabajo para eliminarlo. Desde el punto de vista de una mayor organización del trabajo, esta etapa puede cambiar fundamentalmente la prioridad de otras tareas. En muchos proyectos, la operación de prueba de los nuevos componentes desarrollados como parte del desarrollo se lleva a cabo instalando estos componentes directamente en la versión actual después de una breve prueba autónoma. Sin embargo, el cliente correlaciona los errores que surgen en estos casos ya con los contratos de soporte básico o de garantía, que estipula plazos estrictos para eliminar los defectos. Si, dentro del marco del soporte básico, el período contractual para eliminar el defecto puede medirse en horas, entonces si el defecto se identifica en relación con la nueva funcionalidad,El período para eliminar el mismo defecto está determinado por la fecha de finalización de la operación de prueba (hasta varios meses). Si el gerente del proyecto no presta atención a este matiz "pequeño", la empresa ejecutora tiene todas las posibilidades de comenzar a pagar una multa por un software simple, incluso antes de que se ponga en funcionamiento comercial.4. Control de duplicados. En el caso de volver a unirse a la aplicación para la eliminación de defectos detectados previamente, este requisito está asociado con la tarea presentada anteriormente a través de la conexión "Duplicar» ( Duplicar ). Según los resultados del análisis preliminar del incidente, es necesario informar al cliente sobre sus resultados, ya que la visión del cliente sobre el momento de la eliminación del incidente puede correlacionarse débilmente con las obligaciones contractuales.5. El equipo de soporte técnico debe repetir el incidente en el servidor de prueba antes de enviar la solicitud al analista del equipo de desarrollo. La prueba inicial se puede registrar en JIRA en forma de una subtarea para el requisito relevante.6. Si el incidente no se resolvió en el curso de los pasos anteriores, el requisito se transfiere al estado "asignado" y se transfiere al analista del equipo de desarrollo para identificar las razones de su ocurrencia y formular tareas para su eliminación.7. Si es necesario, el analista debe aclarar el alcance contractual del requisito. Si se hace un comentario sobre la nueva funcionalidad del software, el analista debe asociar este defecto con los requisitos relevantes para el desarrollo / desarrollo / soporte extendido (el enlace "Agrega").8. El análisis también debe determinar la lista de componentes que afectan este comentario. Además, si el comentario es realmente un error de software, debe generarse.tipificación del defecto detectado.9. Después de identificar las causas del defecto, el analista del grupo de desarrollo forma tareas de desarrollo destinadas a eliminar el error identificado. Si es necesario, se forman tareas para probar y aclarar la documentación. Como parte de estas tareas, se determinan los costos laborales planificados. Si la carga de trabajo de una tarea en particular excede las 8 horas, es necesario proporcionar una justificación de la complejidad utilizando las herramientas especificadas en la sección anterior. Teniendo en cuenta la prioridad y la carga de trabajo del equipo del proyecto, se determinan las fechas planificadas para la implementación de estas tareas. Después de que el primer requisito relacionado con el desarrollo del software se ponga en funcionamiento, el incidente debe transferirse al estado de "en el trabajo" .10. La aparición de tareas relacionadas para el desarrollo, prueba y documentación de un requisito es una señal para que el gerente del proyecto tome una decisión sobre qué versión del software se solucionará el defecto identificado. Al mismo tiempo, el gerente de proyecto planifica un evento para la implementación de software al vincular los requisitos correspondientes a la tarea JIRA del tipo "implementación". 11. Si es necesario, el gerente del proyecto aclara las fechas planificadas para la implementación de tareas relacionadas e informa al cliente sobre esto.12. La corrección del defecto se lleva a cabo en el marco de tareas del tipo "desarrollo".13. Después de la eliminación del defecto, el desarrollador, si es necesario, debe aclarar el tipo del defecto detectado y la composición de los componentes que se han modificado.14. Si es necesario, se especifica la documentación.15. Los especialistas del grupo de apoyo realizan pruebas autónomas de la funcionalidad corregida (como parte de la tarea de prueba formada por el analista del grupo de desarrollo).Además, como en el caso de la implementación del nuevo requisito, la base para transferir el incidente al estado de "completado" es el cumplimiento de todas las tareas creadas sobre esta base (con la excepción de las tareas del tipo de "implementación").16. Después de realizar pruebas fuera de línea, la solución se incluye en la actualización y en la versión actual.17. Después de la preparación de todas las mejoras planificadas para su inclusión en el lanzamiento de la entrega, se llevan a cabo pruebas de integración. La realización de pruebas de integración se puede arreglar en JIRA en forma de una subtarea para la tarea correspondiente del tipo "implementación".18. Las actualizaciones de software se transmiten al cliente de la manera establecida. Sin embargo, la transferencia de tareas de los requisitos relevantes al estado de "cerrado" es posible solo después de recibir del cliente evidencia documental de la eliminación del incidente. FuenteCualquier desarrollador sabe que los errores más grandes son aquellos que no se detectaron de manera oportuna en la etapa de formación / especificación de requisitos.Requisitos Reglas de congelamiento
Caminar sobre el agua y desarrollar software de acuerdo con las especificaciones es muy simple cuando ambos están congelados.
Edward V. Berard
Cabe señalar que la aclaración de los requisitos de la manera más efectiva se ha demostrado mediante la creación de una situación en la que el cliente debe dar una respuesta simple a la carta aclaratoria: "Estoy de acuerdo". Para esto, es necesario formular varias respuestas posibles en la carta . El arte de formar esas letras es que la opción que el cliente elige es la más preferible para usted como intérprete.
FuentePor ejemplo, el requisito "simple" de "proporcionar la posibilidad de muestreo por región en todas las pantallas" en la etapa de entrega puede causar muchos problemas, ya que no determina en qué pantalla se debe proporcionar el muestreo, ya sea muestreando por un valor de parámetro o varios cómo debe tenerse en cuenta la historicidad de los cambios en el nombre de las regiones. Si solo pide aclarar este requisito, es poco probable que la respuesta resuelva los problemas indicados. En este caso, puede hacerse una aclaración utilizando una carta de los siguientes contenidos:. 4.5.6. : « 1, 2 3 «». , , ».
Se adjunta una copia de la carta a la tarea. La tarea se transfiere al estado "pendiente" hasta que se recibe una respuesta del cliente, que también se adjunta posteriormente a la tarea. Esta redacción se refleja en el campo correspondiente de la tarea JIRA (ver más abajo, "Aclaración"). Es sobre esta base que se forman decisiones de diseño relacionadas, tareas de desarrollo y tareas de prueba.Idealmente, que a menudo se puede lograr como un horizonte por razones objetivas y subjetivas, para transferir el requisito a un mayor desarrollo, es necesario asegurar que todos los miembros del equipo del proyecto comprendan sus límites. Por lo tanto, tan pronto como una tarea del tipo "requisito" se asocie con las tareas de desarrollo, el gerente del proyecto verifica que cumpla con los criterios de calidad descritos a continuación ( Definición de Listo) Si la redacción básica del requisito no cumple con estos criterios, el trabajo para su perfeccionamiento debe llevarse a cabo sin falta. El resultado del trabajo de refinamiento debe ser una redacción actualizada del requisito o una decisión de diseño (SCF) acordada por el cliente en relación con este requisito. Cuando se contabilizan los costos laborales en una tarea del tipo "requisito", solo se registra el tiempo dedicado directamente a su refinamiento. Todos los demás costos laborales se registran en tareas de los tipos correspondientes (o sus subtareas).Además de los atributos comunes descritos en el artículo anterior , se definió un conjunto de atributos adicionales para cada tarea del tipo "requisito" en JIRA durante un proceso largo y doloroso.* Características del atributo de relleno, común a todo tipo de tareas.La tabla siguiente describe el cambio de los atributos específicos de una tarea del tipo "requisito" cuando se pasa de un estado a otro, donde:
- es posible un cambio de atributo;
- entrada de datos requerida.Continuará
Muchos gerentes de proyecto creen que si los términos de referencia fueron aprobados por el cliente, esta es la verdad fundamental, que no está sujeta a ningún cambio. Esto es en parte cierto: es poco probable que se modifique la redacción de los requisitos de las especificaciones técnicas hasta que se complete el proyecto. Sin embargo, ya en las etapas iniciales del proyecto (mucho antes de la aprobación del Programa y el procedimiento de prueba), nadie se molesta en aclarar con el cliente los límites de cada requisito y fijar el procedimiento propuesto para su verificación. Si dicho trabajo no se ha llevado a cabo, lo más probable es que toda la "Lista de deseos" del cliente expresada durante la implementación, usted decida dentro del presupuesto y el momento del mismo proyecto.No se olvide de las leyes objetivas, que llamaron la atención de Barry Boehm ( Barry W. Boehm ) a fines de los años 80 del siglo pasado. Si al gerente del proyecto no le importa eliminar la incertidumbre y las imprecisiones de los requisitos en las etapas iniciales del proyecto, entonces, en la fase de finalización del proyecto, se le garantiza que tendrá muchos "descubrimientos" desagradables.Sin embargo, la experiencia ha demostrado que la mayoría de las ambigüedades no se pueden resolver simplemente aclarando los requisitos. Además, a menudo es imposible considerar los requisitos de forma aislada, ya que los objetivos en interés de los cuales se crea el software solo se pueden lograr con la implementación integrada de los deseos del cliente.Dentro del marco del enfoque descrito, se propone llevar a cabo la coordinación de un conjunto de requisitos interconectados, así como una interpretación realista de las fantasías del cliente reflejadas en los términos de referencia aprobados al resolver problemas del tipo de "análisis", cuyas características se presentarán en el artículo "JIRA: reglas para la preparación oportuna de software sabroso. TLDR 3: Soluciones de diseño ". Source: https://habr.com/ru/post/undefined/
All Articles