Sunday, October 1, 2017

Sobre Historias de Usuario

¿Qué es una historia de usuario?

Es un artefacto XP que se utiliza para la captura de requerimientos, las historias de usuario usualmente son escritas por un funcional pero pueden ser utilizadas por cualquier miembro del equipo para describir una tarea macro que consume un factor del tiempo productivo del equipo.

¿Qué son los puntos de historia de usuario?

Los puntos de historia de usuario son una medida de magnitud, también se las utiliza para medir el tamaño de una historia de usuario respecto a otra historia de usuario previamente identificada.

¿Entonces cómo relaciono la complejidad de una historia de usuario respecto a otra historia de usuario?

Si no existe una historia anterior que me permita definir la velocidad del equipo en cumplir un conjunto de tareas para satisfacer una historia de usuario entonces se considera el denominado cono de incertidumbre, esto es, que los primeros intentos para estimar una historia de usuario utilizando los puntos de historia de usuario se darán bajo una perspectiva de experimentación. Si por el contrario, existe ya una historia previamente definida se la tomará a esta como una guía, modelo, o punto de referencia para futuras estimaciones.
Recuérdese que los puntos de historia de usuario se utilizan para estimar la complejidad del conjunto de tareas que se requieren para satisfacer una historia de usuario y NO SE PREOCUPAN SOBRE CUÁNTO TIEMPO debo emplear en realizar dichas tareas.

¿Pero… cómo puedo estimar una historia utilizando puntos de historia de usuario si no considero el factor TIEMPO disponible y productivo que poseo para comprometerme como equipo?

Buena pregunta, el tiempo productivo que utilice el equipo para satisfacer una historia de usuario es uno de los grandes dilemas existentes en la ingeniería de software, desde la medición por horas-hombre, líneas de código escritas, hasta los puntos de historia de usuario existe un factor que tiene que ser considerado y que relaciona al factor tiempo con la productividad del equipo, este factor a ser considerado es la VELOCIDAD de producción del equipo; como se sabe, la velocidad es una magnitud de esfuerzo para recorrer una distancia en un determinado tiempo, en este contexto, es preciso recalcar entonces qué tipo de tiempo estamos tomando en cuenta para cubrir esa distancia (el realizar un conjunto de tareas para satisfacer una historia de usuario). Existen dos tipos de tiempo utilizados para esta fórmula, el primero es el tiempo ideal (el que estimamos) y el otro es el tiempo real (el que producimos), a partir de este momento es importante poner atención a los siguientes conceptos para lograr determinar la efectividad de utilizar los puntos de historias de usuario para estimar el esfuerzo productivo del equipo de desarrollo.

¿Entonces cómo mismo es el proceso de estimación mediante los puntos de historia de usuario?

Para poder estimar la magnitud de tiempo (ideal) que me tomará realizar una historia de usuario se requiere primero obtener el factor de VELOCIDAD productiva del equipo, para obtener dicho valor la formula expresa que debo dividir la cantidad total de puntos de todas las historias de usuario que en el SPRINT anterior el equipo completó sobre el tiempo (real) productivo que le tomó al equipo el completar dichas historias. Una vez que se obtiene el valor de VELOCIDAD, entonces es posible estimar mediante triangulación el tiempo (ideal) que tomará al equipo el comprometerse en el SPRINT PLANNING mediante la comparación relativa de complejidad entre historias de usuario anteriores y las nuevas, esto es el utilizar los denominados puntos de historia de usuario.

¿Finalmente, este escrito me ayudó a comprender lo que son los denominados puntos de historia de usuario y su uso adecuado?

Hemos definido qué son puntos de usuario y cómo deben utilizarse durante el juego de planificación de un SPRINT, sin embargo, este concepto será compartido por todos los miembros del equipo?, por los stakeholders?, esto es otra pregunta que debe ser resuelta.

Saturday, June 17, 2017

DSN_XP.FAQs

Respuestas y preguntas sobre Arquitectura DSN_XP

Cualquier inquietud que tengas sobre DSN_XP y sus:
  • Fundamentos como arquitectura software y teoremas
  • Fuentes de información y academia
  • Artefactos, técnicas, lineamientos, recomendaciones
  • Canales de comunicación y redes sociales
  • Conferencias, charlas, OPEN SPACES
  • Documentación y modelos
Este canal es considerado oficial por Arquitectura DSN_XP para nuestros seguidores :o)

