omar nieblas – El Blog de Paco. Tu experto en natación infantil y mucho más

Author Archives: Omar Nieblas

Una historia de usuario (Scrum) describe funcionalidad que se desea desde la perspectiva del cliente o usuario. Una buena historia de usuario describe:

  • La funcionalidad que se requiere
  • Quién la necesita, y
  • Cómo y porqué se va a utilizar.

Los componentes básicos que no se deben omitir en una historia de usuario las podemos resumir en tres elementos principales:

  1. Tarjeta: es la descripción escrita de la historia, que sirve como identificación, recordatorio y también ayuda a planificar.
  2. Conversación: es el núcleo de la historia; es platica que que se tiene con los usuarios, las notas, las grabaciones, los prototipos y los documentos.
  3. Confirmación: el criterio que se utilizara en las pruebas de aceptación que el usuario va a realizar para confirmar que la historia fue terminada.

Estos elementos se conocen como Las 3 C de una Historia de Usuario, por sus iniciales en inglés (Card, Conversation, Confirmation).

El modelo INVEST y la historia de usuario (Scrum)

Una buena historia de usuario también sigue el modelo de INVEST: Independiente, Negociable, Estimable, Pequeña (Small), y Testeable. Veamos lo que significa.

Independiente 

una historia debería ser independiente de otras (lo más posible). Las dependencias entre las historias hace que sea más difícil planificar, priorizar y estimar. A menudo, se puede reducir las dependencias haciendo una combinación de historias, o partiendo historias de forma diferente.

Negociable 

Una historia de usuario es negociable. La “tarjeta” de la historia es tan sólo una descripción corta que no incluye detalles. Los detalles se trabajan durante la etapa de “Conversación”. Una tarjeta con demasiados detalles limita la conversación con el cliente.

Valiosa 

Cada historia tiene que tener valor para el cliente (para el usuario o para el comprador). Una forma muy buena de generar historias valiosas es hacer que el cliente las escriba. Una vez que el cliente se de cuenta que la historia no es un contrato y es negociable, van a sentirse mucho más cómodos para escribir historias.

Estimable 

Los desarrolladores necesitan poder estimar una historia de usuario para permitir que se pueda priorizar y planificar la historia.

Los problemas que pueden impedirle a los desarrolladores estimar una historia son: falta de conocimiento del dominio (en cuyo caso se necesita más Negociación / Conversación); o si la historia es muy grande (en cuyo caso se necesita descomponer la historia en historias más pequeñas).

Pequeña 

Una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.

Testeable 

Una historia necesita poder probarse para que ocurra la etapa de “Confirmación”. Recordemos que desarrollamos aquello que no podemos probar. Si no se puede probar, nunca vamos a saber si lo terminamos. Un ejemplo de historia no testeable sería: “el software tiene que ser facil de usar”.

Conclusión

Las historias de usuario bien escritas son esenciales para el Desarrollo Ágil. Deben ser

  1. deben ser independientes entre si;
  2. se debe poder negociar los detalles entre los usuarios y los desarrolladores;
  3. las historias deben tener valor para el cliente;
  4. deben ser lo suficientemente claras para que los desarrolladores puedan estimarlas;
  5. deben ser pequeñas; y
  6. deben poder probarse usando los casos de prueba pre-definidos.
Contacto:
Omar Nieblas; PM, Scrum Master
Twitter: omarnieblasblog
Facebook: omarnieblasblog
www.omarnieblas.com
contacto@omarnieblas.com

Las siete Herramientas de la Calidad son propuestas en 1968 por Kaoru Ishikawa. Las cuales constituyen un conjunto de técnicas estadísticas sencillas que no requieren de un conocimiento experto para aplicarse en los procesos de equipo.

Según Ishikawa, con  ellas es posible resolver el 95% de los problemas que se presentan en una empresa; sobre todo en el área de producción.

Las 7 Herramientas de la Calidad:

1) Diagrama Ishikawa (diagrama causa-efecto y diagrama espina de pez) :

Consiste en una representación gráfica sencilla en la que puede verse de manera relacional una especie de espina central, que es una línea en el plano horizontal, representando el problema a analizar, que se escribe a su derecha.

