Dos Ideas. - Contribuciones del usuario [es]

JQuery Cascade

2008-10-19T12:42:03Z

200.125.124.96: /* Ejemplo */

[[JQuery Cascade]] es un plugin para la librería [[JavaScript]] [[JQuery]] que permite cargar datos vía ajax ante un evento y luego asignar los mismos a cualquier elemento. Su uso mas común es en un combo [[Html]] SELECT.

==Ejemplo==
Suponer el caso mas común en donde debo cargar un combo SELECT de acuerdo al valor elegido en otro. Por ejemplo se tiene un combo con el tipo de producto y en el otro aparecen los modelos de ese producto. Debemos indicarle el combo origen, el destino y la [[URL]] de donde obtener los datos.

<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.ext.js"></script>
<script type="text/javascript">
function commonTemplate(item) {
return "<option value='" + item.Value + "'>" + item.Text + "</option>";
};
function commonTemplate2(item) {
return "<option value='" + item.Value + "'>***" + item.Text + "***</option>";
};
function commonMatch(selectedValue) {
return this.When == selectedValue;
};
</script>
<style type="text/css">
.cascade-loading{
background: transparent url("indicator.gif") no-repeat center;
}
</style>
</head>
<body>
<h2>Consulta Modelos</h2>

<label>Productos
<select id="comboProductos">
<option value="A">Producto A</option>
<option value="B">Producto B</option>
<option value="C">Producto C</option>
<option value="D">Producto D</option>
</select>
</label>
<label>Modelos
<select id="comboModelos">
</select>
</label>

<script type="text/javascript">
jQuery(document).ready(function()
{
jQuery("#comboModelos").cascade("#comboProductos",{
ajax: {
url: '/BusquedaDeModelosServlet',
data: { myotherdata: jQuery("#ajax_header").html() }
},
template: commonTemplate,
match: commonMatch
});
});
</script>

</body>
</html>
</code>

Si bien todo es configurable, por defecto el formato del retorno de los datos en el servlet debe ser del estilo:
<code>[{'When':'CODIGO','Value':'VALOR','Text':'DESCRIPCION'},{...},{...}]</code>

El atributo '''url''' indica la página que devolverá los datos (en el formato antes mencionado). JQuery Cascade enviará el parámetro '''val''' con la opción seleccionada del combo "padre" a esa URL. De esta manera, es posible crear una página dinámica para generar el contenido.

En [[Java]], la página del ejemplo anterior podría resolverse con un [[Servlet]]:

<code java>
public class BusquedaDeModelosServlet extends HttpServlet {

/**
* Metodo que se llama al invocar al servlet
*/
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

String codigoProducto = request.getParameter("val");

//TODO buscar los modelos segun el producto. Luego armar una respuesta del tipo:

String respuesta = "[{'When':'A','Value':'A1','Text':'Modelo A1'},
{'When':'A','Value':'A2','Text':'Modelo A2'}]";

//escribimos la respuesta
response.getWriter().write(respuesta);
}
}
</code>

==Ver también==
* [[JQuery]]
* [http://plugins.jquery.com/project/cascade Pagina del plugin en JQuery]

JQuery Cascade

2008-10-19T12:37:19Z

200.125.124.96: /* Ejemplo */

[[JQuery Cascade]] es un plugin para la librería [[JavaScript]] [[JQuery]] que permite cargar datos vía ajax ante un evento y luego asignar los mismos a cualquier elemento. Su uso mas común es en un combo [[Html]] SELECT.

==Ejemplo==
Suponer el caso mas común en donde debo cargar un combo SELECT de acuerdo al valor elegido en otro. Por ejemplo se tiene un combo con el tipo de producto y en el otro aparecen los modelos de ese producto. Debemos indicarle el combo origen, el destino y la [[URL]] de donde obtener los datos.

<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.ext.js"></script>
<script type="text/javascript">
function commonTemplate(item) {
return "<option value='" + item.Value + "'>" + item.Text + "</option>";
};
function commonTemplate2(item) {
return "<option value='" + item.Value + "'>***" + item.Text + "***</option>";
};
function commonMatch(selectedValue) {
return this.When == selectedValue;
};
</script>
<style type="text/css">
.cascade-loading{
background: transparent url("indicator.gif") no-repeat center;
}
</style>
</head>
<body>
<h2>Consulta Modelos</h2>

<label>Productos
<select id="comboProductos">
<option value="A">Producto A</option>
<option value="B">Producto B</option>
<option value="C">Producto C</option>
<option value="D">Producto D</option>
</select>
</label>
<label>Modelos
<select id="comboModelos">
</select>
</label>

<script type="text/javascript">
jQuery(document).ready(function()
{
jQuery("#comboModelos").cascade("#comboProductos",{
ajax: {
url: '.../miServlet.do',
data: { myotherdata: jQuery("#ajax_header").html() }
},
template: commonTemplate,
match: commonMatch
});
});
</script>

</body>
</html>
</code>

Si bien todo es configurable, por defecto el formato del retorno de los datos en el servlet debe ser del estilo:
<code>[{'When':'CODIGO','Value':'VALOR','Text':'DESCRIPCION'},{...},{...}]</code>

El servlet que elijamos para buscar los datos, recibirá por parámetro con el nombre "val" el código del valor del combo elegido.

<code java>
public class MiServlet extends HttpServlet{

/**
* Metodo que se llama al invocar al servlet
*/
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

String codigoProducto = request.getParameter("val");

//TODO buscar los modelos segun el producto. Luego armar una respuesta del tipo:

String respuesta = "[{'When':'A','Value':'A1','Text':'Modelo A1'},
{'When':'A','Value':'A2','Text':'Modelo A2'}]";

//escribimos la respuesta
response.getWriter().write(respuesta);
}
}
</code>

==Ver también==
* [[JQuery]]
* [http://plugins.jquery.com/project/cascade Pagina del plugin en JQuery]

JQuery Cascade

2008-10-19T12:36:44Z

200.125.124.96: /* Ejemplo */

[[JQuery Cascade]] es un plugin para la librería [[JavaScript]] [[JQuery]] que permite cargar datos vía ajax ante un evento y luego asignar los mismos a cualquier elemento. Su uso mas común es en un combo [[Html]] SELECT.

==Ejemplo==
Suponer el caso mas común en donde debo cargar un combo SELECT de acuerdo al valor elegido en otro. Por ejemplo se tiene un combo con el tipo de producto y en el otro aparecen los modelos de ese producto. Debemos indicarle el combo origen, el destino y la [[URL]] de donde obtener los datos.

<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.cascade.ext.js"></script>
<script type="text/javascript">
function commonTemplate(item) {
return "<option value='" + item.Value + "'>" + item.Text + "</option>";
};
function commonTemplate2(item) {
return "<option value='" + item.Value + "'>***" + item.Text + "***</option>";
};
function commonMatch(selectedValue) {
return this.When == selectedValue;
};
</script>
<style type="text/css">
.cascade-loading{
background: transparent url("indicator.gif") no-repeat center;
}
</style>
</head>
<body>
<h2>Consulta Modelos</h2>

<label>Productos
<select id="comboProductos">
<option value="A">Producto A</option>
<option value="B">Producto B</option>
<option value="C">Producto C</option>
<option value="D">Producto D</option>
</select>
</label>
<label>Modelos
<select id="comboModelos">
</select>
</label>

<script type="text/javascript">
jQuery(document).ready(function()
{
jQuery("#comboModelos").cascade("#comboProductos",{
ajax: {
url: '.../miServlet.do',
data: { myotherdata: jQuery("#ajax_header").html() }
},
template: commonTemplate,
match: commonMatch
});
});
</script>

</body>
</html>
</code>

Si bien todo es configurable, por defecto el formato del retorno de los datos en el servlet debe ser del estilo:
<code><nowiki>[{'When':'CODIGO','Value':'VALOR','Text':'DESCRIPCION'},{...},{...}]</nowiki></code>

El servlet que elijamos para buscar los datos, recibirá por parámetro con el nombre "val" el código del valor del combo elegido.

<code java>
public class MiServlet extends HttpServlet{

/**
* Metodo que se llama al invocar al servlet
*/
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

String codigoProducto = request.getParameter("val");

//TODO buscar los modelos segun el producto. Luego armar una respuesta del tipo:

String respuesta = "[{'When':'A','Value':'A1','Text':'Modelo A1'},
{'When':'A','Value':'A2','Text':'Modelo A2'}]";

//escribimos la respuesta
response.getWriter().write(respuesta);
}
}
</code>

==Ver también==
* [[JQuery]]
* [http://plugins.jquery.com/project/cascade Pagina del plugin en JQuery]

Sinceridad Como Valor Agil

2008-10-16T02:56:58Z

200.125.124.96:

La '''sinceridad''' es un principio fundamental detrás del éxito de un [[Desarrollo Agil De Software]].

Los métodos ágiles se basan en que las personas dicen la verdad y atúan con integridad. Es importante no perder esto de vista, ya que en el día-a-día se suele hacer más foco en los aspectos técnicos (como [[Test Driven Development]], refactoring), o en temas relacionados con el liderazgo del equipo.

Por ejemplo, es común que durante el desarrollo de una aplicación alguien piense haber creado un buen diseño, pero luego tenga que luchar para hacerlo funcionar. En estos casos, puede ser que el desarrollador no quiera mostrar que cometió un error. De ser así, podría hacerle creer al resto del equipo que "todo está bien", mientras trabaja horas extra para arreglar la situación.

El orgullo suele ser un mal consejero para cubrir decisiones técnicas incorrectas.

En cambio, un entorno ágil no es fértil para estas acciones: simplemente no se puede sostener en el tiempo. Recordemos que en un desarrollo ágil existe propiedad colectiva de código, reuniones diarias, seguimiento de historias y tareas, y seguimiento general del esfuezo restante. Todo esto hace que el proceso entero sea más transparente. Obviamente, y por todo esto, los métodos ágiles se basan en que las personas cuenten y actúen con sinceridad.

Igualmente, ningún equipo ágil es inmune a estos problemas. Es bueno que cada miembro del equipo se pregunte:
* ¿estás expresando sinceramente tus dudas e inquietudes en la [[Retrospectiva Del Sprint]]?
* Si algo te molesta de algún otro miembro, ¿tratás el tema de manera directa y con respeto para solucionarlo?
* ¿Estás dispuesto a admitir abiertamente cuando alguien tiene una mejor idea o diseño que el tuyo?
* ¿Estás dispuesto a admitir que cometiste un error?
* ¿Decís lo mismo de una persona cuando estás frente a ella, y cuando esa persona no está?

En resumen, la Sinceridad es un valor fundamental para el buen funcionamiento de un Equipo Ágil. En general, todos los Valores son cada vez más importantes en las metodologías ágiles: sin valores, las prácticas individuales de TDD, iteraciones, Definición de Terminado y otras pierden todo su sentido.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]
* [http://www.dosideas.com/metodologias/274-el-principio-agil-mas-importante.html El principio ágil más importante]
* [http://www.infoq.com/news/2008/07/truthfulness-agile-value Truthfulness - an Agile value?]

JQuery Form

2008-09-20T14:32:57Z

200.125.124.96: /* Ver también */

[[JQuery Form]] es un plugin para la librería [[JavaScript]] [[JQuery]] que agrega diversa funcionalidad para la manipulación de formularios, y en particular permite convertir a ajax un formulario HTML cualquiera.

Para su uso se indica el formulario a convertir, y en dónde deberá mostrarse el resultado de la invocación.

==Ejemplo==
<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.form.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#formBusqueda").ajaxForm({
type: "POST",
target: "#resultados"
});
});
</script>
</head>
<body>
<h2>Consulta de Invasores</h2>

