Estimando en base a qué

Hola,
Antes de nada, y como aclaración, todo lo que se va a hablar aquí tiene que ver con proyectos de implantación no basados en metologías ágiles, si no en el típico proyecto a alcance y prespuesto cerrado. Donde ante nuevas peticiones se generan las conocidas como “gestiones de cambio”. Después de esta primera aclaración, empezamos.
Uno de los principales problemas en el mundo del software es estimar el coste temporal que puede costar realizar un desarrollo. Obviamente no vamos a dar aquí la fórmula mágica, pero al menos algunas ideas basadas en la experiencia que pueden ayudarnos a orientar la estimación (siempre que nos dejen respetar el modelo).
Una de las principales claves a la hora de estimar, si no la más importante es disponer de un catálogo claro de requerimientos, tanto funcionales como técnicos. Esto es, un documento escrito, donde se describen claramente las necesidades funcionales, a la par que técnicas, del sistema. Insisto en lo de técnicas, ya que uno de los principales errores a la hora de dimensionar es no contar con estas. Ejemplos son un tiempo de respuesta mínimo ante determinadas peticiones, una necesidad de accesibilidad determinada, una tecnología o arquitectura requerida, una integración con un sistema determinado, etc.
Con estos dos documentos de partida tenemos ya parte de lo que necesitamos (dando por hecho que son documentos revisados, trabajados y entendidos por nuestra parte y sobre los cuales hemos podido resolver todas las dudas que nos han surgido al respecto), pero aún no hemos terminado. Nos faltan concretar aspectos clave por nuestra parte como son las actividades que vamos a realizar para conseguir el objetivo.
Como ejemplos de esto último: diseño funcional, plan de pruebas funcional, plan de pruebas de integración entre sistemas, plan de pruebas de carga y estrés, documento de arquitectura, diseño técnico, desarrollo, pruebas unitarias, despliegue, soporte a las pruebas de usuario, manual de usuario, guía rápida de usuario, migraciones de datos, cargas iniciales de datos, manual de despliegue, manual de administración, tareas de seguimiento y control del proyecto así como interlocución con el cliente, etc. A todo esto incorporar adicionalmente los aspectos específicos del cliente y que nos acarrean tiempo, como posibles auditorías de código, de sistemas, certificaciones de calidad… Y cualquier otro punto burocrático que no quede recogido en alguno de los puntos anteriores.
En resumen, todo el conjunto de actividades que consideramos que nuestro proyecto requiere para llegar al éxito. No nos dejemos ninguna sin estimar y si lo hacemos, dejemos bien claro a nuestro cliente que esa actividad en concreto queda fuera del alcance de nuestra colaboración.
Una vez identificadas todas las actividades y con nuestros documentos de requerimientos funcionales y de sistemas disponibles es el momento de ponerse manos a la obra. La pregunta del millón ahora es, ¿cómo empiezo la estimación? ¿cómo traduzco un requerimiento en horas de trabajo? Bajo mi punto de vista tenemos dos formas de hacer esto.
Forma 1, un primer dimensionamiento en base a tablas de estimación
La técnica consiste en base a los requerimientos funcionales empezar a identificar diferente aspectos típicos necesarios en una aplicación de software: número de pantallas, interfaces con otros sistemas, cálculos de negocio, tablas de almacenamientos de datos, migraciones de datos, etc. Todos estos elementos deben catalogarse en torno a una complejidad (alta, media, baja por ejemplo). A cada combinación tipo de elemento/complejidad, le asignamos un valor númerico, pueden ser horas o cualquier valor de referencia, como puntos función. En caso de utilizar la primera opción tendríamos un valor numérico directo traducible a esfuerzo, en el segundo caso tendríamos un número el cual podríamos traducir a continuación a horas en base a un equipo experiencia previa anterior dada. Es importante que por cada criterio de complejidad, tengamos claro qué significa, por ejemplo, una pantalla de complejidad baja tiene menos de tres elementos  y gestiona 2 eventos… una de complejidad media entre 4 y 10 elementos, otra de alta entre 11 y 20… Son ejemplos algo básicos, pero lo importante es que os quedéis con la idea.
Independientemente de que utilicemos puntos función o tablas de valoración por horas (en base a experiencia previa ambos), habremos obtenido el coste de una de las tareas que habíamos identificado anteriormente, la fase de desarrollo. Como punto adicional a tener en cuenta es que estas tablas de valoración deben estar ligadas a una tecnología en concreto (no cuesta lo mismo el coste de construir una aplicación web j2ee, .net, php)… por otro lado, no cuesta lo mismo construir un mismo aplicativo en una misma tecnología, si usamos una solución web o de escritorio. Y, lo más importante, no cuesta lo mismo construir una aplicación con un grupo que cuenta con una media de experiencia en desarrollo de 10 años, que de 3. En fin, que vosotros mismos y aquí la principal dificultad, tendréis que ir adaptando vuestras tablas de valoración en base a vuestra experiencia previa y al contexto de equipo con el que creáis os vais a encontrar para afrontar el proyecto (muy complicado esto último está claro).
A partir de aquí, extrapolamos en base a porcentajes para el resto de tareas, por ejemplo: las pruebas unitarias son un 10% de las horas de construcción, el diseño técnico es un 25% de las horas de construcción, el diseño funcional y el plan de pruebas son un 40 y un 25% respecto al tiempo de construcción; el tiempo de gestión es un 10%, el manual de usuario un 5%… Todos los porcentajes deben ser calculados en base a experiencia previa y/o en base a los requerimientos funcionales o técnicos (es posible que el ámbito funcional del proyecto sea muy complejo y haya que subir el % de diseño funcional o plan de pruebas, o por el contrario, un ámbito funcional sencillo, pero muy complejo a nivel de integraciones con otros sistema y arquitectura de software, por lo que reduciríamos los porcentajes de los documentos funcionales y aumentaríamos los del documento de arquitectura y diseño técnico).
Es una forma, no es la mejor, pero lo que está claro que sirve para dar una primera unidad de medida, un primer tamaño. Que sepamos de qué estamos hablando.
Eso sí, no puede ser la foto única e inamovible, ya que, ¿qué sentido tiene estimar todo en base a horas de construcción si realmente con el nivel de detalle que tenemos, que no olvidemos que es a nivel de requerimientos, lo más sencillo es que nos equivoquemos? Esa pantalla que parecía sencilla a nivel de requerimiento resulta que detrás escondía una complejidad muy importante a nivel de lógica de validación, esa pantalla complejísima luego resulta que no lo es tal ya que tiene muchos campos pero finalmente solo teníamos que comprobar si estaban rellenados para validarlos… eso sí, luego detrás tenía una integración con otros sistema que nadie había detectado en la toma de requerimientos y que nos puede llevar al traste del proyecto. Todo esto por no hablar del conjunto de datos maestros que surge como necesidad mantener, cargas de datos no previstas… vamos, algo que si no manejamos bien puede llevarnos al traste al proyecto, con un señor diciéndonos muy serio que: macho, esto lo estimaste tú, no sé qué te habías fumado.
Para ello, señores/as, no es la solución a todos los problemas, pero está claro que es el siguiente paso recomendado: dimensionemos así el coste de realizar el diseño funcional, el plan de pruebas y el documento de arquitectura, eso sí, una vez estos 3 documentos están listos y firmados por ambas partes, es el momento de volver a estimar el coste de construcción en base a nuestras tablas y ver qué pasa. Ejemplos ya hemos visto antes, ese requerimiento donde solo veíamos 1 pantalla, tras el análisis funcional vemos que se desglosa en 3 pantallas que tiran de unos datos maestros que nadie había identificado antes y provienen de la integración con otros sistemas… esa lógica de negocio no identificada que nos trae problemas de rendimiento y que para desatascar necesitamos conocimiento experto a nivel de base de datos, etc. Por otro lado, y muy importante, este es el momento en el que tenemos ya toda la visibilidad para entender qué es lo que necesita nuestro cliente y poder asegurar si dicho aplicativo ha de ser web, de escritorio, para dispositivos móviles o una combinación de las tres. Y no olvidemos, este es el momento en el que el propio cliente puede ver que alguno de los requerimientos que definió en su día no tienen sentido y eliminarlos, o ajustarlos en su medida.
Fin forma 1.
Forma 2, dimensionamos solo el coste del análisis funcional, plan de pruebas y documento de arquitectura
Nos evitamos todo el paso anterior y estimamos solo los 3 primeros documentos. Por cierto, muy complicado medir lo que nos cuesta hacer solo en papel o en varios diagramas, tiraría aquí de experiencias previas similares. Una vez redactados los documentos, valoramos en base a tablas tal como proponíamos en la forma 1.
Fin forma 2.
Bueno, aquí podríamos preguntarnos, ¿por qué no lo hacemos siempre de la forma 2? Pues porque normalmente nuestros clientes, antes de meterse en un fregado, quiéren saber cuánto puede costarles la broma, así que no está mal tener un dimensionamiento inicial, que aunque sepamos que no es perfecto, puede darnos una idea de coste global. Tened en cuenta que nuestros clientes manejan un presupuesto anual cerrado y lo mejor para ellos entonces es tener una unidad de medida fija con tal de identificar si le pueden dar cabida o no (otra cosa es que jueguen con eso para forzarte a que te pilles los dedos y tires adelante con todas las consecuencias y riesgo asumido en base a una fuente de información claramente insuficiente). Es por esto que plantear una foto inicial y una vez superados los 3 documentos clave restimar, es la que creo mejor de las fotos.
Es además desde el punto de vista de eficiencia de proyecto la mejor, disminuyendo el riesgo para todos. Si resulta que tras elaborar los 3 primeros documentos la estimación de la construcción no se ajusta a lo esperado por el cliente, no pasa nada, se entregan y se facturan como un valor que aportamos. Si nuestro cliente se quiere buscar a otro proveedor para realizar la construcción porque cree que así lo conseguirá hacer más bonito y más barato, adelante. Por otro lado, se puede llegar a la conclusión de que la estimación técnica es adecuada, pero que el problema está en que el coste del sistema en base al beneficio que se espera obtener es desorbitado (ese grupo de usuarios que a partir de 2 problemas generan un mundo de inmensa complejidad para evitarse alguna operación de coste temporal asumible manualmente).
Como os comentaba al principio, no es una fórmula mágica, ni tiene la clave para solucionar todos los problemas, pero al menos en una pequeña guía basada en la experiencia de cómo deberíamos organizar los básicos a la hora de realizar una estimación.
Abrazos.
Miguel.

