En términos ágiles, ¿cómo se planifican y asignan las tareas básicas de infraestructura al inicio de un proyecto utilizando marcos de administración estrictos como TFS en línea?

9

Aquí estoy en el proceso de determinar y estimar un nuevo proyecto de desarrollo de software relativamente pequeño. He revisado las historias de usuarios sugeridas por el cliente y he colocado tareas en contra de cada una, con una estimación y algunas notas breves sobre cómo se realizará la tarea. Hay criterios de aceptación. Todos deberían ser buenos con el mundo.

ingrese la descripción de la imagen aquí

Al mirar el trabajo que había planeado, me di cuenta de que faltaba algo. Habrá un desembolso inicial simplemente configurando cosas en las que podamos atornillar la funcionalidad. Cosas que pertenecen a todas las historias de usuarios, no a una historia de usuario en particular.

Por ejemplo, parte de esta aplicación es un servicio que analiza XML. Desde el punto de vista del usuario, hay historias específicas en las que habrá que hacer diferentes cosas dependiendo del contenido del XML. En realidad, escribir un analizador XML (los bits que buscan un archivo, lo leen y extraen los datos relevantes antes de decidir qué hacer con el contenido) es parte de todas esas historias. Como lo envuelve en un servicio de Windows con un instalador, etc. Es una tarea centrada en el desarrollador sin relevancia directa para un usuario.

Otro ejemplo relevante de esta aplicación en particular es tomar y reescribir un bloque de código heredado deficiente que es útil para las funciones de esta aplicación. Nuevamente, esto no tiene resultados inmediatos para el usuario, pero es un trabajo necesario. ¿Dónde "vive" la planificación y ejecución de este trabajo en un plan de proyecto centrado en historias de usuarios?

He visto a personas resolver esto escribiendo historias de usuarios "Como desarrollador, quiero ...", pero como se ha discutido en otra parte, esta no es una historia de usuario . Es un desarrollador.

Estoy buscando una respuesta concreta a esto, para ayudarme (y a otros) a planificar proyectos utilizando marcos de gestión estrictos como TFS en línea. Estos no tienden a tener la función de crear "historias de partes interesadas" u otras vagas meta-soluciones mencionadas en las respuestas a ¿Cómo un equipo Scrum tiene en cuenta las tareas de infraestructura en la reunión de planificación?

Bob Tway
fuente
2
Si le digo que una computadora o un servicio también pueden ser tratados como un "usuario", ¿eso altera su análisis?
Robert Harvey
1
@mmathis Vi esa pregunta, y es similar y relevante. Sin embargo, ninguna de las respuestas responde realmente a esta pregunta. Especialmente cuando considera un enfoque sobre cómo hacerlo dentro de los marcos existentes como TFS.
Bob Tway
@RobertHarvey parcialmente, sí. Eso cubriría el servicio en este caso, pero no el código heredado. Puedo pensar en otras situaciones en las que ese enfoque podría no cubrir los requisitos. También me interesaría saber qué tan ampliamente aceptado es: parece un cambio semántico para solucionar el problema "como desarrollador".
Bob Tway
2
Puede hacer trampa en tener usuarios del sistema e iteración 0, o puede cortar el pastel de manera diferente. La primera característica brinda cierta funcionalidad al usuario y la infraestructura necesaria para que funcione. Luego, la función 2 que, en consecuencia, trae más infraestructura, de esta manera no perderá tiempo configurando una infraestructura que no necesita. Si ahora está gritando pero eso significa que necesito volver a planificar, entonces no lo está haciendo ágilmente.
ctrl-alt-delor

Respuestas:

12

Me gustan las otras respuestas que dicen poner todo el código de "herramientas" que puedas en la iteración 0. Sin embargo, a veces, este tipo de herramientas aparecen después de que el proyecto ya ha comenzado. Quizás en Iteration 3 se dé cuenta de que necesita un widget de analizador XML generalizado para usar en varias historias en el futuro.

En ese caso, la primera historia de usuario que se basa en estas piezas arquitectónicas internas es a la que pertenecen . Si está a punto de trabajar en la Historia # 345, y dependerá de su analizador XML antes de que pueda contarse como 'hecho', entonces su analizador reutilizable se adjuntará como trabajo para que se complete esa historia.

Mi equipo ha utilizado el enfoque anterior y parecía funcionar bien para nosotros.

