Version en video
Es una metodología ágil para el desarrollo de software como otras metodologías ágiles nació por la inspiración del manifiesto ágil un manifiesto que se creó casi que como consecuencia del desarrollo por cascada ( primero se planea, luego se desarrolla y por último se prueba) . Se dice que el desarrollo por cascada no funcionaba bien para proyectos de software porque hay mucho descubrimiento en el desarrollo y cambios sobre la marcha inesperados es bastante más parecido al método científico ( hipótesis, ensayo, error o éxito, ajuste y repetir).
Donde he trabajado siempre se dice que se usa scrum, como para determinar cómo se organizan las personal. también he escuchado de conocidos que trabajan en tecnología que lo usan en sus empresas, por lo que mi impresión es que esta es una metodología para el desarrollo de software muy aceptada actualmente.
scrum busca ciclos cortos de trabajo que se llaman sprint, la idea es dividir el trabajo de manera que se puedan mostrar cosas completas al final de ese sprint, los sprint son cortos en teoría tanto como sea posible para tener una duración de entre 1 y 4 semanas (donde 2 semanas es lo común).
el trabajo se divide en historias de usuario de manera que se puedan hacer por partes, y que estas partes tengan valor para el negocio por ejemplo una historia puede ser “permitir que un usuario pueda recuperar su contraseña” (ese es el título la descripción podría tener como se quiere que se recupere, bajo que condiciones, como se va determinar que se culminó la tarea etc) y una buena historia tiene algunas características (me parece util este acronimo) el acronimo invest.
I: independent (la historia se debe poder cumplir por sí sola)
N: negotiable ( se puede negociar la historia hasta antes de empezar)
V: valuable ( debe ser valiosa para el negocio, generar valor si se completa)
E: estimable ( se debe poder estimar para calcular que tanto esfuerzo va tomar)
S: small ( debe ser lo suficientemente pequeña para que se pueda hacer un sprint)
T: testable ( se debe poder probar de alguna manera que la historia se completo)
qué criterios debe tener si o si los define el equipo pero la historia no deja de ser una forma de dividir y hacer el trabajo por partes manejables
los equipos en scrum están compuestos por el product owner que viene siendo un representante del negocio en el equipo que entiende las necesidades y se las prioriza al equipo( define qué se debe hacer primero) , un scrum master que es una persona que hace de contrapeso al product owner para disminuir la presión que hay sobre el equipo y ayuda a remover bloqueos, y el equipo de desarrollo que es el que se encarga de implementar las soluciones.De estos 3 el scrum master veo como común que se lo pasen por la galleta (que no pongan a ninguna persona con ese rol en el equipo).
el equipo se recomienda que sean 7 +- 2 personas (entre 5 y 9 personas) este conteo son las persona que hacen historias(hacen el backlog del sprint) por lo que si el product owner hace historias cuenta en este rango sino no, lo mismo para el QA( persona que vela por la cálida y hace pruebas) si afecta la capacidad del equipo cuenta sino no, más personas son contraproducente por que aumentan el costo de la comunicación exponencialmente ( entre más gente esté metida en algo más difícil es sincronizar el trabajo, decidir y organizar ) y menos personas tal vez sean muy pocas para conseguir algo significativo en un tiempo razonable además de ser capaces de hacer cosas si alguien sale de vacaciones por ejemplo. En lo personal me gustan mucho más los equipos tirando hacia el lado de pequeño cuando un equipo crece me parece inevitable que se empiezan a tomar temas variados y se pierde la concentración como equipo en algo específico.
el equipo va varían en composición según el producto algunos equipos van a ser solo desarrolladores backend, otros sólo front-end, otros mixtos entre backend y frontend, otros serán científicos de datos etc.
un último detalle aparte de la metodología creo que es importante que en un equipo haya confianza, que la gente se lleve relativamente bien, que todos se puedan concentrar en el trabajo del equipo y esto he visto que se se posibilita cuando.
- se respetan las curvas de aprendizaje.
- se saca tiempo para permitir hacer mejoras técnicas ( o deuda tecnica)
- Se hacen actividades de integración.
- todos los integrantes trabajan para un solo proyecto ( en ciertos caso se da que una persona tiene x capacidad en un equipo y y en otro, yo creo que eso es contraproducente)
- se hacen discusiones técnicas en grupo
- se hace programacion par/mob programming devez en cuando,para iniciar una persona o seguido si al equipo no le molesta
se piden y se respetan las opiniones de todos, aunque se llegue a compromisos
por el contrario cuando esas cositas se dejan de hacer pues el rendimiento y el ambiente empeoran. no se deja de ser humano por más metodologia o processo
fuentes:
opiniones personales y primeros 3 capitulos de:
Scrum the basics de linkeding learning
https://www.linkedin.com/learning/scrum-the-basics