2) Diagrama de Flujo:

Utilizados para ver fácilmente las entradas y salidas de un proceso, útil para determinar que partes del proceso aportan valor y cuáles no.

3) Gráfica de Control:

Una gráfica de control es un diagrama que sirve para examinar si un proceso se encuentra en una condición estable, o fuera de control.

En las control chart, aparecen varios elementos que debemos conocer:

  • Límites de control superior e inferior: Los límites de control marcan el intervalo de confianza en el cual se espera que caigan los puntos. El espacio entre ambos límites define la variación aleatoria del proceso. Los puntos que exceden estos límites indicarían la posible presencia de causas específicas de variación (“out-of-control point” o “special cause”).
  • Límites de especificación: Definidos por el cliente y que no deben ser superados

4) Histograma

El histograma es un tipo de gráfico de barras que se puede utilizar para comunicar información sobre las variaciones de un proceso y/o tomar decisiones enfocándose en los esfuerzos de mejora que se han realizado.

El histograma permite reconocer y analizar patrones de comportamiento en la información que no son aparentes a primera vista.

Su construcción ayudará a comprender la tendencia central, dispersión y frecuencias relativas de los distintos valores analizados.

 

5) Diagrama de dispersión :

Un diagrama de dispersión o gráfica de dispersión o gráfico de dispersión es un tipo de diagrama matemático que utiliza las coordenadas cartesianas para mostrar los valores de dos variables para un conjunto de datos.

Los datos se muestran como un conjunto de puntos, cada uno con el valor de una variable que determina la posición en el eje horizontal (x) y el valor de la otra variable determinado por la posición en el eje vertical (y).

 

6) Diagrama de Pareto :

El diagrama de Pareto es una herramienta de análisis que ayuda a tomar decisiones en función de prioridades, el diagrama se basa en el principio enunciado por Pareto que dice:

“El 80% de los problemas se pueden solucionar, si se elimina el 20% de las causas que los originan”

7) Hoja de Control :

Las hojas de control, también llamadas hojas de registro facilitan la recopilación de información, previamente diseñadas con base en las necesidades y características de los datos que se requieren para medir y evaluar los procesos.

En mi experiencia como administrador de proyectos de software,  estas herramientas me sirvieron para:

  • Identificar las causas de porque se tenía un alta densidad de errores,
  • Identificar lo que estaba fuera de control examinando sus posibles causas.

El resultado fue:

  • Poner en practica las posibles soluciones detectadas en equipo, que en su momento funcionaron para poner en control el proyecto.

Omar Nieblas, Project Manager
Visita mi blog : www.omarnieblas.com
Buscame en mis redes Sociales:

La gestión del valor ganado es una técnica de gestión de proyectos que permite controlar la ejecución de un proyecto a través de su presupuesto y de su calendario de ejecución, representado en formulas

Compara la cantidad de trabajo ya completada en un momento dado con la estimación realizada antes del inicio del proyecto.

En este articulo vamos a describir las principales fórmulas relacionadas con el Valor Ganado, y explicar porqué se usan, asi como algunos conceptos necesarios para identificar la relación existente.

BAC – Budget at Completion.

  • Es el presupuesto original del proyecto (o del entregable a analizar).  Se define sumando los costos de cada una de las actividades, y preparando un “calendario“ de costos.
  • El costo total de los costos acumulados es el BAC.

EV – Valor Ganado.

  • Es la expresión del avance del proyecto, a costos del presupuesto. En otras palabras, lo que realmente hemos conseguido con el presupuesto que teníamos planificado.

AC – Costo Real.

  • Es el costo acumulado a la fecha.  Este costo se determina sumando los usos de recursos a la fecha

PV – Valor Planeado.

  • Es el costo estimado a lo largo del proyecto

CPI – Formula  del Cost Performance Index.

  • Es un índice que expresa la “eficiencia” en los costos reales del proyecto, comparando el Valor Ganado (costo presupuestado para el trabajo realizado), versus el Costo Real.

CPI = EV / AC 

