Buscar en Gazafatonario IT

martes, mayo 21, 2013

Scrum – Lo Fundamental


Lista de Chequeo de Scrum
Si logra esto puede ignorar el resto de la lista. Su proceso está bien.
  • Entregar software funcionando y probado cada 4 semanas o menos
  • Entregar lo que el negocio necesita más
  • El proceso está mejorándose continuamente

Hablemos un poco de cada uno de estos criterios.

Entregar software funcionando y probado cada 4 semanas o menos

Scrum es un método iterativo e incremental. Pero “iterativo” e “incremental” son dos adjetivos ampliamente usados y pocas veces entendidos correctamente. Ya sabemos que una iteración es un proyecto, con todo lo que eso significa: es decir, si nos atenemos a la definición del PMI®, un proyecto tiene un inicio, una planeación, una ejecución, un seguimiento y control, y un cierre, donde se formaliza la aceptación del producto o resultado, un producto que, en nuestro caso, es precisamente software, desplegado en un ambiente del usuario, no necesariamente ambiente de producción, pero del usuario al fin y al cabo, un entorno distinto al del desarrollador.

Este “incremento” de software funcionando es potencialmente distribuible, o sea, puede ponerse en producción con muy pocas o ninguna modificación, preferiblemente esto último. Y si este proyecto tarda cuatro semanas (como lo prescribe la guía orgánica de Scrum) o menos, mucho mejor. La industria del software, la nuestra, está diciendo a gritos que este lapso de tiempo sea de dos semanas. Así, podemos conseguir retroalimentación más efectiva y al día de los usuarios, mucho más de lo que hemos logrado en el pasado cuando solo entregábamos “papelware”, documentos llenos de texto (requisitos), diagramas de UML (arquitectura, análisis y diseño), casos de prueba, etcétera.

Entregar lo que el negocio necesita más

¿Quién mejor que el usuario conoce el verdadero valor de lo que necesita? Es el usuario, que en Scrum se llama Dueño del Producto, el que define y prioriza sus necesidades y las de los demás interesados, asegurándose así que los intereses de la organización queden incluidos en el producto; también es quien sabe cómo alcanzar las metas organizacionales y es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo, y es el encargado de no perder el foco en el valor de negocio. Bien sabemos que, a más involucramiento del cliente en el proyecto, este saldrá mejor y se obtendrá una mayor satisfacción al final, tanto el usuario como el equipo que lo atiende.

Con esta premisa en mente, en esas iteraciones o sprints de corta duración que mencionaba en el apartado anterior, siempre estaremos entregando el producto que todos quieren ver. Un beneficio directo de esto es la posibilidad que tiene la organización de responder a la competencia aun durante el propio proceso de desarrollo y no después de este, como ocurre en los proyectos ejecutados con métodos más tradicionales. Además, este enfoque hace que el producto vaya madurando en la medida de su exposición a los usuarios. A medida que el producto se expone y más cambios resulten de allí, más maduro llega a ser el producto. Y cuando esto ocurre, la probabilidad de obtener ROI a corto o mediano plazo es mucho mayor.

El proceso está mejorándose continuamente

Empiece con Scrum “al natural” o Scrum orgánico, o sea, el que está definido en la guía de Ken Schwaber y Jeff Sutherland: consiga un dueño de producto (un cliente), nombre un Scrum Master y establezca un equipo de desarrollo pequeño. Y ya está listo para iniciar. Haga la reunión de planeación, asegúrese vía el Scrum Master de que el equipo completo esté realizando la reunión diaria y que al final de cada sprint de 4 semanas o menos se haga una reunión de revisión y una de retrospectiva para conocer no solo el estado del proyecto sino del equipo en general y para crear un plan de mejoramiento que sea ejecutado a partir del siguiente sprint y en los demás proyectos con Scrum.

Asegúrese de que todo lo mencionado se haga como dice la guía, por ejemplo, que las reuniones diarias tarden 15 minutos flash. De lo contrario, mejore primero esos aspectos que no se están haciendo bien. El Scrum Master debería ser capaz de lograrlo. A partir de allí, vaya introduciendo nuevas prácticas, no sin antes entrenar al equipo: refactoring, desarrollo dirigido por pruebas o TDD por sus siglas en inglés, kanban, lean, historias de usuario, programación en pares, casos de uso 2.0, entre otras. Adiciónelas una a una al proyecto, haga acompañar a su equipo de expertos en cada técnica, monitoree su ejecución, mida los resultados y haga los ajustes necesarios. Repita para cada práctica.

