¿Cómo gestionar (ágilmente) una PoC de TI bastante compleja?

Soy un líder técnico empleado en una organización de TI ágil donde la mayoría de los equipos observan Scrum.

Llevo 2 semanas en la tarea de crear una prueba de concepto de un servicio que es bastante grande y complejo (varios meses-hombre) y soy el único recurso FTE dedicado al proyecto. Mientras esperamos que el proveedor nos brinde detalles, comencé a realizar algunas actividades de diligencia debida técnica y asignar requisitos a nuestras capacidades, asignar nuestros casos de uso a características, etc., etc. y fuera de este proceso he logrado para generar una lista de dependencias que deben resolverse (algunos requisitos previos, algunos diferibles) entre otros artefactos. Mi trabajo no está demasiado estructurado todavía.

Mi gerente (vicepresidente y PO suplente) parece tener algunos problemas con esto.

  • Duda de que mi razonamiento sea válido con la mayoría de las dependencias y quiere una segunda y una tercera opinión; quiere que sea yo quien busque otras opiniones.
  • Sugiere que sea yo quien trabaje con las partes interesadas (potenciales) en los requisitos, trabaje con el proveedor en temas abiertos, etc., etc.
  • Él piensa que mi enfoque crítico puede ser un signo de pesimismo, pero siento que simplemente estoy tratando de cuantificar y luego convertir las incógnitas en conocidas , y despejar un poco el terreno antes de que comience el trabajo.
  • Parece que tenemos discusiones prolongadas (sobre holgura) sobre cada uno y en su mayoría desciende a una bola de barro de conversación sin resolución. La información de alimentación por goteo no funciona (o tal vez no es receptivo a las noticias no deseadas).

Las cosas no van muy bien y están tensas en el proyecto. Necesito encontrar una forma de controlar las cosas que aborde los "problemas" mencionados anteriormente en esta etapa inicial, pero lo que es más importante, un proceso para usar a medida que el proyecto aumenta en las etapas de construcción y evaluación donde las cosas estarán ocupadas y habrá no hay tiempo para la ingeniería de procesos.

Si fuera una tarea pequeña y trivial, probablemente la haría , pero este es un proyecto bastante complejo con muchas incógnitas. ¿Qué metodologías (ágiles) debo seguir? Algunas notas.

  • Este es un PoC: es posible que no funcione (¿Piensa en un pico de 3 meses?). Si funciona, es probable que se enfrente a un equipo de scrum formal.
  • Estamos escasos de recursos (principalmente FTE).
  • No hay propietario del producto, pero mi gerente asume el rol. Hasta ahora, las responsabilidades parecen ser el "patrocinio" y la toma de decisiones de alto nivel.
  • No tenemos artefactos del proceso scrum (o pensamiento de diseño, etc.): visión del producto/páginas individuales, historias de usuarios. Hubo algunas conversaciones con el proveedor desde el principio (pero yo no estuve presente en ellas): no tengo mucho material con el que trabajar, excepto una tarea para entregar un PoC y alguna documentación del proveedor.
  • Hay un equipo de 1: yo, el ingeniero FTE que también lleva diseño/tecnología de soluciones. sombreros de propietario de producto/cliente potencial, así como el de un Scrum Master cuando las cosas mejoran. (Presiento algunos conflictos de interés para resolver aquí).
  • Al ser algo con lo que estoy familiarizado, me inclino a usar alguna forma ligera de scrum para obtener los beneficios habituales, pero tal vez sin algunos de los "gastos generales" de las ceremonias.
Estoy un poco confundido. Usted menciona la construcción de un PoC. Un PoC es un experimento, pero parece querer tratarlo como un proyecto completo con una planificación inicial. Su PO parece querer que construya algo lo antes posible. Creo que aquí está la desconexión: tal vez ambos no se hayan puesto de acuerdo sobre cuál debería ser el resultado de esta PoC y qué nivel de calidad se construirá. En cuanto al uso de Scrum, si usted es un equipo de un solo hombre con tal vez otra persona con muchos sombreros, Scrum no funcionará tan bien, especialmente con la construcción de un experimento real, si eso es lo que es el PoC.
@Bogdan: correcto, es un PoC de tipo de estudio de factibilidad, pero es una aplicación empresarial que es lo suficientemente compleja (aproximadamente 60-90 días hombre) para implementar y evaluar que todo el ejercicio debe dividirse en pequeñas partes de trabajo, tamaño, priorizado, medido, etc., que se necesitará algo como Scrum. Tienes razón en que los resultados o los criterios de salida no están definidos; es algo en lo que tenemos que trabajar.
@shalomb, para cada actividad que presente, debe tener una comprensión clara de por qué la necesita. La mayoría de las veces, las personas simplemente siguen a la multitud, haciendo lo que hacen los demás, y eso es muy ineficaz. Si comienza a pensar críticamente (¿por qué exactamente necesito estimar? ¿por qué exactamente necesito medir?) es posible que muchas de estas actividades no sean necesarias para su situación.

Respuestas (2)

Como mencioné en el comentario anterior, usted y su gerente/PO suplente deben ponerse de acuerdo sobre los resultados de esta PoC. Debe definir los objetivos de la implementación o podría arriesgarse a trabajar hacia diferentes objetivos. También discuta cuál será el papel de cada uno en esto. De la pregunta parece que usted quiere que él sea un PO, mientras que él quiere que usted se involucre más con las partes interesadas.

Habiendo dicho eso, personalmente no iría con Scrum para administrar la construcción de un PoC. Esta es la reacción instintiva de todos al elegir un enfoque Agile para crear software, pero no creo que sea necesariamente la mejor opción aquí por varias razones.

Scrum establece algunas cosas y reglas para hacerlo bien desde el principio, creando así una buena estructura dentro de la cual los equipos pueden construir su propio proceso de trabajo. Pero esta estructura puede crear una sobrecarga cuando tiene un equipo pequeño o es el único empleado de tiempo completo que trabaja en el proyecto.

Scrum es lo suficientemente flexible para la mayoría de los trabajos, pero también tiene una parte rígida: el sprint. Esto establece la cadencia para muchas actividades. Muchas partes interesadas interactúan con un equipo Scrum durante la reunión de revisión, es decir, una vez por sprint. Está construyendo un PoC, un experimento de factibilidad, para validar algo. ¿Es suficiente recopilar comentarios una vez por sprint o necesita comentarios antes?

También tienes una Reunión de Retrospectiva. Usas esto para mejorar tu forma de trabajar. ¿Es esto importante cuando se construye el PoC? ¿O es solo el PoC que le interesa? No estoy diciendo necesariamente que debas ir al estilo vaquero y disparar desde la cadera, pero ¿realmente quieres invertir mucho en el proceso? ¿Este PoC será un desperdicio una vez que valide/invalide la idea, o creará la aplicación real encima? Por ejemplo, ¿necesita una definición de Listo? ¿Desea que esta prueba de concepto se considere un éxito solo si se revisó cada línea de código o si tiene una buena cobertura de pruebas unitarias? ¿Sí? ¿No? Si el PoC es un éxito y logra implementar la aplicación real más adelante, entonces puede concentrarse en su proceso. Con un PoC del tipo "saca la cosa lo más rápido posible" probablemente no

Scrum también tiene una reunión de planificación de Sprint. Estimas qué trabajo puedes incluir en el próximo Sprint. Estableces un objetivo de sprint. Creas un incremento liberable en cada sprint. Intenta mantener el alcance sin cambios durante el sprint. ¿Tiene esto sentido para el trabajo que está haciendo? Un PoC es una solución mínima viable. Menos y no lo ayudará a validar/invalidar sus suposiciones. Más y ya no es solo un PoC. ¿Estarán los incrementos en una condición liberable? Si descubre algo que cambia completamente su ámbito de trabajo para el sprint, ¿qué hará con el sprint? ¿Cancelalo? ¿Cumplir con el objetivo de Sprint? Si planificas tu sprint y al día siguiente te das cuenta de que necesitas hacer algo diferente, simplemente perdiste el tiempo planificando y podrías haber trabajado en la implementación de PoC.

¿Necesita hacer un refinamiento de backlog? ¿Está tomando forma su PoC a medida que la construye, o ya extrajo los elementos mínimos que deben ser parte de la PoC? Aparecerán algunas cosas nuevas, algunas cambiarán, algunas ya no serán necesarias, pero eso sucederá debido a lo que descubra durante la implementación, o será porque tiene una "razón comercial" para agregar, cambiar o eliminar elementos de la cartera de pedidos?

Podría pensar en otras razones, pero esto ya se está haciendo largo. Entonces, ¿qué tal una alternativa a Scrum?

Yo personalmente manejaría esto usando Kanban.

Pon todo en un tablero para tener visibilidad de lo que estás haciendo. Hacer Kanban mantendrá a todos más comprometidos. La interacción ocurre más a menudo, no en una cadencia de Sprint.

Establezca límites WIP en las cosas para que no trabaje en demasiadas cosas a la vez. Los límites WIP también resaltarán los bloqueos y los cuellos de botella y permitirán un tiempo de respuesta más rápido para eliminarlos y mantener el flujo de trabajo en movimiento.

En lugar de estimar cada tarea, solo concéntrese en lo que es importante, dónde se encuentra, qué está haciendo, dónde debe estar a continuación. Muchas de las cosas en su tablero serán obligatorias, de lo contrario, el PoC no cumplirá su propósito. No tiene sentido estimarlos, es un desperdicio. Estima cuándo también lo necesitas (como decidir entre dos opciones y elegir la más rápida, así estimas el esfuerzo para saber qué elegir).

Párese frente al tablero Kanban y planifique su trabajo todos los días, no una vez por sprint. Ajuste el rumbo según sea necesario.

Al ser algo con lo que estoy familiarizado, me inclino a usar alguna forma ligera de scrum para obtener los beneficios habituales, pero tal vez sin algunos de los "gastos generales" de las ceremonias.

Comience con Kanban y agregue encima cualquier práctica de Scrum que encuentre útil, lo que creo que funcionaría mejor que Comenzar con Scrum y cortar cosas de él.

¡Posiblemente una de las respuestas más útiles que he leído en este sitio!
" Pon todo en un tablero " - ¿Cuáles serían las columnas en el tablero? Es solo TODO y DONE, que básicamente es solo una lista de verificación. " Ponga límites WIP en las cosas para que no trabaje en demasiadas cosas a la vez " - ¿por qué trabajaría en más de 1 cosa a la vez? Aparecen más de 2 tareas simultáneas cuando colaboras con alguien. Ni Scrum ni Kanban son necesarios para un trabajo de 1 persona.
@Stanislav Bashkyrtsev: El OP creará las columnas que considere necesarias para administrar su trabajo. La pregunta menciona la espera de los proveedores, la participación de las partes interesadas, las etapas de evaluación, la gestión de las dependencias y que la PoC no es una tarea pequeña y trivial. No puede manejar toda esa interacción con TODO y DONE. Nadie trabaja solo en el vacío. Además, un tablero es un radiador de información para que lo vea el gerente del OP, quien de lo contrario podría verse tentado a interrumpir constantemente y preguntar "¿qué estás haciendo ahora?" y "¿ya llegamos?"
@Stanislav Bashkyrtsev: los humanos tienen un límite WIP de 1, porque no podemos realizar múltiples tareas. Pero podemos cambiar de forma múltiple. Mientras el OP está trabajando en algo, es posible que espere la entrada de una parte interesada o que el proveedor solucione una dependencia. Cuando esas cosas estén disponibles, podría cambiar para incorporar la entrada o probar la dependencia. De repente te encuentras con un montón de cosas en progreso, pero ninguna terminada. Un tablero adecuado con límites WIP (1 u otro) está "en tu cara" y te recuerda que tal vez deberías terminar algunas cosas antes de comenzar a trabajar en otra.
@Bogdan, la mayor parte de lo que dijo se puede lograr con lápiz y papel y 2 listas: plan general y plan a corto plazo (actividades de hoy/mañana que incluyen "esperar la respuesta de X e Y"). Y en cuanto a la visibilidad: una reunión de estado de 5 minutos todos los días o dos será suficiente (lo necesita de todos modos para obtener comentarios / comentarios de otros). Introducir procesos de desarrollo aquí es como cazar una mosca con una bazuca. Toda esta pregunta no se trata de gestión de proyectos, se trata de autodisciplina, gestión del tiempo, arquitectura de software, ingeniería, etc.
@StanislavBashkyrtsev: Kanban es un conjunto de principios de sentido común que puedes contar con los dedos de una mano. No es un proceso. No estoy sugiriendo ir por la borda con esto y convertir todo en un pesado proceso de gestión de desarrollo, que anularía el propósito de hacer Kanban por completo, solo sugiero una configuración mínima para obtener visibilidad del trabajo y ayudar a organizarlo. Scrum no es la mejor opción aquí, pero tampoco creo que "simplemente hazlo", como sugieres en tu respuesta y comentarios. Estoy abogando por una opción intermedia.
@Bogdan, otro nombre de Kanban (por cierto, "Kanban" es el nombre en 3D que se tomó por error; deberíamos decir Just-in-time) es un sistema de extracción. Alguien tiene que tirar . Resuelve el problema de sincronizar múltiples entidades (personas/departamentos/equipos) trabajando simultáneamente y pasando los resultados de su trabajo entre sí. No necesita Just-in-time en el caso de una transmisión secuencial de 1 persona; no existen problemas en tal configuración que resuelva Just-in-time. En cuanto a la terminología... Yo llamaría Lean a un conjunto de principios, mientras que Just-in-time es un proceso. No estoy seguro si es importante en esta discusión.
@StanislavBashkyrtsev: Esa es una buena observación sobre las fortalezas de Kanban, pero no niega la utilidad de sus principios para que una sola persona organice su propio trabajo. Véase, por ejemplo, Personal Kanban . No soy un gran admirador de ese libro, pero proporciona algunas buenas explicaciones de por qué podría elegir este enfoque en lugar de listas, lápiz y papel.

No entiendo por qué empezaste a pensar en Scrum aquí. O cualquier otro proceso de equipo . No necesitas coordinación ni reuniones ni nada. Pasa estos 3 meses haciendo lo que importa. Un científico/ingeniero típico primero pasaría tiempo tratando de comprender el problema, luego planearía cómo abordarlo y luego se arremangaría, así que:

  1. Investiga el dominio. Familiarícese con la terminología para poder comunicarse con las partes interesadas.
  2. Encuentre las partes más riesgosas de los requisitos y dibuje maquetas/diagramas.
  3. Luego determine cuál de las maquetas/diagramas puede implementar y cuáles son las dependencias entre ellos.
  4. ¡ Entonces hazlo!

Solo cuando empieces a formar un equipo tendrás que pensar en cómo coordinar y comunicar el trabajo.

Scrum es predeterminado porque la organización lo usa ampliamente y sería el vehículo de entrega más allá de PoC: traer a los miembros del equipo más tarde si es necesario (muy probablemente) es más fácil. Se considera ahora porque necesitamos tener la capacidad de determinar el alcance y estimar el trabajo justo a tiempo, priorizar y demostrar el progreso y la corrección del curso con el paso/no paso en los puntos de control regulares. Aquí hay algunos buenos consejos, pero no estoy de acuerdo con el "enfoque de mini-cascada" porque el "simplemente hazlo" sin una medición continua es lo que inevitablemente conducirá a marchas de la muerte más cerca del momento crucial. Estoy ansioso por evitar eso .
@shalomb (1) No sé si esto cambia algo en esta discusión, pero Scrum está un poco desactualizado. Los métodos modernos son: Teoría de Restricciones, Just-in-time (también conocido como Kanban), Entrega Continua y su mezcla. (2) Incluso si decide introducir Scrum cuando comienza a formar un equipo, no será más complicado más adelante. (3) No mencioné la cascada en mi respuesta ("mini" o no). Cualquier buen proceso de ingeniería/científico es un ciclo que consiste en planificar->hacer->sacar conclusiones->repetir. (4) Scrum no tiene ninguna "medida continua" construida. Ni siquiera tiene métricas para medir.
@shalomb También intentaría al menos considerar la idea de que su gerente tiene razón sobre su enfoque actual. Parece que quiere que seas un desarrollador adulto y lideres el proyecto. Para hacer eso, necesita comprender el dominio y hablar con las partes interesadas. Y por lo que (y cómo) escribes, parece que él tiene algo sobre "mi enfoque crítico puede ser un signo de pesimismo". Parece que piensas demasiado y complicas demasiado las cosas.
@Stansilav: busco un enfoque responsable para garantizar que el PoC se mantenga firme y caiga por las razones correctas (es decir, no falle debido a una estructura y soporte inadecuados). Si esto fuera un PoC para una aplicación web de calcetines tontos , me inclinaría por el enfoque de simplemente hacerlo . Capturar la complejidad del dominio y el razonamiento sobre el terreno mientras se es pragmático es el punto de mi pregunta: mantenerse al tanto de todo esto requiere un gran conjunto de trabajo mental que debe estar fuera de mi cabeza y accesible para la parte interesada (y más importante para mí mismo). , porque no recuerdo detalles desde la semana pasada).
¿Cómo gestionar (ágilmente) una PoC de TI bastante compleja?
RespuestasAquíPolítica de privacidad1y, 0v