Sorteo 1 entrada StarsConf 2017

Hola todos/as

Estamos sorteando una entrada a la StarsConf de este año (2017), cuyo valor ya esta en USD 250, para que se hagan una idea de lo que se sortea xD.

Dentro de la agilidad (y en la vida), es muy valido equivocarse (o meter la pata como decimos en Chile), pero lo mas importante es que de esos errores, aprendas y no lo cometas más. Como es practicamente imposible que cometas todos los errores del mundo, sera dificil que aprendas todo de tu propia experiencia, por lo tanto se hace necesario, ademas, aprender de la experiencia de los demas.

Debes escribir un fail que hayas tenido intentando aplicar agilidad en tu diario vivir y colocar que fue lo que aprendiste de él (independiente si fue en tu lugar de trabajo o en tu casa) y colocarlo en este hilo del foro.

Sortearemos la entrada entre los que escriban en este post (sin repetirse), para ello, partan su texto en la primera linea con el hashtag: #failfast

La duración del concurso será hasta el 26-10-2017, el proceso del sorteo será transmitido por youtube (agregaremos el enlace el día del sorteo), el cual sera elegido completamente al azar, con la ayuda de random.org, de entre todos los participantes.

Sin mas que decir, pueden comenzar a escribir sus mejores fails.

Editado 1

  • Haremos el sorteo el 26-10-2017, después de las 19:00 hrs, pondremos el enlace aquí mismo.

Editado 2

4 me gusta

#failfast Mi Fail fue tratar de impulsarla desde mi equipo de trabajo, con la idea de que eventualmente se iba a poder propagar hacia arriba.

Resumen:Todavía tenemos que convivir con la metodología actual, sin poder agilizar nada

#failfast, que buenas iniciativas, soy nueva en el foro, pero con muchas ganas de Aprender :slight_smile:
Saludos
:wink:

#failfast Genial … soy nueva en el foro y tengo muchas ganas de Aprender!!

Estimado estoy un poco perdida! me llegan los correos pero no entiendo bien
donde debería realizar el comentario para poder participar. me enviarías el
link? gracias!

Saludos cordiales,

*DI Lucía Zandanel Terán *

*info@luciazandanel.com.ar info@luciazandanel.com.ar | **Skype:
lucia.zandanel *

*Diseñadora Gráfica Industrial (UNC) *
*Diseñadora Industrial de Productos *(UNC)
UX - UI - Web Designer - Web Developer

luciazandanel.com.ar http://luciazandanel.com.ar/
*Linkedin: */in/luciazandanelteran

Mendoza - Argentina | Santiago - Chile

#failfast Mi fail fue una vez testear una branch que contenía un mega feature (US epic) en 1 sprint de 2 semanas de duración. Esto trajo como consecuencia que la US no llegara a producción durante ese sprint.

Resumen: Le indiqué a los desarrolladores de mi equipo que trabajáramos las US en pequeños features y organizarlos en branch por separado, cada uno independiente entre sí. Me hizo el trabajo mucho más fácil y enfocado a la agilidad.

#failfast En mi primera pega. Ocurrió un error pero mi jefe le tenia miedo al gerente (igual era jodido) y me dijo que no dijera nada. Y eso se transformó en una bola de nieve, excusas tras excusas y la presión era horrible porque nos señalaron. En ese tiempo era muy polla pero ahora pienso que era una tontera y para esos casos es mejor dejar el orgullo, hablar, solucionarlo y listo. Mejor arreglar las cosas antes que empiece la bola de nieve, es lo mas sano.
Saludos.

#failfast Creo que todos los días cometemos pequeños errores. Lo importante es aprender y superarse. Recientemente, cometimos un error en conjunto en el equipo que dió como resultado que unas actualizaciones no fueran integradas y por ende, luego de confirmar al cliente que esto se había realizado, el cliente se quejó diciendo que los cambios no habían impactado. Fueron varios errores los que cometimos.

  • Yo realicé un hotfix al master. Hice commit y push, pero la conexión falló y el hotfix no se subió. En el programa Smartgit el check de hotfix subido se mostraba como siempre, aunque hoy se que a veces falla en las notificaciones.

  • No comprobé que realmente se hubiese subido. Antes de este incidente, era mi compañero quien cerraba los hotfixes. A raíz de esto, ahora soy yo quien los cierro.

  • Mi compañero cerró todos los hotfixes y features, sin corroborarlos de la lista de checklist que armamos entre todos, dando por sentado que estaban todos subidos. Chequeó el checklist sin revisar.

  • Realizó merge sin saber que había omitido un hotfix, que no había sido subido por mí.

De todo este fail, aprendimos:

  • Que si los procesos no se respetan (comprobaciones - de mi parte al subir el hotfix con un error de subida, de parte de mi compañero al no chequear que existiera el hotfix) el margen de error se dispara.
  • Que lo ideal es que cada quien cierre sus hotfix con el debido cuidado y trabajo en equipo a la hora de atender conflictos.
  • Nos integró más y mejor, porque ahora más que buscar quien es el culpable, buscamos de apoyarnos mutuamente para evitar errores, y contribuir a un resultado óptimo.

#failfast en mi caso creo que uno de los errores más comunes, es el actualizar el tablero canvan diariamente, considero que es un detalle súper importante y que cuesta hacer el habito.

