🌕 😱 👨🏻‍🚀 JIRA como remedio para el insomnio y las crisis nerviosas 🍝 👩🏼‍🏭 🎨

¿Cómo establecer un proceso eficaz de gestión de proyectos en condiciones en las que no se puede hacer "lo correcto" y "lo que es mejor", pero aún hay que hacerlo? El artículo proporciona una descripción general del uso de JIRA para administrar un proyecto de desarrollo de software en interés de un gran cliente gubernamental. Me alegrará si los enfoques descritos le ayudarán personalmente a aumentar la efectividad de su equipo y reducir la tensión en el proyecto. Cualquier crítica es bienvenida.

Fuente

Hijo de errores difíciles

A juzgar por la gran cantidad de artículos modelo en Internet sobre cómo aplicar adecuadamente los sistemas de gestión de proyectos en el desarrollo de software, este es un negocio simple y agradecido. Sin embargo, el uso real de los sistemas de control automatizado en proyectos en los que tuve la oportunidad de participar no fue tan "optimista" como cabría esperar. Hay varios casos típicos que se han encontrado en la práctica.

Las mejores opciones se redujeron al uso por parte del equipo del proyecto de uno de los muchos sistemas de seguimiento de errores. La estructura de tareas y procesos de negocio de un proyecto generalmente se desarrolla "fuera de la caja". Estos sistemas fueron utilizados principalmente por equipos de programadores y probadores. Dicha organización de desarrollo dio buenos resultados en pequeños proyectos con clientes privados, o si las tareas de los ejecutantes incluían solo soporte de garantía para el producto de software (corrección de errores detectados). Sin embargo, con el crecimiento de los nuevos requisitos, este enfoque comenzó a deslizarse. Esto se manifestó en un aumento en el tiempo dedicado a comparar los requisitos del cliente y la información almacenada en el rastreador de errores (y compilar manualmente informes integrados), así como en dividir al equipo en dos campos (programadores "buenos" y analistas "malos").

Otras situaciones se redujeron a inspiraciones "brillantes" del liderazgo, cuando, utilizando palancas administrativas, las mejores metodologías de desarrollo de software fueron "introducidas" en las actividades de los equipos de proyecto. Es cierto que estos líderes creían que sus acciones se limitaban solo al proceso de encontrar esta "bala de plata". No se molestaron con conceptos como " sprint ", " diagrama de combustión de tareas " o " diagrama de flujo acumulativo ". E incluso si se molestaban, los documentos de informes que debían formarse sobre el estado del proyecto (de nuevo manualmente) estaban conectados libremente con esta mejor metodología. Los intentos de introducir a los clientes a estos métodos llevaron al hecho de que las condiciones del proyecto no cambiaron, y a los informes anteriores se requería adicionalmente generar nuevos informes adicionales (de acuerdo con el nuevo método). Dichas contradicciones fueron especialmente pronunciadas en los proyectos de contratos gubernamentales, cuyas condiciones de organización entraron directamente en conflicto con la aplicación exitosa de Agile , RUP o PMBOK .

La apoteosis de la automatización de la gestión fue el proyecto para refinar el sistema de información a nivel federal en interés de un gran cliente estatal. Como parte de este proyecto, el propio cliente utilizó HP Service Manager y JIRA . HP Service Manager se utilizó para recopilar y analizar errores de software. Con la ayuda de JIRA, el cliente planificó las actividades de sus empleados relacionadas con la corrección de estos errores y el desarrollo posterior del sistema. La lista de estados de tareas en estos sistemas proporcionaba toda la variedad de opciones posibles para su procesamiento. Los procedimientos detallados para apoyar estas tareas, formados por la oficina de proyectos del cliente (es decir, personas que no son responsables del mantenimiento y desarrollo), se publicaron en la plataforma Confluence . A los empleados del contratista se les permitió acceder a ambos sistemas, y se les encomendó la responsabilidad de respaldar incidentes y requisitos (con pautas temporales para las tareas de procesamiento y una escala progresiva de multas). Además, se implementó una copia de JIRA en el sitio del contratista, con la ayuda de la cual se planeó operar el equipo del proyecto. La sincronización de las actividades de los tres sistemas se llevó a cabo manualmente (para esto tuve que mantener una "hoja" en Excel, en la que se anotaba la relación de las tareas y su estado actual). Además, los informes que JIRA generó no se adaptaban a la administración, y por lo tanto el equipo del proyecto tuvo que proporcionar informes por hora sobre sus actividades, que también crearon manualmente en Excel. La situación no era infrecuente cuando el jefe del equipo de desarrollo o el jefe de los grupos de apoyo "colgaban" en el trabajo hasta altas horas de la noche, generando informes resumidos sobre el estado del proyecto basados en los resultados del equipo del proyecto. Este proyecto se completó con éxito a tiempo y fue recordado, excepto por una baja productividad récord, un mayor número de crisis nerviosas, agotamiento profesional rápido y, a juzgar por las bonificaciones de los empleados "sobrevivientes", márgenes inesperadamente bajos. Después de tales proyectos, el pensamiento nos persigue durante mucho tiempo: "Si creamos herramientas que faciliten enormemente la vida de los clientes, ¿por qué, debido a esas herramientas, empeoramos nuestras vidas de manera tan sofisticada?"