¿Cuál es mi rol?

DSN_XP.SCRUM.ROLES


Esta entrada tiene como objetivo definir el rol del dueño del producto bajo los lineamientos de DSN_XP. Por defecto, tomaremos prestada la definición de MSF sobre este rol para luego analizar la propuesta de Scrum.

DSN_XP.MSF.ROLES



Tuesday, February 26, 2013

MSF 3.0 en el agilismo

DSN_XP.BKNOW.MÉTODOS.MSF.3.0

MSF 3.0 y DSN_XP
Dentro de la base de conocimientos sobre metodologías estudiadas por DSN_XP, tenemos a Microsoft Solutions Framework en su versión 3.0 

Las preguntas referentes a este modelo son:

¿Existe el concepto de backlog en MSF?

Para DSN_XP, no existe el concepto de backlog en este marco de trabajo propuesto por MSF en su versión 3.0 

De hecho no hemos visto en otros marcos de trabajo y métodos propuestos que hemos investigado el concepto de backlog (salvo claro está que en Scrum si)

El artefacto sin embargo puede ser incorporado con éxito dentro del marco de trabajo propuesto por MSF 3.0, Microsoft mismo manifiesta en los papers liberados lo siguiente:

"MSF is also broader in the project issues it addresses. Agile methodologies develop practices
that are most useful and primarily applied during the design and development phases of a
project life cycle. MSF readily incorporates these practices into software development
projects, but adds the upfront activities of deliberately capturing, documenting, and defining
business value through a more diligent envisioning process. Similarly, MSF adds the back-end
phase of implementation that includes transitioning the software from development to
operations."
Microsoft Solutions Framework
version 3.0 Overview

Repuesta:

No sólo es cuestión de incorporar un artefacto a tu marco de trabajo, también requieres comprender el concepto del modelo del ciclo de vida de desarrollo de tu producto (sea software o no) y el impacto que tendrá el incorporar un artefacto a tu marco para la gestión de proyectos/productos.


¿Cómo se planifican las iteraciones en MSF?


Modelo MSF 3.1

Para DSN_XP, la planificación de las iteraciones bajo las recomendaciones de MSF 3.1 se logra mediante 3 elementos de planificación que son:

  1. Esfuerzo estimado para el cumplimiento de tareas y el aseguramiento de los insumos necesarios para ello.
  2. La dependencia que tendrá cada elemento del diseño dentro del diseño general o la reducción del alcance de su aplicación.
  3. Los recursos asignados (y si se incluyen a las personas dentro de esta categoría porque tienes que asegurar para la comunidad los recursos que estas necesitan)
En conjunto, estos tres componentes definen la planificación de una iteración, entendiéndose que una iteración (repetición) permite la secuencia de micro proyectos (cascada aplicada y controlada) hacia un objetivo más macro que es definido previamente o se desea mejorar, nos referimos al concepto de versionado (uso de iteraciónes)


Nota: no necesariamente significa que la liberación de las versiones sean secuenciales entre sí :o) by MSF3.1

Repuesta:

Las iteraciones para un producto se definen mediante la planificación del producto, mientras que si es sobre un proyecto, las iteraciones se definen mediante la secuencia de fases propuestas por MSF como modelo.

Un análisis de dependencia es requerido para la planificación del producto porque le da sentido mismo al concepto de iteración, a diferencia de un SPRINT para Scrum, la iteración del proceso o flujo debe ser controlada por el manejo de operaciones, al menos para Microsoft es así como debe utilizarse MSF.




Sunday, June 26, 2011

¿Cómo puedo aplicar el método científico en la concepción de DSN_XP?

DSN_XP utiliza la lógica dialéctica para su proceso de abstracción mediante el pensamiento dialéctico o dual y reconoce también la ley de la negación de la negación. Esta forma de pensar se utiliza para defender académicamente los argumentos expuestos por DSN_XP.

2.5.1. De la Ingeniería de Software (IS)


La IS se encarga de estudiar, aplicar, comprender e investigar todos los factores necesarios para el desarrollo del software.


Este término acuñado en las famosas reuniones de la OTAN (1968) pretende entre varias cosas, sistematizar el desarrollo de un proyecto de software en base a una serie de etapas claramente definidas en su concepción.


