Su navegador no soporta JavaScript. Poker Consultant expert advice to Agile developers - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS

Alex Sutherland se licenció en Cal Tech hace unos años y continuó con el programa de doctorado en matemáticas y econometría. Sin embargo, su afición al póquer en línea le estaba generando todo el dinero que necesitaba y se dio cuenta de que la PokerStars La interfaz de usuario no era adecuada para jugadores serios con varias partidas simultáneas.

Formando equipo con un socio de una empresa de software de Los Ángeles que hace Scrum, decidieron implantar el mejor front-end para jugadores de póquer experimentados del sector. TableNinja envió su primera versión del producto Scrum unos meses después.

Alex obtuvo su credencial ScrumMaster en un curso reciente en Beverly Hills y afirma que Scrum les ha ayudado definitivamente a él y a su socio a duplicar la productividad y que funciona mejor a distancia que colocado. Cuando trabajan a distancia, se desconcentran. Cuando trabajan a través de Skype se mantienen concentrados. Como resultado, dicen que sus próximas contrataciones serán probablemente fuera de Estados Unidos.

Esta observación es la misma que hizo el director de tecnología de Xebia en nuestra ponencia en Agile 2008 el año pasado. Los equipos que están la mitad en los Países Bajos y la otra mitad en la India funcionan mejor en su entorno que los equipos ubicados, así que hacen todos sus proyectos de esa manera. Por supuesto, hay que hacer un Scrum realmente bueno para conseguir este efecto.

TableNinja asesora a jugadores de póquer serios de todo el mundo y algunos de los mejores alumnos de Alex están en lugares como Tokio, fuera de Estados Unidos. Dice que sus recomendaciones a los aspirantes a campeones de póquer son las mismas que hace a los desarrolladores de software.

Su juego se divide aproximadamente en tres categorías:

Juego A: todo el dinero se gana en el juego A. El jugador/desarrollador típico funciona a este nivel menos del 10% del tiempo.

Juego B - aquí es donde usted hace pequeñas cantidades de dinero, probablemente 40% de su tiempo.

Juego C - aquí es donde pierdes pequeñas (o quizás grandes) cantidades de dinero alrededor del 40% de las veces.

El objetivo de Alex como entrenador es aumentar tu juego A a 20% de tu tiempo y hacer que tu juego B sea lo suficientemente bueno como para pagar tus pérdidas en tu juego C. Si haces esto, podrás ganar tanto dinero como necesites (y quizás más) jugando al Poker.

El problema para los jugadores de Poker y los desarrolladores de software es que no se mantienen concentrados cuando están en su juego A y dejan de jugar cuando se dan cuenta de que están jugando su juego C. Son como un taxista que tiene un objetivo de $300 al día. Son como un taxista que tiene un objetivo de $300 al día. Durante una conferencia, cuando pueden ir y venir del aeropuerto, hacen $300 en una hora y abandonan. El resto del tiempo trabajan 12 horas al día hasta que consiguen sus $300 dólares. No entienden que sólo deben trabajar el día de la conferencia de esa semana.

La recomendación de Alex es codificar como un loco cuando estás en la zona y dejarlo inmediatamente cuando estás cansado o aburrido. Me di cuenta de esta recomendación encaja muy bien con la observación de Tom Poppendieck de una empresa XP que hizo un experimento con diferentes semanas de trabajo por hora para ver cuando los equipos de XP que hicieron la programación en parejas intensiva alcanzaron su máxima producción de software despachable. En esa empresa, las semanas de 16 horas entregaban la mayor cantidad de software listo para producción.

Sintonizar, encender y abandonar la carrera de ratas podría ser un buen consejo para los desarrolladores ágiles. Puedes empezar jugando un poco TableNinja para hacerte una idea. Mejor aún, únase a nosotros en Beverly Hills Scrum Formación de certificación a finales de este mes y aprender a hacer esto en el desarrollo de software.

es_ARSpanish
Acciones