¿Es obligatoria la propiedad del código colectivo en Scrum?

9

¿Es imprescindible seguir la metodología Scrum para practicar la propiedad del código colectivo , en lugar de, por ejemplo, la propiedad del código débil ?

scrum code-ownership Dimitri C.
fuente
Debo decir que me vuelve loco que otros en mi equipo de pseudo-scrum cambien mi código por una necesidad que no requirió ningún cambio en absoluto, solo la comprensión adecuada de la arquitectura o API que implementé.
Ando
3
Si no hay propiedad colectiva, ¿cómo es posible tener un compromiso por parte del equipo ? Dentro de un conjunto de habilidades (por ejemplo, programación Java), cualquiera debería estar dispuesto a realizar cualquier tarea.
merryprankster

Respuestas:

13

La propiedad del código colectivo no es una parte integral de Scrum .

Sin embargo, es parte de la Programación Extrema . La programación extrema y Scrum funcionan muy bien juntos.

El elemento central en Scrum es el equipo. Por lo tanto, es muy recomendable practicar la propiedad del código colectivo en oposición a cualquier tipo de individualismo .

Scrum funciona mejor en grandes proyectos (> $ 1M) con muchas incertidumbres y con grandes equipos (> = 5 desarrolladores en la misma base de código). La propiedad de código débil puede ser muy efectiva en equipos más pequeños y proyectos más pequeños como lo describe Paul Graham .

Christopher
fuente
"> 1M" ¿qué? ¿Empleados? ¿Caracteristicas? ¿Líneas de código en el producto general? ¿Líneas de código propiedad de un equipo scrum? ¿Por qué no funciona mejor con tamaños de código más modestos (suponiendo que se refería al tamaño del código)?
Bryan Oakley
1
1 millón de dólares Porque el equipo de scrum óptimo es de 7 personas y usar scrum en menos de varios meses no es realmente un proyecto que deba usar scrum. 7 desarrolladores * 6 meses es un proyecto típico de 1 millón de dólares.
1
$ 1M parece terriblemente arbitrario (y fechado: dentro de dos años $ 1M no comprará tanto como lo hace hoy, y ciertamente no tanto como lo hizo hace dos años). Sin embargo, supongo que es un número tan bueno como cualquiera. Un presupuesto de un millón de dólares no pagará mucho más que un solo equipo scrum, así que supongo que estás diciendo que SCRUM no funciona si no puedes pagar al menos un equipo scrum. Eso tiene sentido. Sin embargo, eso no se aplica a una verdadera startup donde todos trabajan con un presupuesto pequeño. Creo que tu respuesta sería mejor si tomas el límite artificial.
Bryan Oakley
@BryanOakley: no exactamente, escribí que Scrum funciona mejor cuando tienes las cifras óptimas . Scrum puede funcionar en equipos más pequeños y con menos iteraciones, pero se vuelve menos útil en esos casos. Prefiero no usar ningún framework en ese caso, o un scrum "ligero", que es lo que hago en una de mis compañías donde solo hay 3 desarrolladores. Sobre lo que puede comprar con $ 1M, no vi que fluctúe mucho desde los últimos 10 años.
10

Sobre el tema de la propiedad del código, creo que esta publicación aquí lo pone mejor de lo que podría escribir:

No quiero depender de nada sin un dueño. Veo cómo este razonamiento puede ser irritante. Cambiar el enfoque de software a software es un truco sucio amado por los tipos de perdedores de gestión media técnicamente impotentes orientados a pseudo-negocios. Aquí está mi intento de distinguirme de su tipo: no solo quiero depender de las cosas con un propietario, sino que también necesito un propietario feliz. Contrariamente a una suposición gerencial común (una de las que rara vez se mantiene pero mantiene a los gerentes cuerdos), no creo en asignar a la fuerza la propiedad. Si al propietario no le gusta el módulo, espere un trabajo de jardinería bastante malo.

/ fanático creyente en la propiedad del código débil.

Denis de Bernardy
fuente
4

No creo que la propiedad del código colectivo sea absolutamente necesaria para scrum, sin embargo, cuanto menos propiedad del código, más flexibilidad hay en las tareas asignadas. Esto es especialmente cierto cuando hay múltiples equipos scrum. Menos propiedad de código también elimina los cuellos de botella que pueden desarrollarse cuando un propietario de código tiene un exceso de trabajo.

La propiedad del código da continuidad al desarrollo y, dependiendo de los conjuntos de habilidades de los miembros del equipo, puede ser imposible eliminarlo por completo.

Blake
fuente