JIRA: reglas para la preparación oportuna de software delicioso. TLDR 1: límites de oportunidad

Anteriormente en el artículo " JIRA como remedio para el insomnio y las crisis nerviosas ", se propuso una opción para usar JIRA para administrar un proyecto de desarrollo de software en interés de un gran cliente estatal. Sin embargo, el manejo descuidado de la automatización del control en la "cocina digital" no solo puede estropear el producto, sino que también puede provocar numerosas lesiones. En una serie de artículos titulados "Reglas para la preparación oportuna de un software delicioso", se propone estudiar en detalle las reglas para organizar el trabajo en un proyecto de software utilizando un catalizador llamado JIRA. Cualquier crítica es bienvenida.

Fuente

Secretos generales

La inteligencia es la capacidad de evitar hacer el trabajo, pero para que se haga.
Linus Tordvalds

Después de la publicación del artículo " JIRA como remedio para el insomnio y las crisis nerviosas ", varios ejecutivos se interesaron en nuestra experiencia en el uso de JIRA y decidieron introducir un esquema de automatización de gestión similar en sus proyectos. Por lo tanto, como resultado de escribir este ensayo, se suponía que simultáneamente "atraparía algunos conejos":

- considerando secuencialmente cada tipo de tareas JIRA como un subproceso del proyecto, durante la presentación:

• unificar las especificaciones de estos subprocesos;
• estandarizar las reglas de negocios para el trabajo organizado;
• para compilar mapas de "trampas" típicas y lugares que requieren "camas de paja" anticipadas;
• Determinar indicadores de rendimiento medibles y alcanzables para cada tipo de tarea.

- formular una declaración del problema para el administrador de JIRA para desplegar nuevos proyectos de acuerdo con el enfoque propuesto;
- obtener regulaciones informales, pero no obstante, comprensibles y transparentes sobre la distribución de responsabilidades de todos los empleados de los equipos de proyecto;
- formalizar las mejores recetas encontradas durante la solución de situaciones problemáticas ("trucos de la vida" del gerente del proyecto);
- Identificar debilidades previamente no notadas del enfoque propuesto durante la discusión de los detalles de su implementación con los lectores de Habr.

Me gustaría señalar de inmediato: algunas de las técnicas descritas han demostrado su eficacia en una de las cocinas digitales LANIT para la gestión de proyectos para el desarrollo y mantenimiento de software personalizado en interés de un gran cliente estatal. Sin embargo, no es un hecho que estas recomendaciones sean igualmente útiles en su proyecto. Por otro lado, estamos entrando en terra incógnita. Algunas de las consideraciones expresadas solo están planificadas para su implementación. Por lo tanto, si ve debilidades en el enfoque propuesto o hay propuestas constructivas para la optimización, bienvenido a la discusión en los comentarios.

Se supone que después de que la unificación se lleve a cabo en interés de diferentes líderes, la tecnología de control descrita se aplicará con éxito a proyectos de software de diferentes orientaciones y escalas diferentes. A su vez, el uso de un único espacio conceptual al registrar las tareas de JIRA crea los requisitos previos para la evaluación automatizada del estado actual de las cosas en el marco de la cartera de proyectos . Además, se supone que un enfoque unificado para registrar los resultados del trabajo en JIRA simplificará la movilidad de los empleados entre varios grupos de proyectos, lo que a su vez también contribuirá a aumentar el éxito de los proyectos.

Límites del proyecto

Cualquier tarea difícil tiene una solución simple, fácil de entender e incorrecta.
Arthur Bloch

Dado que el algoritmo de aplicación JIRA propuesto comenzó a "extenderse" a otros proyectos, fue necesario repensar la pregunta: "¿Qué determina exactamente los límites de un proyecto de software en JIRA?"