El modelo que constituye estas etapas se conoce como “modelo del ciclo de vida del desarrollo del software” (CVDS) y representa la estrategia aplicada al control de proyectos de desarrollo de software en base al tiempo (ciclo).


Los estudios realizados por Kybele, tratan de resolver la problemática de la ciencia y su método de investigación, frente a la tecnología del diseño de software y su método de desarrollo; métodos que se asemejan cada vez más.


Mario Bunge, manifiesta que las teorías científicas permiten ampliar y profundizar el conocimiento del mundo, mientras que las teorías tecnológicas emplean ese conocimiento con fines prácticos, es decir, son teorías instrumentales que generan herramientas (son un instrumento para lograr fines utilitarios).


De ahí que no resulte muy apropiado describir a las tecnologías como simples aplicaciones del conocimiento científico al proceso productivo. [*Kybele] [Esp 89]


Una teoría verdadera puede utilizarse con éxito en la investigación aplicada o en la investigación tecnológica, sin perder de vista que también puede funcionar bien una teoría falsa, porque lo importante para la tecnología es que el resultado sea útil, más allá de si lo que dice es verdadero o falso[1].


Al emplear una “metodología de desarrollo” en la concepción de un proyecto de software, se siguen en esencia los mismos pasos aplicables a la investigación científica, lo que genera un traslape y una duplicación de información y esfuerzos, en la documentación entregada como tesis de grado por parte del estudiante.


Desde la perspectiva del estudiante, es decir, del equipo de desarrollo de software, el conocimiento científico básico y aplicado, tal como lo generan los grupos de investigación científica, es un producto muy diferente al de la tecnología de producción que él utiliza.[2]


En el diseño de un producto, influyen decenas de miles de datos, de los cuales generalmente no más de un 5 a un 10% provienen de la ciencia, el resto se origina en gran medida en la propia actividad productiva y se encuentra incorporada, por ejemplo, en las normas de diseño de operación y mantenimiento, o en mejoras a éstas, derivadas de la experiencia de numerosas personas. [Esp 89, p. 8]


La tecnología es indispensable para que una sociedad pueda alcanzar su desarrollo armónico e integral y consecuentemente el de todos sus miembros.


Generalmente se piensa en las tecnologías de producción, como las únicas o las más importantes; sin embargo, otras tecnologías de negocio adicionales son esenciales para el éxito de un proyecto de software.


Tal es el caso de las tecnologías para:


1) Estudios de mercado y de factibilidad.


2) Diseño de equipos, estructuras y sistemas de apoyo.


3) Construcción y montaje de procesos.


4) Comercialización de productos.


5) Manejo administrativo, financiero y de personal.








[1] “Por ejemplo, se puede curar a un neurótico por medio del chamanismo, etc. (falso), siempre y cuando se use también la sugestión, el condicionamiento, los tranquilizantes, etc. (verdadero). De esto se desprende que la práctica exitosa no garantiza que la teoría de la cual proviene sea verdadera. Una práctica que da resultados no necesariamente convalida o asegura la verdad de la teoría correspondiente. Entre otras cosas, porque en la práctica se manejan muchas variables que no se controlan con precisión, pero que se hace uso de ellas para hacer exitosa la operación. En cambio la teoría considera solo algunas variables, y busca controlarlas artificialmente.” [*Bun 71]






[2] “La escuela de pensamiento de EEUU que es muy floja en filosofía y pragmática en exceso, utiliza las temimos en forma demasiado libre. En la bibliografía se habla de Metodología, cuando se hace referencia a un Método. De Método, cuando se hace referencia a un Proceso. De filosofía, cuando se hace referencia a una Metodología. De Arquitectura cuando se hace referencia a la Infraestructura, etc. Esto no solo ocurre porque quienes redactan los libros carecen en mucho de estos conceptos, sino también porque el Marketing gobierna y se eligen los términos que resuenan mejor para vender el producto. De allí en más, todo esta dado vuelta” [*Pérez]

¿En qué proyectos se ha utilizado DSN_XP?

Para responder a esta pregunta hemos creado una página dentro de este blog denominada DSN_XP.Proyectos en donde ponemos de manifiesto el historial de proyectos en los cuales se describe la participación de DSN_XP.

¿Qué significa experimentar en el diseño de software?

DSN_XP utiliza en el proceso de abstracción la noción de modelo, esto implica el reconocer que detrás del diseño existen tanto el modelador como lo modelado y el modelo se mejora en base a la experimentación continua.