Obtencin de Requerimientos

Obtencin de RequerimientosConocer lo que el cliente quiere

Yo dije que quera un Mustang (tipo de caballo), pero me refera al modelo turbo cargadoNo siempre obtenemos lo que queremos pero el cliente debera poder! Los desarrolladores entregan lo que el cliente quiere. Hablaremos de cmo hablar con el cliente para averiguar cuales son sus requerimientos para el software. Aprenderemos cmo las historias de usuario, luuvias de ideas y el juego de la estimacin nos ayudar a meternos en la cabeza de nuestro cliente. De esa manera, cuando terminemos el proyecto, estaremos confiados de haber construido lo que el cliente quera.. Y no solo una imitacin pobre

Necesitamos un sitio web mostrando las ofertas actuales, y queremos que nuestros usuarios sean capaces de reservar cpsulas espaciales y paquetes especiales y pagar las reservas en lnea. Tambin ofreceremos servicios de lujo que incluirn transporte desde y hacia la estacin espacial y acomodacin en un hotel localrbitas Orin se modernizarbitas Orin provee servicios de transporte espacial de calidad para sus clientes exclusivos, pero su sistema de reservacin es un poco anticuado, y ahora ya estn listos para hacer el salto al siglo 22. Con el siguiente eclipse solar dentro de cuatro semanas, han invertido bastante dinero para asegurarse que su proyecto salga a la perfeccin, y sea culminado a tiempo.Orin no tiene un equipo de programacin con experiencia, por eso nos han contratado a nosotros los expertos para manejar el desarrollo de sus sistema de reservas. Depende de nosotros que sea entregado a tiempo y de manera correcta

Cada tarjeta captura una sola cosa que el software debe proveer

Ttulo:Descripcin:Arreglar el viaje un usuario de rbitas Orin ser capaz de arreglar el viaje desde y hacia el puerto espacial

Ttulo:Descripcin:Reservar un hotel un usuario de rbitas Orin ser capaz de reservar un hotel

Ttulo:Descripcin:Mostrar las ofertas actuales El sitio web mostrar las ofertas actuales de Orin

Ttulo:Descripcin:Pagar en lnea un usuario de rbitas Orin ser capaz de pagar sus reservaciones en lnea

Ttulo:Descripcin:Reservar una cpsula un usuario de rbitas Orin ser capaz de reservar un vehculo

Ttulo:Descripcin:Reservar un hotel un usuario de rbitas Orin ser capaz de reservar un hotelDeberamos utilizar un formato especfico para escribir esto?No. Por ahora estamos tomando y ordenando ideas que nuestro cliente tiene y tratamos de colocarlas en alguna manera ordenadaLos requerimientos son historias de usuario?No tanto, por el momento son solo ideas, a continuacin vamos a desarrollarlas y transformarlas en historias de usuario completas. Por el momento es til escribirlas en algn ladoLas descripciones parecen ambiguas. No necesitamos un poco ms de informacin antes de llamarlas requerimientos?Absolutamente. Existen muchos huecos en estas descripciones. Para llenar estos huecos, debemos regresar y hablar con el clienta un poco msHablar con el cliente para obtener MS informacinSiempre existen huecos cuando tratemos de entender lo que el software debe hacer, especialmente en las etapas tempranas del proyectos. Cada vez que tengamos ms preguntas, o empecemos a hacer suposiciones, necesitamos regresar y hablar con el cliente para que se respondan nuestras inquietudes.He aqu algunas preguntas que podemos tener despus de nuestra primera reunin con el Jefe de Orin:Cuntos tipos de cpsulas espaciales debe soportar el software?El software debera imprimir los recibos y facturas o los reportes mensuales (y qu debe ir en los reportes)?El software debe permitir que las reservaciones sean canceladas o cambiadas?El software tiene una pantalla de administracin para agregar nuevos tipos e cpsulas, y / o nuevos paquetes y ofertas?Existen otros sistemas con los cuales debemos comunicarnos, como sistemas de autorizacin de tarjetas e crdito o control de trfico aeroespacial?..

Te puedes inventar otra pregunta?

Ok, gracias por preguntar. Te responder en unos minutos, ya que he pensado en algo ms que se me olvid decirte antes.Trata de obtener requerimientos adicionales.Hablar con el cliente no solamente nos dar la oportunidad de obtener ms detalles sobre los requerimientos existentes. Tambin queremos averiguar los requerimientos adicionales que el cliente no pens antes. No hay nada peor que terminar un proyecto y el cliente diga que olvid un detalle importante.Entonces cmo hacemos que el cliente piense en todo lo que necesitamos, antes de empezar a construir el software?Bluesky con nuestro clienteCuando iteremos con el cliente los requerimientos, PENSEMOS EN GRANDO. La lluvia de ideas con otras personas; dos cabezas piensan mejor que una, y diez cabezas son mejor que dos, mientras que todos sientan que pueden contribuir sin criticismo. Al principio no descartemos ninguna idea, solo capturemos todo. Est bien si salen ideas descabelladas, mientras siempre nos enfoquemos en las necesidades base que el software intentar alcanzar. A esto se le llama lluvia de ideas Bluesky para requerimientos.