Según los seguidores del PMBoK sin nubes, la respuesta a esta pregunta es elemental: "Por supuesto, los límites del proyecto están determinados por la carta (pasaporte) del proyecto ". Desde este punto de vista, para cada contrato con el cliente, se debe formar un proyecto separado en JIRA. Además, a menudo el desarrollo de un paquete de software puede incluir varias áreas de actividad, dentro de las cuales, por regla general, se celebran varios contratos:

• desarrollo: requisitos de los contratos para la creación de nuevos sistemas (subsistemas);
• desarrollo: requisitos en el marco de contratos destinados a una revisión sustancial de los subsistemas existentes;
• soporte extendido: los requisitos de los contratos 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: eliminación de errores de software identificados durante el período de garantía;
• Soporte básico: eliminación de errores de software identificados después del final del período de garantía.

Además, como parte de la creación del software, el equipo del proyecto debe resolver los requisitos que no están definidos en ninguno de los contratos. Estos son los requisitos del gerente de proyecto relacionados con las actividades previas al proyecto, refactorización, preventa, eliminación de errores identificados independientemente, capacitación del personal, etc.

Sin embargo, como lo ha demostrado la práctica, en el desarrollo real de un producto de software a largo plazo es difícil separar el trabajo de desarrollo y mantenimiento. La operación de prueba aún no ha finalizado (el contrato de desarrollo no está cerrado), y el cliente ya está en plena vigencia para formular requisitos de soporte extendido para los componentes del sistema que aún no se han puesto en operación comercial. El cliente puede ser entendido, porque el mundo está cambiando más rápido de lo planeado en los contratos aprobados. Al mismo tiempo, la identificación de nuevos defectos de software continúa. Y al usuario que descubrió el defecto no le importa en absoluto bajo qué contrato se debe corregir este error. Desde su punto de vista, simplemente no debería haberlo sido. Para atribuir el error identificado a uno u otro contrato, lleva tiempo analizarlo, y si los proyectos JIRA se dividen sobre la base de los contratos, surge un dilema : "¿Y en qué proyecto JIRA debe registrarse este defecto?". Además, es necesario organizar la transferencia de tareas de un proyecto a otro, si se cometió un error de clasificación. Si todos los defectos identificados en el software se asignan a un proyecto separado del equipo de soporte, los riesgos de problemas surgen al resolver problemas de pago por el trabajo en la etapa del contrato de desarrollo o al revisar las quejas sobre el incumplimiento del acuerdo sobre el nivel de prestación del servicio ( SLA ).

Por otro lado, los jefes de departamentos celosos proponen que, dentro del marco del proyecto, se creen proyectos separados para el equipo de soporte, el departamento analítico y el departamento de desarrollo y pruebas. Todos quieren ser un maestro de pleno derecho en su diócesis y no ser responsables de los "bajíos" de los vecinos. Además, la sorprendente flexibilidad de JIRA le permite crear conexiones entre las tareas de diferentes proyectos.

Fuente

En mi opinión, los enfoques anteriores para registrar proyectos en JIRA son similares a tratar de cocinar una sopa en varias ollas ubicadas en diferentes cocinas. El objetivo principal del proyecto es la creación oportuna de un producto de software de una calidad dada. Desde el punto de vista del cliente, la calidad del producto está determinada por el conjunto de capacidades funcionales de este producto, mediante el cual el cliente puede resolver sus problemas de manera segura (es decir, confiable). Y no le importa al cliente funcional final bajo el cual las relaciones contractuales se creó la funcionalidad requerida. Así como no es importante que el piloto conozca la lista de subcontratistas involucrados en la creación de su avión.

Con esto en mente, definir los límites de un proyecto JIRA debería garantizar la armonía entre las siguientes dos consideraciones.

