Gestión de proyectos - Software Publico Uruguayo

Las metodologías ágiles hay que ponerlas en contexto y utilizarlas en su justa medida, cuando sean la mejor opción, que no es siempre. Lo ideal es establecer los criterios para definir si un proyecto determinado, debe ser desarrollado utilizando una u otra metodología. A continuación presentamos criterios a tomar en cuenta:

• Solución técnica desconocida. Saber qué se quiere hacer es diferente a saber cómo, quizás el usuario tenga un concepto de producto claro pero no sepa cómo implementarlo. La metodología ágil agrega más valor cuando la solución técnica es desconocida, es decir si es de un alto grado de complejidad, distinto de lo que el equipo de desarrollo ha trabajado y si es una solución innovadora que el equipo nunca ha realizado. Cuando la solución técnica es conocida, es decir el entorno de la organización es estable, los cambios son infrecuentes y se está desarrollando un producto que ya ha sido desarrollado varias veces, es preferible la utilizar metodología cascada, por ejemplo los mantenimiento o actualización a aplicaciones existentes.
• Requisitos dinámicos. Si se trata de un proyecto en un ámbito donde los puntos de vista de análisis están constantemente cambiando, entonces la metodología ágil te ayudará a responder a esa variabilidad. Si se trata de un proyecto en un ámbito de poco dinamismo, la metodología cascada te ayudaría más.
• Sistema no es crítico.  Si te encuentras con un proyecto de un sistema crítico, no debes utilizar metodologías ágiles, es mejor asegurar el éxito usando metodología cascada.
• Nivel del equipo de desarrollo maduro. Las metodologías ágiles requieren de gran madurez, experiencia y dosis de talento; deben ser equipos con gente senior o semi-senior. Si tu equipo lo integran principalmente novatos es mejor que no intentes utilizar metodologías ágiles.
• Cliente con suficiente tiempo para el proyecto. El cliente debe disponer de suficiente tiempo para dedicarlo al proyecto, es decir brindar recursos humanos calificados para que acompañe al proyecto en toda su extensión, si la respuesta es no, entonces mejor utilizar metodología cascada.
• La forma de contratación no es Precio Fijo. Las metodologías ágiles parten de la premisa que el alcance debe ser modificado de iteración en iteración según las necesidades y prioridades del negocio, pero si de entrada el contrato exige que el alcance del proyecto y sus presupuesto estén definidos desde el principio y que al final el proyecto se entregue exactamente con ese alcance, no debe utilizar metodologías ágiles sino más bien metodología cascada.
• El proveedor de la solución es interno o si es externo tiene una relación de largo plazo. Si está desarrollando la solución con un proveedor externo con una relación de corto plazo, la organización, al no existir suficiente grado de confianza, tenderá a favorecer un esquema de alcance y precio fijo cerrado para la contratación, por lo cual no sería recomendable para este proveedor proponer utilizar metodologías ágiles y más bien debería utilizarse metodología cascada.

Gestión de Proyectos (APE). Comprende un ciclo de vida hibrido.

• Fase 1 - El Pre-proyecto. Identificación de proyecto candidato, se comprende y se proyecta, el compromiso se asegura. Ocupándose de estos problemas en una fase temprana evita los problemas en las fases tardías.
• Fase 2 - El ciclo de vida del Proyecto. Las primeras dos fases, el Estudio de Viabilidad y Estudio Comercial son fases secuenciales. Después de que estas fases se han concluido, el sistema se desarrolla el iterativa  e incrementalmente, sobre bases solidas.
  • Factibilidad
  • Bases (Fundamentación de negocio y arquitectura)
  • Iteración: Exploración e Ingeniería
  • Despliegue
• Fase 3 - el Post-proyecto.  Asegura operación eficiente y eficaz. 

Prevé la iteración de diferentes practicas especificas para soportar la fase de ideación, proyecto y su operación, a la vez que considera la gestión del producto como un continuo.

Los aspectos más importantes para enfocarse en marcos ágiles, comprenden:

• Identificar partes interesadas importantes. Esta es la razón más importante para el éxito o fracaso del proyecto. Interactuar con demasiados interesados ​​y no identificar a los que toman las decisiones puede llevar al caos. Por lo tanto, el mapeo de las partes interesadas con la matriz de poder e interés ayuda al equipo a interactuar con el segmento objetivo.
• Pensamiento de diseño. Un pobre enfoque de pensamiento de diseño puede conducir a baja empatía para los usuarios finales. Los usuarios finales para los que se toma el proyecto deben tenerse en cuenta al diseñar el servicio / producto. Tanto el pensamiento Agile como el Diseño adoptan la idea de refinar el producto con comentarios constantes de los clientes. Es muy importante pensar desde la perspectiva de los usuarios al crear productos. Se basa en la lógica, la imaginación, la intuición y el razonamiento sistémico, para explorar las posibilidades de lo que podría ser, y para crear resultados viables. Combina los dos tipos de pensamientos: el racional y emocional. Se refiere a generar ideas innovadoras centrada en los seres humanos visualizando a través de prototipos que luego se transforman en proyectos, productos, servicios, que resuelvan problemas o satisfagan de mejor manera las necesidades de las personas haciéndolas parte activa del proceso de creación. Presenta un abordaje sistémico, se base en la experimentación, prueba y error.

