Sprint

Whiteboard El whiteboard es una representación visual del progreso de la corriente de Sprint.

Mover tareas en el whiteboard

Muestra el estado actual del Sprint Backlog, la organización de las tareas con ello se puede ver

el progreso del Sprint. Las tareas que están todavía intactas están a la izquierda, las tareas que

en la actualidad se está trabajando se pueden encontrar en las tareas intermedias y las

finalizadas a la derecha. Las notas se mueven igual que en una pizarra real, los miembros del

equipo han de ponerse de acuerdo para acordar como se mueven las tareas

El Sprint se acerca a su fase final cuando las tareas se mueven de izquierda a derecha.

Sprint Backlog

El equipo utiliza el Sprint Backlog para organizar su trabajo actual.

Seleccione historias, crear Tareas

Durante la reunión de planificación del Sprint, se seleccionan historias del Product Backlog. Por

cada historia, el Equipo crea tareas para completar la historio correspondiente.

Quemar el Sprint Backlog

Sólo las historias terminadas cuentan para que el equipo tenga éxito, por lo tan el equipo debe

concentrarse en propagar las historias. Hablando en sentido figurado, completar a la mitad

cada historia significa una tasa de éxito del 0% mientras que la mitad de completar la mitad de

las historias significa una tasa de éxito del 50%.

Product Owner acepta o rechaza los resultados

Una vez en la revisión con el product owner puede ser que haya tareas que queden por hacer

en una historia, es decir puede que haya historias que no tengan todas sus tareas terminadas

pero el Product owner las revise y las acepte como resueltas durante la Revisión del Sprint.

Cuando el Sprint acaba, sólo las historias que han sido aceptadas por el Product owner

determinan lala velocidad del Equipo. Las historias que no son aceptadas se trasladan de

nuevo al Product backlog.

Product

Product backlog El Product Backlog es una lista priorizada de las características del producto.

El product owner crea y da prioridad al Product Backlog

El product owner es responsable de crear elementos del product backlog y mantenerlo todo

actualizado. El product backlog contiene historias que describen las características deseadas

del producto. Además, las historias se priorizaron: la más importante esta´ra más arriba qe las

demás

El equipo selecciona historias durante Sprint Planning

Durante las reuniones de planificación de Sprint, el equipo recoge historias solo de la parte

superior (y sólo la parte superior) del product backlog y se compromete a ponerlas en práctica

durante el próximo Sprint. Mediante la colocación de las características que quiere ver

implementadas en la siguiente versión del producto, el product owner del producto puede

decidir la dirección del proyecto.

Estimación del product backlog

Antes de que el equipo puede empezar a trabajar en historias, los miembros del equipo tienen

que calcular entre sí el esfuerzo (es decir, una historia estimada con 2 puntos

presumiblemente requiere un esfuerzo doble que una historia de 1 punto). Para que esto sea

posible, el propietario del producto debe proporcionar una descripción y una explicación

suficiente de la historia. Una vez que se eligen las Historias que forman parte de un Sprint, no

se puede cambiar. Por lo tanto, el propietario del producto debe estar siempre presente para

la estimación y explicar las historias al equipo (y ajustar la descripción de su alcance y, si es

necesario).

Como regla general, debe haber suficientes historias detalladas y estimadas para los próximos

dos o tres sprints. Poner demasiado detalle en las historias de l final del product backlogpuede

ser negativo y debe evitarse, ya que los detalles pueden cambiar en el futuro.

La velocidad Equipo

La historia y los valores de velocidad promedio muestran cuántos puntos de la historia del

Sprint fue capaz de completar el equipo en el pasado y en promedio. Al ajustar el valor de

velocidad previsto, el propietario del producto y otros miembros del proyecto pueden

proyectar una aproximación de lo que se podrá completar en los sprints siguientes. También

ayuda al equipo a decidir, a cuántas historias que pueden comprometerse a durante la

reunión de planificación de Sprint.

Qualities Qualities son requisitos que afectan a múltiples historias.

¿Qué son las Qualities?

Algunos requisitos son generales sobre todo el proyecto. En ese caso, los requisitos específicos

tienden a aparecer en las historias múltiples. Con el fin de evitar repeticiones, las Qualities se

pueden crear y vincularse a las historias en la Pila de Producto.

Los requisitos no funcionales

Ejemplos populares de estos requisitos son los requisitos no funcionales en el software. En la

siguiente tabla se enumeran una serie de requisitos

Por ejemplo, con historias que aparecen en la izquierda y cualidades en la parte superior. La X

indica que una historia de calidad y están relacionados:

User Documentation Thread Safety

Create User Framework X

Create Administration View X

Create Login View X

Issues La vista de edición es un lugar para realizar un seguimiento de retroalimentación, los insectos y

las ideas del proyecto.

Tipos de cuestiones

Se divide en cuatro partes, a saber, la Bandeja de entrada Issue, Bugs, Ideas y temas cerrados.

Cuando un problema se presenta, se crea en la carpeta Entrada.

Dueño del Producto procesa la Bandeja de entrada

El propietario del producto revisa todos los temas en la Bandeja de entrada y decide cómo

manejarlos. Se puede optar por aplazar la decisión al seleccionar Suspender en el menú

entidad. De lo contrario, selecciona para convertir el número a un error o una idea.

Equipo corrige errores

Los errores son de dominio del equipo y suelen ser defectos de los resultados del trabajo del

pasado que se han descubierto en Sprints posteriores. Cuando una reunión de planificación de

Sprint se lleva a cabo y el equipo decide sobre la cantidad de trabajo que pueden manejar

durante el siguiente sprint, también deben tener en cuenta el trabajo que se tiene que invertir

en la solución de bug. En caso de que alcance un error es demasiado grande o poco claro de lo

contrario, podría ser una mejor idea de crear una historia a partir de ella.

Dueño del Producto gestiona Ideas

Ideas por el contrario deben ser manejados por el propietario del producto. Cuando un

problema se convierte en una idea, se acepta, pero una historia de la Pila de Producto aún no

se ha creado.

Cerrado Issues

Cerrado Issues son cuestiones que se han abordado suficientemente. Las soluciones de los

problemas incluyen una resolución real de un problema, que lo identifica como un duplicado

de otro tema, creando una historia de ella o se niega a hacerle frente.

Releases Lanzamientos se puede utilizar para realizar un seguimiento de las versiones de productos y

sus especificaciones.

Tipos de emisiones

El propietario del producto puede crear lanzamientos de productos que representan versiones

que se liberan al público. Hay dos tipos de prensa: Comunicados y notas de corrección de

errores. Las primeras representan una versión del producto principal mientras que el segundo

es un cambio menor en el estreno asociado (que puede ser necesario si los insectos se

encuentran que tienen que hacer rápidamente).

La asociación de lanzamientos con los resultados del trabajo

Un lanzamiento por lo general abarca una serie de sprints e incluye todas las historias

realizadas durante los Sprints. Además, los errores conocidos puede estar asociada con ambos

tipos de emisiones conocidas como (pero no fija) y fijo.

Projects

Impediments El Scrum Master utiliza la vista impedimento para llevar un registro de impedimentos que

gravan al proyecto.

El ciclo de vida de Impedimentos

Al llegar a los impedimentos (por ejemplo, vienen dadas por un miembro del equipo durante

una reunión diaria de Scrum), el Scrum Master crea un impedimento para documentar su

existencia. A continuación, trabaja para eliminar los impedimentos que obstaculizan el trabajo

del Equipo. Tan pronto como se encuentre una solución, cierra el impedimento al seleccionar

Cerrar en el menú de la entidad y de los documentos de la solución, por lo que entonces los

miembros del equipo pueden comprobar de nuevo para ver si y cómo un impedimento estaba

resuelto.

Risk Los riesgos son eventos anticipados que pueden tener un impacto negativo en el proyecto.

Gestión de Riesgos

Miembros del Proyecto de Gestión de Riesgos debe hacer para evitar el fracaso del proyecto

debido a la aparición inesperada de problemas. Al anticipar y evaluar los posibles problemas,

gestión de riesgos permite que el proyecto continúe sin problemas, incluso cuando se

producen problemas.

Evaluación de Riesgos

Los riesgos se evalúan mediante la estimación de la probabilidad y el impacto. La probabilidad

de un riesgo es la probabilidad del riesgo de convertirse en un problema, mientras que el

impacto es el daño al proyecto que puede ser inducida por el problema. Mediante el desarrollo

de la probabilidad y la mitigación del impacto previsto del equipo puede reducir la

probabilidad y el impacto, lo que hace un resultado favorable proyecto más probable.

Priorización de Riesgos

Los riesgos se priorizan automáticamente en función de los valores de probabilidad e impacto

de acuerdo con la siguiente tabla:

very likely

likely possible unlikely very unlikely

extreme Severe Severe High Significant Moderate

substantial Very High High Significant Moderate Moderate

medium High Significant Moderate Moderate Moderate

minor Significant Moderate Moderate Low Very Low

negligible Moderate Moderate Low Very Low Very Low

seguimiento de los riesgos

Riesgos debe ser constantemente supervisado y revisado por lo menos una vez al mes. La

eficacia de la gestión de riesgos depende de los datos que son hasta la fecha los miembros del

proyecto y que se adhieren a los planes de mitigación existentes.

Journal El Diario del Proyecto cronológicamente registra todos los eventos importantes del proyecto.

