Malentendidos sobre la propiedad colectiva en un entorno ágil [cerrado]

A mi entender, la propiedad colectiva resolverá problemas comunes con lo anticuado, como la calidad, el fracaso por ausencia y el intercambio de conocimientos.

Sin embargo, hay algunas cosas que no entiendo.

  1. ¿Es el equipo una democracia? Si es así, ¿qué pasa si la mayoría está equivocada?
  2. ¿Por qué elegir la corrección técnica sobre la "corrección de las personas"? es decir, lo que es técnicamente correcto puede no ser la opción más motivadora/agradable para las personas que trabajan en el proyecto. Es más probable que un equipo infeliz cree mala calidad que un equipo motivado.
  3. ¿Qué pasa con la creatividad, la comprensión, la exploración y la experimentación del individuo? Es probable que estos se descuiden si las únicas decisiones que se toman se basan en un acuerdo mutuo.
  4. ¿Cómo se maneja la actividad no autorizada? Por ejemplo, si el 99% de un proyecto está hecho y todo el equipo, excepto una persona, se va de vacaciones al día siguiente, ¿qué impide que esa persona cambie cosas que ya se acordaron durante las sesiones de programación en pareja, justo antes de entregar el último 1%? ?
  5. ¿No se incrementará enormemente el tiempo de producción de código? Si todo el equipo tiene que aprender todo el código que se produce, técnicamente solo se puede producir una cosa a la vez.

Editar : Se agregaron los puntos 4 y 5.

Estas son varias preguntas. Si bien pueden estar vagamente relacionados, son preguntas claramente diferentes que deben hacerse por separado para evitar ser demasiado amplias. Además, el tema de los equipos multifuncionales frente al individualismo en los proyectos ocupa libros enteros y es claramente demasiado amplio a menos que se reduzca a un problema concreto al que se enfrenta.
Los hilos de comentarios sobre todas las respuestas se están saliendo de control. PMSE es un sitio de preguntas y respuestas, no un foro de discusión. Utilice los comentarios solo para aclarar o mejorar las respuestas; todo lo demás debe moverse al chat .

Respuestas (3)

La "propiedad colectiva del código" no significa que todos los miembros del equipo tengan voz en cada línea de código que se escribe. El código todavía está escrito por individuos (a menos que estés programando en pareja), y están tomando las decisiones que creen que son las mejores en ese momento. El punto es que ningún individuo "posee" una sección del código.

Si John escribió el módulo Foo y, por alguna razón, se descubre un error crítico mientras John está fuera, no debería haber nada que impida que Sue intervenga y lo solucione. No es el "código de John", son los equipos.

Entonces está la pregunta de "¿cómo corrige Sue el código, si John lo escribió?" y la respuesta no es que Sue y el resto del equipo decidieran cada línea con John, sino que John, con espíritu de trabajo en equipo y cooperación, y sabiendo que no sería la única persona que trabajaría en el código, se tomó el tiempo de escribir pruebas y documentar el código para que Sue pudiera trabajar en él.

Sue también podría tener algo de experiencia con el código de las revisiones de código que, nuevamente, no son una oportunidad para que el equipo decida cómo debería haberse escrito el código, sino simplemente para asegurarse de que cumple su propósito y cumple con los estándares que sigue el equipo. .

En cuanto al punto 3, la experimentación, la exploración, etc. pertenecen a los prototipos y proyectos personales, no al código de producción.

Si no se hace línea por línea, entonces cuando John está trabajando en el código, es la solución de John. Cuando Sue trabaja en el código de John, ¿es la solución de Sue ya que pueden cambiar el código para que se adapte mejor a sus preferencias? En su respuesta al punto 3, ese tipo de mentalidad hará que nadie esté dispuesto a trabajar más y más duro, ya que su trabajo siempre será un sacrificio en lugar de una oportunidad emocionante. No creo que esto sea confiable o eficiente. En principio, creo que la corrección debe estar con las personas, no con la tecnología, ya que las personas felices hacen buena tecnología, no al revés.
Cuando John está trabajando en el código, es la solución del equipo, cuando Sue está trabajando en él, también es la solución del equipo. Si Sue está haciendo cambios no relacionados puramente por preferencia personal, entonces está actuando de manera egoísta y en contra de los mejores intereses del equipo.
Para el punto 3: el código puede ser creativo, experimental y parte de un prototipo por la mañana, y ser una pieza de código de producción claramente escrita y bien documentada por la noche. El punto era más que si estás poniendo código en producción con el que nadie más puede trabajar, entonces no estás siendo un jugador de equipo.
John y Sue no pueden leer la mente de los demás y, por lo tanto, tendrán que hacer suposiciones en ausencia del otro. Si es una elección entre suposiciones y preferencias potencialmente incorrectas, ¿por qué no tener preferencia? La creatividad implica que otros tendrán que aprender ya que es algo nuevo. No creo que signifique que John o Sue no sean jugadores de equipo, creo que simplemente significa que han inventado una forma nueva y eficiente de hacer algo que el equipo aún no ha entendido. ¿Por qué castigar la innovación?
@ThreaT: Línea por línea, no puede haber suposiciones. La computadora no puede leer la mente ni puede hacer suposiciones. En el nivel de diseño superior, puede ser "innecesariamente inteligente" (lo que debe evitarse) o realmente innovador. En el último caso, como John sabe que Sue también podría trabajar en el mismo código, John debe documentar adecuadamente su diseño, para que Sue pueda entenderlo sin hacer suposiciones. También podría ayudarse a sí mismo a recordar qué ingeniosos trucos hizo hace un año.
@BartvanIngenSchenau: Parece que la propiedad colectiva siempre dará como resultado que se seleccione el enfoque común en la fase de diseño, por lo que nunca permitirá la creatividad.
@ThreaT "fase de diseño" grita cascada, no ágil. Creo que tienes una visión demasiado draconiana de lo que implica la "propiedad colectiva". Simplemente escriba el código como lo haría normalmente, pero tenga en cuenta que otros tendrán que trabajar en él (comentarios, limpieza, etc.), no se enoje cuando alguien lo edite y no tenga miedo de editar el código que "no es tuyo". Se trata de dejar los egos a un lado y trabajar en equipo.
@MikeGossmann: Creo que es muy desmotivador si alguien no tiene miedo de ir y cambiar su código para que sea más "estandarizado" mientras está en medio de la creación de algo nuevo. Seguramente debe haber algunos tiempos, límites y propietario alfa/decisivo definitivo, de lo contrario, es solo anarquía y nadie termina siendo feliz y motivado.
@ThreaT: La gente no entra en el código para hacerlo más normalizado, ya que generalmente no hay tiempo para ese 'trabajo inactivo'. Y debe haber comunicación entre los desarrolladores para evitar conflictos. Si estoy trabajando en un gran cambio en las clases X, Y y Z y veo una segunda característica en el trabajo pendiente que involucra una de esas clases, entonces advertiría al equipo que debe quedarse solo hasta que termine con mi gran cambio. Una vez que termine, cualquiera puede comenzar con esa otra característica.
  1. ¿Qué pasa si la mayoría está equivocada?