El DesarrolladorEl Equipo de ClientesSe pueden incluir a los usuarios tambinTu equipo de desarrolladoresNunca nos olvidemos de incluir al cliente en estas sesionesPagar con tarjetas de crdito y PayPalEscribir una resea del vueloOrdenar un DVD del vuelo en transbordadorUtilizar Ajax para una mejor interfaz de usuarioOrdenar bebidas o bebidas dentro del vueloEscoger pasillo o ventanaEvitar polticas de oficina.Nada trunca la creatividad de la lluvia de ideas Bluesky que un jefe que no deja hablar a los dems. Intentemos dejar las descripciones de trabajo y otras polticas en la puerta. Todos deberan tener una opinin por igual para asegurarnos de obtener lo mayor posible de la sesin de lluvia de ideasMuchas veces las sesiones Bluesky se vern asAlgunas veces, sin importar cuanto nos esforcemos; nuestras sesiones pueden ser tan cerradas que nadie opine nada. Muchas veces las personas que conocen lo que el sistema debera realizar realmente no estn acostumbradas a salir de la timidez en un ambiente de lluvia de ideas, y terminaremos con una larga y silenciosa tarde.

< Nada >Ordenar bebidas y comida dentro del vueloAlgunas personas nos darn mucha informacin y otras se cerrarn y nos darn la ley del hielo

El Zen de los buenos requerimientosLa clave para capturar buenos requerimientos es involucrar tantos interesados en el proyecto como sea posible. Si poner a todos en el mismo lugar no funciona, hagamos lluvias de ideas de manera individual y luego los juntamos y ponemos todas las ideas en una pizarra y hacemos un poco ms de lluvias de ideas. Siempre salgamos y pensemos en lo que ha pasado y regresemos en grupo para una segunda entrevistaExisten MUCHAS maneras de obtener requerimientos. Si una tcnica no funciona, simplemente INTENTEMOS OTRAAveriguar lo que las personas REALMENTE hacenTodo se vale (dentro de lo petico y legal) cuando intentamos meternos en la mente de nuestro cliente para entender sus requerimientos. Dos tcnicas particularmente tiles pueden ayudarnos a entender al cliente juego de rol y observacin.

Juego de rol.Si nuestro cliente no puede visualizar cmo necesita que funcione el software, actumoslo. Pretendamos ser el software y el cliente intenta instruirnos en lo que el desea que hagamos. Luego escribimos cada cosa que el software necesita hacer en una de nuestras tarjetas de requerimientosPretendemos ser el softwareNuestro cliente pretende que nosotros somos el software e intenta hacer el trabajoY ahora seleccionara las fechas para las reservasOK, ahora despliego un calendario (y agregamos fechas a mi tarjeta Crear reservacin)

ObservacinAlgunas veces la mejor manera de entender como las personas trabajarn con el software es observarlas y luego descifrar dnde encajara. Nada le gana a la evidencia de primera mano, y la observacin puede ayudar a sacar las restricciones y los detalles que pudieron haberse escapado en la lluvia de ideas o incluso en el juego de roles. Tambin, intentemos observar la misma interaccin ms de una vez con mltiples observadores para no ganar solamente un punto de vista del eventoSu podemos, intentemos que tres personas observen en tres ocasiones distintasIntentemos mantener las observaciones lo ms discretas posiblesS, ofrecemos una gran seleccin de tipos de asientosHmm, ese requerimiento no estaba presente anteriormenteLos requerimientos deben estar orientados al clienteUn buen requerimiento est escrito desde la perspectiva del cliente describiendo lo que el software har para el mismo cliente. Cualquier requerimiento que el cliente no entienda es una bandera roja inmediata, ya que no son cosas que el cliente haya podido pedir.Un requerimiento debera ser escrito en el lenguaje del cliente y ser ledo como una historia de usuario: una historia acerca de cmo nuestros usuarios interactuarn con el software que vamos a construir. Cuando decidamos si tenemos buenos requerimientos o no, juzguemos cada uno contra el siguiente criterio:Las historias de usuario DEBERAN:describir una sola cosa que el software debera hacer para el clienteser escrito en un lenguaje que el cliente pueda entender ser escrito por el clienteser corto. Apuntemos a no ms de tres lneasLas historias de usuarios NO DEBERAN:ser un ensayo extensoutilizar trminos tcnicos que no son familiares para el clientemencionar ninguna tecnologa especficaDebemos ser capaces de chequear cada tem por cada historia de usuario