Conclusión

La entrega constante de software probado y funcionando cada pocos días o semanas, que sea de valor para los usuarios, y el mejoramiento continuo del proceso, contribuyen trascendentalmente al éxito en los proyectos. Scrum es un marco de trabajo que hace posible todo lo anterior. Y esta lista de verificación, la cual iremos atomizando poco a poco en este Gazafatonario, es un instrumento productivo que se puede usar como suplemento de primer orden a la guía de Scrum.

Lecturas adicionales:

La lista de verificación completa de Scrum la encuentran en mi artículo:

Sobre Iteraciones pueden leer mi artículo "Gerencia de Proyectos Iterativos" en la revista de la Asociación Española de Profesionales en Dirección de Proyectos.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

Sobre casos de uso 2.0 y métodos ágiles pueden leer mi serie de artículos en este Gazafatonario:

Casos de Uso 2.0 y Métodos Ágiles:

Casos de Uso 2.0:

¡Quiero una Porción de Caso de Uso!

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones:

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:

¿Por qué existe Casos de Uso 2.0?

Todavía Otra Lección Más Sobre Porciones de Casos de Uso:
http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html

domingo, mayo 12, 2013

Lista de Chequeo Scrum


Clic sobre la imagen para ampliar. Clic para [Descargar] la Lista de Chequeo Scrum
De las muchas listas de verificación que encontré, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.
Esta es la traducción al español.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum, o para evaluar tu actual implementación de Scrum.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum, pero se aseguraron de que el propósito de la práctica Scrum se cumplió de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la Retrospectiva como una herramienta de discusión, no como una herramienta de evaluación.

¿Cómo la uso?

        Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”.

        Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad”.

        Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado, pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.

        Lisa: “Mira, también nos hace falta ‘Entregar producto funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque Mercadeo siempre se está quejando de eso!”

        Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido.”

        Lisa: “Buena idea, intentémoslo.”

¿Cómo NO la uso?

        Gran Jefe: “Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”

        Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”

        Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del sprint! ¡Las quiero ver!”

        Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario”.

        Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”

¿Es esta una lista de chequeo oficial?

No. La lista de chequeo refleja mi opinión personal y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Descargar la lista de chequeo Scrum
Puedes descargar la lista en formato PDF aquí.

Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puedes leer este artículo:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

miércoles, abril 17, 2013

¿Es usted la persona correcta para responder mis preguntas? O el síndrome del sujeto equivocado



En los proyectos de software estamos llenos de personas que no son “las adecuadas para responder nuestras preguntas”, para establecer las verdaderas necesidades del negocio, para darnos a conocer el problema que tienen, el problema detrás del problema, la causa raíz, el impacto de ese problema y las áreas impactadas. Estamos llenos de personas que constantemente no toman decisiones, que tienen que consultar con alguien más, que no entienden lo que nos están contando durante un proceso típico de educción de requisitos, es decir, durante las entrevistas, al responder cuestionarios o al analizar prototipos, entre otras actividades.

Por eso es que nuestros proyectos están repletos de supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los supuestos le están haciendo mucho daño a la industria y conducen a la producción de software de baja calidad o que no satisface para nada las necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno, y si no se produce la respuesta que requiere, entonces la presume.

Esta necesidad de hacer supuestos es inherente al ser humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para llenar el vacío y la insatisfacción que sobreviene, es la única manera de sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de saber.

Debido a ello, cuando un interlocutor, un usuario u otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos dice que no está seguro, que va a confirmar tal o cual asunto, que debe reunirse la próxima semana con una o más personas para aclarar un tema, etcétera, nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos de trabajo tienen siempre una sección de Supuestos en la que registramos estas conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es eliminar esta sección de los documentos, son perjudiciales.

También es bien sabido que los usuarios típicamente no saben lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al preguntar porque somos propensos a creer que el problema de los usuarios es de índole tecnológica y no algo puramente del negocio. Incluso, antes de eso, fallamos al seleccionar y clasificar correctamente a los usuarios correctos o alguien más toma la decisión por nosotros, lo que deja el proyecto en una incertidumbre mayor que aquella con la que inició.