Características del desarrollo nacional.

Resumiendo la experiencia, podemos concluir que los mayores problemas con la automatización de la gestión del desarrollo de software ocurrieron en proyectos para órdenes estatales.

Fuente

Además, los repetidos intentos de resolver estos problemas de acuerdo con las mejores prácticas de desarrollo de software llevaron a la conclusión: estos no son problemas, sino condiciones inevitables para la implementación del proyecto para el cliente estatal. Un análisis de varios proyectos nos permitió identificar los siguientes rasgos característicos generalizados de tales condiciones:

a menudo los requisitos iniciales de las especificaciones técnicas se formulan vagamente, el cliente invierte en estos requisitos todos los nuevos significados a medida que se desarrolla el proyecto (que está asociado, entre otras cosas, con un cambio en el marco regulatorio actual que rige los procesos comerciales automatizados);
el rango de requisitos registrados en los términos de referencia varía desde "corregir la inscripción" hasta "implementar un subsistema para el monitoreo y análisis de todos los procesos", mientras que todos los requisitos deben implementarse incondicionalmente (por regla general, no se aceptan propuestas para refinar la redacción, solo puede influir en algunos límites en el método de implementación);
a veces el cliente, al no tener idea de cómo resolver el problema, "empuja" estos problemas al contratista, incluidos los requisitos que son, por decirlo suavemente, "esotéricos" (algo así como "... el subsistema debe proporcionar un pronóstico para el tipo de cambio de las principales monedas para a corto, mediano y largo plazo ... ");
en el caso de que el contrato esté relacionado con el refinamiento del sistema existente, el cliente requiere la introducción de componentes individuales antes de la operación de prueba con la garantía de la operación ininterrumpida de todo el sistema (se puede comparar con el refinamiento del motor del automóvil sobre la marcha);
el cliente está representado por varias unidades (organizaciones), cuyos requisitos a menudo son contradictorios;
el presupuesto y los plazos para el proyecto permanecen sin cambios, a pesar del cambio y la adición de requisitos;
los clientes no buscan cooperación con los desarrolladores (la cooperación se basa en el principio de "primero hágalo, y luego ya veremos"); los representantes de los clientes evitan la responsabilidad de tomar decisiones con respecto a la especificación de requisitos, se ignora el momento de la coordinación de los problemas problemáticos, es inútil requerir coordinación antes de que comience el desarrollo, porque el hecho de que el equipo no cumpla con los plazos no le concierne al cliente (es decir, estos son nuestros problemas como artistas);
por un lado, el cliente requiere el cumplimiento exacto de todo el paquete de documentación con los requisitos formales de GOST, por otro lado, el desarrollo de instrucciones adicionales para usar el producto para resolver problemas particulares.

Como regla general, todos estos factores provocan la indignación del equipo del proyecto con respecto a los "clientes inadecuados" y la "mala gestión del proyecto". Sin embargo, dada la objetividad y la repetibilidad de las condiciones anteriores, las quejas del equipo del proyecto sobre la "complejidad" del cliente estatal son similares a las quejas del equipo del barco sobre el frío y la oscuridad de la noche polar, después de que la compañía naviera ganó una gran licitación para el transporte a lo largo de la Ruta del Mar del Norte .

Además de las condiciones externas, como resultó, los equipos de empleados involucrados en el proyecto de software comparten las características características comunes.