Ttulo:Utilizar Ajax para la UI La interfaz de usuario utilizar la tecnologa Ajax para proveer una experiencia de usuario ms vistosaDescripcin:

Esta tarjeta no es una historia de usuario; es una decisin de diseo. Guardmosla para ms tarde cuando empecemos a implementar el softwareIDEAS DE DISEOUna historia de usuario est escrita desde la PERSPECTIVA DEL CLIENTE. Tu cliente Y t deberan entender lo que cada historia de usuario significa

Genial, entonces hemos creado ms historias de usuario, y an tenemos ms preguntas. Qu hacemos con todas las cosas que an no tenemos claras?Pregntale al cliente (s, una vez ms)Lo ms til de las historias de usuario es que es fcil para nosotros y nuestros clientes leerlas y descifrar qu puede estar faltando.Cuando estemos escribiendo las historias con el cliente, veremos que generalmente dicen cosas como Oh, y tambin hacemos esto, o En realidad, lo hacemos de esta manera estas son las mejores oportunidades de redefinir los requerimientos y hacerlos ms precisos.Si algo no esta lo suficientemente claro acerca de cualquier cosa, entonces es hora de tener otra discusin con nuestros clientes. Regresemos a preguntar otro conjunto de preguntas. Solamente cuando no tengamos ms preguntas estaremos listos para pasar a la siguiente etapa y cuando el cliente se sienta feliz que las historias han capturado todas las necesidades que necesitan que haga el software por ahoraPara qu sirve el campo Ttulo en la historia de usuario? La descripcin tiene toda la informacinEl campo ttulo es solo una manera til de referirnos a cada historia de usuario. Tambin le da a todos en el equipo la misma manera de referirnos a dicha historia. De esta manera no tenemos a algunos diciendo pagar con PayPal y a otro diciendo pagar con tarjeta de crdito y averiguar despus que estn hablando de lo mismo (cuando ya ambos han hecho trabajo por gusto)Al aadir trminos tcnicos y algunas ideas de diseo a mis historias de usuario, no las hara ms tiles para mi y mi equipo?No, evita utilizar trminos tcnicos o tecnologas en ste punto. Mantn las cosas en el lenguaje del cliente, y nicamente describe lo que el software necesita hacer. Recuerda, que las historias de usuario estn escritas desde la perspectiva del cliente. El cliente tiene que decirte si la historia de usuario est correcta, as que un montn de trminos tcnicos los confundir (Y posiblemente obscurecer el saber si tu requerimientos son precisos o no)Si vemos que hay alguna posibilidad de ingresar decisiones tcnicas que puedes empezar a agregar cuando escribes las historias de usuario, escribe esas ideas en otro conjunto de cartas haciendo referencia el ttulo. Cuando vayas a codificar puedes traer esas ideas de regreso para ayudarte en este punto, cuando es ms apropiadoY se supone que debo hacer este refinamiento de las historias de usuario junto al cliente?S, absolutamente. Despus de todo, estaremmos listos para el siguiente paso una vez que nosotros y el cliente finalmente decidamos que hemos entendido completamente los requerimientos de software. No podemos tomar la decisin por nosotros mismos, as que mantener al cliente cerca es esencial.Esto parece mucho trabajo de obtencin de requerimientos al principio del proyecto. Qu pasar cuando las cosas cambien?El trabajo que hemos hecho hasta ahora es solamente nuestro primer intento de obtencin de requerimientos al principio del proyecto. Continuaremos refinan do y capturando nuevos requerimientos donde sea necesario dentro de las iteraciones del proyecto.Desarrollar los requerimientos con retroalimentacin del clienteLos pasos que hemos seguido hasta ahora han sido solamente para llegar a un punto fijo con las ideas del cliente y refinar esas ideas en historias de usuario. Ejecutamos estos pasos de una u otra forma, al principio de cada iteracin para asegurarnos que siempre tengamos las caractersticas correctas que irn en la prxima iteracin. Veamos cmo se vera este proceso...

Ideas del clienteMantenemos involucrado al cliente en cada pasoRefinar el grupo inicial de historias de usuarioCapturar las ideas bsicasLluvia de ideas BlueskyConstruir las historias de usuarioEncontrar huecos y agregar claridad a los detalles utilizando la retroalimentacin del clienteHistorias de usuario, claras y enfocadas al clientesta es la meta en esta etapaEl primer grupo de requerimientos que vamos a agregar y a clarificar durante las iteraciones del proyectoRecordar, este proceso ocurre al principio de cada iteracin, no solo al principio del proyecto