#failfast Fue tratar de implementarlo sin mayores conocimientos más que las ganas y que durará menos que un candy… que se aprende? Volver a intentarlo hasta lograrlo!

#failfast Realizar un tablero y delegarlo (por ausencia) confiado que los participantes tenían los conocimientos correspondientes… el canva tuvo mas de 10 columnas !!! (se convirtió en un repositorio)

#failfast Soltar al equipo. Creer que el equipo estaba suficiente maduro como para soltar la mano y darme cuenta que rápidamente volvieron a viejas prácticas.

#failfast Mi fail con la agilidad fue la de intentar implementarla en el servicio público.

Hice una charla hace unos meses atrás para incentivarlos a usar las metodologías ágiles. Es difícil cambiar la mentalidad del trabajo en equipo, en especial porque en el servicio público se tiene mucho esa mentalidad de “era tu responsabilidad, para eso te envié un correo el dia xx que debías responder” a enfocarse en solucionar el problema.

De ha poco se ha transformado en una forma de trabajo “hibrida” es decir, adaptando ciertos elementos del scrum (la reunión diaria, los post it, el poker planning, entre otros) a la vida cotidiana. De atrás pica el indio, dice el dicho popular.

#failfast

  • En nuestra 3ra review el PO se quejo de la baja de puntos rendida por el equipo, reflejando que se habian entregado un 20% menos que con respecto al sprint anterior (2 equipos). A veces la mentalidad de Carta Gantt sigue vigente.

  • Trate de implementar un taskboard en mi casa y mi esposa me lo tiro por la ventana, :slight_smile: , cambios culturales requieren trabajar el cambio cultural.

  • nuestros primeros sprints en el actual proyecto fueron dificiles, muchas historias pegadas, habian demasiadas historias baiertas asignadas a un solo desarrollador, actualmente nos enfocamos en tener un pipeline fluido en que se trabaja 1 historia, máximo 2 al mismo tiempo, esto ha generado una mejora en como entregamos valor y ha fortalecido al equipo al trabjar mas cohesionado.

#failfast

En mis principios mientras recién estaba aprendiendo de agilidad y era líder de un equipo de desarrollo, junto a uno de los desarrolladores que era entusiasta en agilidad y que había logrado ya alguna experiencia, se nos ocurrió que todos fuéramos a unas charlas y taller gratis de Scrum. Al otro día el gerente general nos preguntan: dónde estaban? qué estaban haciendo? y nosotros les explicamos… para él estábamos perdiendo el tiempo o sacando la vuelta… en fin, nuestras conclusiones fueron: si el equipo recién está aprendiendo es necesario seguir aprendiendo pero en horario fuera del horario laboral hasta que, después de una base ya decente de conocimiento, recién pasar a intentar que la gerencia conozca del tema y luego lograr más “auspicio oficial” de la gerencia en potenciar más aún a los equipos e involucrándola también. Creo que siempre valdrá la pena.

#failfast
Mi mayor error fue hace tiempo, mientras trabajaba en sitio para hacer match de parejas, por la presión de entrega, sin horas de sueño, falta de pruebas unitarias y de integración. termine subiendo un sitio a producción con la clave 12345 del administrador. Paso que un tipo entro al administrador y empezó a llamar a todas las mujeres del sitio, fue una de las peores experiencias que he tenido.

  • No hacer pruebas unitaria o de integración, lleva a errores como esos y he sabido de casos peores.
  • La falta de separación de ambientes y de QA, la subida a prod fue hacer un dump de la base de datos de desarrollo y pasarlo a prod. el haber trabajado en devops me dio esa visión. un poco de esas practicas hubiese resuelto un monton de problemas.
  • Una cultura insana de entregar todo a ultimo minuto, sin pruebas unitarias sin nada y con los jefes encima todo el tiempo. me recuerda la parabola de los remeros

#failfast mi experiencia aplicando agilidad, surgieron varios errores, una de ellas es que no todos los integrantes del equipo no aolicaba agilidad, no les convencia el framework scrum. Y otro es que el product owner no siempre estaba para apoyarnos, como consecuencia la cantidad de sprint aumento de forma considerable, lo que me quedo de experiencia es motivar a los integrantes de las ventajas de la agilidad sin desmotivacion, y tener mas personas que tengan la misma vision positiva de la agilidad

#failfast mi gran error fue el de creer que siendo profesional formado, tenía las herramientas para coordinar un equipo de técnicos de bajo costo y poder salir adelante con una empresa pretensiosa de servicios multimídia de avanzada y finalmente ni los técnicos pudieran ejecutar los proyectos de automatización por falta de materia gris en algunos casos y conocimientos de idiomas y tecnologías nuevas.

#failfast Mis primeros días como scrum master trate de adueñarme de las historias de usuario! grave error, aprendí rápido a soltar y entender que es trabajo del PO y enseñarle a hacerlo. Saludos

1 me gusta

#failfast mi fail fue que en mi trabajo actual no prestamos atención a la retrospective, constantemente fallábamos en los sprints ya sea por estimaciones muy optimistas o escalaciones que afectaban la sprint y eso generaba falsas expectativas a la PO.

Luego comenzamos a sprintear solo las metas de esa manera cada sprint asumimos un compromiso inquebrantable en condiciones normales y cumplimos con las expectativa general. De cumplir con las expectativas temprano agregamos más tareas o trabajamos en inprovements o QA