El núcleo del equipo del proyecto puede consistir en 5-12 empleados: gerente de proyecto, analistas, evaluadores, escritores técnicos, programadores. A pesar del hecho de que algunos empleados a veces pueden desempeñar varios roles, por regla general, estos equipos de proyecto se caracterizan por un bajo " factor de bus ". Esto en sí mismo también impone restricciones en el uso de métodos ágiles (por ejemplo, es poco probable que el uso de la programación de póker en tales condiciones sea útil).
El equipo del proyecto, junto con los procesos de desarrollo de software, debe proporcionar simultáneamente soporte de garantía (corrección de errores de software) y soporte extendido (finalización operativa de módulos individuales del sistema para los cambios actuales en los procesos comerciales del cliente).
Como parte del desempeño de tareas individuales, participan empleados de departamentos adyacentes de la compañía, así como subcontratistas (compañías externas impuestas por el cliente), para las cuales las tareas del proyecto son generalmente de prioridad secundaria.

Victoria de la esperanza

El segundo matrimonio es la victoria de la esperanza sobre la experiencia de la vida.
Samuel Johnson

Hace dos años, fui invitado como analista líder a un proyecto llevado a cabo por LANIT por orden del gobierno. El equipo del proyecto se formó anteriormente, el proyecto consistió en un refinamiento sustancial del sistema automatizado que existe desde hace más de una década. En general, las condiciones del proyecto fueron las descritas anteriormente. En ese momento, el equipo de desarrollo no utilizó ninguno de los sistemas de gestión de proyectos existentes en su trabajo (aunque casi todos los empleados participaron en proyectos donde se utilizaron dichos sistemas y tenían una opinión bastante escéptica sobre la necesidad de automatizar la gestión). Sin embargo, la situación inicial actual brindó la oportunidad de probar la automatización de la gestión de proyectos "desde cero".

JIRA fue elegida como la plataforma de automatización. Una combinación de los siguientes factores contribuyó a esta elección:

la capacidad de registrar relaciones entre tareas de muchos a muchos;
flexibilidad de configuración para la versión en caja;
guardar el historial de todos los cambios en el proyecto;
arquitectura parcialmente abierta, la posibilidad de refinamiento a sus propias necesidades;
la capacidad de interactuar con sistemas externos que ya han sido utilizados por el equipo del proyecto (SharePoint, Git, SVN, etc.);
la capacidad de usar en su servidor (para proyectos cerrados);
la presencia en la unidad de un empleado que tiene una experiencia significativa en la administración de este sistema y está interesado en unificar su aplicación.

Históricamente, la versión 6.4 de JIRA se utilizó para el trabajo, sin embargo, los elementos individuales de las soluciones que se implementaron en esta versión en nuestro proyecto aparecieron parcialmente en las nuevas versiones de JIRA listas para usar (lo que indirectamente confirmó la exactitud de las decisiones tomadas).

La automatización de la gestión de proyectos inicialmente persiguió los siguientes objetivos:

mejorar la calidad del sueño de los empleados del equipo del proyecto (como saben, una persona descansada trabaja de manera mucho más eficiente);
asegurar una distribución transparente de la responsabilidad por la implementación de las tareas del proyecto;
proporcionar "subprocesamiento múltiple" del equipo del proyecto, es decir paralelizar el trabajo siempre que sea posible;
para proporcionar una formación automática del estado actual de las cosas con respecto a la implementación de cada uno de los requisitos del cliente;
proporcionar monitoreo del estado actual del proyecto, permitiendo identificar problemas y riesgos del proyecto en las primeras etapas;
para formar enfoques unificados para la contabilidad, métodos para evaluar y comparar el estado de varios proyectos de desarrollo de software (similar a los servicios de Google Analytics o Yandex.Metrica , que le permiten evaluar cualquier sitio con los mismos indicadores);
para aumentar la precisión de la estimación del tiempo de las tareas, en función de las estadísticas recopiladas.

Para evitar la "automatización para la automatización", las siguientes consideraciones (limitaciones) también se tuvieron en cuenta al diseñar un modelo de contabilidad de datos en JIRA:

La automatización de la gestión de proyectos no debería molestar al equipo del proyecto. Teniendo en cuenta la experiencia negativa previa en la automatización de la gestión de proyectos, uno de los factores clave de implementación fue la creación de tales condiciones que cada empleado del equipo del proyecto percibió JIRA no como una carga adicional en el barco del proyecto, sino como un sistema de navegación colectiva que notificará al equipo de manera oportuna sobre un peligro inminente y ayudará a lograr el objetivo proyecto de la manera más corta y segura. Además, el uso de este sistema de navegación debería facilitar la vida de todos los miembros del equipo, y no solo la gestión del proyecto. Para hacer esto, inicialmente el procedimiento para trabajar con JIRA se planificó teniendo en cuenta la minimización de la cantidad de datos registrados por programadores, evaluadores y escritores técnicos. Por otro lado, el objetivo era crear un ambiente de trabajo cómodo en JIRA para todos los empleados del proyecto, lo que les ayudaría a garantizar una planificación efectiva de su jornada laboral.

Garantía de continuidad. Uno de los objetivos de la automatización de la gestión de proyectos es garantizar la continuidad para que cualquier empleado calificado pueda "asumir" las tareas de un miembro del equipo que se retira sin un "período de prueba" y con un mínimo dolor de cabeza, de modo que "el escuadrón no note la pérdida de un luchador". En este sentido, recordé un caso que uno de los clientes me contó. Una vez que se quedó para el jefe, quien, después de irse de vacaciones, le dijo la contraseña de su computadora con una réplica: "Bueno, todo está claro allí, lo descubrirás si algo sucede ...". Este empleado pasó varias noches sin dormir comprendiendo el contenido de varias carpetas con los nombres "xxxxx1", "xxxxx11" y "xxxxx111" (los nombres de las carpetas se han cambiado en aras de la decencia). La prevención de tales situaciones requiere el registro de los resultados del trabajo de todos los empleados del equipo del proyecto, incluido el gerente del proyecto, con JIRA.

Minimalismo El objetivo de la automatización de la gestión de proyectos no era calcular, dentro de un minuto, cuánto tiempo pasaba un empleado trabajando para resolver las tareas que se le asignaron, sino garantizar que las tareas con una calidad determinada se resolvieran en el tiempo requerido. Por lo tanto, al implementar un proyecto en JIRA, se adoptó el principio de minimizar los datos registrados en el sistema. Es decir el conjunto de parámetros registrados en el sistema de control debería haber sido mínimamente necesario para tomar decisiones informadas ("La perfección se logra no cuando no hay nada que agregar, sino cuando no hay nada que eliminar "). Se entendió que el modelo adoptado de automatización de gestión de proyectos debería funcionar en condiciones de alta incertidumbre e inconsistencia (por ejemplo, puede conocer la fecha del documento, pero no conocer su número y viceversa). Al escribir la información registrada, utilizamos, cuando fue posible, la regla de Miller , que establece que el número óptimo de tipos (estados) debe estar dentro de "siete más o menos dos" (lo que simplifica enormemente la comprensión del trabajo del sistema por parte de los empleados). Entonces, por ejemplo, al diseñar el ciclo de vida de las tareas (flujo de trabajo), inicialmente se supuso que el número de estados debería cumplir con esta regla.

Consistencia La automatización de la gestión del proyecto debe contribuir a la coherencia y coherencia de las acciones de todos los empleados del equipo del proyecto (evitando la situación de "cisne, cáncer y lucio").

En uno de los proyectos en los que participé, un equipo de analistas desarrolló un modelo de actividad automatizada en notación IDEF0 en un mes. Parecía que el uso mismo de la metodología creada por la Fuerza Aérea de los EE. UU. (!) Garantizaba el éxito de este enfoque. Sin embargo, cuando el jefe del departamento de programación estudió el informe analítico de varias páginas, su primera pregunta fue: "Entonces, ¿qué es exactamente lo que hay que hacer?". El modelo generado resultó ser inadecuado para su uso como descripción del enunciado del problema para los programadores. Los representantes del cliente lo admiraron varias veces, hojeando numerosos esquemas, pero tampoco encontraron la aplicación de este modelo para optimizar sus actividades. Al final, estos esquemas adornaron la descripción de los procesos tecnológicos, dando a este documento un grosor y solidez sin precedentes, pero el efecto positivo del análisis se agotó en esto. Los resultados del mes de trabajo de varios analistas fueron prácticamente no reclamados por el proyecto.