Ttulo:Reservar una cpsula espacial Un usuario ser capaz de reservar una cpsula especificando los datos y el tiempo del vueloDescripcin:

Ttulo:Escoger los asientosUn usuario ser capaz de escoger pasillo o ventanaDescripcin:EntrevistaLas historias de usuario definen el QU de nuestro proyecto... Las estimaciones definen el CUNDODespus de la etapa de captura de los requerimientos tendremos un conjunto de historias de usuarios orientadas al cliente y muy claras que nosotros y el cliente creemos han capturado el QU se est tratando de construir, al menos para la primera iteracin o algo as . Pero no nos confiemos mucho ya que el cliente quiere saber CUANDO sern construidas todas esas historias de usuario.Esta es la parte dondeelcliente pregunta la fantstica pregunta: Cunto se demorarn?

Hmm, grandioso. Ahora qu hago? Cmo hago para averiguar cunto me va a tomar hacer todo esto si lo nico que tengo es un montn de tarjetas? El estimado del proyecto es la suma de los estimados de nuestras historias de usuarioPara averiguar cuanto nos tomar completar todos los requerimientos capturados en nuestras historias de usuario, necesitamos realizar dos pasos:Necesitamos:Estimar cada historia de usuario por cuanto tiempo pensamos nos tomara desarrollarla, es decir diseo, codificacin, pruebas y entregasSumar todos los estimados para obtener un total estimado de cuanto tiempo tomara entregar los requerimientos de software de nuestro proyecto

Pagar Con tarjeta de Crdito o PayPalVisa2 dasMasterCard2 dasPayPal2 dasAmerican Express5 dasDiscovery4 das

Escoger asientosEscoger ventana o pasillo2 dasEscoger el asiento dentro de cpsula10 das

Ordenar DVD del vueloVideo definicin setandar2 dasSubttulos personalizados5 dasVideo de alta definicin5 das

Ordenar comidas para el vueloSeleccionar de una lista de tres comidas y tres bebidas5 dasPermitir elegir opciones vegetarianas2 das

Crear resea del vueloCrear una resea online3 dasAgregar una resea via email5 das

Tu trabajo es leer las tareas de cada tarjeta y resolver un estimado por historia de usuario y anotar cualquier suposicin que tengas de alguna

Tus EstimacionesEstimaciones de BobEstimaciones de LauraColoca tus estimaciones aquAl menos parece que estamos de acuerdo en unaTtulo: Pagar con PayPal/MC/VisaTtulo: Ordenar un DVD del vueloTtulo: Escoger asientosTtulo: Ordenar comidas dentro del vueloTtulo: Resea del vuelo

Conversacin de CubculoDeshacernos de las suposiciones es la actividad ms importante cuando creamos estimados Laura, no creo que ambos estemos equivocados. No entiendo cmo pudimos obtener estimados completamente diferentes?Laura: bueno empecemos con la primera historia de usuario. cmo pudiste estimar 10 das?Bob: pues muy fcil. Escog las tarjetas de crdito ms populares que se me ocurran y luego aad el soporte a PayPalLaura: pero existen muchos ejecutivos que solo utilizan American Express, entonces asum que debamos soportar esa tarjeta tambin, no solo Visa y MasterCardBob: Ok, pero an no me siento completamente feliz con eso. Esa suposicin hace un gran diferencia en cuanto nos demoraremos en desarrollar esa historia de usuarioLaura: lo s, pero qu podemos hacer, no sabemos lo que espera el clienteBob: pero mira estoestimaste a 20 das el Ordenar el DVD del vuelo cuando con todas las opciones no debera tardar ms de 14 das, mximo!Laura: estaba siendo un poco conservadora en realidad. El problema es que crear un DVD es una nueva caracterstica para m, es algo que jams he desarrollado antes y estaba factorizando el tiempo de investigacin, aparte de creacin y pruebas. Entonces sali algo alto.Bob: wow, no lo haba pensado de esa manera, pens que ya se haba pensado en eso y estaba incluido. Me pregunto si el resto de estimaciones incluyen tareas como investigacin e instalacin de software?Laura: en mi experiencia, probablemente no. Por eso estoy cubriendo mi espaldaBob: entonces todas nuestras estimaciones pueden estar mal hechasLaura: bueno, al menos estuvimos de acuerdo en unBob: s, pero he hecho suposiciones tambin, y ni siquiera toma en cuenta las sobrecargas que me decas.Laura: entonces lo que tenemos es un montn de estimaciones que no estn bien hechas. Cmo vamos a generar un nmero de confianza para el proyecto cuando no sabemos an cuales sern las suposiciones de los dems?Pker de planificacinPara poder estimar de manera ms precisa, necesitamos deshacernos de todas las suposiciones que podran poner en riesgo de erro a nuestras estimaciones. Queremos un conjunto de estimaciones que todos puedan creer y que tengamos confianza de poder entregar, o al menos queremos un conjunto de estimaciones que nos deje saber qu suposiciones estn haciendo todos antes de firmar un contrato. Es hora de llamar a todos los que van a involucrarse en la estimacin de nuestras historias, sentarlos en circulo y prepararnos para jugar pker de planificacinColocar una historia de usuario en la mitad del grupo o mesaEsto nos hace enfocarnos en una historia de usuario especfica cuando hagamos las estimaciones.

