![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/03\/QualUserStories.jpg\" "\\"QualUserStories\\"")
<\/a>Requisitos<\/strong><\/h3>\nUn d\u00eda, un jefe de proyecto me explic\u00f3 que yo ten\u00eda que escribir las especificaciones para los requisitos de los usuarios, antes de empezar a programar. \u00bfPor qu\u00e9 tengo que perder 2 o 3 d\u00edas para escribir especificaciones y esperar una semana para que no s\u00e9 qui\u00e9n las accepta, cuando podr\u00eda haber hecho el trabajo de inmediato?<\/p>\n
Bueno, puedo entenderlo. Demasiadas veces empec\u00e9 a tocar el teclado antes incluso de pensar a lo que ten\u00eda de hacer y al final del d\u00eda, demasiadas l\u00edneas de c\u00f3digo que ni siquiera yo pod\u00eda entender, y peor a\u00fan, que no hac\u00edan nada. Bugs, bugs, bugs. As\u00ed que aprend\u00ed a tomar por lo menos 10 minutos a reflexionar, dibujar algo, pensar en un algoritmo.<\/p>\n
Era un tiempo cuando metodolog\u00eda significaba dise\u00f1ar un algoritmo. Despu\u00e9s de eso, fue \u201centidad-relaci\u00f3n\u201d. Estructurar los datos como entidades y definir las relaciones entre ellos. Una metodolog\u00eda llamada Merise, muy famosa en los a\u00f1os 80. Por lo menos me ha gustado mucho, porque era como un ejercicio mental, un juego y era muy \u00fatil para dise\u00f1ar la capa de datos.<\/p>\n
El \u00fanico problema es que tienes un mont\u00f3n de reuniones y por favor, tomate papel porque vamos a pasar unas horas hablando de si esta relaci\u00f3n es bidireccional y de cardinalidad. Y sabes que la eficacia de una reuni\u00f3n es inversamente proporcional a cuanta m\u00e1s gente hay alrededor de la mesa. Y si se trata de una reuni\u00f3n de \u00abuser stories\u00bb, incluso si s\u00f3lo tienes a dos personas alrededor de la mesa, pero que uno es un desarrollador y el otro usuario, olv\u00eddate de la metodolog\u00eda y mejor recordarse de una reglas sencillas.<\/p>\n
Los desarrolladores son de Marte y los usuarios de Venus <\/strong><\/h3>\nLos desarrolladores y los usuarios no hablan el mismo idioma, \u00bfpor qu\u00e9 perder el tiempo cont\u00e1ndose \u00abhistorias\u00bb?<\/p>\n
El proyecto est\u00e1 de retraso. El jefe del proyecto tiene una reuni\u00f3n con los usuarios y escucha sus \u00faltimas \u00abhistorias\u00bb. Luego el se pone con su hoja de c\u00e1lculo o su software de gesti\u00f3n de proyectos para actualizar la planificaci\u00f3n del proyecto. Luego tiene otra reuni\u00f3n para vender a los usuarios el nuevo calendario. Y luego una reuni\u00f3n con su jefe para hablar del calendario final. A\u00fan m\u00e1s presi\u00f3n. Por \u00faltimo, se va a ver al programador que deja todo lo que est\u00e1 haciendo y r\u00e1pidamente desarrolla un prototipo de modo que hay algo que mostrar en la pr\u00f3xima reuni\u00f3n y que los usuarios pueden ver que todo el equipo comenz\u00f3 a trabajar en sus \u00abhistorias\u00bb. Tal vez los usuarios ser\u00e1n felices. Muy a menudo, van a empezar una otra \u00abhistoria\u00bb. O decir que el jefe de proyecto no entiende nada, que es tonto.<\/p>\n
La \u00fanica metodolog\u00eda que conozco es \u00abgarbage in, garbage out\u00bb. Y como director de proyecto, mi primera prioridad siempre ha sido que todos entiendan bien que yo no ser\u00eda responsable de la basura en la entrada. Por lo tanto:<\/p>\n
1. El desarrollador no empieza nada hasta que el usuario tenga la \u00abhistoria\u00bb.<\/p>\n
2. El usuario redacta su \u00abhistoria\u00bb y firma su \u00abhistoria\u00bb. Con su propia sangre, si es posible.<\/p>\n
Todo es cr\u00edtico<\/strong><\/h3>\nLos usuarios quieren todo y su contrario. Una vez tuve una reuni\u00f3n con cerca de 20 vendedores para establecer una lista de requisitos. Despu\u00e9s de un par de horas bastante productivas, ten\u00edamos definido lo que estaban esperando para su aplicaci\u00f3n comercial y les ped\u00ed elegir lo que era cr\u00edtico para ellos, lo que era importante y lo que era \u00abnice to have\u00bb. Me miraron como si yo les ped\u00eda un descuento, y respondieron que \u00abtodo es cr\u00edtico\u00bb. Entonces les expliqu\u00e9:<\/p>\n
\u00abUn cliente llama por tel\u00e9fono y vosotros dese\u00e1is lo m\u00e1s ante posible la pantalla con la ficha del cliente, los \u00f3rdenes de venta, los datos contractuales y las informaciones personales, y todo lo que quieras y en menos de un segundo \u00bfno? Y quer\u00e9is poder actualizar esta informaci\u00f3n tan pronto como sea posible mientras el cliente est\u00e1 en el tel\u00e9fono?\u00bb<\/p>\n
\u00abS\u00ed. El cliente no espera \u00bb<\/p>\n
\u00abTambi\u00e9n quer\u00e9is hacer todo tipo de consultas en todos los datos posibles para identificar conjuntos de clientes potenciales y generar correos para enviar \u00bfno?\u00bb<\/p>\n
\u00abS\u00ed\u00bb.<\/p>\n
\u00abBueno, se puede conseguir todos los datos de un cliente en un segundo, o se puede conseguir un dato de todos los clientes en un tiempo muy corto, pero no se puede tener todos los datos de todos los clientes en un segundo\u00bb .<\/p>\n
Expliqu\u00e9 que para obtener una informaci\u00f3n tan pronto como sea posible, los desarrolladores ponen un \u00edndice en los datos, pero que lo m\u00e1s \u00edndices se usan, m\u00e1s lento todo el sistema. Yo pens\u00e9 que el \u201cquery\u201d de consulta del cliente era m\u00e1s importante, y me compromet\u00ed a proporcionar esta funcionalidad con el tiempo de respuesta lo m\u00e1s r\u00e1pido posible. Luego les dije que si poder hacer todos tipos de consultas complejas en todos los datos era importante, no era algo que har\u00edan ellos todos los d\u00edas, pero una vez al mes o al trimeste. As\u00ed que si este tratamiento es lento, una vez al mes, pod\u00edan ir a tomar un caf\u00e9 a la espera de los resultados. Y estuvieron de acuerdo.<\/p>\n
Los vendedores a veces pueden ser usuarios exigentes, pero al menos entienden el concepto de negociaci\u00f3n.<\/p>\n
As\u00ed que cualquiera que sea la \u00abhistoria\u00bb de los usuarios, lo importante es que:<\/p>\n
3. El usuario define las prioridades.<\/p>\n
4. Comprometete con lo critico, haz lo mejor que puedas de lo que es importante, y el \u00abnice to have\u00bb es para la pr\u00f3xima versi\u00f3n.<\/p>\n
Yo quiero la luna<\/strong><\/h3>\nOtro proyecto consisti\u00f3 en la creaci\u00f3n de un sitio web de jardiner\u00eda. Fue un proyecto dif\u00edcil, con una planificaci\u00f3n apretada, un equipo de proyecto no bastante numeroso, y un mont\u00f3n de presi\u00f3n. Y los usuarios no saben lo que quer\u00edan, con los requisitos en constante evoluci\u00f3n. Hasta que un d\u00eda el director de la \u2018startup\u2019 del sitio web solicit\u00f3 que se desarrolle una secci\u00f3n sobre \u00abla luna y su influencia en las plantas.\u00bb<\/p>\n
Pens\u00e9 que era completamente irresponsable pedir tal cosa cuando ten\u00edamos mucho m\u00e1s importante que hacer, pero \u00e9l era el gran jefe. Ped\u00ed al m\u00e1s joven en el equipo de desarrolladores para que crea un prototipo r\u00e1pido sin perder demasiado tiempo en \u00e9l. \u00c9l desarroll\u00f3 una secci\u00f3n con dos o tres p\u00e1ginas que el usuario pueda actualizar, editar texto, a\u00f1adir algunos enlaces, etc. y coloc\u00f3 la imagen de una luna en la parte superior de cada p\u00e1gina.<\/p>\n
Hice una presentaci\u00f3n ante el gran jefe y sus ayudantes, en mi propio ordenador, y aunque no era todo lo que \u00e9l hab\u00eda pedido, le gustaba. Pero en ese momento, \u00e9l hizo algo est\u00fapido: ense\u00f1o la esquina superior derecha de la pantalla y dijo \u00abQuiero la luna aqu\u00ed.\u00bb Llam\u00e9 al joven programador que estaba en el otro extremo de la sala as\u00ed que todos pod\u00edan ver, cuando se acercaba con pasos lentos a mi despacho, que estaba cansado de los caprichos de los usuarios.<\/p>\n
El jefe reiter\u00f3 su petici\u00f3n: \u00ab\u00bfEs posible poner la luna aqu\u00ed? \u00bb<\/p>\n
El desarrollador joven mir\u00f3 con mucha atenci\u00f3n en el lugar indicado en la pantalla como si estuviera pensando profundamente sobre el tema, y \u200b\u200bsimplemente respondi\u00f3 \u00abNo\u00bb. Luego volvi\u00f3 tranquilamente a su ordenador pasando por una sala completamente aturdida. El jefe estaba tan sorprendido que solo mir\u00f3 la pantalla y dijo: \u00abBueno. Supongo que es bastante bueno, ya que est\u00e1 ah\u00ed\u201d.<\/p>\n
Despu\u00e9s de eso, ya no tuvimos jam\u00e1s ning\u00fan problema. No m\u00e1s evoluci\u00f3n de las especificaciones. A veces yo invitaba el programador a una reuni\u00f3n de proyecto, y se sentaba a mi derecha, en silencio, para que todos puedan recordar que todo \u00abera bastante bueno como estaba\u00bb. A ese joven, yo le llamaba mi \u00abKill Bill\u00bb.<\/p>\n
La lecci\u00f3n aqu\u00ed es: lo que el usuario dice que necesita puede que no sea necesario. El problema no es entender las necesidades, sino producir una aplicaci\u00f3n que satisface las necesidades de la empresa. El desarrollador puede modificar los requisitos hasta que el usuario demuestra que es absolutamente necesario. Esto implica, por supuesto, un buen conocimiento del negocio por parte del equipo del proyecto.<\/p>\n
<\/p>\n
Tengo muchas historias acerca de los usuarios y probablemente tambi\u00e9n tienes algunas. Sea cual sea la metodolog\u00eda, hay algo fundamental que recordar: \u00abKeep it simple\u00bb.<\/p>\n
El trabajo de un desarrollador es producir una aplicaci\u00f3n de calidad, con herramientas de desarrollo que tienen bugs, base de datos con tiempo de respuesta impredecible, librer\u00edas no siempre operacionales y lenguajes de programaci\u00f3n misteriosos y complejos.<\/p>\n
Los desarrolladores tienen ya suficientes problemas sin pedirles que entiendan \u00abhistorias\u00bb.<\/p>\n","protected":false},"excerpt":{"rendered":"
Metodolog\u00edas. Agile. Scrum. Extreme programming. Muchas metodolog\u00edas. \u00ab User stories \u00bb me parece muy de moda actualmente. Est\u00e1 bien. Cuando era un desarrollador, yo no pensaba en las metodolog\u00edas. O eres un buen desarrollador o no lo eres. Y si no lo eres, no existe ni una metodolog\u00eda que podr\u00eda cambiar eso.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-97","post","type-post","status-publish","format-standard","hentry","category-qa"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/97"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=97"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/97\/revisions"}],"predecessor-version":[{"id":130,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/97\/revisions\/130"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=97"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=97"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=97"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Los usuarios quieren todo y su contrario. Una vez tuve una reuni\u00f3n con cerca de 20 vendedores para establecer una lista de requisitos. Despu\u00e9s de un par de horas bastante productivas, ten\u00edamos definido lo que estaban esperando para su aplicaci\u00f3n comercial y les ped\u00ed elegir lo que era cr\u00edtico para ellos, lo que era importante y lo que era \u00abnice to have\u00bb. Me miraron como si yo les ped\u00eda un descuento, y respondieron que \u00abtodo es cr\u00edtico\u00bb. Entonces les expliqu\u00e9:<\/p>\n
\u00abUn cliente llama por tel\u00e9fono y vosotros dese\u00e1is lo m\u00e1s ante posible la pantalla con la ficha del cliente, los \u00f3rdenes de venta, los datos contractuales y las informaciones personales, y todo lo que quieras y en menos de un segundo \u00bfno? Y quer\u00e9is poder actualizar esta informaci\u00f3n tan pronto como sea posible mientras el cliente est\u00e1 en el tel\u00e9fono?\u00bb<\/p>\n
\u00abS\u00ed. El cliente no espera \u00bb<\/p>\n
\u00abTambi\u00e9n quer\u00e9is hacer todo tipo de consultas en todos los datos posibles para identificar conjuntos de clientes potenciales y generar correos para enviar \u00bfno?\u00bb<\/p>\n
\u00abS\u00ed\u00bb.<\/p>\n
\u00abBueno, se puede conseguir todos los datos de un cliente en un segundo, o se puede conseguir un dato de todos los clientes en un tiempo muy corto, pero no se puede tener todos los datos de todos los clientes en un segundo\u00bb .<\/p>\n
Expliqu\u00e9 que para obtener una informaci\u00f3n tan pronto como sea posible, los desarrolladores ponen un \u00edndice en los datos, pero que lo m\u00e1s \u00edndices se usan, m\u00e1s lento todo el sistema. Yo pens\u00e9 que el \u201cquery\u201d de consulta del cliente era m\u00e1s importante, y me compromet\u00ed a proporcionar esta funcionalidad con el tiempo de respuesta lo m\u00e1s r\u00e1pido posible. Luego les dije que si poder hacer todos tipos de consultas complejas en todos los datos era importante, no era algo que har\u00edan ellos todos los d\u00edas, pero una vez al mes o al trimeste. As\u00ed que si este tratamiento es lento, una vez al mes, pod\u00edan ir a tomar un caf\u00e9 a la espera de los resultados. Y estuvieron de acuerdo.<\/p>\n
Los vendedores a veces pueden ser usuarios exigentes, pero al menos entienden el concepto de negociaci\u00f3n.<\/p>\n
As\u00ed que cualquiera que sea la \u00abhistoria\u00bb de los usuarios, lo importante es que:<\/p>\n
3. El usuario define las prioridades.<\/p>\n
4. Comprometete con lo critico, haz lo mejor que puedas de lo que es importante, y el \u00abnice to have\u00bb es para la pr\u00f3xima versi\u00f3n.<\/p>\n