Caso Práctico de Gestión de Proyectos con Puntos Función, Conclusiones

Os dejo un enlace a un pdf que me ha llamado mucho la atención, se trata
de un caso práctico llevado a cabo en un entorno universitario, donde varios grupos debe realizar la gestión de un proyecto a partir de un conjunto de requerimientos iniciales.
https://www.inf.udec.cl/~revista/ediciones/edicion1/mvaras.PDF
Las conclusiones lo mejor, no descubren nada nuevo, pero es cuanto menos curioso, ya que a lo que respecta al alcance y a los requerimientos hace mucho hincapié en la necesidad de disponer del total conocimiento al inicio, cuando, desgraciadamente es algo que no ocurre nunca.
Saludos.

Scrum, Formato de la Reunión de Planificación del Sprint

Siguiendo el libro “Flexibilidad con Scrum” de Juan Palacio (https://www.navegapolis.net), del que ya hablamos en su momento en este mismo blog, paso a redactar unas lí­neas extraí­das del capí­tulo donde se habla del formato que deberí­a tener la reunión de planificación del sprint. Me tomo la libertad de resaltar en negrita las afirmaciones que más me han llamado la atención.
“Los miembros del equipo se auto-asignan las diferentes tareas teniendo como criterio sus conocimientos, intereses y distribución homogénea del trabajo. Esta segunda parte (en el mismo libro se define que la reunión de planificación del sprint tiene que estar dividida en dos partes), debe considerarse como una reunión de equipo, en la que deben estar todos los miembros y ser ellos quienes descomponen el trabajo en tareas, las asignan y estiman“.
Me temo que los cimientos de más de uno se habrán removido al leer cosas como estas. Resulta un ataque frontal a la manera de trabajar de muchas empresas que a mi sinceramente me parece como mí­nimo más que interesante (aunque está claro que no es aplicable en el 100% de los contextos).
Con maneras de trabajar así­, temas como el “nivel de implicación” y “motivación” del equipo tienen que estar por defecto a niveles altí­simos. Y los que tenéis experiencia en el desarrollo de software sabréis que la motivación del equipo de trabajo es uno de los pilares fundamentales para conseguir alcanzar los objetivos.
Saludos.
Miguel.

Navaja de Occam y Principio Fundamental KISS

Navaja de Occam
La navaja de Occam (navaja de Ockham o principio de economí­a o de parsimonia) hace referencia a un tipo de razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta.
Principio Fundamental de KISS
El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingenierí­a.
Este término es un acrónimo que corresponde a la frase en inglés “Mantenlo simple, estíºpido” (Keep It Simple, Stupid). Para evitar ser tosco, el acrónimo se hace corresponder con otras expresiones tales como “Manténgalo breve y simple” (“Keep It Short and Simple”) u otras similares, pero que mantienen la misma idea del principio.
Ambas descripciones han sido extraidas de Wikipedia.
Saludos.
Miguel.

La norma de los 3 minutos

“Si tienes algo que hacer cuyo coste temporal no supera los 3 minutos de dedicación, hazlo.” (Extraido de la norma de los 2 minutos de David Allen en su libro GTD).
Bases en las que se apoya la norma bajo mi punto de vista:
1) Lo más seguro es que si no lo haces (y no lo apuntas en ningíºn lado) se te olvidará.
2) Si lo haces y lo terminas en esos tres minutos te lo quitarás de la cabeza, por lo que disminuirá tu nivel de estrés y aumentará tu nivel satisfacción por el trabajo realizado.
3) Si lo apuntas en lugar de hacerlo, tardarás más tiempo en apuntarlo detalladamente para que luego al retomarlo más adelante sepas de qué va la cosa y no pierdas tiempo ubicándote, o lo apuntarás demasiado rápido y cuando lo intentes hacer te habrás olvidado de muchos detalles cosa que provocará que tardes mucho más de 3 minutos.
4) El dedicar 3 minutos a una tarea, aunque tenga menor prioridad que otras, afectará imperceptiblemente a la fecha de entrega de tareas con mayor coste temporal.
5) En el libro Getting Things Done, David Allen habla de esta norma, pero la deja en 2 minutos y no en 3. Me parece algo escaso para aplicarlo al desarrollo de software, por lo que apuesto por 3.
¿Más ideas?
Un saludo.
Miguel.