Ttulo:Pagar con Paypal/Visa/MCDescripcin: Un usuario ser capaz de pagar su reserva con tarjeta de crdito o PayPal

Queremos una estimacin slida de cuanto nos tomar desarrollar esta historia de usuario. No olvidar que el desarrollo debera incluir diseo, codificacin, pruebas y entregas de cada historia de usuarioA cada persona se le da un juego de 13 cartas, cada carta tiene una estimacin escrita de un ladoSolo necesitamos una baraja pequea para cada persona, lo suficientemente grande para darle a las personas opciones

Esta tarjeta significa que ya est hechoTodos estos estimados son das desarrollador (como das hombre), por ejemplo, dos das-hombre dividido entre dos trabajadores son an dos dasTodos tienen una de estas cartasHmm saben qu puede significar si alguien juega con una de estas cartas para sus estimaciones?Si no se tiene la informacin suficiente podramos considerar esta cartaSi algn jugador utiliza esta carta, necesitarn tomar un descanso por un momentoTodos elijen una estimacin para la historia de usuario y colocan la tarjeta correspondientes bocabajo en la mesaEscogemos la carta que representa a la estimacin escogida para la historia de usuario; no hay que mostrar la carta ni discutir la estimacin con nadie ms

Colocamos la eleccin bocabajo para que nadie ms vea nuestra estimacinLa historia de usuario est an en la mitad es an el centro de atencinAseguremos que nuestros estimados tengan un alcance de toda la historia de usuario, y no solo una parte de ella

Todos voltean sus cartas al mismo tiempoCada jugador en la mesa muestra su mano, dando a conocer su estimacin para la historia de usuario

Estas cartas casi nunca son iguales. Esto est binEl dealer (encargado del juego) marca los resultados de cada estimacinQuien sea que est a cargo del juego anota en un plano cada estimacin de la mesa. Y empieza a hacer un poco de anlisis

Es probablemente seguro descifrar una estimacin precisa dentro de este rangoPreguntemos al desarrollador que jug esta carta, en qu estaba pensando; no hay que ignorarlo, y hay que tratar de extraer las suposiciones que han hechoEntre ms larga sea la diferencia de estimaciones, menos confiados estaremos de estas estimaciones y ms suposiciones debemos erradicar

Cmo va a ayudar esto con las suposiciones? Qu hacemos con el tipo que coloc 100? no podramos ignorarlo verdad?Los resultados grandes pueden ser malos entendidos.Cuando veamos un hueco grande entre las estimaciones de una historia en particular, algo puede esta mal. Podra ser que alguien de nuestro equipo haya mal entendido la historia de usuario; en ese caso es hora de revisitar dicha historia. O puede ser que algunos miembros del equipo no estn seguros de algo que otra parte del equipo s.En cualquier caso, es hora de mirar las suposiciones que nuestro equipo est haciendo y decidir si necesitamos regresar a hablar con el cliente para obtener ms informacin y clarificacin de las historias y las suposiciones que estamos haciendo de ellas.De hecho, incluso si todos estiman dentro del mismo rango, vale la pena preguntar las suposiciones a alguien para asegurarnos de que TODOS las estemos haciendo. Es poco probable que todos se equivoquen de suposiciones en estos casos, pero solamente para estar seguros, discutan y documenten sus suposiciones despus de cada ronda de pker de planificacinEscribamos las suposiciones en la parte trasera de las tarjetas donde escribimos las historias de usuarioPongamos las suposiciones en el juzgadoCuando se trata de requerimientos, una buena suposicin es no tener suposiciones. Cuando juguemos pker de planificacin y resulten en alguna suposicin, no debemos dejar que dicha suposicin se meta en el proyecto sin tratar de hacer todo lo posible por destruirla antes

Poner cada suposicin en el juzgadoEl objetivo es tener la menor cantidad de suposiciones posibles cuando realizamos nuestras estimaciones. Cuando una suposicin aparece en el juego de pker, e incluso si el equipo completo comparte la misma suposicin, hay que pensar que dicha suposicin es errnea hasta que sea clarificada por el cliente