Los supuestos son atajos hacia la veracidad. El problema es que casi nunca acertamos al escoger el camino apropiado. Siempre que sea posible, reemplacemos esas hipótesis por hechos probados, por evidencias que soporten la toma de decisiones, seleccionando mejor nuestros usuarios, entrevistando al mayor número de personas en el menor tiempo posible, así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y de saber cuándo hemos llegado a la definición correcta del sistema. Invite a varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que una de ellas sea la adecuada aumenta.

Por eso, la siguiente ocasión que inicie un proyecto de software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien más puede tomar decisiones cuando usted no está?

¡Las posibilidades son infinitas!

miércoles, febrero 06, 2013

Todavía Otra Lección Más Sobre Porciones de Casos de Uso


Ya sabemos que Casos de Uso 2.0 es una práctica escalable y ágil que usa casos de uso y porciones de casos de uso para conducir el desarrollo incremental de sistemas de software. Sabemos que cualquier tipo de equipo de desarrollo lo puede usar, desde uno pequeño y local hasta uno grande y distribuido en varias locaciones,  en cualquier tipo de esfuerzo de desarrollo, desde la construcción de productos nuevos y simples hasta la elaboración de productos complejos o multisistemas, con cualquier enfoque metodológico, desde la tradicional cascada, hasta enfoques conducidos por bitácora de requisitos.
También sabemos que la porción de caso de uso es el elemento más importante de Casos de Uso 2.0. Una porción de casos de uso nos permite construir los sistemas de manera incremental, por partes, conduciendo todo el esfuerzo, desde el análisis del caso de uso, de una o varias porciones del mismo, pasando por el diseño de la porción, es decir, la realización del caso de uso (de la porción), para luego ir a la implementación de la porción, hasta someter el software a la verificación vía casos (scripts) de prueba; todo, en un ciclo corto de desarrollo, por ejemplo, una iteración de dos semanas o de un mes calendario.
Las porciones están compuestas de historias y de sus casos de prueba asociados, es decir, hay una sindicación entre las historias de un caso de uso y los casos de prueba que son las que finalmente verificarán que la porción del caso de uso está bien construida y satisface las necesidades del usuario. Esta compilación de historias y de casos de prueba tiene un valor claro que es entendido y acordado por los usuarios y los demás interesados en el producto. Por ejemplo, la siguiente figura muestra un caso de uso típico de un sistema de publicación de un periódico digital, con sus atributos más relevantes, y algunas de sus porciones, que podrían implementarse en una iteración.

Propiedades de un Caso de Uso y de algunas de sus Porciones en notas Post-it.
(Haga clic en la imagen para ampliarla)

Esta imagen, que muestra un tablero “repleto” de notas post-it, donde cada nota muestra el caso de uso con sus propiedades o la información destacada de cada una de sus porciones. En estas últimas, vemos un identificador de la porción (número y descripción), los flujos del caso de uso que forman la porción, es decir, las historias, donde FB es Flujo Básico, y A1, A2, etc., son las secuencias alternativas del caso de uso. Y también encontramos los casos de prueba, estos son los escenarios que finalmente comprobarán que la implementación de la porción fue exitosa.

No es necesario que estén todos los casos de prueba para verificar la porción, en términos generales, una historia y un caso de prueba serán suficientes para tener algo de valor para el usuario y empezar a entregar el sistema mediante incrementos. Finalmente, los números grandes en la esquina inferior derecha de cada nota post-it representan el esfuerzo que toma implementar esa porción. Es un estimado que puede realizarse con cualquiera de las técnicas habituales de estimación: puntos de historia, juicio de expertos, la estimación de Fibonacci, etc. Lo bueno de las estimaciones es que no tienen que ser exactas la primera vez, por eso se llaman estimaciones. ¡Si solo entendiéramos eso!

Un Ejemplo de Porciones de Casos de Uso

Con todo esto en mente, veamos un ejemplo característico de una de las actividades principales que incluye Casos de Uso 2.0: Preparar una porción de caso de uso. Si usamos el enfoque iterativo y una bitácora de requisitos, podemos dividir las tareas en dos grandes grupos:
  1.    Tareas antes del desarrollo
  2.    Tareas en cada iteración