<form id="formBusqueda" action="procesarConsulta.jsp">
<input type="text" name="consulta" />
<input type="submit" value="Buscar" />
</form>

<div id="resultados"></div>

</body>
</html>
</code>

==Ver también==
* [[JQuery]]
* [http://www.dosideas.com/java/239-iajaxificando-un-formulario.html Ajaxificando un formulario]
* [http://www.dosideas.com/descargas/doc_download/10-demo-de-jquery-form.html Descargar proyecto de ejemplo de jQuery Form]
* [http://malsup.com/jquery/form/ Web oficial de jQuery Form]

JQuery Form

2008-09-20T14:32:39Z

200.125.124.96: /* Ver también */

[[JQuery Form]] es un plugin para la librería [[JavaScript]] [[JQuery]] que agrega diversa funcionalidad para la manipulación de formularios, y en particular permite convertir a ajax un formulario HTML cualquiera.

Para su uso se indica el formulario a convertir, y en dónde deberá mostrarse el resultado de la invocación.

==Ejemplo==
<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.form.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#formBusqueda").ajaxForm({
type: "POST",
target: "#resultados"
});
});
</script>
</head>
<body>
<h2>Consulta de Invasores</h2>

<form id="formBusqueda" action="procesarConsulta.jsp">
<input type="text" name="consulta" />
<input type="submit" value="Buscar" />
</form>

<div id="resultados"></div>

</body>
</html>
</code>

==Ver también==
* [[JQuery]]
* [http://www.dosideas.com/java/239-iajaxificando-un-formulario.html Ajaxificando un formulario]
* [http://www.dosideas.com/descargas/doc_download/10-demo-de-jquery-form.html Descargar proyecto de ejemplo]
* [http://malsup.com/jquery/form/ Web oficial de jQuery Form]

JQuery Form

2008-09-20T14:27:57Z

200.125.124.96: Página nueva: JQuery Form es un plugin para la librería JavaScript JQuery que agrega diversa funcionalidad para la manipulación de formularios, y en particular permite convertir a aja...

[[JQuery Form]] es un plugin para la librería [[JavaScript]] [[JQuery]] que agrega diversa funcionalidad para la manipulación de formularios, y en particular permite convertir a ajax un formulario HTML cualquiera.

Para su uso se indica el formulario a convertir, y en dónde deberá mostrarse el resultado de la invocación.

==Ejemplo==
<code html4strict>
<html>
<head>
<script type="text/javascript" src="/resources/jquery/jquery.js"></script>
<script type="text/javascript" src="/resources/jquery/jquery.form.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$("#formBusqueda").ajaxForm({
type: "POST",
target: "#resultados"
});
});
</script>
</head>
<body>
<h2>Consulta de Invasores</h2>

<form id="formBusqueda" action="procesarConsulta.jsp">
<input type="text" name="consulta" />
<input type="submit" value="Buscar" />
</form>

<div id="resultados"></div>

</body>
</html>
</code>