Al menos sabemos que no sabemosNo importa cuanto lo intentemos, algunas suposiciones realmente van a sobrevivir a las clarificaciones del cliente. Y esta bien. Algunas veces los clientes no tienen la mejor respuesta a una suposicin particular al principio de un proyecto, y en esos casos necesitamos vivir con esa suposicin. Lo ms importante es conocer que existe esa suposicin y que debemos escribirla como riesgo para esa historia de usuario en particular (podemos escribirla en la parte trasera de la tarjeta). Esto nos ayudar a estar consientes y administrar los riesgos, y eliminarlos en alguna etapa posterior del proyectoA diferencia de no saber lo que no sabemosDependiendo de las prioridades del cliente, podramos decidir retrasar el desarrollo de una historia de usuario que tiene algunas suposiciones sobrevivientes hasta que puedan ser clarificadasYa que no siempre podemos deshacernos de todas las suposiciones, la meta durante las estimacin es ELIMINAR tantas suposiciones como sea posible CLARIFICANDO dichas suposiciones con el cliente. Cualquier suposicin que sobreviva se transforma entonces en un RIESGO

Con todas esta charla de clarificacin con el cliente, me parece que podemos estar molestando al cliente demasiado. Podramos pensar en cmo utilizar el tiempo del cliente de manera efectivaValoremos el tiempo con el cliente.Poner todas las suposiciones en el juzgado y buscando clarificacin por parte del cliente puede convertirse en mucho trabajo. Podemos fcilmente gastar mucho, si no es todo, nuestro tiempo con el cliente. Eso podra estar bien con algunos clientes, pero qu pasa con los que se encuentran muy ocupados para hablar con nosotros cada 15 minutos?En estos casos necesitamos utilizar el tiempo del cliente con mucho cuidado. Aunque intentamos asegurarnos de que hemos entendido todo en el proyecto, no queremos parecer que no entendemos nada tampoco. As que cuando pasemos tiempo con el cliente, asegurmonos que dicho tiempo est organizado, sea eficiente y bien invertido.Intentemos de recolectar una coleccin de suposiciones y luego clarificar todas ellas en una sola reunin con el cliente. En lugar de molestar al cliente al final de cada round de pker de planificacin; es mejor arreglar una sesin de destruccin de suposiciones donde tomamos todas las que hemos recolectado y tratamos de destruir la mayor cantidad posible.Una vez que tengamos las respuestas, regresamos para un round final de pker de planificacinUna vez que tengamos un nmero significativo de suposiciones destruidas en la/s sesin/es con el cliente, es hora de regresar y jugar un ltimo roun de pker de planificacin para que nosotros y nuestro equipo puedan llegar a obtener estimados que factoricen las nuevas clarificacionesPorque existe una brecha entre 40 y 100 das en las cartas de pker de planificacin?Bien, El hecho es que 40 es ums estimacin muy grande, as que si sientes que la estimacin debe ser 41 o incluso 30 das no es realmente importante en este punto. El 40 nos dice nicamente que piensas que aun existen muchas cosas que hacer en esta historia de usuario, y que estamos en los lmites de no ser capaz de estimar esta historia...100 das parece muy largo, es alrededor de medio ao en horas de trabajo! Por qu tenemos 100 das en las cartas?Correcto, 100 das es un tiempo muy largo. Si alguien saca la carta de 100 das entonces hay algo que realmente no se entiende o algo que no se encuentra bien descrito en la historia del usuario . Si encontramos que una historia de usuario es muy larga, entonces es hora de dividirla en historias ms pequeas, y ms estimables.Qu significan los signos de interrogacin en las cartas? Significan que no tienes la suficiente informacin para estimar historia de usuario o la has malentendido, o tambin que tus suposiciones son tan grandes que no tienes confianza de que ningn estimado que pongas en la mesa puede ser el correcto Algunas personas van a escoger los nmeros de broma. Qu hago con ellos?Buena pregunta. Primero, mira las tendencias de las estimaciones individuales para ver si realmente estn siendo usadas de broma, o si de hecho estn correctas. Sin embargo, algunas personas estn inclinadas a escoger nmeros muy altos o muy bajos la mayora del tiempo.Por ende, cada estimacin, particularmente los que estn demasiado alejadas del resto de los jugadores, deberan ser estudiadas despus de cada round para sobresaltar la suposiciones que se estn haciendo sobre la misma.Despus de algunos rounds donde nos empezamos a dar cuenta que los estimados de broma no tienen respaldados, podemos empezar a pensar en sacar a esas personas de la mesa, o hablar en privado con ellos para insistirle que dejen de hacer la broma o que salgan por su propia voluntad Deberamos pensar en quien implementa la historia de usuario con nuestras estimaciones?No, cada jugador estima cunto tiempo se demorar l/ella en desarrollar y entregar el software que implemente dicha historia usuario. A la hora de estimar, no vamos estar seguros de quin va a implementar una historia de usuario en particular, estamos tratando de medir las capacidades de cada uno de los miembros del equipo para entregar dicha historia.Por supuesto, si una historia de usuario particular es perfecta para las habilidades de alguien en particular, entonces dicha persona ser capaz de estimar con un nmero ms bajo que los dems. Pero estas estimaciones bajas deben ser balanceadas con el resto del equipo, quienes deberan cada uno asumir que implementarn dicho historia de usuario de manera individualAl final, la meta es obtener una estimacin que diga "nosotros como equipo estamos confiados que este tiempo es lo que se demorar cualquiera de nosotros en desarrollar esta historia de usuarioCada estimacin se considera ms que slo la implementacin, verdad?S, cada jugador debe factorizar cunto tiempo le tomar en desarrollar, y entregar el software incluyendo cualquier detalle que necesite el mismo. Esto puede incluir documentacin, pruebas, empaquetado, implantacin, y bsicamente todo lo que necesite estar hecho para desarrollar y entregar el software con las caractersticas de la historia de usuario.Si no sabemos qu otros entregable se necesitan, entonces tenemos una suposicin, y podra ser una pregunta para el cliente.