Puede suceder, por supuesto. Espero que cualquier problema que surja de una decisión equivocada sea planteado y discutido en retrospectivas. Con suerte, el equipo reconocería el error que había cometido y se ajustaría.

  1. ¿Por qué elegir la corrección técnica sobre la corrección de las personas?

Por qué de hecho. El equipo debe discutir los pros y los contras de los diferentes enfoques. Pueden decidir que una solución técnicamente no óptima es más apropiada. Un equipo saludable discutirá esto abiertamente y tomará una decisión basada en su experiencia colectiva.

  1. ¿Se descuida el talento individual?

Un buen equipo está buscando maneras de hacer un buen trabajo. Lo harán tanto mediante la colaboración como reforzando las fortalezas de las personas en el equipo.

  1. Cómo se maneja la actividad no autorizada

Si el comportamiento deshonesto está causando problemas, estos se plantearán y discutirán en las retrospectivas. La presión de los compañeros suele ser suficiente para alentar al pícaro a trabajar de una manera más productiva, especialmente si se pueden demostrar los efectos nocivos.

Buena respuesta. Sin embargo, me gustaría que ampliara el punto 3 antes de aceptarlo como correcto. Todavía no veo realmente cómo se fomenta el crecimiento individual con la propiedad colectiva.
Mucho dependerá de las personalidades de los miembros del equipo. Si tienen la mente abierta y no confrontan, entonces verán el potencial del individuo y lo nutrirán. La clave es tener un enfoque rápido y sin recriminaciones cuando algo sale mal. Las retrospectivas darán retroalimentación sobre las cosas que salieron bien y las cosas que salieron mal. Si la persona está haciendo cosas que realmente ayudan, deberían ser mencionadas en las retrospectivas. Un equipo positivo buscará apoyar ese éxito.
@BarnbyGolden: En mi experiencia, la tabla de sprint siempre tiene prioridad sobre la retrospectiva. Incluso si mencionas algo en retrospectiva, es muy poco probable que tengas la oportunidad de hacer cosas nuevas de forma creativa por tu cuenta en lugar de hacerlo de forma colectiva.
La mejora continua es el corazón del proceso Scrum. Si a las personas les resulta difícil actuar sobre las mejoras propuestas, puede haber un problema con la forma en que se ejecutan las retrospectivas. Pero si las personas están sugiriendo cambios, es importante que también describan cómo el cambio mejorará las cosas y, lo que es igualmente importante, cómo pueden medir ese cambio. Dado un argumento razonado y una medida definida de éxito, el equipo generalmente permitirá que se lleve a cabo un cambio. Si el equipo no está dispuesto a intentarlo, sugiere falta de confianza y que se están perdiendo los beneficios de Agile.
No siempre es posible aconsejar cómo una exploración necesariamente mejorará las cosas porque no lo sabrá hasta que lo haya intentado. La exploración de nuevas ideas puede fallar, pero también puede resultar realmente beneficiosa. Incluso si menciona la falta de creatividad en retrospectiva, si hay tareas de mayor prioridad que se requieren constantemente, la creatividad siempre se dejará de lado. Una posibilidad es dejar que los desarrolladores hagan cosas solos de vez en cuando, pero esto obviamente entra en conflicto con la propiedad colectiva.
Buenas respuestas. La propiedad colectiva se trata de que los miembros del equipo se apoyen entre sí y puedan respaldar su producto incluso cuando faltan personas. 1, 2 y 4 son cuestiones de dinámica de grupo que son ciertas independientemente de si se encuentra en un entorno ágil. Para el n.º 3, un entorno Agile debería fomentar una cultura de aprendizaje y experimentación controlada. Esto debería crear oportunidades para explorar opciones. Por supuesto, es concebible que la dinámica organizacional presione al equipo para tomar atajos y tomar el primer camino plausible, independientemente de la calidad, pero eso sería una implementación ágil deficiente.
  1. ¿Y si la mayoría está equivocada?

¡Está bien si esto sucede! La idea es 'fallar rápido', adaptarse, actualizar su plan y seguir adelante, intentando otra cosa. El concepto de 'fracaso rápido' es solo otra forma de aplicar el método científico a su trabajo.

Solo dirijo la primera pregunta por ahora estoy en el móvil.

Malentendidos sobre la propiedad colectiva en un entorno ágil [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v