Consideraciones: Si el CPI = 1; El costo ha sido que se previo; Si el CPI < 1 significa que se ha gastado mas de lo previsto; Si el CPI > 1 significa que se ha gastado menos de lo previsto

SPI – Formula del Schedule Performance Index.

  •  Es un índice que compara el EV (Valor Ganado), es decir lo avanzado,  contra el PV (Valor Planeado) lo que se tenía pensado avanzar a un momento dado.

SPI = EV / PV  

Consideraciones: Si el SPI = 1; El calendario esta avanzando al rito que se previo; Si el SPI < 1 significa que el calendario se ha retrasado mas de lo previsto; Si el CPI > 1 significa que se ha adelantado trabajo del calendario

CV – Formula del Cost Variance.

  • Es una medida de la diferencia entre el Valor Ganado y el Costo Real.

CV = EV – AC

SV – Formula del Schedule Variance.

  • Es una medida que expresa la diferencia entre el Valor Ganado y el Valor Planeado.

  SV = EV – PV

Como administrador de proyectos, el Índice de desempeño de costo y el indice de desempeño del calendario son indicadores de la gestión de valor ganado, que ayudan a analizar la eficiencia de los costos y del plan de trabajo proyectados para el proyecto.

En la experiencia adquirida, puedo decir, que el CPI y SPI son la parte medular a la que la medición del proyecto esta expuesta, debido que en ellos se ven los costos incurridos (a favor o en contra) y las probables desviaciones que tiene el calendario del proyecto. la medición de estos dos indices se refleja en porcentaje.

 

Omar Nieblas, Project Manager
Visita mi blog : www.omarnieblas.com
Buscame en mis redes Sociales:

 

PairLa programación en pareja o Pair Programming es un forma de trabajo propia de las metodologías ágiles en la que dos personas trabajan juntas para resolver los mismos problemas.

Para tener una mejor colaboración, se pueden asignar dos roles dentro de este método de trabajo. A uno se le denomina controlador (driver) y al otro como navegador (navigator).

El primero se encarga de la codificación, mientras que el otro se apega más en la investigación, dirección y/o revisión del código.

Uno de los principales problemas que actualmente enfrentan los programadores es entender un código que ha sido realizado por otra persona, ya que su forma de trabajar pueden no estar relacionadas.

La programación en pareja mejora la calidad del software, ya que, el código desarrollado será menos ambiguo para que ambos integrantes puedan entenderlo.

Ventajas de Pair Programming

  • Aprendizaje: Los programadores transmiten sus conocimientos entre si para intentar encontrar la solución más adecuada, por lo que puede que se obtengan propuestas que con la programación individual podrían no haber surgido.
  • Mejora el trabajo colaborativo: Al trabajar en equipo, irremediablemente surge la comunicación entre programadores, lo que puede hace suponer que el ambiente de trabajo sea mejor.
  • Optimización del tiempo de trabajo: Al distinguir los dos roles antes mencionados, se pueden dividir el trabajo de forma que, mientras que el driver implementa una parte de la solución, el navegador puede realizar tareas de investigación para mejorar la solución que se está desarrollando en ese momento.
  • Mayor disciplina:  Los programadores es más probable que hagan “lo que se debe hacer” en lugar de tomar largos descansos.
  • Mejor código. Reunir a programadores en parejas reduce la probabilidad de  producir malos diseños ya que con sus conocimientos tienden a diseñar con mayor calidad.
  • Flujo de trabajo constante: Las parejas son más resistentes a las interrupciones ya que un desarrollador se ocupa de la interrupción mientras el otro continúa trabajando

En algunas metodologías ágiles como Scrum, en el que el trabajo se divide en periodos de tiempo conocidos comoPair Programming sprints, las parejas trabajan juntas durante estos sprints y  pueden cambiarse al finalizar estos, por lo que las ventajas antes descritas podrían ser aún más satisfactorias.

No debemos pensar que el pair programming es sólo una práctica de estar con un compañero, sino que su consecuencia final es mucho más relevante.

El objetivo final de la Programación en Pares es promover y generar una cultura grupal, en donde la colaboración y la comunicación sean valores fundamentales para todas las personas del equipo.

A %d blogueros les gusta esto: