https://dosideas.com/wiki/api.php?action=feedcontributions&user=Cblatter&feedformat=atomDos Ideas. - Contribuciones del usuario [es]2024-03-28T09:00:48ZContribuciones del usuarioMediaWiki 1.28.2https://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6755Valor de Negocio2012-12-10T14:57:45Z<p>Cblatter: /* Un ejercicio para priorizar el backlog del producto utilizando el cuadrante */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio ! Ah ... quizás lo que no importa al principio tampoco importa al final y no se tenga que hacer porque nadie quiere pagarlo ¿ no ?<br />
<br />
==Un ejercicio para priorizar el backlog del producto utilizando el cuadrante ==<br />
<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Explicar las dimensiones del cuadrante al dueño del producto<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del cuadrante que mejor aplica<br />
* Consensuar la importancia de cada cuadrante, de más a menos importante<br />
* Pedir al dueño de producto que valorice iniciativas de los cuadrantes DESTACA e IMPORTANTE PARA LA COMPAÑÍA<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Un ejercicio para priorizar el backlog del producto en función a objetivos==<br />
<br />
* Obtener objetivos anuales, trimestrales, mensuales de la compañia<br />
* Pedir al dueño de producto que priorice los objetivos, de izquierda a derecha, dejando a la izquierda los de mayor prioridad<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del objetivo que mejor aplica<br />
* Pedir al dueño de producto que valorice las iniciativas<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6754Valor de Negocio2012-12-10T14:57:16Z<p>Cblatter: /* Un ejercicio para priorizar el backlog del producto utilizando el cuadrante */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio ! Ah ... quizás lo que no importa al principio tampoco importa al final y no se tenga que hacer porque nadie quiere pagarlo ¿ no ?<br />
<br />
==Un ejercicio para priorizar el backlog del producto utilizando el cuadrante ==<br />
<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Explicar las dimensiones del cuadrante al dueño del producto<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del cuadrante que mejor aplica<br />
* Consensuar la importancia de cada cuadrante de más a menos importante<br />
* Pedir al dueño de producto que valorice iniciativas de los cuadrantes DESTACA e IMPORTANTE PARA LA COMPAÑÍA<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Un ejercicio para priorizar el backlog del producto en función a objetivos==<br />
<br />
* Obtener objetivos anuales, trimestrales, mensuales de la compañia<br />
* Pedir al dueño de producto que priorice los objetivos, de izquierda a derecha, dejando a la izquierda los de mayor prioridad<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del objetivo que mejor aplica<br />
* Pedir al dueño de producto que valorice las iniciativas<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6753Valor de Negocio2012-12-10T14:18:34Z<p>Cblatter: </p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio ! Ah ... quizás lo que no importa al principio tampoco importa al final y no se tenga que hacer porque nadie quiere pagarlo ¿ no ?<br />
<br />
==Un ejercicio para priorizar el backlog del producto utilizando el cuadrante ==<br />
<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Explicar las dimensiones del cuadrante al dueño del producto<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del caudrante que mejor aplica<br />
* Consensuar las prioridades del cuadrante con el usuario <br />
* Pedir al dueño de producto que valorice iniciativas de los cuadrantes DESTACA e IMPORTANTE PARA LA COMPAÑÍA<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Un ejercicio para priorizar el backlog del producto en función a objetivos==<br />
<br />
* Obtener objetivos anuales, trimestrales, mensuales de la compañia<br />
* Pedir al dueño de producto que priorice los objetivos, de izquierda a derecha, dejando a la izquierda los de mayor prioridad<br />
* Conocer las iniciativas, actividades o funcionalidades que se esperan incorporar al producto o aplicación<br />
* Pedir al dueño de producto que ubique las iniciativas debajo del objetivo que mejor aplica<br />
* Pedir al dueño de producto que valorice las iniciativas<br />
* El resultado del ejercicio es obtener un número de iniciativas para las primeras iteraciones a planificar<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Personas&diff=6687Personas2012-09-11T15:48:26Z<p>Cblatter: </p>
<hr />
<div>La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de una historia desde la perspectiva de un cliente concreto y permitar que el equipo de desarrollo comprenda mejor las necesidades del usuario. Es más gráfica la descripción de una persona que reúna las características de una determinada área que la de un rol.<br />
<br />
Un personaje debe ser descrito como si fuera una persona real. Entonces, debe proporcionar un nombre, la personalidad, la familia, antecedentes de trabajo, nivel de habilidad, las preferencias, patrones de comportamiento y las actitudes personales. También es una buena práctica incluir una imagen y escribir una breve narración de un día de su vida que ayude al equipo a visualizar el usuario. <br />
<br />
Es necesario hacer una investigación previa de los usuarios reales para asegurarse que el personaje representa a los usuarios finales en lugar de la opinión de la persona que escribe los personajes. Esto ayudará a comprender mejor el uso de una funcionalidad que lo que hoy obtiene con el rol. Dependiendo del tamaño de la base de usuarios potenciales y la diversidad de esa población, los personajes identificados pueden variar desde un pequeño grupo de una docena o más. Un error frecuente consiste en diseñar para alguien que está cerca del producto, pero no es el usuario real ... el administrador de TI que rara vez va a ser el que realmente utilice el producto.<br />
<br />
== Ventajas ==<br />
<br />
* El personaje ayuda a los miembros del equipo a entender el contexto de uso de una historia<br />
* La solución propuesta puede estar guiada por lo bien que cumplen con la necesidad de uso del personaje<br />
* Proporcionar una cara humana permite centrar la empatía en las personas que representa el personaje<br />
<br />
== Desventajas ==<br />
<br />
* Los personajes son de ficción y a menudo hay una tendencia a crear personajes que encarnan los rasgos que son comunes a la mayoría de los usuarios, pero al crear un usuario genérico puede conducir a un software que está diseñado para ser todo para todos<br />
* El personaje puede no ser un buen sustituto de un usuario real<br />
<br />
== Material de Referencia ==<br />
<br />
* [http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02| The Agile Extension.pdf ]<br />
* [http://borisgloger.com/en/2012/04/01/the-user-role-is-dead-the-persona-lives/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+borisgloger-en+%28bor!sgloger+-+leading+Scrum+with+passion+-+English+%29&utm_content=Google+Reader| The user role is dead the persona lives]<br />
<br />
== Ver también ==<br />
<br />
* [[Backlog Del Producto]]<br />
* [[Mapa de historias]]<br />
* [[Scrum]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Backlog_Del_Producto&diff=6686Backlog Del Producto2012-09-11T14:46:34Z<p>Cblatter: /* Una técnica de priorización */</p>
<hr />
<div>[[Category:Scrum]]<br />
<br />
== Qué es el backlog o pila de producto? ==<br />
<br />
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.<br />
<br />
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog...<br />
<br />
== Cuándo está completo? ==<br />
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución.<br />
Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.<br />
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.<br />
Es importante disponer de una visión real, comprendida y compartida por todo el equipo.<br />
<br />
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.<br />
<br />
== Formato ==<br />
<br />
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.<br />
<br />
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:<br />
<br />
* Identificador único de la [[historia de usuario]]<br />
* Títilo de la [[historia de usuario]]<br />
* Descripción de la [[historia de usuario]]<br />
* Importancia<br />
* Estimación<br />
* Criterio de aceptación<br />
* Notas a considerar por el equipo de trabajo<br />
<br />
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.<br />
<br />
== Características de un backlog orientado al cliente ==<br />
<br />
* Tiene etapas o fases y cada una aporta valor al usuario del producto<br />
* Permite entender la complejidad de la funcionalidad <br />
* La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio<br />
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto<br />
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado<br />
* Permite saber si una funcionalidad puede suplirse con la combinación de otras<br />
* Da noción de volúmen de información que se manipula en cada funcionalidad <br />
<br />
== Pasos para priorizar el backlog del producto ==<br />
<br />
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.<br />
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. <br />
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.<br />
<br />
== Una técnica de priorización ==<br />
<br />
# Proponer al dueño de producto y demás involucrados que ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia).<br />
# Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo.<br />
# Explicar que la dinámica es de 30 minutos.<br />
# Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1.<br />
# Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado.<br />
# Ahora repita el paso 4 para las tarjetas de prioridad 1.<br />
# Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas.<br />
# Si usted todavía tiene tiempo, puede pedir a los participantes que ordene las tarjetas de prioridad 1. Una alternativa es seguir dividiendo la columna 1 hasta tener el número deseado de tarjetas.<br />
<br />
== Material de referencia ==<br />
<br />
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]<br />
* [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/]<br />
* [http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/ http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/]<br />
<br />
== Ver también ==<br />
<br />
* [[Historia de usuario]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Backlog_Del_Producto&diff=6685Backlog Del Producto2012-09-11T14:45:18Z<p>Cblatter: /* Una técnica de priorización */</p>
<hr />
<div>[[Category:Scrum]]<br />
<br />
== Qué es el backlog o pila de producto? ==<br />
<br />
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.<br />
<br />
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog...<br />
<br />
== Cuándo está completo? ==<br />
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución.<br />
Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.<br />
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.<br />
Es importante disponer de una visión real, comprendida y compartida por todo el equipo.<br />
<br />
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.<br />
<br />
== Formato ==<br />
<br />
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.<br />
<br />
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:<br />
<br />
* Identificador único de la [[historia de usuario]]<br />
* Títilo de la [[historia de usuario]]<br />
* Descripción de la [[historia de usuario]]<br />
* Importancia<br />
* Estimación<br />
* Criterio de aceptación<br />
* Notas a considerar por el equipo de trabajo<br />
<br />
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.<br />
<br />
== Características de un backlog orientado al cliente ==<br />
<br />
* Tiene etapas o fases y cada una aporta valor al usuario del producto<br />
* Permite entender la complejidad de la funcionalidad <br />
* La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio<br />
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto<br />
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado<br />
* Permite saber si una funcionalidad puede suplirse con la combinación de otras<br />
* Da noción de volúmen de información que se manipula en cada funcionalidad <br />
<br />
== Pasos para priorizar el backlog del producto ==<br />
<br />
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.<br />
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. <br />
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.<br />
<br />
== Una técnica de priorización ==<br />
<br />
# Proponer al dueño de producto y demás involucrados que ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia).<br />
# Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo.<br />
# Explicar que la dinámica es de 30 minutos.<br />
# Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1.<br />
# Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado.<br />
# Ahora repita el paso 4 para las tarjetas de prioridad 1.<br />
# Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas.<br />
# Si usted todavía tiene tiempo, ahora se puede pedir a los participantes para ordenar las tarjetas de prioridad 1. Una alternativa es seguir dividiendo la columna 1 hasta tener el número deseado de tarjetas.<br />
<br />
== Material de referencia ==<br />
<br />
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]<br />
* [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/]<br />
* [http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/ http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/]<br />
<br />
== Ver también ==<br />
<br />
* [[Historia de usuario]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Backlog_Del_Producto&diff=6684Backlog Del Producto2012-09-11T14:40:15Z<p>Cblatter: /* Una técnica de priorización */</p>
<hr />
<div>[[Category:Scrum]]<br />
<br />
== Qué es el backlog o pila de producto? ==<br />
<br />
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.<br />
<br />
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog...<br />
<br />
== Cuándo está completo? ==<br />
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución.<br />
Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.<br />
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.<br />
Es importante disponer de una visión real, comprendida y compartida por todo el equipo.<br />
<br />
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.<br />
<br />
== Formato ==<br />
<br />
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.<br />
<br />
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:<br />
<br />
* Identificador único de la [[historia de usuario]]<br />
* Títilo de la [[historia de usuario]]<br />
* Descripción de la [[historia de usuario]]<br />
* Importancia<br />
* Estimación<br />
* Criterio de aceptación<br />
* Notas a considerar por el equipo de trabajo<br />
<br />
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.<br />
<br />
== Características de un backlog orientado al cliente ==<br />
<br />
* Tiene etapas o fases y cada una aporta valor al usuario del producto<br />
* Permite entender la complejidad de la funcionalidad <br />
* La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio<br />
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto<br />
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado<br />
* Permite saber si una funcionalidad puede suplirse con la combinación de otras<br />
* Da noción de volúmen de información que se manipula en cada funcionalidad <br />
<br />
== Pasos para priorizar el backlog del producto ==<br />
<br />
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.<br />
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. <br />
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.<br />
<br />
== Una técnica de priorización ==<br />
<br />
# Proponer al dueño de producto y demás involucrados que ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia)<br />
# Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo<br />
# Explicar que la dinámica es de 30 minutos<br />
# Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1<br />
# Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado<br />
# Ahora repita el paso 4 para las tarjetas de prioridad 1<br />
# Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas<br />
# Si usted todavía tiene tiempo, ahora se puede pedir a los participantes para ordenar las tarjetas de prioridad 1. Una alternativa es repetir el paso 4.<br />
<br />
== Material de referencia ==<br />
<br />
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]<br />
* [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/]<br />
* [http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/ http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/]<br />
<br />
== Ver también ==<br />
<br />
* [[Historia de usuario]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6683Mapa de historias2012-09-11T13:07:21Z<p>Cblatter: </p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.<br />
#Ordenar las tarjetas según el uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias.<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
'''FALTA GRAFICO (PUEDE SER UNA FOTO DEL PROYECTO MODELO EN PIVOTAL)'''<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Material de Referencia ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
<br />
== Ver también ==<br />
<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Historia_de_usuario&diff=6682Historia de usuario2012-09-11T13:05:58Z<p>Cblatter: </p>
<hr />
<div>Una historia de usuario es una descripción funcional de una parte del software.<br />
<br />
== ¿ Por qué escribimos historias de usuario ? ==<br />
<br />
* Orientan a registrar funcionalidad<br />
* Enfatizan la comunicación verbal<br />
* Enfocan en los aspectos relevantes del momento y los detalles pueden verse en el momento más oportuno<br />
* Tienen un buen tamaño para planificar<br />
* Funcionan bien en el desarrollo iterativo<br />
<br />
== ¿ Qué incluyen las historias de usuario? ==<br />
<br />
* Una descripción escrita: es un item del [[Backlog Del Producto]]<br />
* Conversación con el cliente: guardamos apuntes, información obtenida, prototipos<br />
* Confirmación: pruebas que limiten el alcance de la historia<br />
<br />
== Características de las historias de usuario ==<br />
<br />
* Independientes: cada historia es coherente por si misma<br />
* Negociables: se negocia el objetivo y alcance a través de la conversación<br />
* Valiosas para el usuario: añade valor al producto<br />
* Estimables<br />
* Small: pequeñas en esfuerzo para el equipo de trabajo (no más de 2-3 personas/semana de trabajo)<br />
* Testeables: necesitamos saber que vamos a poder probarla<br />
<br />
----<br />
I.N.V.E.S.T.: invertir en<br />
----<br />
<br />
== Historias funcionales ==<br />
<br />
* Escribir historias funcionales nos ayuda a pensar en entregar valor al usuario<br />
<br />
=== ¿ Qué hacemos con historias no funcionales ? === <br />
<br />
* las historias tienen que aportarle valor al usuario y si necesitamos incluir cuestiones técnicas nos conviene incluir tareas en las primeras historias<br />
* en primeras etapas escribir super historias que puedan ser negociadas con el usuario<br />
<br />
=== Desventaja aparente por tener solo historias funcionales ===<br />
<br />
* Unicamente se explica el producto a nivel de cliente<br />
<br />
=== Ventaja aparente por tener solo historias funcionales ===<br />
<br />
* Fuerza a centrarse en la colaboración con el cliente<br />
* No se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente<br />
<br />
=== Ejemplo de una historia de usuario ===<br />
<br />
Historia: Préstamo de libro <br><br />
ID: 5 <br><br />
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento. <br><br />
Importancia: 300 <br><br />
Cómo probarlo: <br />
* Introducir un número de socio incorrecto y comprobar que se indica error<br />
* Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error<br />
* Introducir un libro del que no hay ejemplares y comprobar que se indica un error<br />
* Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno<br />
<br />
=== Ejemplo gráfico de una historia de usuario ===<br />
<br />
[http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/ http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/]<br />
<br />
== Ejercicio para escribir historias de usuario ==<br />
<br />
La propuesta es trabajar con el siguiente ejemplo de requerimiento de usuario de biblioteca y escribir las historias de usuario.<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
Recomendamos hacer la actividad en equipo con un moderador para luego entre todos construir el backlog del producto.<br />
<br />
== Material de Referencia ==<br />
<br />
* [http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011 http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011]<br />
* [http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1 http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1]<br />
* [https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java]<br />
* [http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/]<br />
* [http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html]<br />
<br />
== Ver también ==<br />
<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]<br />
* [[Mapa de historias]]<br />
* [[Personas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Backlog_Del_Producto&diff=6681Backlog Del Producto2012-09-11T13:04:55Z<p>Cblatter: </p>
<hr />
<div>[[Category:Scrum]]<br />
<br />
== Qué es el backlog o pila de producto? ==<br />
<br />
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.<br />
<br />
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog...<br />
<br />
== Cuándo está completo? ==<br />
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución.<br />
Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.<br />
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.<br />
Es importante disponer de una visión real, comprendida y compartida por todo el equipo.<br />
<br />
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.<br />
<br />
== Formato ==<br />
<br />
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.<br />
<br />
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:<br />
<br />
* Identificador único de la [[historia de usuario]]<br />
* Títilo de la [[historia de usuario]]<br />
* Descripción de la [[historia de usuario]]<br />
* Importancia<br />
* Estimación<br />
* Criterio de aceptación<br />
* Notas a considerar por el equipo de trabajo<br />
<br />
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.<br />
<br />
== Características de un backlog orientado al cliente ==<br />
<br />
* Tiene etapas o fases y cada una aporta valor al usuario del producto<br />
* Permite entender la complejidad de la funcionalidad <br />
* La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio<br />
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto<br />
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado<br />
* Permite saber si una funcionalidad puede suplirse con la combinación de otras<br />
* Da noción de volúmen de información que se manipula en cada funcionalidad <br />
<br />
== Pasos para priorizar el backlog del producto ==<br />
<br />
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.<br />
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. <br />
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.<br />
<br />
== Una técnica de priorización ==<br />
<br />
# Proponer al dueño de producto y demás involucrados qie ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia)<br />
# Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo<br />
# Explicar que la dinámica es de 30 minutos<br />
# Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1<br />
# Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado<br />
# Ahora repita el paso 4 para las tarjetas de prioridad 1<br />
# Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas<br />
# Si usted todavía tiene tiempo, ahora se puede pedir a los participantes para ordenar las tarjetas de prioridad 1. Una alternativa es repetir el paso 4.<br />
<br />
== Material de referencia ==<br />
<br />
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]<br />
* [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/]<br />
* [http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/ http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/]<br />
<br />
== Ver también ==<br />
<br />
* [[Historia de usuario]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Personas&diff=6680Personas2012-09-10T14:38:56Z<p>Cblatter: /* Ventajas */</p>
<hr />
<div>La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de una historia desde la perspectiva de un cliente concreto y permitar que el equipo de desarrollo comprenda mejor las necesidades del usuario. Es más gráfica la descripción de una persona que reúna las características de una determinada área que la de un rol.<br />
<br />
Un personaje debe ser descrito como si fuera una persona real. Entonces, debe proporcionar un nombre, la personalidad, la familia, antecedentes de trabajo, nivel de habilidad, las preferencias, patrones de comportamiento y las actitudes personales. También es una buena práctica incluir una imagen y escribir una breve narración de un día de su vida que ayude al equipo a visualizar el usuario. <br />
<br />
Es necesario hacer una investigación previa de los usuarios reales para asegurarse que el personaje representa a los usuarios finales en lugar de la opinión de la persona que escribe los personajes. Esto ayudará a comprender mejor el uso de una funcionalidad que lo que hoy obtiene con el rol. Dependiendo del tamaño de la base de usuarios potenciales y la diversidad de esa población, los personajes identificados pueden variar desde un pequeño grupo de una docena o más. Un error frecuente consiste en diseñar para alguien que está cerca del producto, pero no es el usuario real ... el administrador de TI que rara vez va a ser el que realmente utilice el producto.<br />
<br />
== Ventajas ==<br />
<br />
* El personaje ayuda a los miembros del equipo a entender el contexto de uso de una historia<br />
* La solución propuesta puede estar guiada por lo bien que cumplen con la necesidad de uso del personaje<br />
* Proporcionar una cara humana permite centrar la empatía en las personas que representa el personaje<br />
<br />
== Desventajas ==<br />
<br />
* Los personajes son de ficción y a menudo hay una tendencia a crear personajes que encarnan los rasgos que son comunes a la mayoría de los usuarios, pero al crear un usuario genérico puede conducir a un software que está diseñado para ser todo para todos<br />
* El personaje puede no ser un buen sustituto de un usuario real<br />
<br />
== Ver también ==<br />
<br />
* [http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02| The Agile Extension.pdf ]<br />
* [http://borisgloger.com/en/2012/04/01/the-user-role-is-dead-the-persona-lives/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+borisgloger-en+%28bor!sgloger+-+leading+Scrum+with+passion+-+English+%29&utm_content=Google+Reader| The user role is dead the persona lives]<br />
* [[Backlog Del Producto]]<br />
* [[Mapa de historias]]<br />
* [[Scrum]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Personas&diff=6679Personas2012-09-10T14:31:35Z<p>Cblatter: /* Ver también */</p>
<hr />
<div>La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de una historia desde la perspectiva de un cliente concreto y permitar que el equipo de desarrollo comprenda mejor las necesidades del usuario. Es más gráfica la descripción de una persona que reúna las características de una determinada área que la de un rol.<br />
<br />
Un personaje debe ser descrito como si fuera una persona real. Entonces, debe proporcionar un nombre, la personalidad, la familia, antecedentes de trabajo, nivel de habilidad, las preferencias, patrones de comportamiento y las actitudes personales. También es una buena práctica incluir una imagen y escribir una breve narración de un día de su vida que ayude al equipo a visualizar el usuario. <br />
<br />
Es necesario hacer una investigación previa de los usuarios reales para asegurarse que el personaje representa a los usuarios finales en lugar de la opinión de la persona que escribe los personajes. Esto ayudará a comprender mejor el uso de una funcionalidad que lo que hoy obtiene con el rol. Dependiendo del tamaño de la base de usuarios potenciales y la diversidad de esa población, los personajes identificados pueden variar desde un pequeño grupo de una docena o más. Un error frecuente consiste en diseñar para alguien que está cerca del producto, pero no es el usuario real ... el administrador de TI que rara vez va a ser el que realmente utilice el producto.<br />
<br />
== Ventajas ==<br />
<br />
* El personaje ayuda a los miembros del equipo a entender el contexto de uso de una historia<br />
* La solución propuesta pueden estar guiadas por lo bien que cumplen con la necesidad de uso del personaje<br />
* Proporcionar una cara humana permite centrar la empatía en las personas que representa el personaje<br />
• Proporcionar un ser humano "cara" a fin de centrar la empatía en las personas<br />
<br />
== Desventajas ==<br />
<br />
* Los personajes son de ficción y a menudo hay una tendencia a crear personajes que encarnan los rasgos que son comunes a la mayoría de los usuarios, pero al crear un usuario genérico puede conducir a un software que está diseñado para ser todo para todos<br />
* El personaje puede no ser un buen sustituto de un usuario real<br />
<br />
== Ver también ==<br />
<br />
* [http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02| The Agile Extension.pdf ]<br />
* [http://borisgloger.com/en/2012/04/01/the-user-role-is-dead-the-persona-lives/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+borisgloger-en+%28bor!sgloger+-+leading+Scrum+with+passion+-+English+%29&utm_content=Google+Reader| The user role is dead the persona lives]<br />
* [[Backlog Del Producto]]<br />
* [[Mapa de historias]]<br />
* [[Scrum]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Personas&diff=6678Personas2012-09-10T14:30:52Z<p>Cblatter: /* Ver también */</p>
<hr />
<div>La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de una historia desde la perspectiva de un cliente concreto y permitar que el equipo de desarrollo comprenda mejor las necesidades del usuario. Es más gráfica la descripción de una persona que reúna las características de una determinada área que la de un rol.<br />
<br />
Un personaje debe ser descrito como si fuera una persona real. Entonces, debe proporcionar un nombre, la personalidad, la familia, antecedentes de trabajo, nivel de habilidad, las preferencias, patrones de comportamiento y las actitudes personales. También es una buena práctica incluir una imagen y escribir una breve narración de un día de su vida que ayude al equipo a visualizar el usuario. <br />
<br />
Es necesario hacer una investigación previa de los usuarios reales para asegurarse que el personaje representa a los usuarios finales en lugar de la opinión de la persona que escribe los personajes. Esto ayudará a comprender mejor el uso de una funcionalidad que lo que hoy obtiene con el rol. Dependiendo del tamaño de la base de usuarios potenciales y la diversidad de esa población, los personajes identificados pueden variar desde un pequeño grupo de una docena o más. Un error frecuente consiste en diseñar para alguien que está cerca del producto, pero no es el usuario real ... el administrador de TI que rara vez va a ser el que realmente utilice el producto.<br />
<br />
== Ventajas ==<br />
<br />
* El personaje ayuda a los miembros del equipo a entender el contexto de uso de una historia<br />
* La solución propuesta pueden estar guiadas por lo bien que cumplen con la necesidad de uso del personaje<br />
* Proporcionar una cara humana permite centrar la empatía en las personas que representa el personaje<br />
• Proporcionar un ser humano "cara" a fin de centrar la empatía en las personas<br />
<br />
== Desventajas ==<br />
<br />
* Los personajes son de ficción y a menudo hay una tendencia a crear personajes que encarnan los rasgos que son comunes a la mayoría de los usuarios, pero al crear un usuario genérico puede conducir a un software que está diseñado para ser todo para todos<br />
* El personaje puede no ser un buen sustituto de un usuario real<br />
<br />
== Ver también ==<br />
<br />
* [http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02 |The Agile Extension.pdf ]<br />
* [http://borisgloger.com/en/2012/04/01/the-user-role-is-dead-the-persona-lives/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+borisgloger-en+%28bor!sgloger+-+leading+Scrum+with+passion+-+English+%29&utm_content=Google+Reader| The user role is dead the persona lives]<br />
* [[Backlog Del Producto]]<br />
* [[Mapa de historias]]<br />
* [[Scrum]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Personas&diff=6677Personas2012-09-10T14:28:56Z<p>Cblatter: Página creada con 'La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de u…'</p>
<hr />
<div>La idea es usar personajes de ficción o arquetipos que ejemplifiquen la forma en que los usuarios típicos interactúan con un producto. El objetivo es comprender el valor de una historia desde la perspectiva de un cliente concreto y permitar que el equipo de desarrollo comprenda mejor las necesidades del usuario. Es más gráfica la descripción de una persona que reúna las características de una determinada área que la de un rol.<br />
<br />
Un personaje debe ser descrito como si fuera una persona real. Entonces, debe proporcionar un nombre, la personalidad, la familia, antecedentes de trabajo, nivel de habilidad, las preferencias, patrones de comportamiento y las actitudes personales. También es una buena práctica incluir una imagen y escribir una breve narración de un día de su vida que ayude al equipo a visualizar el usuario. <br />
<br />
Es necesario hacer una investigación previa de los usuarios reales para asegurarse que el personaje representa a los usuarios finales en lugar de la opinión de la persona que escribe los personajes. Esto ayudará a comprender mejor el uso de una funcionalidad que lo que hoy obtiene con el rol. Dependiendo del tamaño de la base de usuarios potenciales y la diversidad de esa población, los personajes identificados pueden variar desde un pequeño grupo de una docena o más. Un error frecuente consiste en diseñar para alguien que está cerca del producto, pero no es el usuario real ... el administrador de TI que rara vez va a ser el que realmente utilice el producto.<br />
<br />
== Ventajas ==<br />
<br />
* El personaje ayuda a los miembros del equipo a entender el contexto de uso de una historia<br />
* La solución propuesta pueden estar guiadas por lo bien que cumplen con la necesidad de uso del personaje<br />
* Proporcionar una cara humana permite centrar la empatía en las personas que representa el personaje<br />
• Proporcionar un ser humano "cara" a fin de centrar la empatía en las personas<br />
<br />
== Desventajas ==<br />
<br />
* Los personajes son de ficción y a menudo hay una tendencia a crear personajes que encarnan los rasgos que son comunes a la mayoría de los usuarios, pero al crear un usuario genérico puede conducir a un software que está diseñado para ser todo para todos<br />
* El personaje puede no ser un buen sustituto de un usuario real<br />
<br />
== Ver también ==<br />
<br />
* [http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02]<br />
* [http://borisgloger.com/en/2012/04/01/the-user-role-is-dead-the-persona-lives/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+borisgloger-en+%28bor!sgloger+-+leading+Scrum+with+passion+-+English+%29&utm_content=Google+Reader]<br />
* [[Backlog Del Producto]]<br />
* [[Mapa de historias]]<br />
* [[Scrum]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Historia_de_usuario&diff=6676Historia de usuario2012-09-10T14:21:46Z<p>Cblatter: </p>
<hr />
<div>Una historia de usuario es una descripción funcional de una parte del software.<br />
<br />
== ¿ Por qué escribimos historias de usuario ? ==<br />
<br />
* Orientan a registrar funcionalidad<br />
* Enfatizan la comunicación verbal<br />
* Enfocan en los aspectos relevantes del momento y los detalles pueden verse en el momento más oportuno<br />
* Tienen un buen tamaño para planificar<br />
* Funcionan bien en el desarrollo iterativo<br />
<br />
== ¿ Qué incluyen las historias de usuario? ==<br />
<br />
* Una descripción escrita: es un item del [[Backlog Del Producto]]<br />
* Conversación con el cliente: guardamos apuntes, información obtenida, prototipos<br />
* Confirmación: pruebas que limiten el alcance de la historia<br />
<br />
== Características de las historias de usuario ==<br />
<br />
* Independientes: cada historia es coherente por si misma<br />
* Negociables: se negocia el objetivo y alcance a través de la conversación<br />
* Valiosas para el usuario: añade valor al producto<br />
* Estimables<br />
* Small: pequeñas en esfuerzo para el equipo de trabajo (no más de 2-3 personas/semana de trabajo)<br />
* Testeables: necesitamos saber que vamos a poder probarla<br />
<br />
----<br />
I.N.V.E.S.T.: invertir en<br />
----<br />
<br />
== Historias funcionales ==<br />
<br />
* Escribir historias funcionales nos ayuda a pensar en entregar valor al usuario<br />
<br />
=== ¿ Qué hacemos con historias no funcionales ? === <br />
<br />
* las historias tienen que aportarle valor al usuario y si necesitamos incluir cuestiones técnicas nos conviene incluir tareas en las primeras historias<br />
* en primeras etapas escribir super historias que puedan ser negociadas con el usuario<br />
<br />
=== Desventaja aparente por tener solo historias funcionales ===<br />
<br />
* Unicamente se explica el producto a nivel de cliente<br />
<br />
=== Ventaja aparente por tener solo historias funcionales ===<br />
<br />
* Fuerza a centrarse en la colaboración con el cliente<br />
* No se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente<br />
<br />
=== Ejemplo de una historia de usuario ===<br />
<br />
Historia: Préstamo de libro <br><br />
ID: 5 <br><br />
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento. <br><br />
Importancia: 300 <br><br />
Cómo probarlo: <br />
* Introducir un número de socio incorrecto y comprobar que se indica error<br />
* Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error<br />
* Introducir un libro del que no hay ejemplares y comprobar que se indica un error<br />
* Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno<br />
<br />
=== Ejemplo gráfico de una historia de usuario ===<br />
<br />
[http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/ http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/]<br />
<br />
== Ejercicio para escribir historias de usuario ==<br />
<br />
La propuesta es trabajar con el siguiente ejemplo de requerimiento de usuario de biblioteca y escribir las historias de usuario.<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
Recomendamos hacer la actividad en equipo con un moderador para luego entre todos construir el backlog del producto.<br />
<br />
== Ver también ==<br />
<br />
* [http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011 http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011]<br />
* [http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1 http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1]<br />
* [https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java]<br />
* [http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/]<br />
* [http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]<br />
* [[Mapa de historias]]<br />
* [[Personas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Metricas_Agiles&diff=6675Metricas Agiles2012-08-31T19:23:45Z<p>Cblatter: </p>
<hr />
<div>Hay distintas métricas en los proyectos de desarrollo:<br />
<br />
* de productividad y resultados del proyecto<br />
* de situación financiera<br />
* de riesgos <br />
* de calidad<br />
<br />
== Productividad y resultados del proyecto ==<br />
<br />
Muchos de los problemas detectados y disfuncionalidades de la organización seguramente existen desde antes de utilizar una gestión ágil de proyectos como [[Scrum]]. Esos problemas no son el resultado de aplicar las métricas sino que por el contrario nos aporta: <br />
<br />
* transparencia a los resultados del proyecto<br />
* ayuda a priorizar el trabajo<br />
* permite tomar decisiones entre las personas involucradas al proyecto <br />
<br />
<br />
==== ¿ Cuáles son las métricas que elegimos para medir productividad en nuestros proyectos ? ====<br />
<br />
* requisitos completados respecto al total de requisitos<br />
* valor que le dan al cliente los requisitos completados<br />
* la velocidad con qué se aporta valor al negocio<br />
* cambios y requisitos añadidos<br />
<br />
==== ¿ Qué hacer con estas métricas ? ====<br />
<br />
Estamos en condiciones de generar un tablero o cuadro de control de nuestro proyecto para que todos los involucrados estén informados y puedan tomar decisiones de su rol. <br />
<br />
El equipo de desarrollo podrá evaluar su propia velocidad, planificar y tomar compromisos. <br />
<br />
El cliente podrá replantear las prioridades que está eligiendo para sus requerimientos, y así con cada persona involucrada. <br />
<br />
Esta info a lo largo del tiempo muestra tendencias.<br />
<br />
==== ¿ Cómo obtener la información necesaria para el tablero ? ====<br />
<br />
Esta info surge de las herramientas de [[Scrum]]: backlog priorizado, burn down, burn up. Y un buen momento para actualizar el tablero es al finalizar cada iteración. Es conveniente compartir puntos destacados del proyecto, riesgos y próximos pasos en el mismo tablero.<br />
<br />
==== ¿ Cuál es la métrica más importante en un proyecto ágil ? ====<br />
<br />
El valor de negocio que se le está dando al cliente. <br />
<br />
Podemos no conocer la rentabilidad específica de un producto que desarrollamos y si podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañia.<br />
<br />
Entonces, podemos trabajar junto al dueño de producto para orientarnos a que obtenga su máximo valor de negocio lo antes posible.<br />
<br />
==== ¿ Por qué es importante considerar el valor de negocio ? ====<br />
<br />
El cliente puede conocer la velocidad con que retorna su inversión y cuando ya no es necesario seguir con el proyecto por que lo que resta hacer tiene un retorno que no compensa el costo.<br />
<br />
[[Archivo:Contrato-agil-change-for-free.gif]]<br />
<br />
== Ejemplo de tablero de productividad y resultados del proyecto ==<br />
<br />
[[Archivo:TableroDelProyecto.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [http://comunidadagil.org/2011/07/tableros-de-proyecto-en-entornos-agiles/ Template del tablero]<br />
* [http://www.proyectosagiles.org/metricas-agiles-cuadro-mandos-balanceado-scrum Métricas ágiles y cuadro de mandos integral para Scrum]<br />
* [http://www.proyectosagiles.org/contrato-agil-scrum Un contrato ágil para Scrum]<br />
* [http://www.proyectosagiles.org/priorizacion-requisitos-valor-coste Priorización de los requisitos por valor y coste]<br />
* [[Historia de usuario]]<br />
* [[Valor de Negocio]]<br />
* [[Backlog Del Producto]]<br />
* [[Gráfico de Burn-Down]]<br />
* [[Gráfico de Burn-Up]]<br />
* [[Velocidad Trabajo Tiempo]]<br />
* [[Hudson]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6674Valor de Negocio2012-08-31T19:08:17Z<p>Cblatter: </p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio ! Ah ... quizás lo que no importa al principio tampoco importa al final y no se tenga que hacer porque nadie quiere pagarlo ¿ no ?<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6673Valor de Negocio2012-08-31T18:44:35Z<p>Cblatter: /* Cuadrante ágil para ponderar el valor de negocio */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio ! Ah ... quizás lo que no importa al principio tampoco importa ahora y no se tenga que hacer porque nadie quiere pagarlo ¿ no ?<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6672Valor de Negocio2012-08-31T18:41:49Z<p>Cblatter: /* Cuadrante ágil para ponderar el valor de negocio */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio a los requerimientos puede ser usar cuadrantes que definan 2 dimensiones para un producto de software. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
Y así habremos priorizado por lo más importante desde el punto de vista del negocio !<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6671Valor de Negocio2012-08-31T18:39:26Z<p>Cblatter: /* ¿ Qué es ROI ? */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario y asociarle una ponderación <br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* a medida que vamos avanzando en el desarrollo y la funcionalidad está completa, mostrar el ROI obtenido<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6670Valor de Negocio2012-08-29T19:01:29Z<p>Cblatter: /* Cuadrante ágil para ponderar el valor de negocio */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo crítico<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6669Valor de Negocio2012-08-29T18:11:53Z<p>Cblatter: </p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo importante para la compañía<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [[Metricas Agiles]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6668Valor de Negocio2012-08-29T18:10:19Z<p>Cblatter: /* Cuadrante ágil para ponderar el valor de negocio */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
* lo destacado<br />
* lo importante para la compañía<br />
* lo importante para el cliente<br />
* a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6667Valor de Negocio2012-08-29T18:08:38Z<p>Cblatter: /* ¿ Qué es ROI ? */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir el ROI a medida que avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
- lo crítico<br />
- lo destacado<br />
- lo importante<br />
- a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6666Valor de Negocio2012-08-29T18:07:30Z<p>Cblatter: /* ¿ Qué es ROI ? */</p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular la ganancia generada a partir de una inversión dada.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir ese ROI a medida que el avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
- lo crítico<br />
- lo destacado<br />
- lo importante<br />
- a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6665Valor de Negocio2012-08-29T18:05:35Z<p>Cblatter: </p>
<hr />
<div>== ¿ Qué es ROI ? ==<br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. Es una fórmula financiera que sirve para calcular qué ganancia nos puede generar un servicio o producto.<br />
<br />
ROI = (ingreso - costo)/costo. <br />
<br />
Por ejemplo, si sabemos que un producto genera un ingreso anual de 2500 pesos y un gasto anual de 1000 pesos, podemos aplicar la fórmula de la siguiente manera:<br />
<br />
ROI = (2500 - 1000)/1000 = 1,5<br />
<br />
Entonces, el producto deja un 50 % de ganancia anual sobre el dinero invertido.<br />
<br />
Podemos desconocer la rentabilidad específica de un producto de software que desarrollamos. En ese caso, podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañía. Otra cosa que podemos hacer, es encontrar alguna manera de medir ese ROI a medida que el avanzamos en el desarrollo.<br />
<br />
Algunos consejos para dar visibilidad al retorno de inversión durante el proceso de desarrollo:<br />
<br />
* tomar funcionalidades representativas para el usuario<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
<br />
== Cuadrante ágil para ponderar el valor de negocio ==<br />
<br />
Una técnica para asociar valor de negocio puede ser usar cuadrantes que definan 2 dimensiones para un producto. <br />
<br />
La primera dimensión es para evaluar la diferenciación en el mercado. Con esta dimensión indicaríamos todo lo que sirve para diferenciar a la organización en el mercado y son fundamentales para el funcionamiento de la empresa. Estas son las cosas en las que la organización debiera estar dispuesta a invertir.<br />
<br />
La segunda dimensión es para evaluar la necesidad para el funcionamiento continuo de la organización. Con esta dimensión dejaríamos clasificado todo aquello que si bien no genera una diferencia en el mercado es crìtico para la compañía.<br />
<br />
Luego de la clasificación, podríamos tener la siguiente priorización:<br />
<br />
- lo crítico<br />
- lo destacado<br />
- lo importante<br />
- a quién le importa<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Valor_de_Negocio&diff=6664Valor de Negocio2012-08-29T17:44:20Z<p>Cblatter: Página creada con 'En ocasiones escuchamos hablar de ROI o Retorno de Inversión. ROI es una fórmula financiera tal que ROI = (ingreso - costo)/costo. Por ejemplo, podemos decir que si un product…'</p>
<hr />
<div>En ocasiones escuchamos hablar de ROI o Retorno de Inversión. ROI es una fórmula financiera tal que ROI = (ingreso - costo)/costo. Por ejemplo, podemos decir que si un producto genera un ingreso anual de 2500 $ y el costo anual de mantener ese producto es de 1000 $ entonces ese negocio nos deja un 50 % de ganancia anual sobre la inversión generada.<br />
<br />
Podemos no conocer la rentabilidad específica de un producto que desarrollamos y si podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañia.<br />
<br />
Entonces, podemos trabajar junto al dueño de producto para orientarnos a que obtenga su máximo valor de negocio lo antes posible.<br />
<br />
Algunos consejos para el ROI:<br />
<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* no tomar requisitos tan pequeños si el usuario no se siente representado<br />
* usar un cuadrante ágil<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Metricas_Agiles&diff=6663Metricas Agiles2012-08-29T17:40:41Z<p>Cblatter: </p>
<hr />
<div>Hay distintas métricas en los proyectos de desarrollo:<br />
<br />
* de productividad y resultados del proyecto<br />
* de situación financiera<br />
* de riesgos <br />
* de calidad<br />
<br />
== Productividad y resultados del proyecto ==<br />
<br />
Muchos de los problemas detectados y disfuncionalidades de la organización seguramente existen desde antes de utilizar una gestión ágil de proyectos como [[Scrum]]. Esos problemas no son el resultado de aplicar las métricas sino que por el contrario nos aporta: <br />
<br />
* transparencia a los resultados del proyecto<br />
* ayuda a priorizar el trabajo<br />
* permite tomar decisiones entre las personas involucradas al proyecto <br />
<br />
<br />
==== ¿ Cuáles son las métricas que elegimos para medir productividad en nuestros proyectos ? ====<br />
<br />
* requisitos completados respecto al total de requisitos<br />
* valor que le dan al cliente los requisitos completados<br />
* la velocidad con qué se aporta valor al negocio<br />
* cambios y requisitos añadidos<br />
<br />
==== ¿ Qué hacer con estas métricas ? ====<br />
<br />
Estamos en condiciones de generar un tablero o cuadro de control de nuestro proyecto para que todos los involucrados estén informados y puedan tomar decisiones de su rol. <br />
<br />
El equipo de desarrollo podrá evaluar su propia velocidad, planificar y tomar compromisos. <br />
<br />
El cliente podrá replantear las prioridades que está eligiendo para sus requerimientos, y así con cada persona involucrada. <br />
<br />
Esta info a lo largo del tiempo muestra tendencias.<br />
<br />
==== ¿ Cómo obtener la información necesaria para el tablero ? ====<br />
<br />
Esta info surge de las herramientas de [[Scrum]]: backlog priorizado, burn down, burn up. Y un buen momento para actualizar el tablero es al finalizar cada iteración. Es conveniente compartir puntos destacados del proyecto, riesgos y próximos pasos en el mismo tablero.<br />
<br />
==== ¿ Cuál es la métrica más importante en un proyecto ágil ? ====<br />
<br />
El valor de negocio que se le está dando al cliente. <br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. ROI es una fórmula financiera tal que ROI = (ingreso - costo)/costo. Por ejemplo, podemos decir que si un producto genera un ingreso anual de 2500 $ y el costo anual de mantener ese producto es de 1000 $ entonces ese negocio nos deja un 50 % de ganancia anual sobre la inversión generada.<br />
<br />
Podemos no conocer la rentabilidad específica de un producto que desarrollamos y si podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañia.<br />
<br />
Entonces, podemos trabajar junto al dueño de producto para orientarnos a que obtenga su máximo valor de negocio lo antes posible.<br />
<br />
==== ¿ Por qué es importante considerar el valor de negocio ? ====<br />
<br />
El cliente puede conocer la velocidad con que retorna su inversión y cuando ya no es necesario seguir con el proyecto por que lo que resta hacer tiene un retorno que no compensa el costo.<br />
<br />
[[Archivo:Contrato-agil-change-for-free.gif]]<br />
<br />
Algunos consejos para el ROI:<br />
<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* no tomar requisitos tan pequeños si el usuario no se siente representado<br />
<br />
== Ejemplo de tablero de productividad y resultados del proyecto ==<br />
<br />
[[Archivo:TableroDelProyecto.jpg]]<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [http://comunidadagil.org/2011/07/tableros-de-proyecto-en-entornos-agiles/ Template del tablero]<br />
* [http://www.proyectosagiles.org/metricas-agiles-cuadro-mandos-balanceado-scrum Métricas ágiles y cuadro de mandos integral para Scrum]<br />
* [http://www.proyectosagiles.org/contrato-agil-scrum Un contrato ágil para Scrum]<br />
* [http://www.proyectosagiles.org/priorizacion-requisitos-valor-coste Priorización de los requisitos por valor y coste]<br />
* [[Historia de usuario]]<br />
* [[Valor de Negocio]]<br />
* [[Backlog Del Producto]]<br />
* [[Gráfico de Burn-Down]]<br />
* [[Gráfico de Burn-Up]]<br />
* [[Velocidad Trabajo Tiempo]]<br />
* [[Hudson]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Archivo:CuadranteValorNegocio.jpg&diff=6662Archivo:CuadranteValorNegocio.jpg2012-08-29T17:21:08Z<p>Cblatter: subida una nueva versión de «Archivo:CuadranteValorNegocio.jpg»:&#32;A manopla es así de tedioso...</p>
<hr />
<div>Dos dimensiones para encontrar valor de negocio.</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Archivo:CuadranteValorNegocio.jpg&diff=6661Archivo:CuadranteValorNegocio.jpg2012-08-29T17:19:29Z<p>Cblatter: subida una nueva versión de «Archivo:CuadranteValorNegocio.jpg»:&#32;Achicando la imagen a manopla!!!!!!!</p>
<hr />
<div>Dos dimensiones para encontrar valor de negocio.</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Metricas_Agiles&diff=6660Metricas Agiles2012-08-29T17:14:58Z<p>Cblatter: /* Ejemplo de tablero de productividad y resultados del proyecto */</p>
<hr />
<div>Hay distintas métricas en los proyectos de desarrollo:<br />
<br />
* de productividad y resultados del proyecto<br />
* de situación financiera<br />
* de riesgos <br />
* de calidad<br />
<br />
== Productividad y resultados del proyecto ==<br />
<br />
Muchos de los problemas detectados y disfuncionalidades de la organización seguramente existen desde antes de utilizar una gestión ágil de proyectos como [[Scrum]]. Esos problemas no son el resultado de aplicar las métricas sino que por el contrario nos aporta: <br />
<br />
* transparencia a los resultados del proyecto<br />
* ayuda a priorizar el trabajo<br />
* permite tomar decisiones entre las personas involucradas al proyecto <br />
<br />
<br />
==== ¿ Cuáles son las métricas que elegimos para medir productividad en nuestros proyectos ? ====<br />
<br />
* requisitos completados respecto al total de requisitos<br />
* valor que le dan al cliente los requisitos completados<br />
* la velocidad con qué se aporta valor al negocio<br />
* cambios y requisitos añadidos<br />
<br />
==== ¿ Qué hacer con estas métricas ? ====<br />
<br />
Estamos en condiciones de generar un tablero o cuadro de control de nuestro proyecto para que todos los involucrados estén informados y puedan tomar decisiones de su rol. <br />
<br />
El equipo de desarrollo podrá evaluar su propia velocidad, planificar y tomar compromisos. <br />
<br />
El cliente podrá replantear las prioridades que está eligiendo para sus requerimientos, y así con cada persona involucrada. <br />
<br />
Esta info a lo largo del tiempo muestra tendencias.<br />
<br />
==== ¿ Cómo obtener la información necesaria para el tablero ? ====<br />
<br />
Esta info surge de las herramientas de [[Scrum]]: backlog priorizado, burn down, burn up. Y un buen momento para actualizar el tablero es al finalizar cada iteración. Es conveniente compartir puntos destacados del proyecto, riesgos y próximos pasos en el mismo tablero.<br />
<br />
==== ¿ Cuál es la métrica más importante en un proyecto ágil ? ====<br />
<br />
El valor de negocio que se le está dando al cliente. <br />
<br />
En ocasiones escuchamos hablar de ROI o Retorno de Inversión. ROI es una fórmula financiera tal que ROI = (ingreso - costo)/costo. Por ejemplo, podemos decir que si un producto genera un ingreso anual de 2500 $ y el costo anual de mantener ese producto es de 1000 $ entonces ese negocio nos deja un 50 % de ganancia anual sobre la inversión generada.<br />
<br />
Podemos no conocer la rentabilidad específica de un producto que desarrollamos y si podemos asumir que alguien analizó que ese producto genera una rentabilidad positiva para la compañia.<br />
<br />
Entonces, podemos trabajar junto al dueño de producto para orientarnos a que obtenga su máximo valor de negocio lo antes posible.<br />
<br />
==== ¿ Por qué es importante considerar el valor de negocio ? ====<br />
<br />
El cliente puede conocer la velocidad con que retorna su inversión y cuando ya no es necesario seguir con el proyecto por que lo que resta hacer tiene un retorno que no compensa el costo.<br />
<br />
[[Archivo:Contrato-agil-change-for-free.gif]]<br />
<br />
Algunos consejos para el ROI:<br />
<br />
* usar un valor tangible para medir el retorno: dinero, personas, tiempo<br />
* no tomar requisitos tan pequeños si el usuario no se siente representado<br />
<br />
== Ejemplo de tablero de productividad y resultados del proyecto ==<br />
<br />
[[Archivo:TableroDelProyecto.jpg]]<br />
<br />
[[Archivo:CuadranteValorNegocio.jpg]]<br />
<br />
==Ver también==<br />
<br />
* [http://comunidadagil.org/2011/07/tableros-de-proyecto-en-entornos-agiles/ Template del tablero]<br />
* [http://www.proyectosagiles.org/metricas-agiles-cuadro-mandos-balanceado-scrum Métricas ágiles y cuadro de mandos integral para Scrum]<br />
* [http://www.proyectosagiles.org/contrato-agil-scrum Un contrato ágil para Scrum]<br />
* [http://www.proyectosagiles.org/priorizacion-requisitos-valor-coste Priorización de los requisitos por valor y coste]<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Gráfico de Burn-Down]]<br />
* [[Gráfico de Burn-Up]]<br />
* [[Velocidad Trabajo Tiempo]]<br />
* [[Hudson]]<br />
<br />
[[Category:Scrum]]<br />
[[Category: Métricas]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Archivo:CuadranteValorNegocio.jpg&diff=6659Archivo:CuadranteValorNegocio.jpg2012-08-29T17:09:00Z<p>Cblatter: Dos dimensiones para encontrar valor de negocio.</p>
<hr />
<div>Dos dimensiones para encontrar valor de negocio.</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6598Mapa de historias2012-05-03T13:46:23Z<p>Cblatter: /* Ejemplo gráfico de un mapa de historias */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.<br />
#Ordenar las tarjetas según el uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias.<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
'''FALTA GRAFICO (PUEDE SER UNA FOTO DEL PROYECTO MODELO EN PIVOTAL)'''<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6597Mapa de historias2012-05-03T13:45:20Z<p>Cblatter: /* Ventajas */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.<br />
#Ordenar las tarjetas según el uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias.<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6596Mapa de historias2012-05-03T13:44:37Z<p>Cblatter: /* Proceso de construcción de un mapa de historias */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.<br />
#Ordenar las tarjetas según el uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer la siguiente pregunta: ¿ lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ?. Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6595Mapa de historias2012-05-03T13:43:18Z<p>Cblatter: /* Proceso de construcción de un mapa de historias */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada. La recomendación es utilizar un color que diferencie las tarjetas de este nivel.<br />
#Ordenar las tarjetas según el uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una tarjeta, utilizando un color diferente de las actividades planteadas más arriba.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Es posible que no represente una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Hacer preguntas del siguiente tipo: <br />
##¿ Lo que vemos es una imagen completa de lo que el producto tiene que ofrecer ? Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al realizar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superior de sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias en forma conjunta para proporcionar una vista del producto completo. La recomendación es indicar en el mapa cuando las historias está completa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6594Mapa de historias2012-05-03T13:35:47Z<p>Cblatter: /* Proceso de construcción de un mapa de historias */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
#Secuencia en orden de uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6593Mapa de historias2012-05-03T13:35:02Z<p>Cblatter: /* Proceso de construcción de un mapa de historias */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
#Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
#Secuencia en orden de uso, de izquierda a derecha. <br />
#Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
#Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
#Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las<br />
actividades y tareas según sea necesario.<br />
#Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
#Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
#Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6592Mapa de historias2012-05-03T13:34:04Z<p>Cblatter: /* Consideraciones a tener en cuenta */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
#Empezar por los objetivos de negocio.<br />
#Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
#Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
#Generar las etapas con las historias de usuario.<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
1. Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
2. Secuencia en orden de uso, de izquierda a derecha. <br />
3. Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
4. Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
5. Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las<br />
actividades y tareas según sea necesario.<br />
6. Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
7. Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
8. Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6591Mapa de historias2012-05-03T13:33:00Z<p>Cblatter: /* ¿ Cómo generar un mapa de historias ? */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo. Entonces, tenemos todas las actividades de los usuarios en el sistema a construir.<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
1º - Empezar por los objetivos de negocio.<br />
2º - Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
3º - Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
4º - Generar las etapas con las historias de usuario<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
1. Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
2. Secuencia en orden de uso, de izquierda a derecha. <br />
3. Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
4. Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
5. Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las<br />
actividades y tareas según sea necesario.<br />
6. Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
7. Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
8. Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6590Mapa de historias2012-05-03T13:31:19Z<p>Cblatter: /* ¿ Cómo surge esta técnica ? */</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. Y su idea principal surgió por la necesidad de contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo (en el sentido de que soporta todas las actividades de los usuarios del sistema).<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
1º - Empezar por los objetivos de negocio.<br />
2º - Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
3º - Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
4º - Generar las etapas con las historias de usuario<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
1. Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
2. Secuencia en orden de uso, de izquierda a derecha. <br />
3. Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
4. Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
5. Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las<br />
actividades y tareas según sea necesario.<br />
6. Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
7. Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
8. Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Mapa_de_historias&diff=6589Mapa de historias2012-05-03T13:29:47Z<p>Cblatter: Página creada con 'Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque …'</p>
<hr />
<div>Un mapa de historias (story map) es una herramienta para asistir en el entendimiento del producto, su uso y la priorización de las etapas o entregas productivas. Es un enfoque visual para construir un backlog del producto. <br />
<br />
El primer desafío de un equipo en el camino de la agilidad es el de armar un buen backlog de producto (product backlog) que permita realizar una planificación efectiva para la construcción del producto. No es fácil lograr el nivel adecuado de detalle, y corremos el riesgo de perdemos en la priorización de un mar de historias demasiado detalladas. Todavía más difícil es dividir efectivamente el backlog en etapas (releases) valiosas para el negocio e incorporar inteligentemente la devolución (feedback) a nuestros planes.<br />
<br />
== ¿ Cómo surge esta técnica ? ==<br />
<br />
La técnica fue desarrollada por Jeff Patton. La idea es contar con un enfoque visual a la hora de construir el backlog de un producto.<br />
<br />
== ¿ Cómo generar un mapa de historias ? ==<br />
<br />
Las historias de usuario se organizan en un modelo bidimensional en lugar de la clásica lista-sábana. Entonces:<br />
<br />
* el primer paso es pensar el producto desde los procesos de negocio y las necesidades de los usuarios. Así es más simple asegurar que el backlog está completo (en el sentido de que soporta todas las actividades de los usuarios del sistema).<br />
* el segundo paso es pensar las historias de usuario que se necesitan para llegar a los procesos de negocio y/o necesidades del usuario. De esta manera se visualizan más claramente las funcionalidades alternativas y la relación entre las historias de alto nivel y los detalles.<br />
<br />
== Consideraciones a tener en cuenta ==<br />
<br />
1º - Empezar por los objetivos de negocio.<br />
2º - Conocer las comunidades de usuarios, sus actividades y tareas antes de escribir las historias de usuario. Modela la secuencia de cosas desde el punto de vista del usuario.<br />
3º - Escribir las historias de usuario. Los items menos priorizados del backlog están menos refinados. No perder de vista la relación entre los objetivos de negocio y las historias de usuario. Una lista de cosas a construir puede hacer que nos enfoquemos demasiado en los detalles. Preguntas a considerar: ¿ cuan frecuente se utilizará? ¿ exosten alternativas para realizar lo mismo ? ¿ que tan crítico es contar con eso en el producto final ?<br />
4º - Generar las etapas con las historias de usuario<br />
<br />
== Proceso de construcción de un mapa de historias ==<br />
<br />
1. Identificar las principales actividades que el producto debe soportar, la escritura de cada actividad en una tarjeta separada o una nota adhesiva. Utilizar un color para tarjetas de actividades.<br />
2. Secuencia en orden de uso, de izquierda a derecha. <br />
3. Una vez que las actividades están en un orden lógico, definir las tareas individuales que conforman las actividades. Estas tareas deben ser una pieza discreta de trabajo para una persona que utiliza el producto. Escribir cada tarea por separado en una nota tarjeta o adhesivo, utilizando un color diferente de las actividades.<br />
4. Colocar las tareas en una sola fila en un orden lógico y secuencial por debajo de las actividades. Una vez más, a menudo no será una secuencia estricta<br />
que debe ser seguida cada vez, pero habrá un orden en que se realicen las tareas. Esta es la secuencia de las tareas en el mapa.<br />
5. Validar las actividades y tareas con los expertos de dominio y otras partes interesadas. Haga la pregunta: ¿constituyen una imagen completa de lo que el producto tiene que ofrecer? Actualizar y modificar las<br />
actividades y tareas según sea necesario.<br />
6. Añadir sub-tareas por debajo de las tareas, de nuevo utilizando una tarjeta de color diferente o nota adhesiva. Estas a menudo cubren las formas alternativas de llevar a cabo una tarea o un acuerdo con las excepciones o los problemas potenciales al reali|zar una tarea. Estas tareas están en el nivel de historia de usuario y habrá muchas de ellas. La visualización de la fila superiorde sub-tareas en el mapa ofrece una visión de producto de mínima esperado, el conjunto de características que deben ser entregados por el producto tiene que tener algún valor para el negocio. Esta visión horizontal de las historias de usuario proporciona un punto de partida lógico para la liberación y planificación de la iteración, como la posición vertical de una historia de usuario muestra su prioridad relativa en el panorama general.<br />
7. Validar el mapa de historias con las partes interesadas, y actualizarla cuando sea necesario.<br />
8. Mantener el mapa de historias juntos para proporcionar una vista del producto completo. Indique cuando las historias se completan en el mapa.<br />
<br />
== Ventajas ==<br />
<br />
* Es una herramienta interesante para la creación de etapas que aprovechen al máximo el aspecto iterativo y evolutivo del desarrollo ágil. <br />
* Puede ser una herramienta valiosa para coaches que quieran transmitir a equipos principiantes el concepto de historias de usuario y de backlog de producto.<br />
* Hace foco en el negocio y no en el detalle de las historias<br />
<br />
== Desventajas ==<br />
<br />
* Puede ponerse engorroso de hacer cuando el producto es demasiado grande y entonces sea necesario más de un mapa de historias, donde cada uno ilustre un flujo de trabajo diferente.<br />
<br />
== Ejemplo gráfico de un mapa de historias ==<br />
<br />
*** FALTA GRAFICO o link de PIVOTAL ***<br />
<br />
== Ejercicio para hacer un mapa de historias ==<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
== Ver también ==<br />
<br />
* http://prezi.com/fj534uoemif6/story-mapping/<br />
* http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02<br />
* [[Historia de usuario]]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Historia_de_usuario&diff=6588Historia de usuario2012-05-03T13:08:20Z<p>Cblatter: /* Ver también */</p>
<hr />
<div>Una historia de usuario es una descripción funcional de una parte del software.<br />
<br />
== ¿ Por qué escribimos historias de usuario ? ==<br />
<br />
* Orientan a registrar funcionalidad<br />
* Enfatizan la comunicación verbal<br />
* Enfocan en los aspectos relevantes del momento y los detalles pueden verse en el momento más oportuno<br />
* Tienen un buen tamaño para planificar<br />
* Funcionan bien en el desarrollo iterativo<br />
<br />
== ¿ Qué incluyen las historias de usuario? ==<br />
<br />
* Una descripción escrita: es un item del [[Backlog Del Producto]]<br />
* Conversación con el cliente: guardamos apuntes, información obtenida, prototipos<br />
* Confirmación: pruebas que limiten el alcance de la historia<br />
<br />
== Características de las historias de usuario ==<br />
<br />
* Independientes: cada historia es coherente por si misma<br />
* Negociables: se negocia el objetivo y alcance a través de la conversación<br />
* Valiosas para el usuario: añade valor al producto<br />
* Estimables<br />
* Small: pequeñas en esfuerzo para el equipo de trabajo (no más de 2-3 personas/semana de trabajo)<br />
* Testeables: necesitamos saber que vamos a poder probarla<br />
<br />
----<br />
I.N.V.E.S.T.: invertir en<br />
----<br />
<br />
== Historias funcionales ==<br />
<br />
* Escribir historias funcionales nos ayuda a pensar en entregar valor al usuario<br />
<br />
=== ¿ Qué hacemos con historias no funcionales ? === <br />
<br />
* las historias tienen que aportarle valor al usuario y si necesitamos incluir cuestiones técnicas nos conviene incluir tareas en las primeras historias<br />
* en primeras etapas escribir super historias que puedan ser negociadas con el usuario<br />
<br />
=== Desventaja aparente por tener solo historias funcionales ===<br />
<br />
* Unicamente se explica el producto a nivel de cliente<br />
<br />
=== Ventaja aparente por tener solo historias funcionales ===<br />
<br />
* Fuerza a centrarse en la colaboración con el cliente<br />
* No se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente<br />
<br />
=== Ejemplo de una historia de usuario ===<br />
<br />
Historia: Préstamo de libro <br><br />
ID: 5 <br><br />
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento. <br><br />
Importancia: 300 <br><br />
Cómo probarlo: <br />
* Introducir un número de socio incorrecto y comprobar que se indica error<br />
* Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error<br />
* Introducir un libro del que no hay ejemplares y comprobar que se indica un error<br />
* Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno<br />
<br />
=== Ejemplo gráfico de una historia de usuario ===<br />
<br />
[http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/ http://sixservix.com/blog/david/2010/02/10/estructura-historia-usuario/]<br />
<br />
== Ejercicio para escribir historias de usuario ==<br />
<br />
La propuesta es trabajar con el siguiente ejemplo de requerimiento de usuario de biblioteca y escribir las historias de usuario.<br />
<br />
# Se quiere desarrollar un sistema sencillo de control de préstamos en una biblioteca.<br />
# El sistema debe admitir el alta y la baja de socios y de libros. <br />
# Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. <br />
# Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. <br />
# Cuando llega a cero el socio se de de baja automáticamente.<br />
<br />
Recomendamos hacer la actividad en equipo con un moderador para luego entre todos construir el backlog del producto.<br />
<br />
== Ver también ==<br />
<br />
* [http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011 http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011]<br />
* [http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1 http://groups.google.com/group/agile-spain/browse_thread/thread/5a15cfb5a47a3569?hl=es&pli=1]<br />
* [https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java]<br />
* [http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/]<br />
* [http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html http://devnettips.blogspot.com/2009/03/definiendo-historias-de-usuario-en.html]<br />
* [[Backlog Del Producto]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]<br />
* [[Mapa de historias]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Backlog_Del_Producto&diff=6467Backlog Del Producto2012-01-02T14:14:03Z<p>Cblatter: </p>
<hr />
<div>[[Category:Scrum]]<br />
<br />
== Qué es el backlog o pila de producto? ==<br />
<br />
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.<br />
<br />
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog....<br />
<br />
== Cuándo está completo? ==<br />
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo; está en continuo crecimiento y evolución.<br />
Habitualmente se comienza a elaborar con el resultado de una reunión de "Fertilización cruzada" o brainstorming; o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto.<br />
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.<br />
Sí que es importante sin embargo disponer de una visión real, comprendida y compartida por todo el equipo.<br />
<br />
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.<br />
<br />
== Formato ==<br />
<br />
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.<br />
<br />
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:<br />
<br />
* Identificador único de la [[historia de usuario]]<br />
* Títilo de la [[historia de usuario]]<br />
* Descripción de la [[historia de usuario]]<br />
* Importancia<br />
* Estimación<br />
* Criterio de aceptación<br />
* Notas a considerar por el equipo de trabajo<br />
<br />
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El [[Dueño Del Producto]] es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.<br />
<br />
== Características de un backlog orientado al cliente ==<br />
<br />
* Tiene etapas o fases y cada una aporta valor al usuario del producto<br />
* Permite entender la complejidad de la funcionalidad <br />
* La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio<br />
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto<br />
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado<br />
* Permite saber si una funcionalidad puede suplirse con la combinación de otras<br />
* Da noción de volúmen de información que se manipula en cada funcionalidad <br />
<br />
== Pasos para priorizar el backlog del producto ==<br />
<br />
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.<br />
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. <br />
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.<br />
<br />
== Ver también ==<br />
<br />
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]<br />
* [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/]<br />
* [[Historia de usuario]]<br />
* [[Scrum]]<br />
* [[Backlog Del Sprint]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Diagrama_de_componentes&diff=6440Diagrama de componentes2011-11-23T16:58:24Z<p>Cblatter: /* Ver también */</p>
<hr />
<div>Los diagramas de componentes muestran las relaciones entre los componentes de software, sus dependencias, comunicación, ubicación y otras condiciones.<br />
<br />
=== Una guía para construir un diagrama de componentes===<br />
<br />
#Pensar en un único diagrama que unifique los componentes de software que utilizaremos en la solución.<br />
#Dentro de la estructura de proyecto [[UML]] es conveniente generar un paquete con todos los componentes a utilizar.<br />
#Añadir al diagrama todos los '''componentes''' anteriormente creados<br />
#Definir las '''relaciones''' que hay entre los componentes. Por lo general, se utilizan relaciones de dependencias entre componentes.<br />
#Definir que '''interfaces expuestas''' contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software. La necesidad de una interfaz se muestra con un arco y la exposición de una interfaz con un circulo.<br />
<br />
== Ejemplo ==<br />
<br />
[[Archivo:DiagramaDeComponentes.jpg]]<br />
<br />
Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre los que estén modelando el sistema.<br />
<br />
== Ver también ==<br />
* [http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html Tutorial UML 2 - Diagrama de Componentes]<br />
* [[Diseño Por Contrato]]<br />
* [[Patrones De Diseño]]<br />
* [[Interfaces De Usuario]]<br />
* [[UML]]<br />
<br />
[[Category: Diseño De Software]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Diagrama_de_componentes&diff=6439Diagrama de componentes2011-11-23T16:57:56Z<p>Cblatter: /* Ver también */</p>
<hr />
<div>Los diagramas de componentes muestran las relaciones entre los componentes de software, sus dependencias, comunicación, ubicación y otras condiciones.<br />
<br />
=== Una guía para construir un diagrama de componentes===<br />
<br />
#Pensar en un único diagrama que unifique los componentes de software que utilizaremos en la solución.<br />
#Dentro de la estructura de proyecto [[UML]] es conveniente generar un paquete con todos los componentes a utilizar.<br />
#Añadir al diagrama todos los '''componentes''' anteriormente creados<br />
#Definir las '''relaciones''' que hay entre los componentes. Por lo general, se utilizan relaciones de dependencias entre componentes.<br />
#Definir que '''interfaces expuestas''' contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software. La necesidad de una interfaz se muestra con un arco y la exposición de una interfaz con un circulo.<br />
<br />
== Ejemplo ==<br />
<br />
[[Archivo:DiagramaDeComponentes.jpg]]<br />
<br />
Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre los que estén modelando el sistema.<br />
<br />
== Ver también ==<br />
* [[Diseño Por Contrato]]<br />
* [[Patrones De Diseño]]<br />
* [[Interfaces De Usuario]]<br />
* [[UML]]<br />
* [http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html Tutorial UML 2 - Diagrama de Componentes]<br />
<br />
[[Category: Diseño De Software]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Diagrama_de_componentes&diff=6438Diagrama de componentes2011-11-23T16:56:38Z<p>Cblatter: /* Una guía para construir un diagrama de componentes */</p>
<hr />
<div>Los diagramas de componentes muestran las relaciones entre los componentes de software, sus dependencias, comunicación, ubicación y otras condiciones.<br />
<br />
=== Una guía para construir un diagrama de componentes===<br />
<br />
#Pensar en un único diagrama que unifique los componentes de software que utilizaremos en la solución.<br />
#Dentro de la estructura de proyecto [[UML]] es conveniente generar un paquete con todos los componentes a utilizar.<br />
#Añadir al diagrama todos los '''componentes''' anteriormente creados<br />
#Definir las '''relaciones''' que hay entre los componentes. Por lo general, se utilizan relaciones de dependencias entre componentes.<br />
#Definir que '''interfaces expuestas''' contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software. La necesidad de una interfaz se muestra con un arco y la exposición de una interfaz con un circulo.<br />
<br />
== Ejemplo ==<br />
<br />
[[Archivo:DiagramaDeComponentes.jpg]]<br />
<br />
Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre los que estén modelando el sistema.<br />
<br />
== Ver también ==<br />
* [[Diseño Por Contrato]]<br />
* [[Patrones De Diseño]]<br />
* [[Interfaces De Usuario]]<br />
* [[UML]]<br />
<br />
[[Category: Diseño De Software]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Diagrama_de_componentes&diff=6437Diagrama de componentes2011-11-23T16:56:25Z<p>Cblatter: </p>
<hr />
<div>Los diagramas de componentes muestran las relaciones entre los componentes de software, sus dependencias, comunicación, ubicación y otras condiciones.<br />
<br />
=== Una guía para construir un diagrama de componentes===<br />
<br />
#Pensar en un único diagrama que unifique los componentes de software que utilizaremos en la solución.<br />
#Dentro de la estructura de proyecto [[UML]] es conveniente generar un paquete con todos los componentes a utilizar.<br />
#Añadir al diagrama todos los '''componentes''' anteriormente creados<br />
#Definir las '''relaciones''' que hay entre los componentes. Por lo general, se utilizan relaciones de dependencias entre componentes.<br />
#Definir que '''interfaces expuestas''' contendrá la solución. Las interfaces expuestas pueden tipificarse o clasificarse en requeridas por un componente o provistas por un componente. Por ejemplo, un componente requiere de un servicio externo entonces se utiliza una interfaz requerida. Otro ejemplo, un componente expone un servicio entonces se utiliza una interfaz provista por nuestro software.<br />
La necesidad de una interfaz se muestra con un arco y la exposición de una interfaz con un circulo.<br />
<br />
== Ejemplo ==<br />
<br />
[[Archivo:DiagramaDeComponentes.jpg]]<br />
<br />
Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre los que estén modelando el sistema.<br />
<br />
== Ver también ==<br />
* [[Diseño Por Contrato]]<br />
* [[Patrones De Diseño]]<br />
* [[Interfaces De Usuario]]<br />
* [[UML]]<br />
<br />
[[Category: Diseño De Software]]</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Equipo_Pnt&diff=6427Equipo Pnt2011-11-06T17:29:33Z<p>Cblatter: </p>
<hr />
<div>PNT (Proyectos de Nuevas Tecnologías) es un equipo de desarrollo de una consultora de sistemas, trabajando en proyectos de una empresa multinacional de telefonía.<br />
<br />
PNT fue formado inicialmente en diciembre de 2004 para resolver el diseño y desarrollo de proyectos basados en tecnologías Java.<br />
<br />
La experiencia de PNT fue documentada a lo largo de los años por varios de sus integrantes en una intranet propia del grupo, a través de notas en un [[Joomla]]. Luego experimentaron el uso de [[Team Elements]] y actualmente su gestiòn de conocimientos está desarrollada en una wiki de la consultora.<br />
<br />
== Integrantes ==<br />
Los integrantes actuales de PNT son:<br />
* Adrian Prados<br />
* Carlos Benitez<br />
* Carolina Barbiero<br />
* Claudia Blatter<br />
* Diego Gomez<br />
* Diego Romero<br />
* Emiliano Estevez<br />
* Favio Tolosa<br />
* Fernando Guerra<br />
* Fernando Martinez<br />
* Franco Morinigo<br />
* Gerardo Matsui<br />
* Ignacio Capodanno<br />
* Jonathan Lijs<br />
* Juan Manual Aguero<br />
* Laureano Clausi<br />
* Leandro Gutierrez<br />
* Leonardo De Seta<br />
* Lucas Martinez<br />
* Matias Novillo Caceres<br />
* Matias Zamorano<br />
* Maximiliano Ganuza<br />
* Pablo Novas<br />
* Pablo Rivero<br />
* Sebastian Murua<br />
<br />
== Ex-integrantes ==<br />
Las siguientes personas fueron miembros de PNT y aportaron a Dos Ideas a través de artículos y notas varias:<br />
* Agustin Fernandez<br />
* Agustin Gallego<br />
* Alejandra Holman<br />
* Alejandro Amaya<br />
* Andrea Girimonte<br />
* Andres Candal<br />
* Cristian DeBenedetti<br />
* Demian Berjman<br />
* Fabian Soliz<br />
* Federico Cherchyk<br />
* Federico Ferrer<br />
* Fernando Piccirillo<br />
* Fernando Requena<br />
* Gabriel Teolis<br />
* German DelTuffo<br />
* Juan José Barrera<br />
* Marcela Diaz<br />
* Marcelo Zabalet<br />
* Mariano Cifre<br />
* Mariela Eujanian<br />
* Nicolas Ferrucci<br />
* Ramiro Gomez Mazza<br />
* Sergio Sanchez<br />
* Valeria Molinari<br />
* Victor Cabas<br />
<br />
== Otros participantes ==<br />
Las siguientes personas interactuaron directamente con PNT y también realizaron aportes:<br />
* Alejandro Vega<br />
* Carlos Alvarez</div>Cblatterhttps://dosideas.com/wiki/index.php?title=Equipo_Pnt&diff=6426Equipo Pnt2011-11-06T17:21:59Z<p>Cblatter: </p>
<hr />
<div>PNT (Proyectos de Nuevas Tecnologías) es un equipo de desarrollo de una consultora de sistemas, trabajando para una empresa multinacional de telefonía móvil.<br />
<br />
PNT fue formado inicialmente en diciembre de 2004 para resolver el diseño y desarrollo de proyectos basados en tecnologías Java.<br />
<br />
La experiencia de PNT fue documentada a lo largo de los años por varios de sus integrantes en una intranet propia del grupo, a través de notas en un [[Joomla]]. Luego experimentaron el uso de [[Team Elements]] y actualmente su gestiòn de conocimientos está desarrollada en una wiki de la consultora.<br />
<br />
== Integrantes ==<br />
Los integrantes actuales de PNT son:<br />
* Adrian Prados<br />
* Carlos Benitez<br />
* Carolina Barbiero<br />
* Claudia Blatter<br />
* Diego Gomez<br />
* Diego Romero<br />
* Emiliano Estevez<br />
* Favio Tolosa<br />
* Fernando Guerra<br />
* Fernando Martinez<br />
* Franco Morinigo<br />
* Gerardo Matsui<br />
* Ignacio Capodanno<br />
* Jonathan Lijs<br />
* Juan Manual Aguero<br />
* Laureano Clausi<br />
* Leandro Gutierrez<br />
* Leonardo De Seta<br />
* Lucas Martinez<br />
* Matias Novillo Caceres<br />
* Matias Zamorano<br />
* Maximiliano Ganuza<br />
* Pablo Novas<br />
* Pablo Rivero<br />
* Sebastian Murua<br />
<br />
== Ex-integrantes ==<br />
Las siguientes personas fueron miembros de PNT y aportaron a Dos Ideas a través de artículos y notas varias:<br />
* Agustin Fernandez<br />
* Agustin Gallego<br />
* Alejandra Holman<br />
* Alejandro Amaya<br />
* Andrea Girimonte<br />
* Andres Candal<br />
* Cristian DeBenedetti<br />
* Demian Berjman<br />
* Fabian Soliz<br />
* Federico Cherchyk<br />
* Federico Ferrer<br />
* Fernando Piccirillo<br />
* Fernando Requena<br />
* Gabriel Teolis<br />
* German DelTuffo<br />
* Juan José Barrera<br />
* Marcela Diaz<br />
* Marcelo Zabalet<br />
* Mariano Cifre<br />
* Mariela Eujanian<br />
* Nicolas Ferrucci<br />
* Ramiro Gomez Mazza<br />
* Sergio Sanchez<br />
* Valeria Molinari<br />
* Victor Cabas<br />
<br />
== Otros participantes ==<br />
Las siguientes personas interactuaron directamente con PNT y también realizaron aportes:<br />
* Alejandro Vega<br />
* Carlos Alvarez</div>Cblatter