Get best of the week

Proyectos simultáneos de Ajile (bajo la cárcel) y Cascada

Existen muchos marcos ya probados y probados para organizar el flujo de trabajo, en los cuales los métodos y principios están bien descritos. Si ensamblamos un automóvil, usamos Kanban, preparamos un pastel - Lean, desarrollamos un sitio web personalizado - PMBoK. Es importante tener en cuenta que cada proyecto es único y necesita una adaptación de los enfoques, pero en general, para su caso, lo más probable es que ya haya suficientes soluciones útiles. Construyendo procesos para mí, tomé un poco de todo.

Era


Trabajó en una startup. Un producto, un equipo pequeño, no hay límites de tiempo estrictos. Usó Scrum y Kanban en su forma más pura, por así decirlo. Anotamos tareas en Trello y las arrastramos en 4 tableros: ideas, tenemos que hacerlo, en el trabajo, está listo. Para hablar sobre el progreso del trabajo, llamaban todos los días y una vez por semana planificaban tareas para el próximo sprint. Todo es como la gente tiene.

Se ha convertido


Habiendo cambiado un poco el curso del desarrollo, fui a una nueva experiencia en un estudio web. Allí, en primer lugar, le sorprendió la flexibilidad de trabajar con clientes y, si no tenía sarcasmo, la falta de un sistema.

Para mostrar el panorama general, daré un ejemplo muy simplificado.
Cliente A: Necesito desarrollar una página de destino para un evento de tal o cual fecha.
Project Manager (MP): está bien, lo haremos en una fecha determinada.
Cliente B: realice con urgencia los siguientes cambios en el sitio.
MP: OK, agregue lo antes posible.

Luego, el MP acuerda la estimación para el cliente A, escribe las tareas en el rastreador, creando proyectos separados y tableros no conectados. Le dice al equipo qué hacer. Los desarrolladores comienzan a cortar, y al finalizar, el gerente muestra el resultado a los clientes.

Las entradas en el sistema se ven así:
imagen

Problemas


El enfoque del mantenimiento es bastante lógico, pero surgen los siguientes problemas:

  • Falta de conexión visible entre las
    tareas del cliente y del equipo . Las tareas comerciales generalmente se encuentran en la tabla y se descomponen en Jira. Cuando un desarrollador escribe otro método API, para comprender quién lo usará, debe ir al administrador y aclarar nuevamente.
  • El
    diseñador de priorización incorrecto informa la finalización prematura del diseño (sí, esto también sucede). Él pregunta: ¿qué hacer a continuación? MP establece la tarea del cuarto proyecto, el primero en la lista. Al final del día, se da cuenta de que la cuarta tarea del primer proyecto fue más importante.
  • No existe una representación visual del alcance del trabajo,
    tareas en diferentes proyectos. Nadie quiere mantenerlos en la cabeza o buscar en los catálogos. Es más fácil, cuando terminé, preguntar: ¿qué hacer a continuación?
  • Distribución desigual de la carga por tiempo y por empleado
    Está claro lo que Vasya y Petya están haciendo en este momento, es más difícil decir quién estará ocupado después de 2 semanas y si sus tareas serán equivalentes.
  • Cuando se planifica el tiempo de finalización, no se tienen en cuenta las tareas de otros proyectos. Se nos
    pidió que cambiaramos el enlace en el sitio. Oh, es fácil, hagámoslo hoy. Luego, el gerente recuerda que hay errores súper críticos en otro sitio. Como resultado, el cambio en el enlace, según el cliente, el equipo se extendió durante una semana.

Quizás en este ejemplo con las ediciones y la página de inicio no parezca aterrador, ya que todo esto es fácil de tener en cuenta, pero en la práctica podría haber 5 proyectos al mismo tiempo con 40 tareas en cada uno. Muchos proyectos vinieron de otros gerentes. Los tableros, tipos de tareas, metodologías en ellos fueron elegidos de acuerdo a su estado de ánimo.

Convertir melón


Para crear un sistema, primero fue necesario llevar los datos a un solo formato. Transformando la masa de entidades transferidas a mi disposición, logré llegar al siguiente concepto:

imagen

creo que todo está claro en la imagen, pero hay pequeños matices asociados con la implementación en Jira. Analicemos cada entidad usando ejemplos.

Con el concepto de un proyecto, todo es inequívoco tanto en la mente de la comunidad como en la de Atlassian. Esta es una secuencia de acciones destinadas a obtener resultados en un tiempo limitado. Por ejemplo: para desarrollar un sitio web, para apoyar la aplicación durante todo el tiempo de vida, para crear una empresa de publicidad.

Epic (lanzamiento)- grandes piezas aisladas del proyecto: cuenta personal, cesta, catálogo de productos. Aquí los desacuerdos ya están comenzando. Jira tiene una entidad: épica, pero aún así solía liberar.

El hecho es que para implementar la estructura correcta, es necesario tener 3 niveles de anidamiento, Jira al momento de escribir el artículo tiene 2 + 1 (el historial y la tarea se encuentran en el mismo nivel). +1 es una subtarea, no lo tengo en cuenta, ya que tiene la función de complemento en lugar de anidar debido a la falta de flexibilidad y fuerte vinculación con el padre.

En lugar de liberarlo, podría usar componentes o sprint, pero para mis propósitos parecían menos exitosos. Por la misma razón, la épica se usa para grabar historias.

La historia (épica) en esta estructura es la tarea del negocio (el deseo del cliente). Tarea- acciones comprensibles para resolver problemas comerciales.