Dada esta experiencia, en la automatización de la gestión de proyectos, se suponía que se crearía un único transportador de tareas que garantizaría una conversión coordinada de los requisitos del cliente en un producto de software final de la manera más corta posible y a un costo mínimo. Al mismo tiempo, sobre la base del monitoreo de los parámetros disponibles de este transportador, se suponía que debía identificar, medir y desarrollar las propiedades emergentes del equipo del proyecto, por lo que era posible juzgar el estado del proyecto en todas sus etapas.

Tablero Kanban al revés

En mi opinión, el éxito de la automatización de control depende en gran medida de la precisión con que se modela el objeto de control en un sistema automatizado.Como se suponía que automatizaría la gestión del proceso de creación de software, se llevó a cabo un análisis de este proceso. En mi opinión, el proceso de crear módulos de software separados siempre representa el ciclo de vida clásico de la cascada en cascada. Primero, aparece una lista de requisitos para el producto creado. Los requisitos pueden provenir de diferentes fuentes y tener diversos grados de detalle. Algunos de los requisitos están interconectados, otra parte es relativamente independiente. Para requisitos individuales, puede formular inmediatamente una tarea de desarrollo, mientras que otros requieren aclaración y concreción. Es decirsiempre hay trabajos relacionados con la recopilación, clasificación y aclaración de los requisitos del cliente (mientras que la redacción de los requisitos individuales puede ser ambigua hasta el final del proyecto). Una vez que los requisitos son lo más específicos posible, por regla general, se forman las llamadas definiciones de tareas para grupos de requisitos interconectados, que detallan los detalles de la implementación de estos requisitos y son el material de origen para que los programadores comiencen a trabajar. Después de la programación, los módulos creados se prueban de forma autónoma, se integran en el sistema y se vuelven a probar. Según las actualizaciones de software completadas, se realizan los cambios apropiados en el diseño y la documentación operativa, después de lo cual se llevan a cabo una serie de actividadesdestinado a reconocer el cumplimiento de las aspiraciones (requisitos) del cliente y la posterior implementación de la funcionalidad desarrollada en la operación comercial.

Fuente

La principal diferencia entre la vida real y el hermoso esquema de cascada es su aleatoriedad (todo sucede no en etapas e inconsistentemente). En realidad, la transición de una fase de desarrollo a otra no necesariamente ocurre solo después de la finalización completa y exitosa de la fase anterior. La cascada real tiene sus propios remansos de contradicciones, remansos y aguas poco profundas de indiferencia, pantanos de verborrea, rápidos y remolinos de ambigüedad, rápidos y piedras resbaladizas de imaginación desenfrenada y, a menudo, fuentes e incluso géiseres de nuevos requisitos. No es posible rehacer este elemento dentro del marco del proyecto, así como es imposible para el equipo del barco rehacer el río a lo largo del cual es necesario asegurar la entrega de la carga del cliente.

Para la transparencia de la distribución de responsabilidades en la automatización de la gestión de proyectos, se implementó el principio "1 tarea - 1 ejecutor". Es decirEl proceso de completar una tarea obviamente no implicaba su transferencia a otros artistas. Este principio permitió aplicar el mismo proceso de negocios a todo tipo de tareas, ya que el estado del trabajo se determinó principalmente desde el punto de vista del ejecutor de esta tarea. El flujo de trabajo estándar de JIRA se ha modificado ligeramente. El cambio principal fue la sustitución del estado "redescubierto" por el estado "pendiente", es decir indica cuándo se suspende el trabajo en una tarea por cualquier motivo. Para registrar tareas redescubiertas, se ha utilizado el campo de usuario "Contador de redescubrimiento". Al mismo tiempo, los tipos de razones para la transferencia de tareas estaban pendientes, en espera de una solución:

coordinación con el cliente;
solicitud de información adicional del cliente;
esperando la solución de tareas / subtareas relacionadas;
Se requiere una aclaración del enunciado del problema.

Cabe señalar que la introducción del estado "en espera" en realidad implementó el " botón de parada del transportador " para los empleados del equipo del proyecto , lo que a su vez aseguró la identificación colectiva de los problemas en las primeras etapas del proyecto.

Como resultado del análisis, se implementó el siguiente modelo para registrar la información del proyecto con JIRA. El enfoque estándar para compartir tareas que JIRA representaba no se utilizó en el proyecto. Se crearon seis tipos de tareas, que en esencia correspondían a las etapas principales del desarrollo de software:

"Requisito" : tipo de tarea para registrar los requisitos del cliente (similar en las nuevas versiones de JIRA - épica);
«» – , ( ) ( ) ( JIRA – story);
«» – ;
«» – , ;
«» – , ;
La "implementación" es el tipo de tarea para registrar los resultados del trabajo destinado a introducir el software desarrollado en las actividades del cliente (realizar pruebas, demostraciones, liberar una versión / parche / corrección de datos, implementar software en los servidores del cliente, capacitar a los usuarios, etc.).

Las subtareas se utilizaron para resolver problemas particulares (el tiempo que no excede las dos horas) durante la ejecución de la tarea principal (por ejemplo, coordinar una decisión de diseño con un programador o gerente de proyecto, realizar revisiones de códigos, preparar datos de prueba, etc.).

De acuerdo con las reglas establecidas en el proyecto, el registro de un requisito es una base obligatoria para planificar otras tareas. Después del registro del requisito y su aclaración con el cliente (si es necesario), se forman otros tipos de tareas, destinadas a implementar este requisito. En otras palabras, dentro del marco del modelo adoptado, otras tareas siempre deben estar asociadas con el requisito en interés de los cuales se cumplen (utilizando el tipo de conexión "causa" -> "acción"). En aras de implementar un requisito, se pueden crear varias tareas de desarrollo, por otro lado, se puede crear una tarea (para análisis, desarrollo, prueba, documentación, implementación) en interés de varios requisitos (en contraste con el enfoque estándar de JIRA, cuando se suponeque una tarea solo puede asociarse con una tarea de tipo épico). Dentro del marco del modelo propuesto, también es posible relacionar otras tareas dependientes. Por un lado, este enfoque garantizaba la coherencia de las decisiones tomadas, por otro, brindaba la posibilidad de un reflejo bastante exacto del estado real de las cosas en el proyecto. En este caso, es posible una variedad de opciones para organizar el trabajo, para entender la confusión de lo que parece muy difícil.

Los métodos para reflejar las tareas encontradas en JIRA no proporcionaron una visión conveniente del estado del proyecto en su conjunto (dada la variedad de complementos, tal vez simplemente no tuvimos tiempo suficiente para encontrar el que se necesitaba). Por lo tanto, para simplificar el trabajo con el modelo propuesto para registrar tareas, se creó nuestro propio tablero de instrumentos (al final, el zapatero debe poder coser las botas por sí mismo). El tablero creado hizo posible mostrar el estado de las tareas en el proyecto desde el punto de vista de implementar cada requisito por separado.

El tablero creado, a primera vista, era ligeramente diferente del tablero Kanban clásicoSin embargo, en nuestro caso, las columnas no significaban el estado de las tareas, sino su tipo. En este panel, se formó una línea separada para cada requisito, en la que todas las tareas relacionadas con este requisito se agruparon por actividad (en la secuencia clásica de cascada). Si la tarea se creó en interés de cumplir varios requisitos, entonces la tarjeta de esta tarea se repitió en cada una de las líneas de requisitos relacionados. El estado de las tareas se reflejó en este panel con el color que creó la "tercera dimensión". El grado de preparación del requisito se determinó en este caso por la preparación de todas las tareas asociadas con este requisito. Resultó como un tablero Kanban al revés. Por otro lado, desde la posición del PMBOK,el panel generado era una versión mejorada de la clásica Matriz de trazabilidad de requisitos.

Para mostrar el estado de las tareas, se adoptó el siguiente esquema de color:

azul: la tarea se incluye en el plan de trabajo;
azul: la tarea está en progreso;
rosa: la tarea no tiene ejecutor;
amarillo: la tarea está pendiente, requiere una solución;
gris: la tarea está cerrada (puede olvidarse de ella);
naranja: se interrumpieron los plazos para completar la tarea.

La aparición de inscripciones y marcas rojas en la tarjeta de tareas indica la necesidad de una acción inmediata en relación con la tarea (por ejemplo, la inscripción se muestra en rojo si no se ha establecido la fecha límite).

Además de los colores, a medida que se desarrolla el proyecto, las tarjetas de tareas en el tablero están rodeadas de etiquetas adicionales que le permiten evaluar de un vistazo el estado del trabajo en el proyecto.

Etiquetas de prioridad:

- Normal;

- importante

- crítico

- bloqueo

Etiquetas sobre el marco de requisitos:

- desarrollo (requisitos dentro del marco de proyectos destinados a una revisión sustancial de los sistemas existentes);