==Ver también==
* [[JQuery]]
* [http://malsup.com/jquery/form/ Web oficial de jQuery Form]

JQuery

2008-09-20T14:27:50Z

200.125.124.96: /* Plugins */

[[JQuery]] es un nuevo tipo de librerías de Javascript que permite simplificar la manera de interactuar con los documentos HTML, permitiendo manejar eventos,desarrollar animaciones, y agregar interacción con la tecnología [[AJAX]] a nuestras páginas web.

==Ejemplo==
La wikipedia y la propia página de [[JQuery]] tienen varios ejemplos de uso.

==Plugins==
Toda la funcionalidad de [[JQuery]] se puede extender mediante el uso de plugins. Hay una enorme cantidad de plugins disponibles, que realizan variadas tareas.

* [[JQuery Form]]: manipulación de formularios, para convertirlos al estilo ajax

==Ver también==
* [http://jquery.com/ Web oficial de jQuery]
* [http://docs.jquery.com/Using_jQuery_with_Other_Libraries Using jQuery with other libraries]
* [http://es.wikipedia.org/wiki/JQuery jQuery en la Wikipedia]

JQuery

2008-09-20T14:24:22Z

200.125.124.96:

[[JQuery]] es un nuevo tipo de librerías de Javascript que permite simplificar la manera de interactuar con los documentos HTML, permitiendo manejar eventos,desarrollar animaciones, y agregar interacción con la tecnología [[AJAX]] a nuestras páginas web.

==Ejemplo==
La wikipedia y la propia página de [[JQuery]] tienen varios ejemplos de uso.

==Plugins==
Toda la funcionalidad de [[JQuery]] se puede extender mediante el uso de plugins. Hay una enorme cantidad de plugins disponibles, que realizan variadas tareas.

* [[JQuery Forms]]: manipulación de formularios, para convertirlos al estilo ajax

==Ver también==
* [http://jquery.com/ Web oficial de jQuery]
* [http://docs.jquery.com/Using_jQuery_with_Other_Libraries Using jQuery with other libraries]
* [http://es.wikipedia.org/wiki/JQuery jQuery en la Wikipedia]

Parámetros Para Web Service

2008-09-16T01:27:43Z

200.125.124.96: /* Ver también */

Practicamente cualquier aplicación medio seria necesita usar parametros de configuración. Un webservice no iba a ser diferente.

Alternativas hay para todos los gustos o más bien para todas las necesidades, desde crear un fichero properties para ese par de parametros de configuración a uno xml para configuraciones algo más estructuradas. Incluso se ha llegado a ver usar el fichero properties-service.xml de JBoss. Una mala práctica que no aconsejamos, mejor el properties o xml empaquetado dentro de la aplicación y evitamos ataduras innecesarias.

En el caso de desarrollar un webservice con Axis2, el propio Axis2 nos ofrece otra alternativa: el fichero ''services.xml'' del propio webservice.

Veamos un ejemplo de cómo almacenar parametros de configuración simples y complejos dentro del fichero ''services.xml'':

<code xml>
<service name="elWebserviceDeDosIdeas">
<description>Webservice de DosIdeas</description>
<parameter name="ServiceClass">DosIdeas.ServiceClass</parameter>
<parameter name="UnParametroSimple">UnValorSimple</parameter>
<parameter name="UnParametroComplejo">
<mailconfig>
<username>DosIdeas</username>
<password>clave</password>
<host>http://mail.dominio.com</host>
</mailconfig>
</parameter>
<operation name="operacion">
</operation>
</service>
</code>

Y ahora para obtenerlos hay que hacer uso de la clase MessageContext, obtener el contexto actual y usar el método getParameter teniendo en cuenta que estamos recuperando objetos de tipo OMElement. Un código para el ejemplo anterior seria el siguiente:

<code java>
MessageContext msgContext = MessageContext.getCurrentMessageContext();
Parameter parametroSimple = msgContext.getParameter("UnParametroSimple");
Parameter parametroComplejo = msgContext.getParameter("UnParametroComplejo");

System.out.println("Parametro Simple " + parametroSimple.getParameterElement().getText());
System.out.println("ParametroComplejo " + parametroComplejo.getParameterElement());
</code>

==Ver también==
*[[Web Service]]
*[http://ws.apache.org/axis2/ Axis2]

Dirección IP En WebService

2008-09-16T01:27:01Z

200.125.124.96: /* Ver tambien */

Suele ser habitual realizar una auditoría sobre las invocaciones de nuestros webservices.
Además de la operación, fecha y hora, petición y respuesta, una de las cosas más interesantes a guardar es la dirección IP del cliente. Este dato quizás no es tan trivial de obtener, hay que hacer uso del objeto MessageContext asociado al mensaje recibido.

Por lo que aquí os dejo el código:

<code java>
MessageContext msgCtx = MessageContext.getCurrentMessageContext();
String remoteAddress = (String)msgCtx.getProperty("REMOTE_ADDR");
</code>

Otras cosas interesantes que se pueden obtener son los objetos ServletContext y HttpServletRequest:

<code java>
ServletContext servletContext = (ServletContext)msgCtx.
getProperty("transport.http.servletContext");
</code>

<code java>
HttpServletRequest httpServletRequest = (HttpServletRequest)msgCtx.
getProperty("transport.http.servletRequest");
</code>

==Ver tambien==
*[[Web Service]]
*[http://ws.apache.org/axis2/ Axis2]

StackTrace Dentro De AxisFault

2008-09-16T01:26:31Z

200.125.124.96: /* =Ver tambien */

Una cosa que siempre es muy molesta es que los AxisFault no incluyen la información relativa al stacktrace de la excepción que los generó. Esto puede llegar a ser muy molesto, especialmente durante las pruebas de integración donde no sueles disponer de acceso directo a los ficheros de log. Afortunadamente en [http://ws.apache.org/axis2/ Axis2] existe una solución muy sencilla.

Para incluir dentro de un AxisFault el stacktrace de la exception que lo generó, basta con cambiar estos dos parámetros del fichero de configuración de Axis2 ''(conf/axis2.xml)'' de false a true:

<code xml>
<parameter name="sendStacktraceDetailsWithFaults">false</parameter>
<parameter name="DrillDownToRootCauseForFaultReason">false</parameter>
</code>

Y a continuación, reiniciar y redesplegar el Axis2.

==Ver tambien==
*[[Web Service]]
*[http://ws.apache.org/axis2/ Axis2]

StackTrace Dentro De AxisFault

2008-09-16T01:26:16Z

200.125.124.96: /* Ver tambien */

Una cosa que siempre es muy molesta es que los AxisFault no incluyen la información relativa al stacktrace de la excepción que los generó. Esto puede llegar a ser muy molesto, especialmente durante las pruebas de integración donde no sueles disponer de acceso directo a los ficheros de log. Afortunadamente en [http://ws.apache.org/axis2/ Axis2] existe una solución muy sencilla.

Para incluir dentro de un AxisFault el stacktrace de la exception que lo generó, basta con cambiar estos dos parámetros del fichero de configuración de Axis2 ''(conf/axis2.xml)'' de false a true:

<code xml>
<parameter name="sendStacktraceDetailsWithFaults">false</parameter>
<parameter name="DrillDownToRootCauseForFaultReason">false</parameter>
</code>

Y a continuación, reiniciar y redesplegar el Axis2.

===Ver tambien==
*[[Web Service]]
*[http://ws.apache.org/axis2/ Axis2]

Invocar Web Service Desde Eclipse

2008-09-16T01:25:45Z

200.125.124.96: /* Ver también */

Existe una herramienta para eclipse que podemos usar para que nos ayude con los [[Web Service]].

La herramienta es [http://www.eclipse.org/webtools/initial-contribution/IBM/evalGuides/WebServicesToolsEval.html Web Service Explorer] y permite invocar servicios web de una forma visual y relativamente sencilla desde nuestro eclipse.

Para usarlo hay que tener instalada la [http://www.eclipse.org/webtools/ Web Tools Plataform] en tu eclipse (lo más cómodo es bajarse el all-in-one) y pulsar en la opción ''Run -> Launch the Web Services Explorer''.

Lo siguiente será seleccionar el webservice a invocar, para ello podemos cargar su WSDL pulsando en el segundo botón de la derecha (WSDL Page) y luego en WSDL Main en Navigator.
A continuación debemos introducir la URL donde esté publicado el WSDL del servicio web y pulsar en ''Go''.

Tras unos instantes, si todo va bien, se habrá generado un cliente para el webservice y podrás ver sus operaciones y sus endpoints. Estos últimos son editables.

A partir de aquí es tan sencillo como seleccionar una operación y rellenar los datos necesarios para invocar al servicio web. Las peticiones y respuestas se pueden ver tanto en el interfaz gráfico ''(modo Form)'' como en XML ''(modo Source)''.

Como punto negativo decir que a veces el interfaz gráfico no se genera correctamente con mensajes muy complejos y además no es que sea muy intuitivo. Aunque no lo parezca, si haces doble-click sobre los títulos de los paneles se maximizan.

==Ver también==
*[[Web Service]]
*[[Eclipse]]

JDBC

2008-09-16T01:23:58Z

200.125.124.96: /* Ver tambien */

JDBC es una especificación de un conjunto de clases y métodos de operación que permiten a cualquier programa Java acceder a sistemas de bases de datos de forma homogénea. Lógicamente, al igual que ODBC, la aplicación de Java debe tener acceso a un driver JDBC adecuado. Este driver es el que implementa la funcionalidad de todas las clases de acceso a datos y proporciona la comunicación entre el API JDBC y la base de datos real.

===Porque JDBC===
La necesidad de JDBC, a pesar de la existencia de ODBC, viene dada porque ODBC es un interfaz escrito en lenguaje C, que al no ser un lenguaje portable, haría que las aplicaciones Java también perdiesen la portabilidad. Y además, ODBC tiene el inconveniente de que se ha de instalar manualmente en cada máquina; al contrario que los drivers JDBC, que al estar escritos en Java son automáticamente instalables, portables y seguros.

Toda la conectividad de bases de datos de Java se basa en sentencias SQL, por lo que se hace imprescindible un conocimiento adecuado de SQL para realizar cualquier clase de operación de bases de datos. Aunque, afortunadamente, casi todos los entornos de desarrollo Java ofrecen componentes visuales que proporcionan una funcionalidad suficientemente potente sin necesidad de que sea necesario utilizar SQL, aunque para usar directamente el JDK se haga imprescindible. La especificación JDBC requiere que cualquier driver JDBC sea compatible con al menos el nivel «de entrada» de ANSI SQL 92 (ANSI SQL 92 Entry Level).

===Que driver usar===
Saber qué driver JDBC instalar en tu servidor de aplicaciones no debe tomarse a la ligera.

En las grandes organizaciones es bastante habitual encontrarse con Oracles 9 y 10, cuyas inversiones aún están amortizándose.
A la hora de definir el entorno de desarrollo preguntas qué versión de Oracle y de Java usan bajo qué versiones de Oracle y Java debe funcionar la aplicación, te bajas el driver JDBC thin adecuado para las versiones mínimas (si te lo pasan mucho mejor!) y ala, a trabajar.

Ésta es la teoría. A la hora de ponerla en práctica, te vas a la página para descargar los drivers JDBC Oracle y te encuentras con que existe un enlace para cada cada gran versión de Oracle Database. La impresión que te llevas es que si tienes, pej un Oracle 9.2.0.6, tienes que seleccionar el enlace de Oracle 9.2.x drivers. Bueno, esto es correcto pero sólo en parte.

Si consultamos la matriz de interoperabilid entre drivers y database veremos que todas las versiones de los drivers JDBC funcionan para todas las versiones de Database desde la versión 9.2.x. Para más información, en especial para versiones anteriores, se puede consultar la FAQ de JDBC.
Entonces, ¿por qué tanta versión?
Las diferencias entre las versiones del driver JDBC radican principalmente en las funcionalidades JDBC que implementan y en las versiones Java bajo las que funcionan.

Así por ejemplo, la versión 11 del driver JDBC thin Oracle sólo está disponible para Java 5 y 6, si quieres usar auto-generated keys tendrás que usar una versión 10 o superior y si quieres tener soporte completo para tipos LOB (CLOBs y BLOBs) olvídate del classes12.jar.

===Recomendación===
Lo más recomendable es utilizar la última versión del driver JDBC compatible con tu versión de Java.

===Y en el ambiente productivo===
Hasta aquí la parte sencilla. Las sorpresas vendrán cuando tu aplicación pase de tu entorno controlado de desarrollo a uno de pruebas del cliente y empiecen a sucederse los expedientes X con tareas de acceso a la base de datos.

Nuestro consejo es comprobar la versión del driver JDBC instalada en el servidor de pruebas. Si es una versión antediluviana seguramente ya tienes la causa. La solución es convencer al responsable de Sistemas del cliente de actualizar el driver JDBC pero esto será una dura prueba para tus habilidades de negociación...

==Ver tambien==
*[http://www.itapizaco.edu.mx/paginas/JavaTut/froufe/parte21/cap21-3.html Tipos de Drivers JDBC]

JavaScript

2008-09-13T22:14:24Z

200.125.124.96: /* Más información */

[[JavaScript]] es un lenguaje de programación interpretado, es decir, que no requiere compilación, utilizado principalmente en páginas web, con una sintaxis semejante a la del lenguaje Java y el lenguaje C.

Al igual que [[Java]], [[JavaScript]] es un lenguaje orientado a objetos propiamente dicho, ya que dispone de Herencia, si bien esta se realiza siguiendo el paradigma de programación basada en prototipos, ya que las nuevas clases se generan clonando las clases base (prototipos) y extendiendo su funcionalidad.

Todos los navegadores modernos interpretan el código [[JavaScript]] integrado dentro de las páginas web. Para interactuar con una página web se provee al lenguaje [[JavaScript]] de una implementación del DOM.

==Frameworks==
[[JavaScript]] cuenta con infinidad de frameworks y librerias que otorgan diversa funcionalidad. Entre los más conocidos:
* [[JQuery]], un framework de aplicación base, sumamente extensible.
* [[Prototype]], un framework de aplicación base que permite definir clases, muy usado.
* [[Rico]], un framework de componentes de presentación [AJAX].
* [[Concurrent Thread Javascript]], librería para manejo de hilos.

==Ver también==
* [http://es.wikipedia.org/wiki/JavaScript JavaScript en la Wikipedia]
* [http://www.theserverside.com/tt/articles/article.tss?l=OOJavaScriptDemonstrated Conceptos y operaciones básicas]

Dos Ideas.:Acerca de

2008-08-31T14:45:14Z

200.125.124.96:

{{aviso|texto=''Dos personas, una naranja cada uno. Intercambian sus naranjas, y como resultado: dos personas con una naranja cada uno.''

''Dos personas, una idea cada uno. Intercambian sus ideas, y como resultado: '''dos personas con dos ideas cada una'''.''
}}

Dos Ideas es un sitio con información relevante para el mundo de sistemas, obtenida de experiencias reales.

== Valores de Dos Ideas ==
*'''Independencia''': no somos patrocinados por ninguna empresa, decimos lo que creemos.
*'''Sentido comunitario''': el contenido lo aportamos entre todos, para crecer y aprender juntos, compartiendo con el resto del mundo.
*'''Libertad de acceso''': todos están invitados a participar en la comunidad.
*'''Libertad de expresión''': todos son libres de expresar sus opiniones en los foros, participar en la wiki y en otras actividades.

== Objetivos de Dos Ideas ==
* Crear una comunidad de profesionales de sistemas.
* Compartir experiencia, conocimientos, ideas y opiniones en la comunidad.
* Fomentar el uso de tecnologías libres y de calidad.

== Historia ==
Dos Ideas surge originalmente con la experiencia del [[Equipo Pnt]] a lo largo de 3 años de diseño y desarrollo de proyectos Java.

El [[Equipo Pnt]] adquirió amplia experiencia en el uso de diversas herramientas libres para Java, bases de datos, testing, gestión y calidad de proyectos. Dos Ideas surge como una forma de poder seguir en contacto con todos los que participaron en el [[Equipo Pnt]] en algún momento, y poder compartir la experiencia adquirida en diferentes lugares.

Así, el fin de Dos Ideas se amplia y este sitio aparece como un punto de encuentro para todos los profesionales de sistemas.

Dos Ideas aparece online el 12 de mayo de 2008.

Test Driven Development

2008-08-31T14:41:38Z

200.125.124.96:

Desarrollo guiado por pruebas, o Test Driven Development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utiliza la [[Prueba Unitaria]] (unit test en inglés).

Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

TDD permite un diseño más robusto-tanto es así que a menudo se piensa TDD como Diseño manejado por las pruebas (Test Driven Design). En consecuencia, TDD facilita un diseño más mantenible a través de la noción de pruebas. Estas pruebas obligan a reflexionar sobre el comportamiento del código y la forma de garantizar que funciona según lo previsto. La mayoría de las veces, el código influenciado por TDD es relativamente seguro, y sin duda, es bastante simple.

El código que es seguro y simple es más fácil de cambiar que el código que muestra los rasgos opuestos como la complejidad y la fragilidad. Lo que es más, porque el código escrito con TDD se respaldada en pruebas, cualquier cambio que rompe el código se descubre rápidamente. En esencia, el código escrito con TDD en la mente es más fácil de cambiar y más fácil de arreglar.

Pero TDD no trata de que los cambios sean fáciles, al menos no directamente. No, TDD tiene que ver con la velocidad. Cuando los equipos ejecutan TDD consistentemente en sus mentes, las características se producen con mayor rapidez. Características más rápidas significan menos tiempo al mercado. Reducción del período de tiempo de salida al mercado significa mayor posibilidades de obtener más clientes. Lo mejor de todo es que la velocidad de comercialización está respaldado por una red de seguridad de las pruebas que permiten un cambio rápido en la misma cantidad de tiempo (si no más rápido).

==Las 3 reglas de TDD==
La práctica de TDD puede resumirse en 3 simples reglas:

# No se puede escribir código productivo, a menos que sea para hacer pasar un test fallido.
# No se puede escribir más que lo necesario para que falle un test unitario; los errores de compilación se consideran fallos.
# No se puede escribir más código productivo del estrictamente necesario para hacer pasar un test.

==Ciclo de desarrollo TDD==
# '''Escribir la prueba'''. Para escribir la prueba, el desarrollador debe entender claramente las especificaciones y los requisitos. El diseño del documento deberá cubrir todos los escenarios de prueba y condición de excepciones.
# '''Escribir el código haciendo que pase la prueba'''. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Ésta es la parte conducida por el diseño, del TDD. Como parte de la calibración de la prueba, el código debe fallar la prueba significativamente las primeras veces.
# '''Ejecutar las pruebas automatizadas'''. Si pasan, el programador puede garantizar que el código resuelve los casos de prueba escritos. Si hay fallos, el código no resolvió los casos de prueba.
# Refactorización y limpieza en el código. Después se vuelven a efectuar los casos de prueba y se observan los resultados.
# '''Repetición'''. Después se repetirá el ciclo y se comenzará a agregar las funcionalidades adicionales o a arreglar cualquier error.

Este ciclo se suele abreviar como '''rojo-verde-refactor''' (haciendo referencia a fallar un test, hacerlo pasar, y hacer un refactor).

==Ver también==
* [[Testing De Aplicaciones]]
* [[Metodologias De Desarrollo]]
* [http://es.wikipedia.org/wiki/Tdd TDD en la Wikipedia]
* [http://www.agiledata.org/essays/tdd.html Introduction to TDD]
* [http://www.developer.com/java/ent/article.php/3622546 TDD, a portable methodology]
* [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd The 3 rules of TDD]

Planificacion De Poker

2008-08-31T14:15:54Z

200.125.124.96: /* Cartas para imprimir */

La Planificación de Poker (o Planning Poker, en inglés) es una [[Tecnica De Estimacion]] usada en conjunción con [[Wideband Delphi]], para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil.
Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas.
Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión.

==El proceso==

El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.

Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.

Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.

De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.

Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.

==Las cartas==

Este método se basa en un juego de cartas que tiene cada persona que estima.
El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en [[Extreme Programming]], con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.

* ½, 1, 2, 3, 5, 6, 7, 8, infinito

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.

Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”

Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes:

* No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
* No definir tareas con duraciones inferiores a medio día ideal de trabajo.
* Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.

====Variante: sucesión de Fibonacci====
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:

* El juego de cartas está compuesto por números de la sucesión de Fibonacci.
* La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

Para estimar tareas puede ser válido un juego de cartas como éste:

* 0, ½, 1, 2, 3, 5, 8, 13, 20, infinito

Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

====Funcionamiento====

* Cada participante de la reunión tiene un juego de cartas.
* Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
* Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
* Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
* Cuando todos han hecho su selección, se muestran boca arriba.
* Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
* Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
** Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
** Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
** Tomar la estimación menor, mayor, o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además...
resulta divertido y dinamiza la reunión.

==La unidad de estimación: el día ideal==
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de "día ideal de trabajo". Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.

Dicho de otra manera: "si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?".

Por ejemplo, la carta "5" representa que quien estimó podría completar la funcionalidad estimada en 5 días "ideales" de trabajo.

==Cartas para imprimir==
* [http://www.dosideas.com/descargas/doc_download/1-cartas-para-planificacion-de-poker.html Juego de cartas de Planificación de Poker para imprimir]

==Ver también==
* [[Tecnica De Estimacion]]
* [http://en.wikipedia.org/wiki/Planning_poker Planning Poker en la Wikipedia]
* [http://www.navegapolis.net/content/view/525/59/ Planificación de Poquer]

Planificacion De Poker

2008-08-31T14:08:53Z

200.125.124.96:

La Planificación de Poker (o Planning Poker, en inglés) es una [[Tecnica De Estimacion]] usada en conjunción con [[Wideband Delphi]], para lograr consensuar estimaciones de tamaño de los requisitos de un proyecto de una manera rápida y ágil.
Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas.
Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión.

==El proceso==

El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripción de los mismos. Luego se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas (que estan numeradas según la serie de Fibonacci) la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo.

Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas (esto es así para evitar que las estimaciones de unas personas sesgen las de otras). Si la dispersión entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.

Generalmente la dispersión en las estimaciones es sintoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos oscuros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimación, la dispersión de las estimaciones será mucho menor y se podrá llegar facilmente a un consenso.

De esta manera es facil estimar los requisitos de una manera democrática, agil y rápida y que nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetará.

Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimación se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo están distribuidos geográficamente.

==Las cartas==

Este método se basa en un juego de cartas que tiene cada persona que estima.
El modelo inicial de James Grening consta de 8 cartas con los números representados mas abajo, porque James lo ideó para las estimaciones de versión en [[Extreme Programming]], con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.

* ½, 1, 2, 3, 5, 6, 7, 8, infinito

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.

Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”

Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.

Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes:

* No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
* No definir tareas con duraciones inferiores a medio día ideal de trabajo.
* Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.

====Variante: sucesión de Fibonacci====
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:

* El juego de cartas está compuesto por números de la sucesión de Fibonacci.
* La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.

Para estimar tareas puede ser válido un juego de cartas como éste:

* 0, ½, 1, 2, 3, 5, 8, 13, 20, infinito

Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.

====Funcionamiento====

* Cada participante de la reunión tiene un juego de cartas.
* Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
* Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
* Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
* Cuando todos han hecho su selección, se muestran boca arriba.
* Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
* Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
** Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
** Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
** Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
** Tomar la estimación menor, mayor, o la media.

Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además...
resulta divertido y dinamiza la reunión.

==La unidad de estimación: el día ideal==
Los números que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques más utilizados es el de "día ideal de trabajo". Esto es, la unidad representa un día ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningún tipo.

Dicho de otra manera: "si estuviera yo solo encerrado en una habitación, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, ¿cuánto tardaria en desarrollar la funcionalidad X de forma completa y con calidad productiva?".

Por ejemplo, la carta "5" representa que quien estimó podría completar la funcionalidad estimada en 5 días "ideales" de trabajo.

==Cartas para imprimir==
* [http://www.dosideas.com/descargas/cat_view/40-scrum.html Juego de cartas de Planificación de Poker para imprimir]

==Ver también==
* [[Tecnica De Estimacion]]
* [http://en.wikipedia.org/wiki/Planning_poker Planning Poker en la Wikipedia]
* [http://www.navegapolis.net/content/view/525/59/ Planificación de Poquer]

Configuracion De Spring

2008-08-28T01:49:12Z

200.125.124.96: /* Aplicaciones web */

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet'' (ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración usando ContextLoaderListener===
<code xml>
<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>
</code>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno Con Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]

Configuracion De Spring

2008-08-28T01:48:52Z

200.125.124.96: /* Configuración con el Listener */

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet''(ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración usando ContextLoaderListener===
<code xml>
<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>
</code>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno Con Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]

Configuracion De Spring

2008-08-28T01:48:10Z

200.125.124.96: /* Obtención del contexto */

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet''(ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración con el Listener===

<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno Con Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]

Configuracion De Spring

2008-08-28T01:47:59Z

200.125.124.96:

Dependiendo el tipo de aplicación y entorno, la configuración del contexto de [[Spring Framework]] varia.

==Aplicaciones web==
En las aplicaciones web, Spring puede configurarse de manera muy simple a través de un Listener o un Servlet.

En el archivo ''web.xml'' se agrega la variable de contexto ''contextConfigLocation'', la cual apunta a los archivos de configuración. Luego, puede utilizarse el listener ''ContextLoaderListener'' o el servlet ''ContextLoaderServlet''(ambos provistos por el framework) para que inicialicen el contexto de Spring.

===Configuración con el Listener===

<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:archivoDeSpring1.xml,
classpath:archivoDeSpring2.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>

===Obtención del contexto===
Con el contexto configurado, se utiliza la clase ''WebApplicationContextUtils'' para acceder al contexto de Spring.
<code java>
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
FooBean foo = (FooBean) context.getBean("fooBean");
</code>

==Ver también==
* [[Obtener Variables De Entorno Con Spring]]
* [http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/context/support/WebApplicationContextUtils.html Javadoc de WebApplicationContextUtils]

Integracion Continua

2008-08-28T01:29:39Z

200.125.124.96:

La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios. El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas sea realizada cada vez que el código cambia o es enviado al software de [[Control De Versiones]].

Existe una gran cantidad de [[Herramientas Para Integracion Continua]] en el mercado.

==Contexto==

Un proyecto de desarrollo de software con [[Control De Versiones]] y [[Automatizacion De Build]] posee la necesidad de integrar el código con frecuencia para reducir los riesgos de problemas en la integración final del proyecto.

==Problema==

Integración de código en el trabajo de todo el equipo despúes de ciclos largos (semanas o meses) se torna una sesión de carga a defectos de integración.
Integraciones poco frecuentes pueden generar atrasos en el cronograma y problemas de calidad en el producto.
Sin integraciones frecuentes no es posible certificar diariamente la estabilidad del producto.

==Fuerzas==

* Los problemas de integración se deben detectar idealmente cuando son insertados en el código que puede generarlos.
* Los desarrolladores no poseen el hábito de hacer check-in de código con frecuencia.
* La compilación de código se puede demorar y tornarse un impidimento para la construcción e integración continua del código.

==Solución==

Utilice una herramienta que permita realizar la integración contínua del código (al menos una vez por día).
Adopte un proceso que torne los resultados de la herramienta cruciales para avalar el estado del proyecto.

==Raciocinio==

La integración contínua es un concepto que surge a partir de la idea de realización de builds diarios con pruebas de humo.
El modelo ideal de integración contínua permite que la construcción y ejecución de pruebas de humo sea realizada cada vez que el código cambia o es enviado al software de control de versiones.

El proceso de build diario minimiza los riesgos de integración porque los problemas son identificados continuamente.
También reduce el riesgo de baja calidad de código, pues un conjunto de pruebas básico permite que las funcionalidades principales del software sean continuamente avaladas.

Grandes empresas desarrolladores de software como Microsoft, Netscape, IBM, Oracle utilizan este proceso de integración continua diaria en sus principales proyectos.

El proceso de integración continua se hace efectivo cuando el build es generado con éxito.
En el caso que el build no sea generado debido a problemas, la prioridad del equipo pasa a la corrección de los defectos.
Normalmente el error en un build ocurre cuando este no compila o no pasa las pruebas básicas automatizadas.

El proceso de integración continua funciona de la siguiente manera:

* Los desarrolladores del equipo hacen modificaciones en el código fuente, compilan y ejecutan las pruebas unitarias automatizadas y hacen el check-in (o commit) del código en la línea activa del desarrollo en la herramienta de control de versiones.
* La herramienta de integración continua de acuerdo a ciertos períodos de tiempo (se recomienda colocar períodos cortos menores a cuatro horas) verifica si nuevo código se ha colocado en la línea activa del software de control de versiones.
* Si es así, la herramienta de integración continua extrae todo el código fuente y compila en el servidor isolado que tiene por objetivo generar builds limpios.
* Si compila, la herramienta de integración continua ejecuta otras tareas que pueden ser definidas por la herramienta de build como: compilar y ejecutar pruebas unitarias, pruebas de aceptación, generar información de las pruebas, de la cobertura y de análisis estático de código.
* La herramienta de Integración Continua actualiza los datos de la página Web del proyecto con todos los resultados de la ejecución del build y con todos los fuentes alterados y con los datos de que se hizo en cada iteración.
* La herramienta envía mensajes (por email, page, MSN, etc) para el equipo informando el resultado del proceso de build durante la integración continua.

==Contexto Resultante==

El proyecto posee una herramienta de integración continua que ejecuta automáticamente los builds al mismo tiempo que ocurren las modificaciones en el código.

El [[Control De Versiones]], la [[Automatizacion De Build]] y la [[Integracion Continua]] se tornan fundamentales para la ejecución continua y automatizada de [[Automatizacion De Pruebas Unitarias]], [[Automatizacion De Pruebas De Aceptacion]], [[Automatizacion De Metricas De Producto]] y la generacion de [[Radiadores De Informacion]].

==Patrones Relacionados==

* [[Control De Versiones]]
* [[Automatizacion De Build]]
* [[Automatizacion De Pruebas Unitarias]]
* [[Automatizacion De Pruebas De Aceptacion]]
* [[Automatizacion De Metricas De Producto]]
* [[Radiadores De Informacion]]

==Ver también==
* [[Herramientas Para Integracion Continua]]

==Reconocimientos==

* (BERCZUK e APPLETON, 2002)
* (CLARK, 2004)
* (COCKBURN, 2004a)
* (CUSUMANO e YOFFIE, 1998)
* (CUSUMANO e SELBY, 1996)
* (DUVALL, 2007)
* (FOGEL, 2005)
* (FOWLER e FOEMMEL, 2006)
* (MCCONNELL, 1996b)
* (RICHARDSON e GWALTNEY, 2005)
* (SCHUH, 2005)

Groovy Con Spring

2008-08-26T23:54:45Z

200.125.124.96: /* Test */

[[Spring Framework]] tiene soporte para integrar [[Groovy]] como un bean normal más. Además de [[Groovy]], es posible integrar otros lenguajes dinámicos, como JRuby y BeanShell.

==Librerías necesarias==
Se deben incluir las siguientes librerias:
* groovy-1.0.jar
* asm-2.2.2.jar
* antlr-2.7.6.jar

Todas vienen junto a la distribución de Groovy.

==Ejemplo==
En este ejemplo crearemos una interfaz en [[Java]], la implementaremos en Groovy, y la declareremos como un bean más en Spring.
===El código===
Necesitamos crear 3 archivos:
* La interfaz ''Mensajero.java''
* La implementación en groovy ''MensajeroImpl.groovy''
* La configuración de Spring

==== La interfaz: Mensajero.java ====
<code java>
package com.dosideas.dynlang;

public interface Mensajero {
String decirHola(String nombre);
}
</code>

==== El script de implementación: MensajeroImpl.groovy ====
<code groovy>
package com.dosideas.dynlan.groovy;

import com.dosideas.dynlang.Mensajero

class MensajeroImpl implements Mensajero {

String decirHola(String nombre) {
"Hola, " + nombre;
}
}
</code>

==== Configuración de Spring: applicacion.xml ====
<code xml>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:lang="http://www.springframework.org/schema/lang"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.5.xsd">

<lang:groovy id="mensajero"
script-source="classpath:MensajeroImpl.groovy" />

</beans>
</code>

=== Test ===
Crearemos un test que ejecute esta lógica. Accedemos directamente al bean ''mensajero'', como si fuera un bean normal.

<code java>
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {
"/application.xml"
})
public class MensajeroTest {

@Autowired
private Mensajero instance;

@Test
public void decirHola() throws InterruptedException {
String nombre = "Zim";
String result = instance.decirHola(nombre);
String expResult = "Hola, " + nombre;
assertEquals(expResult, result);
}
}
</code>

== Cambios en caliente ==
Es posible hacer que el script sea modificado y recompilado "en caliente". Es decir, teniendo a nuestra aplicación corriendo, podemos modificar la lógica del script y la misma comenzará a ejecutarse en caliente, sin necesidad de ningún otro cambio. Esta es sin dudas una de las características más interesantes de usar lenguajes dinámicos con Java.

Para activar esta característica hay que usar el atributo ''refresh-check-delay'' al momento de declarar el bean en Spring, el cual le indicará cada cuántos milisegundos debe buscar cambios en el script. Por ejemplo:
<code xml>
<lang:groovy id="messenger"
script-source="classpath:Messenger.groovy"
refresh-check-delay="1000"/>
</code>

== Ver también ==
* [[Groovy]]
* [http://www.dosideas.com/descargas/doc_download/8-groovy-con-spring.html Descargar proyecto de ejemplo]
* [http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html Dynamic language support ]

Scrum Master

2008-08-25T03:05:14Z

200.125.124.96: /* Ver también */

[[Category:Scrum]]
El Scrum Master es uno de los [[Roles De Scrum]]. Anteriormente solía ser el project manager, ahora es la persona responsable para asegurarse que el proceso de Scrum es utilizado correctamente. Hay distintas maneras de pensar sobre el rol del Scrum Master. Podría ser, por ejemplo, como un padre, ya que cuando se crea un equipo de Scrum, al principio no saben como auto-administrarse, no saben como trabajar entre todos, no saben cómo trabajar con el [[Dueño Del Producto]], o cómo trabajar dentro de timeboxes. Entonces, al igual que un padre, el Scrum Master es el responsable de enseñarles cómo hacer todo esto hasta que aprendan, llevándolos en el proceso de convertirse en un equipo auto-administrado. Además, el Scrum Master es como un coach, responsable de alentar a todo el equipo, ser su líder y guía. El Scrum Master es también un referee que asegura que se sigan las reglas.

El Scrum Master por sobre todas las coasas tiene que asegurar las reglas. Muchos de los procesos que utilizan las organizaciones crean impedimentos para el progreso del trabajo del equipo. A veces puede parecer más simple el abandonar y aceptar que el proceso organizacional no puede cambiar, y así comprometer la eficiencia del equipo. Por lo tanto es vital que, para mantener la alta productividad de Scrum, se sigan las reglas y las mismas se mantengan sin importar el entorno. Haciendo esto, se hace evidente las cosas de la organización que son disfuncionales y se interponen en el proceso de creación de software.

El trabajo del Scrum Master es quitar cualquier impedimento, interno o externo al equipo que le impida alcanzar el objetivo de construir el software que comprometieron al inicio del Sprint.

==Responsabilidades==

Un Scrum Master es entonces un Lider y Facilitador, y es el responsable de:
* Mejorar la vida y productividad de los miembros del equipo, facilitándole la creatividad de cualquier manera posible.
* Asegurar la cooperación de todos los roles, y quitar cualquier barrera que lo impida.
* Proteger al equipo de interferencias externas, y quitar impedimentos.
* Asegurar que se siga el proceso
* Invitar a personas al Scrum diario, y a reuniones de revisión del sprint y planificación
* Seguir la [[Lista De Impedimentos]], quitando las barreras entre el desarrollo y el cliente, de manera que el cliente maneje directamente la funcionalidad desarrollada.
* Enseñarle al cliente cómo maximizar su retorno de inversión y cumplir sus objetivos con Scrum
* Mejorar las prácticas y herramientas usadas, de manera que cada incremento de funcionalidad sea potencialmente productivo.

==Ver también==
* [[Roles De Scrum]]
* [http://www.dosideas.com/metodologias/187-antes-de-construir-software-debemos-construir-personas.html Antes de construir software, debemos construir personas]

Checkstyle

2008-08-25T03:02:52Z

200.125.124.96:

Checkstyle es una herramienta para ayudar a los programadores a escribir código [[Java]] que adhiera a los estándares. Automatiza el proceso de chequeo de código [[Java]] para sacarle a los programadores esta aburrida (aunque muy importante) tarea. Esta herramienta es ideal para los proyectos que quieren esforzarse en codificar en forma estándard.

Checkstyle es altamente configurable y puede dar soportes a varios estándares de código. Un ejemplo de archivo de configuración es el provisto para soporte de los [[Sun Code Conventions]].

== Integración con IDEs ==

Checkstyle se integra a varios [[IDE]]s a través de distintos plugins desarrollados por terceras partes.

Los plugins más conocidos son:

* [[Eclipse-CS]]
* [http://www.mvmsoft.de/content/plugins/checkclipse/checkclipse.htm Checklipse]
* [http://code.google.com/p/checkstyle-idea/ Checkstyle-idea]
* [http://jetstyle.sourceforge.net/ JetStyle]
* [http://www.sickboy.cz/checkstyle/ Checkstyle Beans]
* [http://nbcheckstyle.sourceforge.net/ nbCheckStyle]
* [http://sourceforge.net/projects/jbcheckstyle-pg/ JBCS ]
* [http://jbcheckstyle.sourceforge.net/jbcheckstyle/ jbCheckStyle]

==Ver también==
* [[PMD]]
* [http://checkstyle.sourceforge.net/ Web oficial de Checkstyle]

PMD

2008-08-25T03:02:23Z

200.125.124.96:

[[PMD]] analiza el código [[Java]] y busca potenciales problemas como:

* Possible bugs - sentencias vacías try/catch/finally/switch
* Dead code - variables locales, parámetros y métodos privados no usados
* Suboptimal code - mal uso de String/StringBuffer
* Overcomplicated expressions - innecesarias sentencias if's, ciclos forque podría ser while
* Duplicate code - código copiado y pegado significa errores copiados y pegados

== Integracion con IDEs ==
[[PMD]] se integra a varios [[IDE]]s a través de sus respectivos plugins ([http://pmd.sourceforge.net/integrations.html Integración con IDEs]).

* [[PmdEclipse]]

== Ver también ==
* [[Checkstyle]]
* [http://pmd.sourceforge.net/ Web oficial de PMD]

Checkstyle

2008-08-25T03:01:37Z

200.125.124.96: /* Ver también */

Checkstyle es una herramienta para ayudar a los programadores a escribir código [[Java]] que adhiera a los estándares. Automatiza el proceso de chequeo de código [[Java]] para sacarle a los programadores esta aburrida (aunque muy importante) tarea. Esta herramienta es ideal para los proyectos que quieren esforzarse en codificar en forma estándard.

Checkstyle es altamente configurable y puede dar soportes a varios estándares de código. Un ejemplo de archivo de configuración es el provisto para soporte de los [[Sun Code Conventions]].

Checkstyle se integra a varios [[IDE]]s a través de distintos plugins desarrollados por terceras partes.

Los plugins más conocidos son:

* [[Eclipse-CS]]
* [http://www.mvmsoft.de/content/plugins/checkclipse/checkclipse.htm Checklipse]
* [http://code.google.com/p/checkstyle-idea/ Checkstyle-idea]
* [http://jetstyle.sourceforge.net/ JetStyle]
* [http://www.sickboy.cz/checkstyle/ Checkstyle Beans]
* [http://nbcheckstyle.sourceforge.net/ nbCheckStyle]
* [http://sourceforge.net/projects/jbcheckstyle-pg/ JBCS ]
* [http://jbcheckstyle.sourceforge.net/jbcheckstyle/ jbCheckStyle]

==Ver también==
* [[PMD]]
* [http://checkstyle.sourceforge.net/ Web oficial de Checkstyle]

PMD

2008-08-25T03:01:20Z

200.125.124.96: /* Ver también */

[[PMD]] analiza el código [[Java]] y busca potenciales problemas como:

* Possible bugs - sentencias vacías try/catch/finally/switch
* Dead code - variables locales, parámetros y métodos privados no usados
* Suboptimal code - mal uso de String/StringBuffer
* Overcomplicated expressions - innecesarias sentencias if's, ciclos forque podría ser while
* Duplicate code - código copiado y pegado significa errores copiados y pegados

[[PMD]] se integra a varios [[IDE]]s a través de sus respectivos plugins ([http://pmd.sourceforge.net/integrations.html Integración con IDEs]).

Los plugins más conocidos son:

* [[PmdEclipse]]

== Ver también ==
* [[Checkstyle]]
* [http://pmd.sourceforge.net/ Web oficial de PMD]

Sesion De Ejemplo De Scrum

2008-08-24T15:34:30Z

200.125.124.96: /* Reset de la clave */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Reset de la clave====
El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia ''Reset de la clave''
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] decide tomar la estimación de 4 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=90 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Reset de la clave - I=80 - E=4
Pedido cambio plan - I=70 - E=20
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:33:38Z

200.125.124.96: /* Compromiso */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Reset de la clave====
El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia ''Reset de la clave''
- Miembro 1: 8
- Miembro 2: 10
- Miembro 3: 10

El [[Scrum Master]] decide tomar la estimación de 10 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=90 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Reset de la clave - I=80 - E=4
Pedido cambio plan - I=70 - E=20
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:28:18Z

200.125.124.96: /* Compromiso */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Reset de la clave====
El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia ''Reset de la clave''
- Miembro 1: 8
- Miembro 2: 10
- Miembro 3: 10

El [[Scrum Master]] decide tomar la estimación de 10 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=90 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Reset de la clave - I=80 - E=10
Pedido cambio plan - I=70 - E=20
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:27:24Z

200.125.124.96: /* Identificación del Cliente */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Reset de la clave====
El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia ''Reset de la clave''
- Miembro 1: 8
- Miembro 2: 10
- Miembro 3: 10

El [[Scrum Master]] decide tomar la estimación de 10 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:27:06Z

200.125.124.96: /* Identificación del Cliente */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Reset de la clave====
El equipo discute rapidamente cómo será el envio del mail, y uno de los integrantes recuerda una solución parecida en otro proyecto. El equipo estima la historia ''Reset de la clave''
- Miembro 1: 8
- Miembro 2: 10
- Miembro 3: 10

El [[Scrum Master]] decide tomar la estimación de 10 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:24:43Z

200.125.124.96: /* Cambio de Plan */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:23:36Z

200.125.124.96: /* Identificación del Cliente */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:23:27Z

200.125.124.96: /* Identificación del Cliente */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Reset de la clave====
* El [[Dueño Del Producto]] cuenta la historia.
** Desea que el sistema le permite al usuario regenerar su clave olvidada. Para esto, quiere que exista una opción que envie un mail con un link especial, donde lo redirija a algún formulario de cambio de clave.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:19:28Z

200.125.124.96: /* Cambio de Plan */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Identificacion del cliente - I=8
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Identificacion del cliente - I=90
Reset de la clave - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:17:31Z

200.125.124.96: /* Cambio de Plan */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10
Reset de la clave - I=5

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login y la gestión de su clave, al darse cuenta que con esa funcionalidad podría salir antes con el producto. El backlog queda de la siguiente manera

Login - I=100
Reset de la clave - I=90
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Sesion De Ejemplo De Scrum

2008-08-24T15:13:41Z

200.125.124.96: /* Compromiso */

[[Category:Scrum]]
Esta es la transcripción de una sesión de [[Scrum]] en un proyecto ficticio. Se listan las acciones y resoluciones que se toman en las distintas reuniones y momentos claves en un proyecto Scrum.

==Primera Reunión: Visión==

El Dueño del Producto realiza una pequeña exposición del proyecto a desarrollar y el valor que el mismo le agregaría a la organización.

*El proyecto es para permitir que los clientes de la organización puedan cambiar sus planes de internet y agregar servicios en forma online, mediante una aplicación WEB.
*La visión del proyecto es que los clientes puedan cambiar sus planes de internet en forma positiva y que puedan agregar servicios a los ya contratados. Esto hará que la organización pueda llegar al presupuesto de ingreso del año. También se agrega que los clientes pueden consultar el estado de sus trámites y pueden cancelarlos y modificarlos si todavía no se inició actividad sobre los mismos.
*Se decidió como se integraría el equipo y el tamaño de las iteraciones (3 semanas).

Al finalizar la exposición del Dueño del Producto, se discutió sobre la arquitectura del mismo entre los miembros del equipo.

Se trató de una breve reunión de 45 minutos, donde se comunico la visión del proyecto y todos comprendieron la importancia y valor del mismo para la organización.

==Segunda Reunión: Exposición==

Aquí el Dueño del Producto expone su [[Backlog Del Producto]] el cual ha surgido de la reunión de Visión y de algunas reuniones que el mismo ha mantenido con los stakeholders de la organización. A cada ítem del backlog se lo identifica en una tarjeta con: Título, Breve descripción, Forma de validación, Importancia, Estimación

===Velocidad===
Antes de asistir a la reunión de Planificación, el equipo tiene que conocer su velocidad inicial y factor de foco. Como el equipo no tiene historia, utiliza un factor de foco de 60%.

El equipo se conforma de 2 desarrolladores y el [[Scrum Master]], los desarrolladores trabajarán 15 días ideales, el [[Scrum Master]] también, solo que no se lo tendrá en cuenta para la velocidad del equipo. En total suman 30 días ideales. Se reduce este número con el factor de foco: 30 x 0.60 = 18.

Finalmente, la velocidad estimada del equipo para el Sprint que inicia será de 18 puntos.

===Exposición de Historias===
Y se genera el siguiente backlog de historias ordenada por importancia:

====Backlog del Producto====
*Pedido cambio plan - I=70
*Consulta de estado de pedidos - I=60
*Pedido de Servicio - I=50

A medida que el Dueño del Producto hace un resumen de cada historia, los miembros del equipo realizan la estimación. Esta misma se realiza a través de la metodología de estimación de pocker. La estimación se hace en días ideales.

====Cambio de Plan====
* Pedido de cambio de Plan. ''- El Dueño del Producto cuenta la historia. -''
** El cliente entra en una pantalla donde se le pregunta el código de identificación y entonces se le muestra los datos de Apellido y Domicilio del mismo.
** El cliente visualiza su plan actual, y de una lista ordenada por importe elige el nuevo plan al cual desea acceder, constando la misma de la descripción del plan y del importe.
** Se verifica si el cliente está en condiciones de tomar este plan.
** Se confirma la operación por parte del sistema

* Se preguntan los detalles convenientes para poder estimar la historia.
** ¿Cómo sería la identificación del cliente (login)? Esto crea una nueva historia (Login).
** ¿Cómo se identifica al cliente?'' Se explican las validaciones del mismo, para que pueda operar.
** ¿El pedido de cambio de plan se resuelve Online o no? Se explica que no.
** ¿Se puede modificar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Modificar pedidos.
** ¿Se puede cancelar un pedido grabado? El Dueño del Producto explica que si, y en que casos y así surge una nueva Historia Cancelar pedidos.

Se divide la Historia Pedido de Cambio de Plan y queda el [[Backlog Del Producto]] de esta manera, luego identificar la importancia de cada historia:

Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Login - I=10

El equipo le pregunta al Dueño del Producto de donde sacarán la identificación del cliente, al estar la historia de Login en una importancia muy lejana al Pedido de cambio de plan.
* Se sugieren opciones:
** Poner prioridad al Login
** Usar un usuario ficticio hasta poder realizar la historia de Login
** Pedir el cliente como un campo mas dentro del Pedido de cambio de plan

El [[Dueño Del Producto]] decide priorizar el Login quedando el backlog de la siguiente manera

Login - I=100
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

Entonces se comienza nuevamente pidiendo al [[Dueño Del Producto]] que exponga la historia Login

====Login====
* Login -''El [[Dueño Del Producto]] cuenta la historia''-
** El cliente entra al sistema, este le pide un Login que consta de usuario y pass.
** Si pasa correctamente el sistema le muestra el menú del sistema.
** Si el usuario o pass son incorrectos, muestra un mensaje y sigue mostrando en la pantalla la opción de Login.

Se preguntan los detalles convenientes para poder estimar la historia.
* No hay detalles a preguntar por parte del equipo.

====Cambio de Plan (2)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
** Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
** Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
** Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
** Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
** Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
** Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
** Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
** Se piden algunos datos adicionales.
** Aquí se comienza a hablar un poco de la arquitectura de la solución.
*** De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
*** Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
*** El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
*** Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
*** Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
*** Se decide no gestionar los errores en esta historia.

Se preguntan los detalles convenientes para poder estimar la historia.
* Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
* El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

''Cuando se estima se conoce que la historia es mas grande de lo que se puede estimar (20 puntos de historia) y entonces se decide dividirla''

====Identificación del Cliente====
* Identificación del Cliente -''El [[Dueño Del Producto]] cuenta la historia''-
**Luego del Login, el sistema sabe si el usuario es un cliente, o es un operador que le venderá alguna operación a un cliente.
**Si es un cliente, el sistema busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)
**Si el operador es un vendedor, entonces el sistema pide que identifique el cliente al cual va a gestionar y que se identifique el vendedor con su número asignado.
**Luego, valida los datos y busca la información general y comercial del mismo en los 3 sistemas que tiene la empresa.
**Muestra la información general por pantalla y también la información comercial (Plan, servicios contratados)

*Se preguntan los detalles convenientes para poder estimar la historia.
**Se deja claro en el equipo que los servicios de validaciones y búsqueda de datos generales y comerciales se encuentran realizados y solo habría que reutilizarlos.
**El equipo pregunta como sería el manejo de errores, y el Dueño del Producto afirma que tienen que unificarse los mismos en la pantalla para darle información fácil de entender al cliente.

====Cambio de Plan (3)====
* Cambio de Plan -''El [[Dueño Del Producto]] cuenta la historia''-
**Se valida que el cliente pueda hacer un cambio de plan por condiciones comerciales.
**Se buscan los planes positivos (mayor al que tiene el cliente) para darle a elegir el que desea.
**Se pide la provincia y localidad de facturación de los cuales se le presentan una serie de opciones al usuario.
**Se piden algunos datos adicionales.
**Aquí se comienza a hablar un poco de la arquitectura de la solución.
***De las reuniones preliminares (Preparación) se sabe que la Arquitectura elegida es algo que desacople lo máximo posible al cliente del estado de los sistemas.
***Entonces por ello se elige hacer la grabación del Pedido de Cambio de Plan en forma Offline, vía mensajería.
***El Dueño del Producto pide que se realicen algunos reintentos antes que el pedido fuese rechazado.
***Luego que ocurran los intentos y que no pueda ser procesado el Cambio de Plan se habla de que tendría que grabarse como error y mostrarse en la Consulta de Pedidos.
***Aquí entonces comienza a surgir otra historia que va a llamarse Circuito de Errores en los pedidos.
**Se decide no gestionar los errores en esta historia.

===Estimación de Historias===
====Login====
Entonces se procede a la estimación del ''Login''
- Miembro 1: 5
- Miembro 2: 13
- Miembro 3: 3

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 2 que explique que tuvo en cuenta en la estimación.
* El miembro 2 explica:
** Crear modelo de datos
** Hablar con el área de seguridad de la información para que defina los lineamientos de seguridad.
** Se tiene en cuenta una autenticación aunque todavía no se sabe como hacerla.
** Encriptación de pass.
** Realizar las operaciones sobre un protocolo seguro, contando que el equipo no tiene experiencia en esto.

Lo mismo hace con el Miembro 3 del equipo.
* El miembro 3 explica:
** Se usa el API de seguridad actual. El que se usa en el módulo de cobranzas y de atención al cliente.
** No se piensa crear nada nuevo, solo altas de opciones, objetos, usuarios, roles, etc en el esquema actual.

El Dueño del Producto dice que habría que utilizar la forma en que el cliente ingresa al sistema de cobranzas, sin ningún cambio funcional al mismo.

Se vuelve entonces a estimar.
- Miembro 1: 5
- Miembro 2: 3
- Miembro 3: 3

El [[Scrum Master]] toma la decisión de elegir el promedio redondeado. Entonces la estimación de la historia es 4.

====Cambio de Plan====
Entonces se procede a la estimación de ''Cambio de Plan''
- Miembro 1: 20
- Miembro 2: infinito
- Miembro 3: infinito

Al tratarse de una historia muy grande (solo hay cartas hasta 20 días ideales) el [[Dueño Del Producto]] la divide en dos.
Quedando el [[Backlog Del Producto]]:

Login - I=100
Identificación del Cliente - I=80
Pedido cambio plan - I=70
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20

====Identificación del Cliente====
Entonces se procede a la estimación de ''Identificación del Cliente''
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: ?

El miembro 3 del equipo dice no entender lo que hay que estimar.
El [[Dueño Del Producto]] detalla un poco mas la historia.

Se vuelve entonces a estimar.
- Miembro 1: 8
- Miembro 2: 13
- Miembro 3: 13

El [[Scrum Master]] decide tomar la estimación de 13 puntos de historia.

====Cambio de Plan (2)====
Entonces se procede a la estimación
- Miembro 1: 8
- Miembro 2: 20
- Miembro 3: 13

Al ser una diferencia importante, el [[Scrum Master]] decide preguntarle el Miembro 1 que explique que tuvo en cuenta en la estimación.
*Miembro 1 explica:
**Los servicios de provincia y localidad están resueltos en otro módulo y los reusaría.
**Los datos adicionales los considera sin validaciones, solo texto ya sea numérico o alfanumérico.

Lo mismo hace con el Miembro 2 del equipo.
*Miembro 2 explica:
**Entiende que los servicios de provincia y localidad no son reusables y que habría que rehacerlos.
**Comenta que es la primer página que estarían haciendo del módulo.
**Comenta que sería la primera vez en usar mensajería en el equipo y que no lo ve trivial este tema.
**También tuvo en cuenta que hay que persistir los datos luego leyendo con un MDB de la cola e impactarlo en la BD.

Lo mismo hace con el Miembro 3 del equipo.
*Miembro 3 explica:
**Entiende que los servicios de provincia y localidad no son reusables aunque considera que los componentes si.
**Cree que el tema de hacer por primera vez mensajería no será trivial.

El miembro 1 del equipo dice que no tuvo en cuenta la lectura de la cola y el impacto en los sistemas.

Se vuelve entonces a estimar.
- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: carta de café.

El equipo se toma 5 minutos y vuelve para continuar con la estimación.

- Miembro 1: 13
- Miembro 2: 20
- Miembro 3: 20

El [[Scrum Master]] decide tomar la estimación de 20 puntos de historia.

===Compromiso===
Hasta aquí llevamos 37 días ideales (puntos de historia) para realizar las historias estimadas.
Solo se puede tomar hasta 18 puntos de historia, por lo cual se deja de estimar en este momento y se procede a la planificación.
Entonces queda comprometido un [[Sprint]] con las historias de Login e Identificación del Cliente (17 puntos de historia) en el [[Backlog Del Sprint]] y quedando el Cambio de Plan como próxima historia estimada dentro del [[Backlog Del Producto]].

El [[Backlog Del Sprint]] queda de esta manera
Login - I=100 - E=4
Identificación del cliente - I=80 - E=13

Y de esta manera queda el [[Backlog Del Producto]]
Pedido cambio plan - I=70 - E=10
Consulta de estado de pedidos - I=60
Pedido de Servicio - I=50
Modificar pedidos - I=30
Cancelar pedidos - I=20
Circuito de errores - I=15

===Fin de la Planificación===
Entonces para finalizar la reunión de planificación (Exposición) se toman las siguientes decisiones.
- Objetivo del Sprint : Identificación del Cliente
- Reunión Diaria [[Reunion Diaria De Scrum]] : De 10:00 a 10:15 en la sala 1 del 3er piso.
- Duración de Sprint : 3 semanas
- Reunión de [[Revision Del Sprint]] : 8 de Mayo de 2007 en la sala 1 del 3er piso.
- Gráfico Burndown

El gráfico Burndown se comienza dibujando los días (sobre el eje horizontal), los puntos de historia (sobre el eje vertical) y la línea de avance ideal.

Aquí se da por terminada la reunión de planificación (exposición) y luego por la tarde, comenzará la reunión de planificación (Resolución).

==Segunda Reunión: Resolución==

La dinámica de la reunión, es parecida a la de exposición, solo que aquí el protagonista principal es el equipo, que toma cada una de las historias y las divide en tareas estimando cada una de las mismas.

Se comienza la reunión tomando el primer ítem del [[Backlog Del Sprint]], que es Login.
El equipo comienza a desmembrar la misma en tareas, quedando las mismas de la siguiente manera:
- Pantalla de Login
- Método de autenticación

Ahora, se comienza la estimación de las tareas.
Esto se realiza con la estimación de pocker, donde cada uno de los miembros del equipo elige una carta de las disponibles para las tareas (medio, 1, 2 , 3, 4, café, infinito, ?) y la pone dada vuelta (sin mostrar)
Luego, cuando todos tienen elegida la estimación se dan vuelta las cartas y se sigue la misma dinámica que en las estimaciones de las historias.

===Tarea Pantalla de Login===

Entonces se procede a la estimación
- Miembro 1: 3
- Miembro 2: infinito
- Miembro 3: infinito

Los miembros 2 y 3 explican que habría que hacer una pantalla de Error y también una de Ok para terminar la historia y las estimación que ellos piensan sería mayor a 4 días ideales. Entonces el equipo crea dos tareas mas.

- Pantalla de Error
- Pantalla de Ok

Quedando las tareas del ítem Login como sigue:

- Pantalla de Login
- Método de autenticación
- Pantalla de Error
- Pantalla de Ok

==== Pantalla de Login ====
Nuevamente se procede a la estimación
- Miembro 1: 3
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

==== Método de autenticación ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 dia ideal.

==== Pantalla de Error ====

Entonces se procede a la estimación
- Miembro 1: medio
- Miembro 2: 1
- Miembro 3: 1

El [[Scrum Master]] decide tomar la estimación de 1 día ideal.

==== Pantalla de Ok ====

Entonces se procede a la estimación
- Miembro 1: 1
- Miembro 2: 2
- Miembro 3: 2

El [[Scrum Master]] decide tomar la estimación de 2 días ideales.

=== Estimación del resto de las tareas ===

Está dinámica se repite para la historia Identificación del Cliente.

Luego que se terminan de desmembrar en tareas las historias de Login e Identificación del Cliente, se procede a contar todas las estimaciones de todas las tareas, y esa será la cantidad de días ideales que tendrá como máximo el sprint por el momento.

Entonces se dibuja un punto sobre el eje y con la cantidad obtenida y otro sobre el eje x con la cantidad de días del sprint, en este caso 15.

Luego, se dibuja una línea que une estos dos puntos, dando como resultado la línea ideal de avance del sprint.

AGREGAR AGREGAR Que pasa con el seguimiento de los tipos de lineas reales sobre las ideales.
AGREGAR AGREGAR Concepto de hecho del grupo de trabajo
AGREGAR AGREGAR

==Comienzo del Sprint:==
* El miembro 2 toma la tarea Pantalla de Login, poniendo en la misma su nombre.
* El miembro 3 toma la tarea hacer le método de autenticación, poniendo en la misma su nombre.
* A la mañana siguiente, antes de la reunión diaria, el miembro 2 pone que la tarea de Pantalla de Login le demandará 2 días para terminarla.
* A la mañana siguiente, antes de la reunión diaria, el miembro 3 pone que la tarea de Método de Autenticación terminada, y toma la tarea Pantalla de Error poniéndole su nombre a la tarea.
* Cada mañana se hace la reunión diaria ([[Reunion Diaria De Scrum]]).

==Reunión Diaria==
La [[Reunion Diaria De Scrum]] se hace a las 10:00 todos los días en la sala 1 del 3er piso.
Aquí asisten todos los que quieren y solo participan de la misma el equipo del [[Scrum]].

* El miembro 1 dice que ayer estuvo trabajando en la Pantalla de Login y que hoy hará lo mismo y espera que en 1 día mas esta termine.
* El [[Scrum Master]] le pregunta si tiene algún obstáculo para realizar el trabajo.
* El miembro 1 dice que no está levantado el servicio de Login en la instancia de desarrollo.
* El miembro 2 dice que ha terminado con el Método de Autenticación y esto es lo que estuvo haciendo ayer y que el día de hoy tomará la Pantalla de Error.
* El miembro 2 no tiene ningún obstátuclo para continuar con su trabajo.
* El [[Scrum Master]] cuenta la nueva estimación de todas las tareas asignadas y de las pendientes y dibuja el punto en el gráfico Burndown. Luego traza la línea desde el día anterior hasta este punto.

Todos los días se repite la dinámica de la reunión diaria.

En cualquier momento del [[Sprint]], puede surgir una nueva tarea en una historia que se está desarrollando, entonces debería ser estimada y seguir el mismo tratamiento que las demás tareas, sin ningún seguimiento especial.

=== Impedimentos e Imprevistos ===

En cualquier momento del [[Sprint]], pueden surgir '''Impedimentos''' para seguir avanzando normalmente, estos serán informados y se pondrán a la vista de todos en la [[Lista De Impedimentos]], implementada como una columna del afiche del proyecto.

También, durante el sprint pueden surgir '''Imprevistos''', que son tareas que no tienen que ver con el [[Sprint]] y tienen que se resueltas por algún miembro del sprint. Estas también se pondrán a la vista de todos en la columna de imprevistos pendientes, y se los asignarán los miembros del equipo poniendo su nombre y una estimación para terminarla. Luego al terminarla se pasará de columna a Imprevistos Terminados.

Un ejemplo de Imprevisto, pueden ser los bugs del sprint anterior que se deberán tomar con mayor prioridad que cualquier historia del sprint, si así se requiere.

=== Revisión del objetivo ===

Cada semana (dos veces en las 3 semanas del sprint) se realiza una revisión del objetivo.

Pasada la primer semana:
* El gráfico Burndown marca que la línea real está muy por encima del objetivo por lo que el equipo decide que habrá un nuevo objetivo, sacando la historia de Identificación del Cliente del objetivo del Sprint.
* Para poder seguir utilizando el gráfico Burndown, se traza una linea paralela al eje x sobre el punto 13 del eje Y, y allí se vuelve a dibujar la línea objetivo.

Pasada la segunda semana:
* El gráfico Burndown marca que la línea real está muy cerca de la nueva línea objetivo, por lo cual se decide continuar todo de la misma manera.

En la tercer semana:
* Como mínimo 2 días antes de la Revisión del Sprint, el equipo genera un branch en la herramienta de [[Control De Versiones]]
* El equipo sigue trabajando en la entrega del producto en el branch de integración y lo nuevo sobre el Head.

AGREGAR AGREGAR Ejemplos de gráficos de Historias y Tareas.

AGREGAR AGREGAR Ejemplos de Burndowns diferentes.

AGREGAR AGREGAR Ejemplos de Tareas.

==Reunión de Revisión==

La reunión ha quedado agendada en la reunión de planificación. El equipo no se tomó mas de una hora en la preparación de la misma, ya que solo se muestra lo que está funcionando, sin preparar ninguna otra información adicional.
Los invitados llegan, otros miembros de otros proyectos se unen a ver que se presenta.

Empieza la demostración, contando el objetivo del [[Sprint]], y cual era el plan original del mismo con las historias que se desarrollarían.
Luego se comenta lo que se encuentra terminado (en este caso la pantalla de Login) y se explica que ha pasado con lo no desarrollado a grandes rasgos.

La demostración tiene que ser sobre funcionalidad que al usuario le sirva y aplique a la forma de demostrarlo que se ha elegido para la historia.

En esta reunión puede participar cualquiera y se espera que los que tienen ingerencia en el producto puedan dar opiniones para mejorar en lo que a lo funcional respecta, estas opiniones serán tomadas en cuenta por el Dueño del Producto en el próximo [[Sprint]].

Al terminar la reunión, el [[Scrum Master]] pone la fecha de la próxima reunión de Revisión.

==Reunión de Retrospectiva==

El equipo y el Dueño del Producto se juntan a la tarde el mismo día de la reunión de Revisión.
El [[Scrum Master]] dice como fue el [[Sprint]], mostrando que han llegado varios imprevistos al comienzo del sprint, y que además se tuvieron algunos inconvenientes (impedimentos) con el servidor de login de la empresa, el cual se encontró caído en lo que respecta al ambiente de desarrollo por 3 días.

El equipo divide los temas del sprint en:
- Bueno
- A mejorar
- Mejora (concreta, esto se mejorará en el próximo sprint)

La dinámica será en que cada miembro exponga su impresión del sprint y agregue temas a las dos primeras columnas.
Luego se le dará 3 votos a cada miembro del equipo y escribirán en un papel el mismo.
Entonces el [[Scrum Master]], recuperará los votos, y los pondrá en cada item, eligiendo entre los dos o tres mas votados para pasar a la columna Mejora.
Se expondrá que se hará para mejorar el ítem concreto y luego se da por finalizada la reunión de [[Retrospectiva Del Sprint]].

Agil

2008-08-20T23:52:27Z

200.125.124.96:

El Desarrollo ágil de Software a un paradigma de las [[Metodologias De Desarrollo]] basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados.

El proceso ágil usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incoporando los cambios continuamente.

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una '''iteración''', la cual debe durar de una a cuatro semanas. Cada iteraciones del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La mayoría de los equipos Agiles están localizados en una simple oficina abierta. La oficina debe incluir revisores, diseñadores de iteración, escritores de documentación y ayuda y directores de proyecto.

==Manifiesto ágil==
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

* A los individuos y su interacción, por encima de los procesos y las herramientas.
* El software que funciona, por encima de la documentación exhaustiva.
* La colaboración con el cliente, por encima de la negociación contractual.
* La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

===Valores del Manifiesto Ágil===
====Valorar más a los individuos y su interacción que a los procesos y las herramientas====
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.

Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.

====Valorar más el software que funciona que la documentación exhaustiva====

Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.

Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.

====Valorar más la colaboración con el cliente que la negociación contractual====

Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.

En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

====Valorar más la respuesta al cambio que el seguimiento de un plan====

Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.

==Principios ágiles==
Los principios fundamentales de una metodología ágil se pueden resumir:
* Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
* Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
* Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
* Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
* Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
* La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
* El software que funciona es la principal medida del progreso.
* Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
* La atención continua a la excelencia técnica enaltece la agilidad.
* La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
* Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
* En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

==Características de un desarrollo ágil==

* Proceso iterativo e incremental
* Mitigación del riesgo mediante iteraciones fijas
* Mejora continua
* Calidad desde el primer día
* Priorización de requerimientos de acuerdo a su valor
* Equipos dedicados y auto-gestionados
* Colaboración continua con el cliente
* Incorporar al cambio
* Prácticas de desarrollo modernas

==Metodologías y prácticas ágiles==
* [[Scrum]]
* [[Extreme Programming]]
* [[Test Driven Development]]
* [[Sinceridad Como Valor Agil]]

==Ver también==
* [[Metodologia Agil En Una Organizacion En Cascada]]
* [http://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil Manifiesto ágil en la Wikipedia]
* [http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software Desarrollo ágil de software en la wikipedia]
* [http://es.wikipedia.org/wiki/Proceso_%C3%A1gil Proceso ágil en la Wikipedia]
* [http://www.navegapolis.net/content/view/801/62/ Listado de metodologías ágiles]

Hibernate

2008-08-20T02:27:11Z

200.125.124.96: /* Ver también */

Hibernate es un framework de persistencia de objetos para Java. Su función principal es la de [[Mapeo Objeto-Relacional]], es decir, mapear objetos a tablas de una base de datos relacional.

Actualmente Hibernate cuanta con varios subproyectos que resuelven distintos aspectos del acceso y manipulación de datos.

== Ver también ==
* [[Cache De Hibernate]]
* [[Hibernate Con Spring]]
* [http://www.hibernate.org/ Web oficial de Hibernate]
* [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html#tutorial-firstapp Tutorial de Hibernate]
* [http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html Comparación entre Hibernate, iBatis y JPA]
* [http://www.dosideas.com/java/180-testeando-rapido-todos-los-mapeos-de-hibernate.html Testear todos los mapeos de Hibernate]

Portada

2008-08-10T22:44:47Z

200.125.124.96: /* Los primeros pasos en la Wiki */

__NOTOC__
Bienvenido a la wiki de Dos Ideas, un lugar para compartir experiencias concretas del mundo profesional de Sistemas. Aquí podremos volcar conocimientos y ejemplos de diversas tecnologías, aplicadas a cuestiones prácticas. Más información en [[DosIdeas:Acerca de | Acerca de Dos Ideas]].

== Desarrollo de sistemas ==
La wiki de Dos Ideas contiene información sobre el proceso completo del desarrollo de sistemas.

* [[Metodologias De Desarrollo]] contiene metodologías y diversos puntos de vista, prácticas y ejemplos.
* [[Desarrollo De Software]] contiene ejemplos prácticos y consejos sobre el uso de distintas tecnologías.

== Los primeros pasos en la Wiki ==
[http://www.dosideas/images/stories/amigable.png]

{{aviso|texto=Si es tu primera visita a la Wiki de Dos Ideas, no te olvides de leer [[Ayuda:Ayuda | Cómo usar la Wiki]]. Recordá que esta wiki la hacemos entre todos, sentite libre de agregar tus aportes y mejoras.}}

{{aviso|texto=Te esperamos para unirte a la comunidad en el [http://www.dosideas.com sitio principal de Dos Ideas].}}

* Usa el [[Sandbox]] para experimentar y jugar con páginas wiki.
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [http://meta.wikimedia.org/wiki/Help:Contents Guía de uso de MediaWiki]

Portada

2008-08-10T22:44:29Z

200.125.124.96: /* Los primeros pasos en la Wiki */

__NOTOC__
Bienvenido a la wiki de Dos Ideas, un lugar para compartir experiencias concretas del mundo profesional de Sistemas. Aquí podremos volcar conocimientos y ejemplos de diversas tecnologías, aplicadas a cuestiones prácticas. Más información en [[DosIdeas:Acerca de | Acerca de Dos Ideas]].

== Desarrollo de sistemas ==
La wiki de Dos Ideas contiene información sobre el proceso completo del desarrollo de sistemas.

* [[Metodologias De Desarrollo]] contiene metodologías y diversos puntos de vista, prácticas y ejemplos.
* [[Desarrollo De Software]] contiene ejemplos prácticos y consejos sobre el uso de distintas tecnologías.

== Los primeros pasos en la Wiki ==
[http://www.dosideas/images/stories/amigable.png|left]

{{aviso|texto=Si es tu primera visita a la Wiki de Dos Ideas, no te olvides de leer [[Ayuda:Ayuda | Cómo usar la Wiki]]. Recordá que esta wiki la hacemos entre todos, sentite libre de agregar tus aportes y mejoras.}}

{{aviso|texto=Te esperamos para unirte a la comunidad en el [http://www.dosideas.com sitio principal de Dos Ideas].}}

* Usa el [[Sandbox]] para experimentar y jugar con páginas wiki.
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [http://meta.wikimedia.org/wiki/Help:Contents Guía de uso de MediaWiki]

Portada

2008-08-10T22:43:34Z

200.125.124.96: /* Los primeros pasos en la Wiki */

__NOTOC__
Bienvenido a la wiki de Dos Ideas, un lugar para compartir experiencias concretas del mundo profesional de Sistemas. Aquí podremos volcar conocimientos y ejemplos de diversas tecnologías, aplicadas a cuestiones prácticas. Más información en [[DosIdeas:Acerca de | Acerca de Dos Ideas]].

== Desarrollo de sistemas ==
La wiki de Dos Ideas contiene información sobre el proceso completo del desarrollo de sistemas.

* [[Metodologias De Desarrollo]] contiene metodologías y diversos puntos de vista, prácticas y ejemplos.
* [[Desarrollo De Software]] contiene ejemplos prácticos y consejos sobre el uso de distintas tecnologías.

== Los primeros pasos en la Wiki ==
[[:Image:http://www.dosideas/images/stories/amigable.png|left]]

{{aviso|texto=Si es tu primera visita a la Wiki de Dos Ideas, no te olvides de leer [[Ayuda:Ayuda | Cómo usar la Wiki]]. Recordá que esta wiki la hacemos entre todos, sentite libre de agregar tus aportes y mejoras.}}

{{aviso|texto=Te esperamos para unirte a la comunidad en el [http://www.dosideas.com sitio principal de Dos Ideas].}}

* Usa el [[Sandbox]] para experimentar y jugar con páginas wiki.
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [http://meta.wikimedia.org/wiki/Help:Contents Guía de uso de MediaWiki]

Metodologia Agil En Una Organizacion En Cascada

2008-08-09T14:30:39Z

200.125.124.96: /* Resistencia del Management */

Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hecho, esta es una situación común, y este "puente" suele ser el primer paso para una transformación más profunda.

Es posible entonces, por ejemplo, llevar un proceso ágil de desarrollo por más que los extremos no lo sean. Sin embargo, hay que tener en cuenta algunos obstáculos que puedan ocurrir en el camino, y cómo sortearlos.

==Obstáculos==
===Resistencia===
La resistencia al cambio es normal, y no será una excepción al intentar aplicar una nueva metodología. Es importante que la actitud a tomar deberá ser la de "vender" la metodología ágil, y no transformarse en un actor defensor de la misma (por sentirnos atacados).

====Resistencia del Management====
Lo más más recomendable es no intentar venderle el cambio: de todas formas, no saben lo que se está haciendo ahora tampoco.

Por otro lado, es importante comunicarse en su mundo e idioma: explicar los beneficios de una metodología ágil, el incremento del ROI, entregas más tempranas, mayor calidad, reducción de costos, etc. Evitar términos como Scrum, Sprint, Backlog, XP, etc, que no aportan al objetivo final.

Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.

====Resistencia del negocio====
Es importante involucrar al [[Dueño Del Producto]] y demás participantes desde el principio: tienen que sentirse parte del proceso, y comprender el mismo.

Sirve mucho destacar el bajo riesgo: "Satisfacción garantizada, o le devolvemos el dinero". Es decir, explicar que el Dueño del Producto puede realizar cambios frecuentes (cada 1 Sprint!), revisando qué cosas no le gustó del proceso y ver cómo cambiarlas. Más aún, puede cancelar el proyecto temprananmente si consigue la funcionalidad requerida, o el proyecto deja de tener sentido para el negocio.

Por último, una buena práctica es comenzar a adoptar herramientas y prácticas ágiles al proceso de desarrollo, por más que la metodología todavía no se implemente. Técnicas como [[Integracion Continua]], [[Automatizacion De Pruebas Unitarias]], programación de pares, etc, pueden ir "preparando el terreno" entre las personas.

====Resistencia del Equipo====
No hacerse problema por los integrantes escépticos: de hecho, es su trabajo diario el cuestionar y revisar. Es necesario responder y aclarar todas sus inquietudes, con sinceridad. Si no se sabe una respuesta, o plantean una situación que no se había previsto, integrarlos para hallar juntos una solución.

Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.

===Administración de recursos===
Muchas veces las empresas necesitan asignar personal por adelantado. Puede ayudar en estos casos presentar un Release Plan, para poder ir calculando qué personas serán necesarias en distintas fechas.

No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.

===Vendors y Contrataciones===
Los Vendors proveen al equipo con algún servicio o producto necesario para el proyecto. Si la relación con el Vendor es a corto plazo, no vale la pena intentar explicarles el proceso ágil: simplemente tomar su resultado y seguir avanzando. Por otro lado, en el caso de relaciones a largo plazo (por ejemplo, integrantes tercerizados del equipo) será necesario realizar una capacitación y explicar el proceso de desarrollo ágil.

Cuando el proyecto sea para un cliente que no es ágil, será importante explicarles el proceso, haciendo incapié en los beneficios que se dará. Remarcar que pueden cancelar el proyecto cuando lo deseen, de manera de brindarles seguridad.

===Facilidades y Herramientas===
Todos los equipos y lugares de trabajo son diferentes, por lo que las soluciones van a variar de acuerdo al lugar. Involucrar siempre al equipo para encontrar soluciones al acondicionamiento del lugar: cómo ubicarse, dónde reunirse, qué salas usar, dónde pegar los gráficos, etc.

Es importante destacar que los equipos físicamente separados van a necesitar comunicarse diariamente, comunicar su avance a los stakeholders, poder planificar y colaborar entre ellos, y registrar decisiones que realicen.

Como requerimientos técnicos generales se pueden mencionar la necesidad de automatizar las prueba, integración continua y repositorios de código.

===Costos y Presupuesto===
Cuando sea necesario calcular el costo del proyecto, puede servir acotar el problema y calcular el costo de cada iteración. De hecho, con este dato se puede incluso calcular el costo por cada punto de historia, y el costo por "hacer nada".

En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.

==10 consejos para integrar Ágil y Cascada==
# '''Establecer un ritmo de Inspección y Adaptacion''': Llevar adelante todas las reuniones de [[Revision Del Sprint]] y [[Retrospectiva Del Sprint]], haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
# '''Encontrar un ejecutivo involucrado''': Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
# '''Socializar, no evangelizar''': Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
# '''Usar el poder del Backlog''': Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
# '''Tirarse a la pileta''': Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
# '''Usar el principio de "lo mínimo requerido"''': Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
# '''Invitar a todos los no-agiles a las reuniones de planificación''': Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
# '''Enviar el feedback "hacia arriba"''': Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
# '''Prestar atención al comportamiento''': En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
# '''Invitar a todo el mundo a las Retrospectivas''': En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]

==Más información==
* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]

Metodologia Agil En Una Organizacion En Cascada

2008-08-09T14:30:31Z

200.125.124.96: /* Administración de recursos */

Metodologia Agil En Una Organizacion En Cascada

2008-08-09T14:30:22Z

200.125.124.96: /* Resistencia del Equipo */