Además, se agregaron algunos contadores y campos a las entidades. El más importante de ellos es una escala para evaluar la complejidad de una tarea del 1 al 10 en unidades arbitrarias (punto de la historia).

Creación del sistema


Hay datos, luego debe decidir de qué forma y cómo mostrarlos. Creé un proyecto común para el equipo y escribí una consulta JQL para extraer tareas de todos nuestros proyectos (la consulta es fácil de generar en la sección de problemas). Se agregaron tablas y estados de Kanban correspondientes a nuestro proceso técnico: Backlog → Tareas → Hacer → Revisar → Pruebas → Coincidencia → Listo.

Resultó la siguiente imagen:

imagen

ahora todas las tareas pasan por un solo ciclo de producción, que es bastante universal (no puede probar el diseño, sino transferirlo inmediatamente a un acuerdo). En caso de falla de cualquier etapa, se agrega un comentario a la tarea y se envía nuevamente a Tareas pendientes. Cada tarea tiene enlaces visibles al proyecto, historial del cliente (épico) y épico (lanzamiento).

Usando la misma consulta JQL con el complemento BigGantt (o cualquier otro) para Jira, las tareas se pueden ver en forma de un diagrama de Gantt. Cambie el tiempo de entrega, los plazos, registre dependencias, vea la carga de los artistas. Contraer tareas en la historia, historia en épicas, es decir visualizar una hoja de ruta o un plan de trabajo detallado.

Parte administrativa


De las metodologías, se utiliza Lean (se determina una secuencia de acciones, mientras que la posibilidad de ejecución paralela de tareas permanece), Kanban (las tareas van de especialista en especialista, se identifica fácilmente un cuello de botella). De Scrum tomó reuniones diarias para mantener una comprensión de quién está haciendo qué. También evaluaron la complejidad de las nuevas tareas en los puntos de la historia. Quería, pero no podía usar sprints, porque el cliente a veces cambió la prioridad de las tareas, y ya no es posible regular la cantidad de trabajo después del inicio del sprint.

Después de la reunión, las tareas se priorizan en una cartera de pedidos, se asigna un ejecutor y se transfiere a Tareas pendientes. El desarrollador crea una rama en BitBucket, la tarea salta automáticamente a Doing. Al finalizar, el "desarrollador" se transfiere a Review, el artista cambia a otro desarrollador. Si todo está bien, el "revisor" hace una fusión y el código está en el servidor de prueba. Jira envía la tarea al probador. Después de la verificación, QA lo transfiere al gerente. Eso muestra al cliente. El cliente está satisfecho: el código se envía al servidor de batalla bajo la estrecha supervisión de las pruebas automáticas diarias.

Gracias por tal automatización, gracias a nuestros ingenieros devops. Acabo de configurar el cambio de estados y ejecutores para eventos desde git. Esto se hace en la configuración de los procesos de negocio, si trabaja dentro del ecosistema Atlasian. Y cuando use GitLab, Bitrix, Redmine tendrá que jugar.

Soluciones


Veamos lo que logramos lograr:

  • La falta de una conexión visible entre las tareas del cliente y el equipo.
    Las tareas comerciales se registran en Jira como historias (épicas), se pueden ver con un porcentaje de finalización y en el diagrama de Gantt. El desarrollador, al realizar la tarea, ve a qué historia pertenece, puede ir y leer la descripción.
  • Priorización incorrecta El
    diseñador, habiendo completado la tarea antes, toma una nueva de la parte superior de la lista de tareas pendientes, donde se les da prioridad por la proporción del punto de historia al costo (tareas comerciales en rublos).
  • No existe una representación visual del alcance del trabajo.
    Tareas en un proyecto. Cada miembro del equipo ve cómo se mueven a lo largo del tablero Kanban, el curso general de trabajo. Lo que se ha hecho y lo que queda por hacer.
  • Distribución desigual de la carga por tiempo y por personal Los
    diagramas de Gantt le permiten planificar el trabajo en un horizonte largo (con actualizaciones constantes). Hay una proyección sobre los artistas intérpretes o ejecutantes. Se puede ver cuando el ejecutor tiene 2 tareas a la vez, mientras que alguien no las tiene.
  • Al planificar el tiempo de finalización, las tareas de otros proyectos no se tienen en cuenta.
    Al agregar una nueva tarea a cualquier proyecto, se puede ver en la cartera general. La prioridad con respecto a otras tareas se establece para ella en una sola métrica.

Planes


Algunos procesos se redujeron o automatizaron, pero quedaban muchos más en los planes:

Generación de estimaciones de tiempo y material de proyectos.


Al realizar cada tarea, el empleado anota el tiempo en ella. Al conocer las tarifas por hora de cada persona, su posición, el factor de corrección (por cuánto multiplicar para contabilizar los costos de la empresa), puede generar una tabla con una lista de trabajos y costos.

Liquidaciones automáticas entre gerentes


Si tengo tareas, pero no hay suficientes recursos para completarlas, le pido a otro gerente el contratista. Cuando llega el momento de los informes, incluyo como gastos las horas de dinero gastadas del empleado en mi plan y como ingresos en el plan de otro gerente.

Todos los meses tenía que levantar todo el trabajo, consultar con los gerentes, multiplicar y restar sin ninguna creatividad. Si todos los empleados cambiaran a un único formato de datos (la forma de realizar proyectos en Jira), todos los cálculos serían posibles sin intervención humana.

More articles:


All Articles