2008-08-29 12 views
6

Soy el segundo desarrollador y un empleado reciente aquí en una tienda PHP/MySQL. Me contrataron en su mayoría debido a mi experiencia en la lucha de algún tipo de proceso de un caos desordenado. Al menos, eso es lo que hice en mi última compañía. ;)Scrum: La resistencia es (no) inútil

Desde que estoy aquí (hace unos meses), me he traído a bordo de mi jefe, mi director de producto y varias otras figuras clave (pero sobre todo pollos, si perdonas los estereotipos basados ​​en Scrum) . También ayudé a dar visibilidad al ciclo de desarrollo de un producto importante que ha estado rezagado durante más de un año. ¡La gente lo ama!

Sin embargo, mi compañero de trabajo (el único otro desarrollador aquí por ahora) no está en eso. Ella prefiere cerrar la puerta, concentrarse en su trabajo y quedarse sola. ¿Yo? Estoy en todo el enfoque ágil de colaboración, cooperación y apertura. Sin su aporte, comencé las prácticas de Scrum (scrums diarios, gráficos burndown y otras cosas que encontré que funcionaron para mí y para mis equipos anteriores (el genial mural gráfico de H. Kniberg). Durante nuestra presentación diaria, ella se escabulle e ignora nosotros como si realmente no estuviéramos parados frente a su puerta (en realidad estamos). Es bastante sorprendente. Nunca he visto tanta resistencia.

Pregunta ... ¿cómo la llevo a bordo? La presión de los compañeros no de trabajo.

Gracias compañero de Scrum-Borg,

beaudetious

+0

Parece que el problema no es incorporarla a Scrum, sino hacer que trabaje en equipo y no como individuo. Intenta pedirle a tu jefe que fomente el trabajo en equipo utilizando bonificaciones. –

+0

Gracias por toda la información. Redirigiré mis esfuerzos para involucrarla en nuevos procesos de desarrollo y buscar sus opiniones sobre cómo deberían evolucionar las cosas. Me han dicho que ya la ayudé a sacarla de su cueva de codificación en la que normalmente reside desde que llegué aquí. Este lugar nunca ha visto una colaboración como yo anticipo que eventualmente llegaremos. Lo veré como un desafío profesional. Gracias, beaudetious – beaudetious

+1

Es más adecuado para http://programmers.stackexchange.com/ –

Respuesta

13

Mientras Scrum otro método ágil ologías como que encarnan una gran cantidad de buenas prácticas, a veces darle un nombre y hacerlo (como muchos bloggers han comentado) una "religión" que debe adoptarse en el lugar de trabajo es bastante desagradable para muchas personas, incluyéndome a mí.

Depende de cuáles sean sus opciones y compromisos, pero sé que estaría mucho más interesado en aceptar ideas porque son buenas ideas, no porque sean un carro. Intente implementarla/atraerla a las prácticas de una en una, mostrándole cómo pueden mejorar su vida y flujo de trabajo también.

Los programadores aman las cosas geniales que les ayudan a hacer las cosas. Odian que se les predique o se les pida que suban a lo que ven como un carro. Preséntelo como el primero en vez del último. (Ni que decir tiene, asegúrese de que en realidad es el anterior)

Editar: otra pregunta

realidad nunca he trabajado para un lugar que utiliza una metodología ágil específica, aunque estoy bastante feliz donde estoy ahora en que incorporamos muchas prácticas ágiles sin la exageración y el dogma (lo mejor de ambos mundos, en mi humilde opinión).

Pero estaba leyendo acerca de Scrum y, ¿es un sistema así incluso beneficioso para un equipo de 2 personas? Según parece, Scrum agrega una cierta cantidad de gastos generales a un proyecto, y eso podría superar los beneficios cuando tienes un equipo muy pequeño donde la comunicación y la planificación ya son fáciles.

+0

Creo que Scrum en un equipo de 2 personas puede ser útil para asegurar que cada persona sepa dónde está el otro en el proyecto y luego las demostraciones al final de un sprint podrían ser una especie de "show and tell" para adultos para compartir lo que se hizo, pero eso es JMO. –

2

Creo que la clave sería ayudarla a entender por qué estás haciendo Scrum en primer lugar. Supongo que tienes tus razones, entonces ¿por qué no se lo dices? Es probable que tenga resistencia ante cualquier cambio si las personas involucradas no entienden por qué hay cambio o de qué se beneficiarán con él. Si puede explicar sus razones para utilizar Scrum y los siguientes beneficios para ella de una manera que se relacione con su trabajo diario, creo que es más probable que adopte una actitud más positiva hacia él.

Si no ve ningún valor en el proceso de Scrum, o no entiende cómo se relaciona con ella, probablemente no le importe.

Creo que uno de los conceptos más importantes que alguien debe entender con respecto a Scrum es el hecho de que trabajas en grupo y te comprometes con tu proyecto como grupo, no como individuos. Para muchas personas, esto es lo más difícil de entender, ya que están tan acostumbrados a vivir en "su propio mundo".

4

Simple. No hables de scrum. No uses scrum sobre ella. En su lugar, tome los principios subyacentes del scrum (por ejemplo, el propósito en oposición a la aplicación) y cree diferentes enfoques que se adapten a su forma de trabajar pero que tengan matices sutiles de scrum.

Todas las personas son diferentes y a muchos programadores no les gusta el scrum. No lo forzaría sobre ellos ya que eso sería simplemente contraproducente. Sugiero que identifique los problemas en el proceso de desarrollo (de una manera no scrum), vea si puede lograr que acepte que los problemas existen, luego pregunte su lo que ella piensa que sería una buena solución. Su cooperación y aporte al proceso es esencial para su cooperación; si no tiene aceptación, no se convertirá en ciudadana.

A partir de allí, con suerte puedes crear algún tipo de scrum cuasi-híbrido + su enfoque del proceso donde ambos pueden acordar el camino a seguir.

11

Sin su entrada, empecé las prácticas de Scrum (scrums diarios, cartas de quema y otras cosas que he encontrado que trabajaron para mí y mis equipos anteriores (ALA gráfico mural fresco de H. Kniberg). Durante cabo diaria del stand hasta que se cuela y nos ignora como si realmente no estuviéramos frente a su puerta (en realidad). Es bastante sorprendente. Nunca he visto tanta resistencia.

Pregunta ... ¿cómo puedo conseguirla? a bordo La presión de grupo no funciona

¡Qué! ¿Quién querría trabajar en un entorno tan opresivo? Tienes suerte, ella está enviando su currículum y podrás contratar a alguien que esté a bordo con tu proceso de desarrollo.

Asumiendo que quieres aferrarme a ella, rechazaría (o desactivaría) la retórica y trabajaría primero en ser amigo y compañero de trabajo. Si el proyecto llega un año tarde, no puede sentirse bien consigo misma y parece que no tiene miedo de proclamar su éxito. Eso puede ser intimidante.

No sé nada de Scrum, sin embargo. Solo me estoy imaginando cómo sería caminar con los zapatos de tu compañero de trabajo.

0

Continúe sus esfuerzos para involucrar al otro desarrollador. Recuerde que usted es el que quiere hacer este cambio. Pide ayuda con los problemas que tienes. Invítalos a la reunión diaria de pie. Actualmente, estoy planificando la parada diaria y me aseguro de que todos los cerdos y pollos estén invitados. Si usted es el líder en el proyecto, depende de usted abordar la situación y correr el riesgo. Ponte a ti mismo ahí afuera.

1

No estoy seguro de que Scrum sea el tema central aquí; Supongo que se siente amenazada por el chico nuevo que trae muchas ideas nuevas y agita las cosas. He estado en esa situación antes como la nueva persona aportando una nueva perspectiva sobre las cosas, y algunas veces es simplemente difícil traer de inmediato a esas personas a una nueva forma de pensar. A menudo requiere un cambio cultural que no ocurre de la noche a la mañana.

Trata de obtener su opinión y opinión sobre las cosas tanto como sea posible, y trata de demostrar que respetas que ha estado en el equipo más tiempo que tú. Si después de un tiempo ella todavía no participa, entonces todo lo que puede hacer es mencionarlo a su gerente y dejar que lo tomen desde allí.

6

beaudetious, amigo,

yo te sugiero leer el blog de Steve Yegge llama "Good Agile, Bad Agile". Es antiguo, pero es una maravilla, y creo que es una lectura obligada para cualquier persona, como yo, hace aproximadamente 2 meses, que se pone un poco "impaciente" por agilizar su lugar de trabajo. Agile ofrece una gran cantidad de buenas prácticas, pero debes tomarlas todas con un grano de sal y adoptar lo que te falta y omitir todos los demás problemas que podrían no ser útiles para una situación en particular, por ejemplo: el scrum diario. Si a su compañero de trabajo le gustaría programar en silencio (lea Peopleware para saber por qué esto es algo bueno) y está siendo una miembro productiva del equipo, deje de molestarla con su scrum y déjela trabajar de la manera que más le guste.

Las personas son generalmente menos "hostiles" con respecto a estas prácticas si solo se acerca a ellas y simplemente dice "¿Tiene un segundo? Escuche, la comunicación es realmente un problema en este momento, siento que no sé lo que" y realmente no quiero volver a pisar los pies y pasar dos días escribiendo algo que ya te gustó la semana pasada, así que vamos a trabajar en esto. Me gustaría probar X, ¿qué opinas? ". Sea compasivo y no tolere las "manzanas podridas", así es literalmente cómo agilicé mi lugar de trabajo, y muchos problemas comenzaron a evaporarse. De ninguna manera somos un lugar 100% XP o 100% compatible con Scrum, porque solo usamos lo que funciona y fue necesario.