Graham
fuente
Iba a responder de manera similar a esta. Si una historia necesita algo, es parte de esa historia. Algunas historias podrían obtener el beneficio de venir después de otra historia que construyó la infraestructura. Sin embargo, debe conservar todas aquellas historias que lo requieran, en caso de que las historias se vuelvan a priorizar. No puedes estar seguro de cuál será el primero.
Jay S
1
+1 Esto toca un gran punto. Si se llama iteración 0, 1 o lo que sea una bagatela. Todos menos los más irrazonables o desinformados entienden que se requiere algún trabajo preliminar. Si pintas, preparas las paredes, si cocinas, cortas, si eres músico, practicas.
Robbie Dee
6

Si se trata de infraestructura, generalmente se coloca en Iteration Zero. ¿Qué es la iteración cero? Normalmente es el tiempo entre el inicio y la planificación antes de que comiencen las iteraciones reales.

Un ejemplo, digamos que necesitamos un nuevo servicio web. Por lo tanto, necesito crear el proyecto, configurar la integración continua, configurar un repositorio de control de código fuente, configurar el script de compilación y la implementación automatizada, etc. Los usuarios realmente no se preocupan por esto, pero los necesitamos independientemente.

Por lo tanto, ese trabajo se realizaría en la iteración 0. Para cuando se inicie la iteración 1, ya habrá un nuevo shell de proyecto que se compilará, tendrá un script de compilación automatizado y se implementará. Ahora, ninguna de las funciones del usuario estaría allí, pero está lista para funcionar.

Todavía seguiría y planificaría este trabajo como parte del trabajo de iteración 0.

La refactorización suena como una historia técnica que puede ir en cualquier iteración.

Jon Raynor
fuente
44
+1 porque también usamos esto, pero en realidad Interation Zero es el nuevo Iteration One. Es solo una iteración que a la parte interesada del negocio realmente no le importa, pero es necesaria para llegar a las cosas que le interesan a la parte interesada.
Greg Burghardt
Puede tener una iteración de buena fe 0, pero eso no quiere decir que no pueda comenzar a entregar valor desde el día 1. No necesita un servidor de compilación, una implementación automatizada y un repositorio de código fuente para comenzar a cortar el código; esto puede suceder más tarde (o incluso en paralelo).
Robbie Dee
3

Depende de la infraestructura.

Si la infraestructura es muy importante o tiene que cumplir con complicadas regulaciones de cumplimiento, entonces puede tener un equipo de infraestructura separado, que puede tener un horario propio. Puede ser ágil, puede ser una cascada. En este caso, la construcción de la infraestructura se administraría en su proyecto como una dependencia externa .

Si la infraestructura será administrada por su equipo y se configura solo una vez, puede usar la técnica de iteración 0 que Jon describe.

Si la configuración de la infraestructura tomará varias iteraciones (por ejemplo, quizás haya configurado su servidor de compilación ahora pero los servidores de control de calidad y preprod se construirán un poco más tarde), entonces su construcción se puede administrar como PBI no funcionales. Los PBI funcionales pueden tener ciertas dependencias de estos, que puede codificar en TFS utilizando el enlace "predecesor".

Y, por supuesto, puede mezclar y combinar todo lo anterior. Por ejemplo, no puede hacer mucho sin un servidor de compilación continuo, por lo que podría ponerlo en la iteración 0. Mientras tanto, sus servidores de preprod pueden definirse como tareas para las iteraciones 2 y 3, y pueden tener dependencias externas en su equipo de DBA ( que no son ágiles) que le asignarán instancias de base de datos en su centro de datos. O tal vez tenga que esperar a que se emitan certificados SSL para ciertas funciones; pueden ir en la iteración 4, y cualquier elemento funcional que se base en esos certificados debe estar vinculado a ellos con una relación predecesora / sucesora.

En todos los casos, recuerde:

  1. Siempre defina criterios claros de aceptación. Los encargados del hardware tienen una tendencia molesta a poner en pie un servidor y llamarlo cuando no ha sido validado en absoluto.
  2. Durante el inicio de la iteración de su equipo, el equipo deberá examinar las dependencias y su disponibilidad antes de comprometerse con cualquier PBI o elemento de trabajo.
John Wu
fuente
Los encargados del hardware tienen una tendencia molesta a poner en pie un servidor y ponerlo en práctica cuando no se ha validado en absoluto. Buen punto, de ahí la reciente prevalencia de DevOps.
Robbie Dee