Entradas publicadadas a lo largo del Noviembre, 2009

Calidad

Según la definición de la Wikipedia: “La calidad se suele definir como el cumplimiento de los requisitos, ya sea que estos sean explícitos o implícitos, para la satisfacción de un cliente. Diferentes clientes pueden tener diferentes conjuntos y niveles de requisitos respecto de una misma categoría de productos o servicios. Es por ello que la definición de requisitos, debe realizarse para un cliente o conjunto de clientes en particular.

La calidad, según esta definición, tiene dos caras: Los valores explícitos y los valores implícitos.

Los equipos que estén realizando Scrum no deben descuidar ninguno de estos dos aspectos.

Los valores explícitos: El producto o servicio resultado de un proceso de creación, ya sea empleando Scrum u otra metodologías, debe cumplir un mínimo de calidad, la cual está influenciada por el precio del producto o el servicio. Los clientes son conscientes de que a un menor precio se renuncia a una parte de la calidad, pero que esta siempre debe tener un mínimo que satisfaga a los mismos.
Los equipos deben controlar su calidad durante todo el sprint, no se debe deteriorar por ningún motivo, para ello se pueden incluir técnicas de control o gestión que hagan que esta no disminuya en favor de aumentar la velocidad y cumplir objetivos. Intentar aumentar la producción reduciendo la calidad suele ser un error muy frecuente.
Una solución por ejemplo en el desarrollo de software es el Pair Programming. El objetivo es introducir mejoras en los procesos dentro del sprint que garanticen la calidad de los productos sin sacrificar otros aspectos como la productividad y el beneficio.
Los valores explícitos son los que marca el mercado para cada producto.

Los valores implícitos: Este aspecto es mucho mas díficil de controlar y de apreciar directamente, depende de manera directa de cada cliente, de su forma de ser y de su umbral personal de calidad. Algunos clientes, por mucha calidad que tenga un producto nunca llegarán a apreciarla, como por ejemplo, si le ofreces a una persona que pruebe un alimento nuevo, apreciará su sabor, pero le será muy difícil poder apreciar la calidad, dado que es una experiencia nueva.
Es por tanto que la calidad como valor implícito depende de la percepción del cliente. El valor implícito es el nivel de calidad que el cliente esta dispuesto a admitir como mínimo, que es distinto en cada caso. La mejor manera de obtener este valor es evaluar el nivel del cliente en las reuniones tenidas con él antes de comenzar los trabajos. A veces el cliente quiere exigir unos niveles de calidad pero no esta dispuesto a pagarlos, ante lo cual es mejor explicarle el coste que supone llegar a este nivel, explicarle que rebajando algo el mismo se obtiene un producto de calidad menor, que no quiere decir peor, pero que es mas que suficiente para que se cumplan los objetivos del cliente y de los costes.
Para conocer los valores de calidad del cliente es muy importante mantener un contacto directo con él, no saltándose las presentaciones de productos y sobre todo, dejando que este participe, opine y que pueda realizar comentarios o críticas al trabajo entregado. Es en este momento, cuando se le van presentando los resultados del sprint, donde verdaderamente vamos a conocer el nivel de calidad que quiere para su producto o servicio.
Los valores explícitos son los que marca cada persona para cada producto.

Es un error muy frecuente pensar que aumentando la carga de trabajo y los controles se va a conseguir mejorar los objetivos. Se puede aumentar la calidad, pero la mayoría de las veces este aumento de calidad no es el objetivo, dado que el resultado del trabajo va para un sector o cliente que conoce el precio y asume unos niveles de calidad medios, el cleinte no esta dispuesto a pagar mas aunque aumente la calidad.
Pongamos por ejemplo un bolígrafo: Muchos clientes saben el coste de este artículo y lo que ofrece por la cantidad que pagan, no por mejorar la calidad a costa de aumentar el precio el cliente se va a quedar mas satisfecho, dado que al pagar mas por un producto se le exigirá mas y es posible que aunque aumentemos la calidad, al subir el coste el cliente quede menos satisfecho que pagando menos.

En resumen, hay que trabajar pensando en una calidad que cumpla los objetivos previstos por el cliente, que unas veces será menor y otras mayor. No se debe obsesionar a los equipos productivos con buscar una excelencia en la calidad, dado que esta búsqueda llevará normalmente una subida de costes al bajar la velocidad. Muchos clientes, y sobre todo el mercado actual ante la crisis, prefieren abaratar costes siempre que se cumplan unos mínimos de calidad.

scrumninja_logo

Una herramienta para la gestión de Scrum creada por la empresa Internaut Design.

Se puede probar de forma gratuita, y para los proyectos de sofware libre es totalmente gratuita, pero tiene el incoveniente de que para gestionar equipos te hace falta tener una licencia de pago.

Es muy limitada en cuanto funcionalidades, pero es ahí donde sus creadores quieren hacer hincapié, en que haces pocas cosas pero muy bien hecha, y la verdad es que con la herramienta se puede gestionar todo lo necesario para Scrum.

Dispone de un tablón de tickets muy original, algo que hasta ahora no habíamos encontrado en ninguna herramienta, representa fielmente el tablón y es muy sencillo de usar.

Dispone también de dos patrones, puntos y horas.

Recomendamos esta herramienta para los iniciados y equipos que tengas pocos proyectos, la verdad es que es muy fácil de usar y muy intuitiva. Pero al contrario que otras, es de pago, y se queda pequeña para equipos que necesiten una mayor gestión.

Scrum clock
Ya hemos comentados en otros post el mismo planteamiento, el tiempo no es un patrón óptimo de medida. Pero esta semana hemos vuelto a leer en varios artículos de gestión de recursos humanos, como empleaban el tiempo como unidad de medida, no solo para las horas trabajadas si no también para los premios o compensaciones por el trabajo bien hecho.

