Aprendiendo una cosa nueva todos los días
Cada sprint termina con una reunión de revisión del sprint de dos partes. Dicha reunión comienza con una revisión y demostración al cliente y termina con la retrospectiva del equipo. Ambos componentes tienen lugar el último día del sprint. La revisión del sprint se centra en la “inspección” y “adaptación” del incremento (potencialmente enviable), mientras que la retrospectiva del sprint se centra más en la “inspección” y “adaptación” del proceso del sprint.
Sigue leyendo
La Definición de Hecho (DoD) es una lista de requisitos que una historia de usuario debe cumplir para que el equipo la considere completa. Mientras que los Criterios de Aceptación de una Historia de Usuario consisten en un conjunto de Escenarios de Prueba que deben cumplirse para confirmar que el software funciona como se espera.
Sigue leyendo
En el verano de 2011, Ken Schwaber y Jeff Sutherland revisaron su Guía de Scrum. En ella, eliminaron un comportamiento establecido desde hace mucho tiempo y conocido por Scrum, que es el compromiso que el equipo hace con el propietario del producto y los clientes. El compromiso fue sustituido por la previsión. Dicen que los equipos pueden prever su trabajo, pero no comprometerse con él.
Sigue leyendo
Un diagrama de casos de uso modela diferentes tipos de usuarios que interactúan con el sistema para resolver un problema. Como tal, describe los objetivos de los usuarios, las interacciones entre los usuarios y el sistema, y el comportamiento requerido del sistema para satisfacer estos objetivos. Los casos de uso definen las interacciones entre los actores externos y el sistema para alcanzar determinados objetivos. Un diagrama de casos de uso contiene cuatro componentes principales
Sigue leyendo
El caso de uso 2.0 es un enfoque escalable y ágil que utiliza los casos de uso para capturar los requisitos e impulsar el desarrollo incremental de un sistema para cumplirlos. Le ayuda a comprender cómo se utilizará el sistema y le guía en el desarrollo de un sistema adecuado para dar soporte a los usuarios.
Sigue leyendo
Un caso de uso es una descripción escrita de cómo un usuario realiza una tarea en su sistema. Describe el comportamiento del sistema desde la perspectiva del usuario al responder a una solicitud. Cada caso de uso se representa como una secuencia de pasos sencillos, que comienzan con el objetivo del usuario y terminan cuando se logra el objetivo.
Sigue leyendo
A UML use case diagram is the primary form of system/software requirements for a new software program under developed. Use cases specify the expected behavior (what) of a system, and not the exact method of making it happen (how). A complete set of use cases specifies all the different ways to use the system and therefore defines all behavior required of the system bounding the scope of the system.
Sigue leyendo
Una tabla de decisiones es una excelente herramienta para utilizar tanto en las pruebas como en la gestión de requisitos. Esencialmente, es un ejercicio estructurado para formular requisitos cuando se trata de reglas empresariales complejas. En una tabla de decisiones, la lógica empresarial está bien dividida en condiciones, acciones (decisiones) y reglas para representar los distintos componentes que forman la lógica empresarial.
Sigue leyendo
En el desarrollo de software, la “estimación” habitual incluye una evaluación cuantitativa del trabajo necesario para realizar una determinada tarea de desarrollo; suele expresarse en términos de duración (hora/día) o unidad estimada (story point). El objetivo es consolidar una serie de estas estimaciones individuales para obtener una indicación de la duración, el trabajo o el coste global del proyecto de software.
Sigue leyendo
Siempre nos encontramos con estos términos en el desarrollo de software. A veces la gente una característica de software – requisito / caso de uso, elementos de backlog …. ¿Cuál es la convención de la gente de software para usar eso o qué?
Sigue leyendo