Hace un tiempo hablé de diferentes herramientas para gestión de proyectos, de entre todas ellas elegí Kunagi.

Está en inglés y he intentado traducirlo, pero me encontré con que no es posible. Así que al menos voy a realizar pequeña user guide en español para ver como funciona.

En cada una de las secciones de kunagi existen un poco de documentación donde se explica en detalle para que funcionalidad tiene esa parte de la aplicación. He dividido por títulos y subtítulos.

Al final he dejado un PDF con el post.

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  oOwner determinan la 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 priorizan: la más importante estará más arriba que 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 backlog puede 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 manejar los. 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.

Aquí os dejo el PDF