Meetup de SCRUM

estimados les dejo la invitacion para el proximo meetup que se hara el miercoles 18 y se tratara de scrum.

saludos!!

Algunas referencias de cosas que conversamos en el meetup:

Libro “Reinventing Organizations” de Ken Wilber y Frederic Laloux

Javier Urrutia y su empresa CoreDevEx: buscando ser referentes de buenas prácticas en la industria del software y dedicados a ser punto de investigación en desarrollo para la realidad de las empresas chilenas de software

WikiSpeed y de cómo construir un auto conforme a requerimientos de seguridad y rendimiento aplicando principios ágiles:

Intenté encontrar un link acerca de la herramienta para realizar retrospectivas llamada RetroMax, no lo encontré. Alguien lo tiene?

Yo entendí que se llamaba Retromat… http://plans-for-retrospectives.com/?id=2-65-37-48-92

Bueno, algunos mencionaron que el problema de las retrospectivas es que la gente reclama por todo, que no tiene suficiente luz, que le falta espacio cerca de la ventana… etc. Me gustaría haber podido llegar a esa parte en alguna retrospectiva. Mi experiencia siempre ha sido que la gente se queda completamente callada, no dice nada y no escribe nada, y pone cara de ¿cuánto va a durar esto? porque tengo que seguir trabajando en vez de hacer estupideces…

De hecho me parece genial que la gente reclame porque tiene poca luz. desde mi punto de vista, para eso sirven las retrospectivas, para que la gente reclame y diga realmente lo que le molesta. Quizás el problema es la poca luz, o tal vez el problema es que encierran a la gente en un espacio muy chico y con poca ventilación, o tal vez están demasiadas horas seguidas frente al teclado y necesitan salir a tomar sol y ver que hay vida fuera del trabajo…

Mi experiencia ha sido que gente de 30 años ya se está quedando pelada y el exceso de luz artificial hace que no sólo pierda el pelo, sino que el cuero cabelludo se está descascarando y tiene directamente un hoyo en la cabeza… no hay sueldo que compense la pérdida de tu salud… lo siento.

Hay casos peores como cancer cerebral y extirpación de la mitad del cerebro a personas que se les ha exigido demasiado. Y después nadie quiere hablar con el tipo porque les da asco o nervios hablar con alguien que está descerebrado… pero lo que no se dan cuenta es que si trabajas muchas horas tu cerebro está físicamente ahí, pero estás descerebrado también porque el cerebro después de algunas horas se desconecta.

Hay casi una desesperación por parte de las jefaturas de proyecto por “verte trabajando”, mientras en realidad lo importante es terminar el trabajo, realizar las funcionalidades, cumplir los objetivos, o dicho de otra manera, lograr la optimización global del proceso… y eso no tiene nada que ver con estar tipeando como mono, pero en organizaciones enfermas se ve así…

Esa idea permea en los desarrolladores y se termina esclavizado al teclado y con un oceano de código repetido que no tiene sentido.

Lo único bueno que he sacado de las retrospectivas es que efectivamente escribo lo que me parece bien y lo que me parece mal, luego actúo sobre lo que parece mal como si fuera un item de proyecto, de hecho le doy más prioridad a los items de la retrospectiva que el proyecto en sí… porque el proyecto necesita velocidad, y esa velocidad sólo se puede lograr si mejoro lo que está mal, el proyecto me da lo mismo , lo postergo, o lo hago lento, eso tiene una ventaja importante: no me cambian los requerimientos rápidamente, no intentar atosigar el proyecto con cambios, porque si ven que el proyecto va a salir muy rápido, la estimación estaba mala, entonces las jefaturas tendrán una mala evaluación por estimar mal, si cambian los requerimientos a cada rato, pueden hacer que la estimación se acerque lo más posible a lo que pasa en la realidad agregando desperdicio… es triste, pero es la realidad…

Si trabajas lento al principio tienes espacio para mejorar. Si aprovechas ese tiempo para mejorar el proceso, el proyecto puede terminar en menos de la mitad del tiempo y con cero bugs.

Claudia mencionó algo interessante: en cuanto estimas un prototipo, si lo estás haciendo porque tienes dudas técnicas, no tiene sentido estimarlo, sino significa que no tienes esas dudas… en la prácitca mi experiencia ha sido que los desarrolladores buscan algo parecido en Google y se demoran un día en compilarlo y hacerlo funcionar. Luego otro día en mostrarlo funconando y hacer el code review, y son unas 3 iteraciones (prototipo evolutivo) para que el código quede bonito, como biblioteca y listo para incorporarlo al proyecto, lo que lleva entre 1 y 2 semanas.

Esto puede parecer trivial, pero en mi experiencia un proyecto de 100 requerimientos debería tener al menos 100 prototipos y el tiempo de desarrollo podría fácilmente irse la mitad en sólo hacer prototipos. Con esto no me refiero a maquetas, sino a pruebas de concepto.

A menos claro de que tengamos la visión de que el proyecto tiene tecnologías definidas y chicotiemos los caracoles, pero en mi experiencia esos proyectos nunca termnan bien, siempre hay redeficiones, malos entendidos, retrasos, mucho código repetido, mucho tratar de meter pelotas dentro de hoyos cuadrados y cosas por el estilo.

Tampoco se trata de que si haces prototipos el mundo sea color de rosa, porque no hay nada que le reviente más al cliente que ver que el proyecto de 8 meses lo terminaste en 2 y ahora te la llevas mirando por la ventana, conversando y descansando.

Pero si terminaste el proyecto, o por lo menos la parte encargada a ti y tu equipo, ¿qué van a hacer?

Aunque parezca increíble, tener tiempo de sobra también es un problema.

Hola , estarán disponibles las SLIDES ???.

Muchas Gracias

la prometido es deuda!

slides Meetup de intro a SCRUM

1 me gusta