GTD y el cómo gestionar tu tiempo

Extraigo la descripción de GTD que incorpora wikipedia en el siguiente link https://es.wikipedia.org/wiki/Getting_Things_Done
“GTD se basa en el principio de que una persona necesita borrar de su mente todas las tareas que tiene pendientes guardándolas en un lugar especí­fico. De este modo, se libera a la mente del trabajo de recordar todo lo que necesita hacer, y permitiéndole concentrarse en la realización de aquellas tareas. La psicologí­a de GTD se basa en hacer fácil el almacenamiento, seguimiento y revisión de toda la información relacionada con las cosas que necesitas hacer. Allen (desarrollador de la teorí­a) sugiere que muchos de los bloqueos mentales en los que nos encontramos a la hora de completar ciertas tareas vienen dados por una planificación insuficiente (p.e., para cualquier trabajo nosotros debemos aclarar lo que se debe conseguir y que acciones se deben llevar a cabo para completarlo). Segíºn Allen, es más práctico hacerlo reflexionando previamente sobre ello, generando una serie de acciones que hacer más tarde sin necesidad de volverlo a planificar durante su realización.”
Puestos además en serio, me acabo de comprar el libro en Amazon.com
Tí­tulo: Getting Things Done: The Art of Stress-Free Productivity
Autor: David Allen
Idioma: Inglés
En cuanto esté algo más empapado del tema… os cuento con más profundidad.
Saludos.
Miguel.

Proverbio Chino aplicable a la Gestión de Proyectos

El mejor lí­der es aquel cuya existencia no nota la gente. El siguiente mejor es al que la gente respeta y alaba. El siguiente es el que la gente teme; y el siguiente al que odia. Cuando el trabajo del mejor lí­der está acabado, la gente dice: Lo hicimos nosotros mismos.
 
Lao-Tzu (Filósofo chino siglo V a.C.)
Más información sobre Lao-Tzu en la Wikipedia:
https://es.wikipedia.org/wiki/Laozi