archivo

Archivo de la etiqueta: Mary Poppendieck

Se tiende a añadir más y más funcionalidades al producto, pensando que de esta forma se le estarán dando al usuario más posibilidades, sin caer en la cuenta de la relación coste/beneficio de las mismas y que llegado el momento el usuario utiliza casi siempre las mismas.

Eso en el caso de que se piense en el usuario y no en incrementar la facturación a costa de eso (que es lo que suele ocurrir: crear necesidades donde no las hay).

Las nuevas funcionalidades visten más que otras tareas a realizar en el sistema y que son mucho más importantes, como rematar bien funcionalidades que sí que resultan esenciales, mejorar el rendimiento y la usabilidad o situar la deuda técnica en unos niveles acordes a las características del sistema.

Nuevas funcionalidades sí, siempre y cuando aporten valor, pero un valor real.

Sobre este tema Mary Poppendieck opina lo siguiente: “Nuestros sistemas software contienen más funcionalidades que las que se van a utilizar jamás. Esas funcionalidades extras incrementan la complejidad del código y elevan los costes de manera no lineal. Si ni siquiera la mitad de nuestro código es innecesario, el coste del sistema con le código adicional no es el doble, es por lo menos diez veces más caro de lo que debería ser”.

Con más funcionalidades se incrementa la deuda técnica, las mismas tendrán feedback y se realizarán ajustes, habrá errores que lleguen a producción y puedan tener influencia sobre otras funcionalidades más importantes y casi lo peor de todo: nuestra atención se desvía de lo realmente importante y se centra en lo accesorio, afectando al acabado y calidad del producto final.

No rematar las tareas y arrastrar deficiencias en el producto constituyen una resistencia importante al proceso de desarrollo, afectando a la velocidad del equipo de desarrolladores y lo más importante, afectando al nivel de satisfacción de los usuarios.

Por ese motivo es fundamental que se tengan en cuenta en el proceso de desarrollo, ya sea dentro de la línea principal y/o como parte de un segundo equipo dedicado exclusivamente a resolver estos problemas, en base a las prioridades que se establezcan para las mismas.

Sobre este tema Mary Poppendieck realiza la siguiente reflexión: “La única forma de prevenir que se nos escapen defectos en el futuro es examinar los que se producen en el presente, metódicamente encontrar sus causas y, uno a uno, eliminarlos”.

El ritmo de desarrollo es muy importante, ya que condiciona la capacidad de adaptación al cambio del producto, ya sea provocado por el entorno o por las necesidades del usuario, por ese motivo, reducir la probabilidad de que se produzcan contingencias que afecten al funcionamiento continuo de la “maquinaria” resulta esencial.

Asunto muy controvertido. Por un lado se encuentra el hecho de tener a las personas el mayor porcentaje posible de su tiempo asignado a tareas facturables y por otro la certeza de que una persona que tiene su cabeza en muchos proyectos tiene su enfoque dividido y eso afecta a su rendimiento.

Estar en un 20% en un proyecto, un 5% en otro, un 50% en otro, un 10% en otro y un 15% en otro, no es ninguna exageración, incluso puedo quedarme hasta corto. Quien se haya encontrado o se encuentre en esta situación o quien dependa de personas que se encuentran en la misma sabrán lo que eso significa: el porcentaje final en cada proyecto será probablemente superior al asignado (lo que implicará overtime) y con un rendimiento en términos generales probablemente inferior al porcentaje final (y en consecuencia también inferior al asignado oficialmente).

Y eso si intentas equilibrar tu esfuerzo, si por las circunstancias terminas dedicando más esfuerzo a uno de esos proyectos que a los otros, vistes uno pero dejas sin nada al resto.

Cada cual sabe cuáles son sus límites pero en ningún caso se llegará a infinito y cuando son tantos los proyectos a los que estás asignado y menor es el porcentaje que puedes dedicar a los mismos más te estarás acercando al mismo.

Es complicado alcanzar el equilibrio entre ocupación máxima a nivel de facturación y asignación óptima a proyectos para que la productividad no se vea resentida (o muy poco resentida) pero el hecho de que sea difícil no quiere decir que no deba ser un objetivo.

Mary Poppendieck y Tom Poppendieck realizan la siguiente reflexión sobre este tema (traducción libre): “La asignación de personas a múltiples proyectos es una fuente de pérdidas. Cada vez que los desarrolladores de software cambian entre tareas, se pierde un tiempo significativo en volver a alinear los pensamientos y entrar en el flujo de la nueva tarea”.

Comentan Mary y Tom Poppendieck que: “El rápido desarrollo tiene muchas ventajas. Sin velocidad, no se puede retrasar las decisiones. Sin velocidad, no tenemos información fiable. En el proceso de desarrollo, el ciclo de descubrimiento es fundamental para el aprendizaje: diseñar, implementar, feedback, mejorar”.