1. Es necesario que el proyecto refleje todo el trabajo que se realiza durante la creación / modificación del producto de software (o su subsistema). El proyecto debe considerarse como un proceso único para la creación de un producto de software (un "avión"). Por lo tanto, el principio principal: un producto de software, un proyecto JIRA. Es importante no olvidar lo que produce su empresa: un "avión" o un "motor para aviones". En cualquier caso, los creadores de software no deben ser alienados de las consecuencias de sus decisiones.
   
   Independientemente del tipo de relación contractual con el cliente, el punto de entrada al proceso de creación de un producto de software es cualquier requisito para su modificación. El evento final es la recepción de la confirmación del cliente de que este requisito se ha implementado (o declarado insolvente). Esta regla es la principal para evaluar la integridad de la planificación y la integridad de las tareas en el proyecto JIRA.
   
   Es aconsejable que el proyecto JIRA también encuentre un lugar para el trabajo auxiliar que se inició con el fin de cumplir con los requisitos del cliente. Durante el desarrollo del software, se producen muchos eventos que, por regla general, permanecen "detrás de escena": reuniones periódicas para aclarar plazos, implementar servidores de prueba, preparar datos de prueba, generar instrucciones adicionales, etc. JIRA puede ser de gran ayuda para detectar agujeros a través de los cuales el tiempo de trabajo de los empleados del equipo del proyecto fluye generosa e irrevocablemente. Pero solo con la condición de que estos trabajos se registren en el proyecto JIRA.
2. En el caso de desarrollar sistemas de software realmente grandes, no debe insertar todo en un proyecto JIRA, lo que aumenta significativamente el riesgo de interrupción. En tales casos, dentro de un proyecto JIRA separado, es aconsejable agrupar por funciones de software que brindan soporte para uno de los procesos comerciales del cliente (por regla general, dichas funciones se asignan a subsistemas separados ya en la etapa de diseño conceptual).

Fuente: Sergey Arkhipenkov. Evaluación del proyecto: charlatanería o chamanismo

Vale la pena pensar en la formación de proyectos individuales de JIRA para registrar los resultados del trabajo realizado regularmente en el marco de varios productos de software (por ejemplo, contabilizar el tiempo empleado por los empleados en estudiar nuevas tecnologías o trabajos relacionados con las copias de seguridad).

Una de las restricciones en un proyecto JIRA puede ser el número máximo de empleados del equipo del proyecto. La experiencia personal sugiere la siguiente conclusión: la composición máxima del equipo de desarrollo en un solo proyecto JIRA sigue la regla de Miller (en las mejores tradiciones de Agile). El grupo de desarrollo aquí se refiere a programadores y analistas que formulan las tareas para ellos. Y, por supuesto, el gerente del proyecto. (¡Como podría pensar! ¡Esto es sagrado!) Además, si el presupuesto del proyecto lo permite, el 80% restante de los empleados del equipo del proyecto, compuesto por amigas del equipo de apoyo, evaluadores gruñones, escritores técnicos aburridos y un administrador de sistemas divertido, puede ser incluido de manera segura y armoniosa en el proyecto. Jira.

Cómo poner tareas en los estantes

En mi ático solo hay las herramientas que necesito. Hay muchos de ellos, pero están en perfecto orden y siempre a mano.
Sherlock holmes

En cualquier proyecto, la navegación de los empleados en el flujo de tareas a resolver es uno de los componentes importantes del éxito. Sin embargo, a medida que crece el volumen del proyecto, se hace cada vez más difícil comprender este flujo, que puede convertirse, en sí mismo, en uno de los problemas de administrar un proyecto grande. Por lo tanto, la definición de un único sistema de coordenadas que todos los participantes clave puedan navegar igualmente fácilmente es una parte integral de la automatización de la gestión de proyectos.

La base de dicho sistema de coordenadas en nuestro proyecto fueron las siguientes consideraciones: un producto de software, como regla, puede ser imaginado como una caja negra que se comunica con el mundo exterior a través de tres formas principales:

• a través de la interfaz de usuario ;
• a través de documentos formados para imprimir en papel;
• mediante protocolos de intercambio electrónico de datos ( API / EDI ).

Es en el espacio de estas tres dimensiones donde los usuarios finales ven el software. Por otro lado, la creación de software está dirigida precisamente a la formación y procesamiento de estos flujos de datos.