Existe una clara obsesión por parte de los jefes de mantener a los empleados ocupados todo el tiempo al cien por cien de productividad. Los empleados son presionados por unos planes y objetivos impuestos por los mandos. Unos objetivos que vienen de arriba a abajo, tomando normalmente como valor indicativo el número de horas diarias de cada empleado.

Los objetivos no solo tienen como inconveniente que son planteados tomando el patrón tiempo, si no que además los jefes suelen quieren acelerarlo sin ninguna justificación, en cualquier momento que ven a un empleado haciendo lo que pueden considerar una labor no incluida en los objetivos, cargan sobre el mismo su jerarquía para que dediquen solo su tiempo a producir.

Los jefes no suelen reflexionar sobre la posibilidad de que dejando tiempo y espacio para la comunicación y el diálogo se aumente la productividad, aunque esta se produzca en menos horas de trabajo específico. Se suele tender a que los objetivos se alcancen debido al número de horas y no a la calidad de las mismas. Con esto se pone de manifiesto que desaprovechan la posibilidad de que el resultado sea mas óptimo para el cliente, dado que en los periodos de comunicación y reflexión las personan suelen intercambiar impresiones, solucionar problemas, además de mejorar el producto que están realizando.
Al final el objetivo mas importante es poder crear el mejor producto, el que cumpla los objetivos que el cliente demanda, generar un valor al mismo. El patrón horas trabajadas no es ninguna garantía para crear el mejor producto, ni muchos menos el tener a todos los empleados ocupados todo el tiempo. La opción mas óptima para producir un producto que aporte valor a los clientes es que las horas de producción sean las necesarias para conseguir el objetivo. Para que esto ocurra se debe destinar tiempo para la reflexión, la comunicación y para el intercambio de conocimiento, generando estas transferencias productos o servicios de alto valor.

El patrón tiempo debe desterrarse de los procesos creativos, en los que la mente humana es la principal creadora del producto. Existen algunos procesos mecánicos donde si es clave el número de horas para alcanzar los objetivos, pero suelen ser procesos industriales en cadena.

La imposición de las horas debe venir desde abajo a arriba, y no al revés, por que siempre los jefes tienen una visión distorsionada de las tareas, sobre todo por no estar implicados de forma directa en las tareas de producción, y aunque manejen las estadísticas de la misma, la sociedad actual y sus procesos evolucionan rápidamente, por lo que son los miembros productivos los que están mas cercanos a estos cambios.

TeamTrick logo

TeamTrick es un interesante proyecto creado por Manuel Morales.

Su objetivo es ofrecer una herramienta de software libre para las empresas u organizaciones que utilicen Scrum.

Actualmente esta en su fase inicial, muy inicial, pero puede ser el comienzo de una buena herramienta de gestión de Scrum. El proyecto necesita ser conocido en la comunidad, así podrá ir creciendo con la aportación de todos.

La herramienta está desarrollada en Ruby on Rails, algo que la puede limitar en su evolución, dado que tiene menos comunidad de desarrolladores que otros lenguajes como PHP, aunque por otro lado son de los más activos, pero a cambio ofrece las ventajas de sencillez y claridad de código propias de Ruby y los frameworks en general. Sin duda  un entorno colaborativo de muchas personas hace el trabajo mas fácil.

Desde este blog queremos dar publicidad a este proyecto, creemos que hay que animar a las personas que se implican en desarrollar herramientas para mejorar la comunidad de Scrum, y si encima son de software libre, aún con mas motivo.

Esperamos poder seguir comunicando buenas nuevas sobre este software.

Este fin de semana se han celebrado 9 iweekend al mismo tiempo. Han participado 8 ciudades españolas y una mexicana. Resaltar que el evento tiene como objetivo crear una empresa en un fin de semana.

Cada equipo de cada ciudad organizaba su propia gestión. Ante la imposibilidad de poder explicar Scrum e integrarlo en una hora, en uno de los equipos se han empleado algunas de las herramientas que aporta Scrum, y gracias a ello se ha organizado todo el trabajo.

Se crearon los siguientes roles:

Product Owner: lo representaba en emprendedor que aportó la idea sobre la que el equipo iba a trabajar.

Scrum Master: La persona encargada del tablón con las historias y de controlar que estaba haciendo cada miembro del equipo en ese instante.

Tres Equipos: Programación, Marketing y Comunicación.

El cliente: En este caso lo interpretaban los organizadores del evento, que esperaban la entrega del producto al finalizar el fin de semana que dura el evento.

Se creó un tablón con la pila de producto y de sprint.

Se pusieron fotos de todos los miembros del equipo para poder seguirlos en todo momento.

Una vez finalizado el fin de semana frenético en el que se ha presentado una beta del producto, se ha organizado una reunión de retrospectiva, pero por falta de tiempo, esta se ha emplazado para unos días después.

A partir de ahora, el próximo paso es que todos los miembros del proyecto reciban un curso de Scrum, para continuar empleandolo como proceso ágil para las próximas fases de desarrollo del proyecto.

No se pudieron implementar métricas por falta de tiempo, no se podían organizar reuniones de estimación, dado que solo eran dos días, por lo que no se ha podido obtener ni la velocidad ni el factor de foco, aunque si se ha podido obtener un porcentaje de historias terminadas sobre las previstas.

Los miembros del equipo no han tenido tiempo de poder valorar las ventajas de las metodologías ágiles, pero al menos se han aproximado a ellas de una forma directa, pudiendo comprender los valores positivos de las mismas.

En resumen, la experiencia ha sido positiva, sobre todo por el gran panel de control de historias, que en todo momento daba una indicación del estado del proyecto.