Eventos en el Diario del Proyecto

Cuando los usuarios hacen cambios importantes en los datos del proyecto, el evento se

registra y se coloca en el Diario del Proyecto. El diario se utiliza principalmente para mostrar

los últimos acontecimientos en el cuadro de instrumentos. Mayores acciones pueden ser

consultados en la vista revista Project.

Change Log vs Proyecto Diario

Los cambios realizados a las entidades no se registran aquí. En su lugar, se puede ver

seleccionando Mostrar Registro Cambiar en el menú entidad.

Next Sprint La siguiente vista Sprint se utiliza para preparar el siguiente Sprint de antemano.

Dueño del Producto prepara Siguiente Sprint

El propietario del producto puede seleccionar una fecha de inicio y la duración de Sprint y

Sprint debe hacerle el un nombre basado en el objetivo del Sprint. Después de la reunión de

revisión del Sprint Sprint actual, el propietario del producto selecciona Cambiar a Sprint este

fin de terminar y presentar el Sprint actual y sustituirlo por el Sprint Backlog con el nuevo.

Todas las historias inconclusas después se trasladó de nuevo a la Pila de Producto y todas las

tareas pendientes se eliminan.

Collaboration

Forum El foro es un lugar para tener conversaciones con otros participantes del proyecto.

Tipos de sujetos

Hay dos tipos de sujetos visibles en la vista del foro. En primer lugar, temas creados en la vista

del Foro y en segundo lugar, las discusiones que se unen a otras entidades. Se pueden

distinguir al ver el identificador de la entidad. Discusiones independientes tienen IDs como

sbjN (donde N es un número), mientras que los debates vinculados a alguna entidad tienen el

mismo ID que la entidad correspondiente (por ejemplo sto42 para una discusión de la historia

con el ID sto42).

Calendar El calendario puede ser utilizado para programar en proyectos relacionados con los

acontecimientos.

Reuniones: Scrum Scrum diarios

Hay una serie de reuniones relacionadas con Scrum para ser programado.

Todos los días a la misma hora (y el mismo lugar) un Scrum diaria debe realizarse (y

supervisadas por el Scrum Master). En esta reunión de estado a todo el mundo responde a tres

preguntas:

¿Qué hiciste ayer?

¿Qué vas a hacer hoy?

¿Existen impedimentos?

Reuniones Scrum: opiniones y Retrospectivas

Al comienzo de un Sprint, el Dueño del Producto invita al equipo a hacer una reunión de

planificación Scrum, en la que el equipo selecciona Historias de la Pila de Producto y se

compromete a completar durante el próximo Sprint.

Al final del Sprint, Sprint Sprint examen y las reuniones se llevan a cabo retrospectivos. En las

reuniones de revisión de Sprint el equipo presenta sus resultados de trabajo para el

propietario del producto, que luego decide aceptar o rechazar el trabajo. En Retrospectivas de

Sprint el equipo y el Scrum Master reflexionar sobre el trabajo del Sprint pasado y discutir las

posibles mejoras que se pueden hacer para Sprints futuras.

File repository El repositorio de archivos se puede utilizar para cargar los archivos que pueden ser

convenientemente enlazados dentro del proyecto.

Enlazar archivos subidos

Un archivo subido se le asigna un ID Flen (donde N es un número). Cuando se utiliza este ID en

algún lugar dentro de Kunagi (como en las descripciones de la entidad o chat), un enlace al

archivo correspondiente se crea automáticamente.

Subir desde formas

Puede utilizar la función de carga no sólo en la vista del repositorio de archivos, sino también,

durante la edición de otras entidades en el proyecto, utilizando la barra de herramientas de

edición de texto.

Courtroom La sala se puede utilizar para realizar un seguimiento de violaciónes regla participantes del

proyecto.

Acuerdo en el castigo, utilizar los ingresos

Por ejemplo, usted podría ponerse de acuerdo sobre los miembros del equipo tienen que

pagar un euro cuando llegan tarde a las reuniones diarias de Scrum. Cada vez que un miembro

del equipo llega tarde, el número de violaciónes se aumenta entonces. Al llegar a una cantidad

suficiente de dinero, usted puede hacer una fiesta y lo utilizan para comprar pasteles y

cerveza.

Administration

Blog El blog puede ser utilizado para comunicar información relacionada con el proyecto, tales

como notas de la versión o las hojas de ruta para el desarrollo, para el público.

Creación y publicación de blog

Cada miembro del proyecto puede crear y editar entradas de blog. Una vez creados, los

comentarios no se publican de forma predeterminada, para permitir la preparación de

antemano. El propietario del producto puede publicar entradas de blog. Sólo las entradas

publicadas se tendrán en cuenta los datos del proyecto cuando se exporta.