Sprint

Whiteboard
El whiteboard es una representacin visual del progreso de la corriente de Sprint.

Mover tareas en el whiteboard Muestra el estado actual del Sprint Backlog, la organizacin de las tareas con ello se puede ver el progreso del Sprint. Las tareas que estn todava intactas estn 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 reunin de planificacin del Sprint, se seleccionan historias del Product Backlog. Por cada historia, el Equipo crea tareas para completar la historio correspondiente. Quemar el Sprint Backlog Slo 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 revisin 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 Revisin del Sprint. Cuando el Sprint acaba, slo 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 caractersticas 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 caractersticas deseadas

del producto. Adems, las historias se priorizaron: la ms importante estara ms arriba qe las dems

El equipo selecciona historias durante Sprint Planning Durante las reuniones de planificacin de Sprint, el equipo recoge historias solo de la parte superior (y slo la parte superior) del product backlog y se compromete a ponerlas en prctica durante el prximo Sprint. Mediante la colocacin de las caractersticas que quiere ver implementadas en la siguiente versin del producto, el product owner del producto puede decidir la direccin del proyecto. Estimacin 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 descripcin y una explicacin 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 estimacin y explicar las historias al equipo (y ajustar la descripcin de su alcance y, si es necesario). Como regla general, debe haber suficientes historias detalladas y estimadas para los prximos 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 cuntos 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 aproximacin de lo que se podr completar en los sprints siguientes. Tambin ayuda al equipo a decidir, a cuntas historias que pueden comprometerse a durante la reunin de planificacin de Sprint.

Qualities
Qualities son requisitos que afectan a mltiples historias. Qu son las Qualities? Algunos requisitos son generales sobre todo el proyecto. En ese caso, los requisitos especficos tienden a aparecer en las historias mltiples. 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 estn relacionados:
User Documentation Thread Safety

Create User Framework

Create Administration View

Create Login View

Issues
La vista de edicin es un lugar para realizar un seguimiento de retroalimentacin, 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.

Dueo del Producto procesa la Bandeja de entrada El propietario del producto revisa todos los temas en la Bandeja de entrada y decide cmo manejarlos. Se puede optar por aplazar la decisin al seleccionar Suspender en el men entidad. De lo contrario, selecciona para convertir el nmero 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 reunin de planificacin de Sprint se lleva a cabo y el equipo decide sobre la cantidad de trabajo que pueden manejar durante el siguiente sprint, tambin deben tener en cuenta el trabajo que se tiene que invertir en la solucin de bug. En caso de que alcance un error es demasiado grande o poco claro de lo contrario, podra ser una mejor idea de crear una historia a partir de ella.

Dueo 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 an no se ha creado.

Cerrado Issues Cerrado Issues son cuestiones que se han abordado suficientemente. Las soluciones de los problemas incluyen una resolucin 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 pblico. Hay dos tipos de prensa: Comunicados y notas de correccin de errores. Las primeras representan una versin 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 rpidamente).

La asociacin 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. Adems, 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 reunin diaria de Scrum), el Scrum Master crea un impedimento para documentar su existencia. A continuacin, trabaja para eliminar los impedimentos que obstaculizan el trabajo

del Equipo. Tan pronto como se encuentre una solucin, cierra el impedimento al seleccionar Cerrar en el men de la entidad y de los documentos de la solucin, por lo que entonces los miembros del equipo pueden comprobar de nuevo para ver si y cmo un impedimento estaba resuelto.

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

Gestin de Riesgos Miembros del Proyecto de Gestin de Riesgos debe hacer para evitar el fracaso del proyecto debido a la aparicin inesperada de problemas. Al anticipar y evaluar los posibles problemas, gestin de riesgos permite que el proyecto contine sin problemas, incluso cuando se producen problemas.

Evaluacin de Riesgos Los riesgos se evalan mediante la estimacin 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 dao al proyecto que puede ser inducida por el problema. Mediante el desarrollo de la probabilidad y la mitigacin del impacto previsto del equipo puede reducir la probabilidad y el impacto, lo que hace un resultado favorable proyecto ms probable.

Priorizacin de Riesgos Los riesgos se priorizan automticamente en funcin de los valores de probabilidad e impacto de acuerdo con la siguiente tabla:
likely very likely extreme substantial medium minor negligible Severe Very High High Significant Moderate Severe High Significant Moderate Moderate High Significant Moderate Moderate Low Significant Moderate Moderate Low Very Low Moderate Moderate Moderate Very Low Very Low possible unlikely very unlikely

seguimiento de los riesgos

Riesgos debe ser constantemente supervisado y revisado por lo menos una vez al mes. La eficacia de la gestin de riesgos depende de los datos que son hasta la fecha los miembros del proyecto y que se adhieren a los planes de mitigacin existentes.

Journal
El Diario del Proyecto cronolgicamente 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.

Dueo del Producto prepara Siguiente Sprint El propietario del producto puede seleccionar una fecha de inicio y la duracin de Sprint y Sprint debe hacerle el un nombre basado en el objetivo del Sprint. Despus de la reunin de revisin 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 despus 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 nmero), mientras que los debates vinculados a alguna entidad tienen el mismo ID que la entidad correspondiente (por ejemplo sto42 para una discusin 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 das a la misma hora (y el mismo lugar) un Scrum diaria debe realizarse (y supervisadas por el Scrum Master). En esta reunin 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 Dueo del Producto invita al equipo a hacer una reunin de planificacin Scrum, en la que el equipo selecciona Historias de la Pila de Producto y se compromete a completar durante el prximo Sprint.

Al final del Sprint, Sprint Sprint examen y las reuniones se llevan a cabo retrospectivos. En las reuniones de revisin 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 nmero). Cuando se utiliza este ID en algn lugar dentro de Kunagi (como en las descripciones de la entidad o chat), un enlace al archivo correspondiente se crea automticamente.

Subir desde formas Puede utilizar la funcin de carga no slo en la vista del repositorio de archivos, sino tambin, durante la edicin de otras entidades en el proyecto, utilizando la barra de herramientas de edicin de texto.

Courtroom
La sala se puede utilizar para realizar un seguimiento de violacines regla participantes del proyecto.

Acuerdo en el castigo, utilizar los ingresos Por ejemplo, usted podra 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 nmero de violacines 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 informacin relacionada con el proyecto, tales como notas de la versin o las hojas de ruta para el desarrollo, para el pblico.

Creacin y publicacin 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 preparacin de

antemano. El propietario del producto puede publicar entradas de blog. Slo las entradas publicadas se tendrn en cuenta los datos del proyecto cuando se exporta.