Fuente

Además, los principales objetos de la base de datos y los procesos comerciales automatizados se adoptaron como coordenadas adicionales dentro del proyecto. Para navegar dentro de este espacio de coordenadas, se formaron clasificadores apropiados, cuyo soporte fue proporcionado por el gerente del proyecto y los analistas. Cada elemento del clasificador constaba de un código y su definición.

En el curso de mis proyectos, para cada clasificador, se revelaron gradualmente sus propias características, que deben tenerse en cuenta si decide aplicar un enfoque similar.

• En nuestro caso, los códigos de los formularios impresos no repiten la numeración de los formularios de acuerdo con los documentos del cliente. Además, los formularios individuales tenían varias opciones de impresión. Entonces, por ejemplo, a lo largo de la existencia del software, la forma de uno de los informes ha cambiado varias veces en función de los cambios en los documentos reglamentarios (el nombre y la esencia del informe no han cambiado). Al mismo tiempo, para los datos antiguos era necesario seguir imprimiendo este informe en formularios antiguos. Las mismas consideraciones se aplican a la clasificación bajo los proyectos de protocolos para el intercambio electrónico de datos.
• En la jerarquía de formularios, los elementos individuales pueden incluir paneles de navegación (menús), formularios de lista, tarjetas de objeto, pestañas, paneles de filtro, formularios de carga / descarga de datos, así como formularios de operaciones de grupo complejas.
• Es deseable "hacer crecer" los "árboles" de los procesos tecnológicos para que tengan operaciones tecnológicas atómicas (indivisibles), sobre la base de las cuales, a su vez, es posible garantizar el funcionamiento del subsistema de distribución de acceso (subsistema de seguridad).
• Dado que todos los elementos de clasificación con este enfoque se muestran en las pantallas JIRA dentro de un campo, es necesario proporcionar al menos una codificación primitiva además de los nombres de los componentes para distinguir el formulario "Registro de empleados" del proceso de "Registro de empleados".

Para aquellos que no buscan formas fáciles, las tareas JIRA pueden marcarse en función del registro de los códigos correspondientes en el campo "Componentes". Al registrar tareas de cualquier tipo en JIRA, en el campo "Componentes", solo necesita indicar la lista de códigos de objeto para los que el trabajo planificado está destinado a cambiar / formar. En función de los resultados de la resolución de cada problema, el ejecutor responsable debe aclarar la composición de los componentes (si es necesario). Los clasificadores de componentes se mantienen fuera de JIRA.

Para los amantes de la comodidad a este respecto, quizás el complemento Subcomponentes para JIRA pueda ayudar mucho .

Cabe señalar que el uso de clasificadores correctamente compilados de componentes de software estandariza implícitamente la conciencia colectiva y el lenguaje de comunicación del equipo del proyecto, lo que resulta en un aumento en el nivel general de comprensión. Por otro lado, este enfoque es uno de los métodos de coerción no violenta de los analistas para tareas más detalladas, lo que, a su vez, aumenta la precisión de la estimación del momento de la implementación de los requisitos del proyecto.

Las reglas de clasificación adoptadas para las tareas no solo reducen el tiempo dedicado a la búsqueda, sino que también proporcionan la capacidad de automatizar:

• estimaciones del aporte total de mano de obra planificada (o costos laborales reales) para trabajos destinados a la implementación de ciertos elementos de software,
• evaluación de la distribución real de prioridades: en alguna etapa del proyecto, su gerente puede sorprenderse al descubrir que la mayor parte del trabajo no se lleva a cabo en relación con los componentes prioritarios,
• Análisis de la calidad del desarrollo de la documentación .
• evaluación de la calidad de la gestión de proyectos en términos de planificación. Por un lado, no tiene sentido planificar tareas en las que los componentes no se forman (se modifican) y, por otro lado, la planificación de tareas, durante el desarrollo de las cuales cambian docenas de objetos, indica que el problema no está completamente establecido.

Al atar tareas, no ate sus manos