- soporte ampliado (requisitos para la finalización operativa de módulos de sistema individuales para los cambios actuales en los procesos comerciales del cliente);

- soporte de garantía (errores de software detectados);

- actividades ajenas al proyecto (requisitos del director del proyecto relacionados con actividades previas al proyecto, refactorización , preventa , desarrollo de nuevas tecnologías, capacitación del personal, etc.).

Etiquetas del motivo de la expectativa:

- solicitud de información adicional del cliente;

- coordinación con el cliente;

- esperando la solución de tareas / subtareas relacionadas;

- Se requiere una aclaración de la formulación.

Etiquetas especiales:

- la base de datos se ha finalizado en la tarea;

- el número de requisitos relacionados con la tarea (cuanto más requisitos relacionados, más importante es la tarea);

- el número de subtareas no resueltas;

- la tarea se redescubre.

De hecho, este panel se ha convertido en la herramienta principal para recibir diariamente una respuesta a la pregunta sobre la gestión de proyectos: "¿Qué es lo más importante hoy?", Lo que a su vez nos permitió responder de manera oportuna a los problemas. Desde la perspectiva del modelo propuesto, para evitar problemas en el proyecto, es necesario asegurar una reducción diaria en la cantidad de rojo, naranja y amarillo en el tablero propuesto. Por otro lado, un motivo de preocupación también fue la falta de tareas relacionadas para el requisito (es decir, la situación en la que el requisito está planificado y no hay trabajo para implementarlo).

El uso de filtros para el tablero creado permitió en el complejo reflejar el estado de las cosas de acuerdo con la lista de requisitos seleccionada. Con su ayuda, fue posible coordinar rápidamente las acciones de todo el equipo del proyecto, enfocando los esfuerzos en las áreas más problemáticas, sin perder una imagen holística del proyecto.

La cascada no puede ser ágil

Para registrar los resultados del trabajo en todo tipo de tareas, se desplegaron dos repositorios (para la documentación del proyecto y para el código del software). Agregar (cambiar) materiales en estos repositorios se reflejó automáticamente en las tareas relacionadas de JIRA y fue el principal tipo de informes de los artistas intérpretes o ejecutantes.

La organización del trabajo utilizando el enfoque propuesto para registrar tareas en JIRA se redujo al siguiente esquema.

JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
, . , , , . () .
, , . , , ( ), () , , , ( ).
( ) , , . . , . «» , ( ).
Idealmente, las tareas de prueba deben formarse antes de registrar las tareas de desarrollo (que especifica los objetivos de los programadores). Durante la prueba, el probador responsable no solo mantiene un registro de los errores detectados, sino que también corrige las imprecisiones detectadas en la tarea de prueba y en el manual del usuario.
De acuerdo con los requisitos, de acuerdo con los cuales se planificó una lista completa de trabajos, se forman tareas de implementación (durante el registro de las cuales la prioridad y los plazos para la implementación de los requisitos se especifican nuevamente en JIRA).
Después de la entrega al cliente, la solicitud puede transferirse al estado "cerrado" con la indicación obligatoria de los detalles del documento de aceptación.

Cabe señalar que la formación de tareas de todo tipo para la implementación de un solo requisito no es un requisito previo para una planificación exitosa. Por ejemplo, un requisito simple como "corregir un error en un nombre de campo" puede asignarse directamente a un programador. Al mismo tiempo, durante la implementación del proyecto, se observó que la mayor parte de los comentarios durante las pruebas preliminares y la operación de prueba tuvieron en cuenta los requisitos para los que no se formaron las decisiones de diseño.

En el marco del enfoque propuesto, la planificación del trabajo utilizando el método de planificación Rolling Wave ha demostrado su eficacia. Al mismo tiempo, en parte debido al tablero descrito anteriormente, fue posible evitar la fragmentación e inconsistencia de los trabajos planificados. En las etapas iniciales de registro, la selección de acuerdo con los requisitos se parecía a un paraguas rojo , cuando para la mayoría de los requisitos no se determinaron las fechas de disponibilidad y los ejecutivos responsables, y el trabajo se planificó solo para una pequeña parte de ellos. Sin embargo, el tablero de requisitos se convirtió gradualmente en una alfombra azul-verde. Las manchas rojas y naranjas que aparecen en esta alfombra nos obligaron a realizar ajustes diarios a las tareas previstas, lo que ayudó a reducir los riesgos del proyecto.