En el primer grupo, Casos de Uso 2.0 propone las actividades típicas de Encontrar Actores y Casos de Uso, para conocer el “cuadro” completo, es decir, tener una visión de lo que será el sistema de software; pero a continuación, Casos de Uso 2.0 incluye la práctica de Dividir los Casos de Uso y la de Preparar una Porción de Caso de Uso. Entre tanto, las tareas del segundo grupo se muestran en la figura a continuación:

Actividades de Caso de Uso 2.0 para Enfoques de Desarrollo Iterativos
Fuente: Libro-e Use Case 2. 0 Jacobson y otros.
(Haga clic en la imagen para ampliarla)

En el caso de los actores y casos de uso, la figura siguiente muestra un subconjunto del modelo de un sistema de publicación de un periódico digital. Nómina y Facturación son dos ejemplos de actores que no son personas, son sistemas de software, externos al sistema que se está construyendo. Por su lado, Editor, Periodista, Bloguero y Lector, representan actores persona, grupos de usuario del software. Cada uno de estos tiene asociados uno o más casos de uso.

Diagrama (parcial) de Casos de Uso de un Sistema de Publicación de un Periódico Digital
(Haga clic en la imagen para ampliarla)
Para ilustrar el ejemplo de las porciones, tomemos el caso de uso Comprar Artículo, ejecutado por el Lector del periódico. A continuación muestro la narrativa del caso de uso.

Narrativa del caso de uso Comprar Artículos de un sistema de información de publicación de un periódico digital
(Haga clic en la imagen para ampliarla)
Lo que sigue es encontrar algunas de las historias del caso de uso con las que podamos iniciar el desarrollo, no de todo el caso de uso, pero sí de algunas de sus partes que tengan valor claro y entendido para el usuario.


Algunas historias del caso de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
Notamos que algunos de los flujos están definidos explícitamente en la narrativa del caso de uso, mientras que otros como el A8 y el A9 no lo están. Estos cabrían dentro del grupo “etcétera” de la narrativa. Observamos también que el flujo básico es suficiente para tener una historia con sentido completo, de valor para el usuario. A esta historia le podemos “sumar” uno o más casos de prueba y estamos listos para construir una pequeña parte del software que tiene un peso bien definido para los usuarios.

Algunas porciones del caso de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
En este cuadro vemos algunas de estas porciones para el caso de uso Comprar Artículos. Esto completa el trabajo de dividir el caso de uso. A continuación, preparamos la porción, digamos la primera de ellas, hacemos una estimación del esfuerzo que nos tomará someterla al resto del ciclo de vida durante una iteración y seguimos con el proceso: diseño (realización), implementación y verificación y, finalmente, demostración del producto (parcial) a los usuarios.
Conclusión
En el pasado hemos visto como un caso de uso puede llegar a ser lo suficientemente grande y complejo como para que se pueda implementar en una iteración corta. Las porciones de casos de uso proporcionan el medio y la coherencia de artilugios de las metodologías ágiles, como las historias de usuario, con el poder del modelado de los casos de uso para que no perdamos de vista el alcance completo del producto de software que estamos construyendo, permitiendo fabricar en un ciclo corto (una iteración de muy pocas semanas a un mes) una parte del producto que tiene valor significativo para los usuarios.
De esta manera es posible, por ejemplo, usar la práctica de Casos de Uso 2.0 con un marco de trabajo ágil como Scrum o con otros enfoques como AUP u otras metodologías livianas. Pero de este asunto hablaremos en los próximos días, cuando les presente La Esencia de la Ingeniería de Software.
Nota:
Esta entrada se puede descargar como artículo para su libre distribución, haciendo clic en:


miércoles, enero 23, 2013

¿Por qué existe Casos de Uso 2.0?


Necesitamos prácticas que nos apasionen y que se enfoquen en las personas sobre los procesos pero que además nos posibiliten resultados de calidad. Necesitamos además que nuestro trabajo sea aún más colaborativo y permita una integración unificada, continua. Precisamos de un enfoque que permita bajar la tensión “ellos versus nosotros” entre desarrolladores y verificadores.