• Carta del proyecto. Documento inicial donde se define el alcance para poner en marcha el proyecto, dotar el equipo y llegar a un acuerdo sobre el alcance, el presupuesto sobre el objetivo del proyecto. Proporciona dirección y en ágil, pero el tamaño o la documentación debe ser nítida y clara. Los riesgos, las limitaciones, las dependencias y los supuestos deben destacarse claramente a los interesados. Permite la permanente justificación del proyecto.
• Reuniones agiles. La reunión diaria, la retrospectiva de iteración, la reunión de pila de producto, etc. pueden arruinar a la dinámica si no se lleva a cabo y se las administra bien. Demasiadas reuniones pueden perder mucho tiempo y reducir la productividad y la motivación del equipo. Se debería garantizar que las partes interesadas apropiadas sean parte de la reunión cuando sea necesario. Lo más importante es que debemos aprender de nuestros errores y corregirlos mediante comentarios a través de la reunión retrospectiva de sprint. Invite a partes interesadas importantes (gerentes / directores) a reuniones específicas para alentar al equipo y mantener la motivación alta ya que el equipo comprenderá la importancia del proyecto.
• Requisito. El retraso acumulado del producto y el retraso acumulado del sprint deben ser constantemente refinados y mantenidos para tener alcance y cronogramas bajo control. El requisito debe ser ajustado teniendo en cuenta el marco SMART (específico, mensurable, realizable, centrado en los resultados y limitado en el tiempo). Lanzamiento y planificación de Sprint: se dice que la planificación eficaz es de 3/4 de trabajo realizado y el objetivo de sprint debe ser realista. la participación de la gente es importante en cada reunión de planificación. Las estimaciones de los puntos de la historia deben basarse en las conciencias del equipo y no se deben alentar los remanentes de velocidad. Definir el valor desde el Cliente. Las historias de usuario deben promover conversaciones  y la confirmación como acuerdo que refleja a todas las personas implicadas; pueden incluir la siguientes información:
  • ID – un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.
  • Nombre – una descripción corta de la historia. Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos hablando, y suficientemente clara como para distinguirla de las otras historias. El enunciado está compuesto por tres partes bien definidas:
    • El rol: ¿Quién realiza la acción?, ¿qué papel juega en la aplicación?.
    • La funcionalidad: Representa la función que el rol quiere o necesita hacer en el sistema que se va a desarrollar. Puede diferenciarse entre acciones obligatorias u opcionales, utilizando la palabra puede o necesita para describir la acción.
    • La finalidad: Lo que el rol necesita lograr al ejecutar la acción. Este es el resultado de ejecutar la acción desde el punto de vista del rol. Este punto puede ser opcional, pues la historia puede documentarse sólo con la definición del rol y la acción (sin definir la consecuencia).
  • Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la “máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese nuevo elemento?
• Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias, usualmente corresponde a “días-persona ideales”.
• Como probarlo – una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Si se practica TDD (Test-Driven Development, desarrollo orientado a test) esta descripción puede usarse como pseudo-código para la prueba de aceptación.
• Notas – cualquier otra información, clarificación, referencia a otras fuentes de información, etc. Normalmente muy breve.

Es posible complementar con información adicional:

• Categoría – una categorización básica de la historia. Así, el dueño de producto puede filtrar fácilmente “optimización” y cambiar todas las prioridades de este tipo a “baja”, etc.
• Componentes - el Dueño de Producto puede identificar qué componentes técnicos estarán involucrados en la implementación de la historia. Esto es útil cuando tienes varios equipos y quieres que sea fácil para cada equipo saber a qué historias deben dedicarse.
• Solicitante – el Dueño de Producto puede querer mantener un historial acerca de qué cliente o persona interesada pidió originalmente la historia, para poder así ofrecerle información actualizada sobre el progreso de la misma.
• ID de incidencia– si tienes un sistema de seguimiento de errores, es útil mantener un historial de cualquier correspondencia directa entre una historia y uno o más errores reportados.

Características que deben de presentar las historias de usuario:

• Independiente, Una historia no depende del resto de historias, de forma que se pueden clasificar por prioridad, como se desee, pues no tienen un orden lógico.
• Negociable, Las historias como tal, en su primera fase, son ideas, o conceptos, pero se deben desarrollar en la fase de comunicación.
• Valiosa, Las historias deben tener valor por sí solas para el cliente, usuario o comprador.
• Estimable, una vez finalizada la conversación debemos poder estimar las historias, si no son estimables será necesario una segunda puesta en común.
• Pequeña, una buena historia debería poderse realizar en una semana, por lo que no suelen ser extensas.
• Verificable, es necesario probar una historia para ver si se ha resuelto con éxito.

El valor, solo puede definirlo el consumidor final y solamente es significativo cuando se expresa en términos de producto / servicio que satisface las necesidades del consumidor a un precio concreto, en un momento determinado. El valor lo crea la organización, desde el punto de vista del cliente.

• Identificar los factores de expectativas de clientes y su satisfacción nos permite y priorizar los  requerimientos:
• Por que y para que?  Priorizar: factores de expectativas de clientes y su satisfacción, considerando alineación con objetivos estratégicos, riesgos; y no solo: complejidad, dependencias, conocimiento, esfuerzo. Relacionado al negocio vs deseos, los primeros son críticos, y resto negociables.
• Sugiere reducir/priorizar requerimientos, costos y tipo de MVP.

Aplicación de criterios para priorizar los requerimientos:

A fin de organizar los requerimientos y su mapeo a las entregables conveniente el uso del mapa de historias de usuario.