Al describir los principios generales de nuestro modelo , se dijo sobre el uso de un solo tipo de conexión "razón" -> "acción" (y en el marco del proyecto descrito, esta conexión fue suficiente). Sin embargo, el deseo de utilizar los mismos mecanismos JIRA para automatizar la gestión en varios proyectos diferentes requiere expandir el número de tipos de relaciones utilizadas y unificar los enfoques para su aplicación.

Fuente

JIRA "listo para usar" ofrece al usuario varios tipos diferentes de conexiones entre tareas, y el uso incontrolado de estas conexiones puede tener consecuencias tristes. Para no confundirnos a nosotros mismos y a los demás, hemos acordado las siguientes reglas básicas para el enlace de tareas JIRA.

• El cierre del mismo tipo de enlace en el bucle es inaceptable (aunque JIRA lo permite).
• Una relación adicional “Depended” (“razón” => “acción”) se usa solo para conectar tareas de diferentes tipos, y solo en la dirección de “flujo” del modelo en cascada clásico (cascada): requisito => análisis => desarrollo => prueba => documentación => implementación. Es inaceptable especificar estas conexiones en el orden inverso y vincular tareas del mismo tipo. Si nacieron nuevos requisitos durante la implementación, cuando estos requisitos se registran con JIRA, la conexión entre ellos y la tarea de implementación, durante la cual aparecieron, no se forma.
• La conexión " Bloques " ("bloques" => "bloques") se puede usar dentro de cualquiera de los tipos de tareas para construir secuencias de flujo de trabajo (por ejemplo, para componer un script de ejecución de prueba).
• La relación " Cloners " ("padre" => "niño") se utiliza solo para la comunicación de tareas del tipo "requisito". Asocia el documento original del cliente que contiene varios requisitos ("padre") con tareas que contienen requisitos atómicos "descendientes".
• La relación "Suplemento" ( Relativos ) ("complementos" => "se complementa") se usa solo para relaciones dentro del marco de tareas del tipo "requisito". Se utiliza para registrar la relación entre la tarea del requisito principal y las tareas en las que se registran los errores, comentarios y aclaraciones identificados durante la prueba. De hecho, utilizando este tipo de comunicación, se proporciona el registro del historial de cambios en los requisitos.
• La relación "Duplicar" ("duplicar" => "duplicar") se usa solo para la comunicación de tareas del tipo "requisito". Al especificar duplicados, es necesario determinar el requisito básico, dentro del marco del cual se planificará el trabajo para su implementación. En relación con los duplicados, no se crean comunicaciones con tareas de implementación.

Flujo de trabajo para todas las ocasiones.

La razón de muchos problemas es que establecemos tantas tareas como sea necesario completar, y no tantas como podamos completar.
Maxim Dorofeev

, JIRA, . , JIRA (workflow). .

. «» . , JIRA . , .

, «» «», «» ( , ).






, .
*

, :

— ;

— ;

— .


« » «» . , . «». , . «» ( ).

BPM ( business process management ), . BPM «» , :

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

PMP ITIL . , , BPM , , . BPMS . - BPM ( , , Agile ). BPM « » ( , ). «» «» ( ). «»?

BPM . , , , BPM , .

Fuente

JIRA . , JIRA , , . BPM. , JIRA BPMS. Todas estas sugerencias adicionales para usar JIRA para automatizar la gestión de proyectos de software se harán teniendo en cuenta esta consideración clave.

Uno de los primeros pasos en la escalera CMMI es identificar, documentar y unificar los procesos de la organización. Por lo tanto, como parte de la serie de artículos "JIRA: las reglas para la preparación oportuna de software sabroso", se supone que debe formular consistentemente especificaciones para todos los tipos de tareas a resolver y tratar de formular un aparato de criterios para su evaluación integral desde el punto de vista del enfoque basado en procesos. El siguiente artículo estará dedicado a las características de registro de tareas del tipo "requisito" y procesos de negocio para su implementación.