Me parece muy interesante que cita como ventajas, inconvenientes o deficiencias propias de otras estrategias de desarrollo: como atrasar casi indefinidamente decisiones que hay que tomar (gusten o no) y que las hipótesis formuladas queden sin ser demostradas durante demasiado tiempo.

Lo que está claro es que un enfoque clásico donde hay que esperar al final del proyecto a que se levante el teĺón para ver si el resultado es el adecuado es un riesgo absolutamente innecesario y que no se ajusta a la naturaleza del contexto del desarrollo de software: incertidumbre y cambio.

Si la solución no es acertada hay que esperar hasta el final, si hay que mejorar cosas (no solo del producto sino también del funcionamiento de las personas implicadas en el proyecto) también hay que esperar al final (es cierto que se pueden corregir deficiencias en ese funcionamiento sobre la marcha pero se escaparán muchas de ellas debido a que no se tendrá conciencia del impacto real que están teniendo en el desarrollo del producto).

Cuanto más se parezca el sistema de información que se está desarrollando a un mando a distancia más esfuerzo requerirá su desarrollo, más complicado será de mantener y probablemente las funcionalidades más críticas sean muy mejorables por no haber dedicado a las mismas el esfuerzo que se necesita, debido a que se ha tenido que repartir en el desarrollo de funcionalidades menos críticas o absolutamente imprescindibles.

Este mantra se tiene que quedar grabado en los desarrolladores y en el Product Owner: “Lo más crítico y lo más importante lo primero. Después, si se puede, se tratará todo lo demás”.

A esto hay que sumarle la necesidad de buscar la solución más simple que resuelva el problema. No siempre daremos con la tecla pero por lo menos hay que intentarlo, ya que si hay intención la solución adoptada será menos compleja que sin hacer ese esfuerzo.

Desarrollar funcionalidades innecesarias es muy problemático conforme el sistema crece y no se termina de poner en producción porque complicará sobre manera la puesta en marcha ya que los usuarios se encontrarán con un sistema muy complejo y pondrán resistencia a su utilización.

Sobre este asunto, Mary y Tom Poppendieck realizan la siguiente reflexión: “El terreno más fértil para la mejora de la productividad en el desarrollo de software radica en no llevar a cabo funcionalidades que no son necesarias”.

Cuando hablamos de mejorar la productividad o velocidad del desarrollo no solemos pensar en primera instancia en que ese software hay que probarlo, algo que es un error muy frecuente.

De hecho no se puede hablar de incremento de la productividad o de la velocidad si no va aparejado de un mantenimiento o mejora de la calidad de los entregables. De nada sirve llegar una semana antes si después te tienes que llevar dos semanas corrigiendo errores (en el mejor de los casos).

Ya sabemos que el testing se trabaja a distintas escalas, desde las pruebas unitarias, pasando por las de integración hasta llegar a las de sistema/aceptación. En función de la estrategia de desarrollo que utilices podrás trabajar a nivel de testing a menor o mayor nivel pero en ningún caso se puede renunciar a comprobar si lo que has desarrollado funciona y se corresponde con las especificaciones y esta tarea recae en el propio desarrollador y en personal dedicado al testing (si se dispone de él).

Estoy harto de ver casos en los que los desarrolladores no prueba de manera adecuada el software que desarrollan e independientemente de que en algún caso pueda haber dejadez, lo que falla principalmente es la técnica, aunque parezca mentira se puede saber programar estupendamente y después no tener ni idea de cómo hacer un testing efectivo.

Para terminar, os dejo una cita de Mary y Tom Poppendieck (traducción libre): “No importa lo rápido que desarrolles software si no eres capaz de hacerle un testing a la misma velocidad”.

Que te cambien los requisitos en fases avanzadas del desarrollo hace daño al proyecto si no se ha utilizado una metodología adecuada, si el producto que se está realizando tiene una deuda técnica inapropiada y si los stakeholders no están educados no solo en la propia realidad del desarrollo de software sino en la propia realidad de los cambios en la organizaciones y en consecuencia de sus personas y procesos.

Son muchos factores como para no hacer daño y precisamente por eso el efecto es tan negativo. Sin embargo si el enfoque del desarrollo de software y el contexto en que se realiza el mismo tiene en cuenta que las condiciones pueden cambiar, el cambio se puede convertir en ventaja. Por ejemplo, la adecuación de un proceso a un cambio normativo y en consecuencia del sistema de información que lo soporta o que lo va a soportar, si se realiza antes que los competidores, de una manera efectiva, proporciona una ventaja respecto a los mismos.

Mary Poppendieck, es la introductora junto a Tom Poppendieck de la aplicación de los conceptos de fabricación Lean en el proceso de desarrollo de software, basada en su experiencia en el campo de sistemas de control de procesos y en la jefatura de Departamentos IT en plantas de manufactura. Su experiencia en el sector y su aportación al desarrollo de software, hace que debamos tener muy en cuenta su siguiente reflexión: “Los cambios tardíos de los requisitos en el ciclo de vida son una ventaja competitiva… ¡si se puede actuar sobre ellos!”.