El modelo de organización de datos propuesto mostró buena escalabilidad. Inicialmente, solo tres empleados del equipo del proyecto (un analista y dos programadores) usaron JIRA en su trabajo, mientras que se registraron los requisitos para subsistemas individuales. Sin embargo, al final del proyecto, el 100% de los requisitos de desarrollo y soporte extendido se registraron y monitorearon en JIRA con la participación de todos los empleados del equipo del proyecto.

A pesar de que la idea de la automatización de la gestión de proyectos se basaba en un modelo de desarrollo en cascada (cascada), resultó que, en el marco del enfoque propuesto, si se desea, los elementos ágiles se pueden usar sin problemas. ¿Y quién, en general, dijo que la cascada no es flexible? Por ejemplo, para aplicar Scrum , en el marco del modelo propuesto, es suficiente para garantizar la regularidad de los eventos (tareas) para la implementación del software, y luego, en consecuencia, todo el trabajo asociado con este evento será "obligado" a obedecer las reglas de sprint establecidas de esta manera.

Además, el método propuesto para registrar tareas no limita al gerente del proyecto al aplicar el enfoque Kanban y al usar toda la variedad de paneles Agile que JIRA ofrece "listos para usar".

Para continuar

Cual es el resultado? El software desarrollado se ha puesto en operación comercial. Durante las pruebas preliminares, la operación de prueba y las pruebas de aceptación, el cliente registró muchos comentarios sobre el producto de software implementado. Sin embargo, posteriormente, sobre la base de los materiales para aclarar los requisitos almacenados en JIRA, el cliente se vio obligado a reconocer el 25% de los comentarios como nuevos requisitos que iban más allá del alcance del proyecto (la complejidad planificada de cumplir estos requisitos era acorde con la tarea técnica completada). Los problemas asociados con la implementación del contrato para las órdenes estatales no desaparecieron, sin embargo, monitorear el cumplimiento de los requisitos utilizando JIRA hizo posible identificar los riesgos de interrupción en la etapa de inicio y responder rápidamente a ellos. Esto, a su vez, aseguró la dinámica positiva del proyecto en todas sus etapas, a pesar de las peculiaridades del desarrollo de software nacional. Se observó que si los requisitos del cliente se registraban con JIRA y se formaban tareas de análisis, desarrollo y prueba sobre ellos, entonces había mucho menos desacuerdos y disputas con respecto a dichos requisitos.

En la etapa actual (etapa de mantenimiento), todos los requisitos se reflejan en JIRA. Todos los empleados del equipo del proyecto de una forma u otra usan JIRA en su trabajo. El costo de los programadores para registrar los resultados de su trabajo en JIRA toma menos del 1% de su tiempo de trabajo. Para los analistas, por el contrario, JIRA se ha convertido en una de las principales herramientas de trabajo. Encontrar un conjunto completo de información para cualquiera de los requisitos del cliente es menos de un minuto. Los documentos de informes basados en los resultados del trabajo realizado se generan automáticamente en función de los datos contenidos en JIRA. Además, en base a estos datos, se forma la documentación que acompaña a las versiones (una lista de cambios y un programa de prueba de versiones).

Dos años de experiencia aplicando JIRA bajo las nuevas reglas han confirmado viejas verdades:

JIRA no reemplaza la gestión de proyectos, pero ayuda a navegar rápidamente por el flujo de diversas tareas;
JIRA lo ayudará a enfocar su proyecto en el lugar correcto en el momento correcto, pero no lo hará por usted;
JIRA no resolverá los problemas del proyecto para usted, pero ayudará a identificarlos ya en las primeras etapas (al mismo tiempo, identificará los problemas que esperaba ocultar);
Como cualquier sistema automatizado, JIRA lo ayudará a implementar rápidamente cualquiera de sus decisiones, sin importar si es bueno o malo;
JIRA no reemplaza la comunicación de los empleados del equipo del proyecto, pero ayudará a resolver las disputas sin dolor;
JIRA no salvará a un empleado del despido, pero ayudará a otro, que ha tomado el lugar del jubilado, a informarse rápidamente;
JIRA ayudará a generar documentos de informes del proyecto, pero solo sobre la base de la información para la que proporcionó el registro.

Y lo más importante: JIRA no decidirá por usted si usará su ayuda o no.

Empleos LANIT para interesados