Qu pasa si el equipo est de acuerdo en la misma estimacin cuando las cartas se voltean?. Necesito preocuparme de la suposiciones?Claro que s. Incluso si todos estn de acuerdo, es posible que todos tengan las suposiciones errneas. Cuando las estimaciones no coinciden indica que existe ms trabajo por hacer y que el equipo est haciendo suposiciones diferentes y posiblemente grandes en sus estimaciones. Cuando dichas estimaciones coinciden nos indica que el equipo podra estar haciendo las mismas suposiciones errneas, as que debemos examinar esta suposiciones Sin importar el resultado del pker.Es importante tener todas y cada una de las suposiciones abiertas sin importar lo que digan las estimaciones, para poder clarificar esta suposiciones desde el principio y mantener nuestro nivel de confianza lo ms alto posible pker.Es importante tener todas y cada una de las suposiciones abiertas sin importar lo que digan las estimaciones, para poder clarificar esta suposiciones desde el principio y mantener nuestro nivel de confianza lo ms alto posibleNo hacer suposiciones de las suposiciones hablemos de TODO

Estamos todos de acuerdo, no necesitamos ms informacin. Esta historia de usuario nos tomar 40 das en desarrollarLa historia de usuario es muy grande40 das es una largo tiempo, y muchas cosas pueden cambiar. Recordemos, 40 das son dos meses en tiempo de trabajo.Una iteracin completa debera ser de alrededor de un mes calendario de duracin . Sin contar los fines de semana y das festivos, es decir al rededor de 20 das de trabajo. Si nuestras estimaciones son de 40 das por slo una historia de usuario, entonces ni siquiera va a entrar en una interaccin de desarrollo a menos que hayan dos personas trabajando en la misma historia!Como regla, las estimaciones que son ms largas de 15 das tienen menos probabilidades de ser precisas que las estimaciones que duran menos de 15 dasRecordamos esto de la primera diapositiva?De hecho, algunas personas creen que las estimaciones ms largas que siete das deberan ser chequeadas nuevamente

Si debemos tener estimaciones largas como est, entonces necesitamos hablar como equipo en la mayora de veces. En las siguientes diapositivas hablaremos de esoUna estimacin GRANDE es una estimacin MALACuando la estimacin de una historia de usuario se pasa de la regla de los 15 das podemos hacer lo siguiente:Dividir las historias de usuario en historias ms pequeas y ms fcilmente estimables.Aplicando la regla del Y. cualquier historia de usuario que tenga un y en su ttulo o descripcin probablemente pueda ser dividida en dos o ms historias pequeasHabla con el cliente una vez msTal vez existen algunas suposiciones que estn haciendo que las estimaciones crezcan. Si el cliente pudiera clarificar las cosas, esas suposiciones podran desaparecer y hacer que las estimaciones se reduzcan significativamenteEstimaciones ms grandes que 15 das por historia de usuario nos dar mucho margen de error.Cuando una estimacin es muy larga, aplicar la regla Y para dividir la historia de usuario en historias ms pequeas

Cada tarjeta captura una sola cosa que el software debe proveer

Ttulo:Descripcin:

Ttulo:Descripcin:

Ttulo:Descripcin:Escoger los asientos Un usuario escoger pasillo o ventana, ser capaz de seleccionar el asiento que desea y cambiar ese asiento 24 horas antes del vuelo

Ttulo:Descripcin:

Ttulo:Descripcin:Ordenar comidas en el vuelo Un usuario escoger qu comida desea, de tres tipos de men, y ser capaz de indicar si son vegetarianos o veganos