Requerimos prácticas que nos licencien para manejar mejor los cambios y que nos habiliten para entregar productos de manera incremental. Y también necesitamos prácticas que soporten un mejor manejo del conocimiento de los productos que construimos y que nos apoyen cuando hacemos frente a situaciones adversas, que nos permitan mantenernos enfocados en lo que es de valor para nuestro cliente.

Casos de Uso 2.0 es precisamente eso, una práctica escalable y ágil que usa casos de uso para capturar un conjunto de requisitos y conducir el desarrollo incremental de un sistema que los ejecute. Casos de Uso 2.0 se reenfoca en lo esencial y ofrece una forma de trabajo liviana y más limpia para que los equipos de software logren los beneficios del desarrollo iterativo e incremental a un nivel corporativo.

Pero para llegar más al corazón de Casos de Uso 2.0, necesitamos mirar la radiografía de los casos de uso: ¿Qué hizo tan popular a los casos de uso? Con el tiempo, los casos de uso alcanzaron un uso multitudinario porque comunican efectivamente lo que el sistema debe hacer, porque ponen los requisitos en el contexto de las metas de un usuario específico y porque conducen el desarrollo a través del diseño, el código y, si se quiere, las pruebas.

En el fondo, el modelado de casos de uso es una idea muy simple. Esto quiere decir que con Actores, Casos de Uso, Inclusiones y algunos otros artilugios podemos llegar al núcleo de lo que el sistema debe hacer, porque nos enfoca inequívocamente en quién (o qué) usará el sistema y nos permite encontrar con rapidez asombrosa lo que el sistema debe hacer para que ese quién logre algo útil en su proceso de negocio.

Otra pregunta que debemos responder antes de dar el salto de versión es ¿por qué necesitamos casos de uso todavía? Si hay muchas otras prácticas relacionadas de requisitos populares, ¿por qué estás no han reemplazado la necesidad de casos de uso? Por ejemplo, las historias de usuario son grandiosas para sistemas pequeños y equipos pequeños, aunque bien es cierto que con pequeños incrementos podemos construir un sistema grande.

También hay otros enfoques, como la especificación de características, fabulosa para manejo de productos; los tradicionales requisitos declarativos, excelsos para capturar cualidades independientes atómicas; el modelado de dominio, extraordinario para sistemas de funcionalidad simple y ricos en información. Sí, hay muchas otras buenas técnicas pero a todas les hace falto algo para reunirlas y proporcionar una solución simple y escalable.

Ahora sí, ¿por qué necesitamos casos de uso 2.0? En principio, para corregir algunos de los malentendidos:

  • Los casos de uso son livianos, no pesados
  • Los casos de uso son historias, no funciones
  • Los casos de uso son simples, no complicados
  • Los casos de uso son para todo tipo de desarrollo, no solo para desarrollo de aplicaciones nuevas y “planas”.
  • Para reenfocarnos en lo esencial, de vez en cuando viene bien un refrescamiento de ideas y de experiencias.
  • Para dar un mejor soporte a las innovaciones y mejoras tales como Desarrollo Dirigido por Pruebas (TDD), Kanban y Scrum.

Lo que hace distintivo a Casos de Uso 2.0 es que nos ayudan a entender el cuadro completo, es una práctica tan liviana como queremos que sea, habilita la entrega incremental del producto, no es solo sobre requisitos, es para todo el ciclo de vida, también es para requisitos no funcionales, para software embebido, incluso no es solo para desarrollo de software, también es para desarrollo de negocios y, finalmente, es escalable en todas las direcciones para cubrir cualquier necesidad real.

Como siempre, cuando se trata de procesos y métodos, aconsejo no desvirtuar la capacidad que tenemos los seres humanos de pensar. Lo que posibilitan las técnicas es precisamente potenciar nuestra habilidad para encontrar el mejor siguiente paso en el camino hacia la satisfacción. Al final de cuentas es el cerebro humano el que visiona productos e ideas, ninguna tecnología ni método puede reemplazar nuestro proceso de pensamiento.


Referencias

El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.

Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario IT:

Casos de Uso 2.0

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html 

Casos de Uso 2.0 y Métodos Ágiles

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html 

Casos de Uso 2.0: Cosas con las cuales trabajar

http://www.gazafatonarioit.com/2012/11/casos-de-uso-20-cosas-con-las-cuales.html 

Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales.html