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?

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.

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?

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.

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.

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.