Ttulo:Descripcin:Tratemos de dividir estas historias de usuario, en historias ms pequeasLa meta es la convergenciaDespus de un round slido de pker de planificacin, no solo deberamos tener estimaciones para cada historia de usuario sino tambin la confianza en estas estimaciones. La meta ahora es eliminar cuantas suposiciones sean posibles, y converger todos los puntos de cada estimacin de historia de usuario.

Estas estimaciones estn bastante cerca una de otraLas estimacin que nosotros y nuestro equipo ha llegado a consenso Nos hemos desecho de las otras estimaciones fuera de rangoRealizar el ciclo de pasos hasta que alcancemos un consenso:Hablar con el clientePrimero que nada, obtener tanta informacin como sea posible y remover todas las suposiciones y malos entendidos como se pueda hablando con el clienteJugar pker de planificacinJugar pker de planificacin con cada historia de usuario para sacar a la luz cualquier tipo de suposicin. Pronto aprenderemos cuanta confianza tenemos para estimar el trabajo que necesitamos realizarClarificar suposicionesUtilizando los resultados del pker de planificacin, seremos capaces de ver dnde el equipo pudo tener malos entendidos con las historias de usuarios, y dnde se puede necesitar clarificacinLlegar a un consensoUna vez que todos las estimaciones se han cerrado, hay que quedar de acuerdo en un nmero para la estimacin de esa historia de usuarioTambin puede ser til anotar las estimaciones bajas, altas y convergidas para darnos una idea del mejor y peor escenarioRegresar al paso 1 si encontramos suposiciones que solo el cliente puede aclarar

Cun suficiente es suficiente?Decidir que nuestras estimaciones son suficientes para un consenso depende enteramente de nosotros mismos. Cuando nos sentimos confiados en una estimacin, y estamos cmodos con las suposiciones que se han hecho, entonces es hora de escribir la estimacin en la tarjeta de la historia de usuario y seguir adelanteCiclo de Requerimiento a Estimacin

Capturar las ideas bsicasLluvia de ideas BlueskyConstruyendo las historias de usuarioIdeas del cliente

Ttulo:Reservar una cpsula espacial Un usuario ser capaz de reservar una cpsula especificando los datos y el tiempo del vueloDescripcin:

Encontrar huecos en la claridadSiempre manteniendo al cliente dentro del procesoRefinar las historias de usuarioHistorias de usuario claras y enfocadas al clienteJugar pker de planificacinTrabajar con el equipo

Ttulo:Reservar una cpsula espacial Un usuario ser capaz de reservar una cpsula especificando los datos y el tiempo del vueloDescripcin:

Ttulo:Reservar una cpsula espacial Un usuario ser capaz de reservar una cpsula especificando los datos y el tiempo del vueloDescripcin:Obtener cualquier informacin faltante del cliente, y dividir historias grandesEstimar cuanto tomar desarrollar todos los requerimientos del clienteESTIMAR!Ya estamos listos para estimar cuanto tiempo nos tomar terminar todo el proyectoConverger las estimaciones dispersas, y colocar el estimado en cada historia de usuarioFinalmente, estamos listos para estimar todo el proyectoYa tenemos historias de usuarios cortas y enfocadas en el cliente, hemos tambin juagado pker de planificacin para cada historia de usuario. Hemos solucionado todas las suposiciones que hemos hecho con el equipos en las estimaciones y tenemos un conjunto de estimaciones en que creer. Es hora de regresar al cliente con el estimado total del proyecto

Agregar una estimacin a cada historia de usuario por cuanto tiempo pensamos nos tomar desarrollar esa funcionalidadSumar todas las estimaciones para obtener un estimado total de cuanto tiempo nos tomar cumplir con los requisitos del proyecto

Tenemos la estimacin por cada historia de usuarioY el estimado total del proyecto esSumamos cada uno de las convergencias de nuestras estimaciones de las historias de usuario, y encontramos la duracin total de nuestro proyecto, si queremos construir todo lo que el cliente desea.

Suma de estimaciones por historia de usuario= 489 Das!

489 das para todo el proyecto? Son casi dos aos!!Es demasiado tiempo. Para cuando hayan terminado el software, mi competencia nos habr pulverizadoQu hacer cuando la estimacin es demasiado larga?Finalmente tenemos una estimacin en la cual confiamos, y toma en consideracin todos los requerimientos que el cliente desea. Pero hemos terminado con un proyecto inmenso que nos va a tomar demasiado tiempo.Es hora de regresar y discutir el tema? Vamos a admitir derrota y darle el proyecto a alguien ms? O le preguntamos al cliente cuando desea l que sea la fecha lmite y nos olvidamos del arduo trabajo que nos llevo hasta aqu?