[ad_1]
La JIRA de Atlassian comenzó su vida como una herramienta de seguimiento de errores. Sin embargo, hoy en día, se ha convertido en un conjunto de planificación ágil, “para planificar, rastrear y lanzar un gran software”. En muchas organizaciones se ha convertido en el mapa principal de los proyectos de software, el centro de todo desarrollo, la infame “fuente de verdad”. ”
Es un tópico que el mapa no es el territorio. Por desgracia, esto parece especialmente cierto de JIRA. Su origen como rastreador de errores, y su uso resultante de "tickets" como su unidad de definición fundamental, han hecho que sus mapas sean especialmente difíciles de seguir. Jira1 con demasiada frecuencia se usa de una manera que lo convierte, sin darse cuenta, en un "antipatrón" en toda la industria, es decir, "una respuesta común a un problema recurrente que generalmente es ineficaz y los riesgos son altamente contraproducentes".
Una cosa que escribir software elegante tiene en común con el arte: sus creadores deben seguir siendo conscientes de la macro visión general del proyecto, al mismo tiempo que están trabajando en sus micro detalles más pequeños. JIRA, por desgracia, enseña implícitamente a todos a ignorar la visión más amplia mientras se enfoca en los detalles. No hay un todo. En el mejor de los casos, existe una "Epopeya", pero el punto central de una Epic es descomponerse en piezas más pequeñas para trabajar de forma independiente. JIRA fomenta la desintegración de la macro visión.
Además, el JIRA basado en características no admite fácilmente el concepto de infraestructura para todo el proyecto que no se corresponde con características individuales. Un modelo de datos utilizado en todo el proyecto. Un componente complejo usado en múltiples páginas. Una capa de almacenamiento en caché para una interfaz de terceros. Un servicio en segundo plano que proporciona datos en tiempo real utilizados en varias pantallas. Seguro puede Guíelos en el paradigma de tickets de JIRA … pero la telaraña de dependencias que resulta no ayuda a nadie.
Lo peor de todo, sin embargo, es la interminable presión implícita para que los boletos sean marcado terminado, para pasar a la siguiente fase. Los boletos, en la mentalidad de JIRA, se toman, se enfocan hasta que se completan, y luego se pasan, para que nunca más se vean. Tienen un ciclo de vida unidireccional: especificación; diseño; desarrollo; pruebas; lanzamiento. ¿Eso no suena un poco … um … cascada? No se supone que el desarrollo ágil sea fundamentalmente diferente ¿Del desarrollo de la cascada, en lugar de simplemente reemplazar una cascada grande con mil pequeños?
Aquí hay una analogía. Imagine una herramienta de planificación de la ciudad que facilita el diseño de mapas de la ciudad que incluyen torres, distritos residenciales, parques, centros comerciales y carreteras … pero que no admite fácilmente cosas como obras hidráulicas, alcantarillas, túneles del metro, la red eléctrica, etc. ., que solo puede ser encajado a través de hacks incómodos, en todo caso.
Ahora imagine que esta herramienta se usa como modelo para la construcción, con el supuesto implícito de que a) el vecindario es la unidad fundamental de la construcción de la ciudad b) las ciudades se construyen un vecindario a la vez y los vecindarios una cuadra a la vez. Lo que es más, uno está incentivado para pasar al siguiente solo cuando el último está absolutamente completo, hasta las flores que crecen en las tiras medianas.
Ahora Imagine que se pide a los desarrolladores, ingenieros y trabajadores de la construcción de la ciudad que calculen e informen sobre el progreso en términos de cuántos barrios y bloques se han completado en su totalidad y qué tan lejos están cada uno. ¿Te parece un modelo particularmente efectivo de planificación urbana? ¿Crees que te gustaría vivir en su resultado? O, en la práctica, ¿crees que la mejor manera de hacer crecer una ciudad podría ser un poco más orgánica?
Extendamos esa metáfora. Suponga que comenzó a construir la ciudad de manera más orgánica, de modo que, en un punto significativo, tenga un centro lleno de una mezcla de edificios temporales y permanentes; se sentaron las bases de los rascacielos (es decir, se resolvió la incertidumbre técnica); gran parte de la infraestructura central construida; unos pocos grupos de estructuras iniciales en los vecindarios centrales, y barrios marginales en las afueras; una pista de aterrizaje donde estará el aeropuerto; y el tráfico que va y viene entre todos estos lugares. En otras palabras, usted ha construido una ciudad en proceso cruda pero en funcionamiento, su esqueleto construido, listo para ser desarrollado. ¡Bien hecho!
Pero si se mide por cuántas cuadras y barrios están absolutamente terminadoSegún las interpretaciones artísticas de los planificadores urbanos, ¿cuál es su progreso? Por esa medida, tu progreso es cero.
Así que no es así como JIRA te incentiva a trabajar. Eso se vería como una enorme columna de tickets en progreso y cero completos. Eso parecería más que terrible. En su lugar, JIRA lo incentiva a completar un bloque completo y luego al siguiente; un barrio entero, y luego el siguiente; para eliminar tantos tickets diferentes como sea posible, para marcarlos como completos y transmitirlos, incluso si unirlos después del hecho es más difícil que construirlos para que trabajen juntos en primer lugar ,.
(Si prefiere un modelo a menor escala, solo transponga: ciudad → construcción de condominios, vecindario → piso, bloque → unidad, etc.)
Y así, la gente toma los tickets, los implementa tal como están escritos, los transmite a quien sea el siguiente en el flujo de trabajo, considera que su trabajo está bien hecho, incluso si trabajar en grupos dispersos en paralelo puede ser mucho más efectivo … y sin siquiera considerar los más grandes Gol. "Implementar el botón Cargar" dice el ticket; así que eso es todo lo que se hace. El ticket no explica que el objetivo mayor del botón Cargar es permitir que los usuarios realicen una copia de seguridad de su trabajo. Tal vez sea técnicamente más fácil cargar automáticamente cada cambio de estado, de manera que el usuario obtenga copias de seguridad automáticas sin botones más una pila completa de deshacer / rehacer. Pero todo lo que dice el ticket es: "Implementar el botón Cargar". Así que eso es todo lo que se hace.
Con demasiada frecuencia, la única vez que alguien se preocupa por la visión del proyecto en su conjunto es desde el principio, cuando el (los) gerente (s) del proyecto con exceso de trabajo inicialmente lidian con la ingrata tarea de descomponer todo el proyecto en un bosque de Entradas. Pero el todo punto Un desarrollo ágil es aceptar que el proyecto siempre estará cambiando con el tiempo y, aunque en menor medida, para varias personas, todos en el equipo, para contribuir a ese cambio. JIRA se ha convertido en una herramienta que realmente funciona en contra de esto.
(Y ni siquiera me refiero a pedirle a los ingenieros que estimen un proyecto que otra persona ha descompuesto, en subcomponentes cuya partición se siente poco natural, dándoles aproximadamente treinta segundos por función durante una reunión de planificación, y entonces basando todo el plan del proyecto en esas conjeturas a medias ciegas, sin investigar, sin investigar, sin volver a visitarlas o dar tiempo para un análisis más atento. Ese antipatrón no es culpa de JIRA … exactamente. Pero la estructura de JIRA contribuye a ello.
No estoy diciendo que JIRA no tenga lugar. Es muy bueno cuando estás en el punto en el que dividir las cosas en partes pequeñas y terminarlas secuencialmente tiene sentido. Y, como es de esperar, su historial es extremadamente bueno para el seguimiento de problemas.
Permítanme reiterar: para escribir software elegante, debe tener en mente tanto la macro como la micro visión mientras trabaja. JIRA es buena en el manejo de micro piezas. Pero necesitas algo más para la macro. (Y no, un prototipo seleccionable no es suficiente; son importantes, pero también requieren un contexto descriptivo).
Permíteme proponer algo impactante y revolucionario: prosa. Sí, eso es correcto; palabras en una fila Párrafos cuidadosamente escritos. No estoy hablando de documentos de requisitos enormes. Estoy hablando de tal vez una descripción general de diez páginas que describe en detalle la visión del proyecto completo y un documento arquitectónico de seis páginas que explica la infraestructura del software, donde se encuentran los servicios de agua, alcantarillado, electricidad, metro y aeropuertos de la ciudad. Cómo funcionan, para extender la metáfora. Cuando Amazon puede, famoso, requerir memos de seis páginas para poder convocar reuniones, esto realmente no parece demasiado pedir.
El simple hecho de dejar de tratar a JIRA como el mapa principal y el modelo de finalización del proyecto socava una gran parte de su antipatternidad implícita. Úselo para rastrear el desarrollo iterativo y las correcciones de errores, por todos los medios. Es muy bueno en eso. Pero es una herramienta muy mal adaptada para ser el mapa de la visión general o la infraestructura de un proyecto, y es Nunca La fuente de la verdad. La fuente de la verdad es siempre el código en ejecución. En el software, como en el arte, el micro trabajo y la macro visión siempre deben estar informados entre sí. Dejemos que JIRA mapee el micro trabajo; pero deje que un lenguaje sencillo y antiguo describa la visión macro y trate de prestarle más atención.
1Atlassian parece haber descapitalizado JIRA entre las versiones 7.9 y 7.10, pero de manera descriptiva, todo en mayúsculas aún parece más común.
[ad_2]
VendeTodito