Escrito por Mike Cohn

Traducido por el grupo de contenidos de agile-spain

Artículo Original

La gente se resiste a cambiar a Scrum por muchas razones diferentes. Algunos se resisten porque se sienten cómodos con su trabajo actual y sus compañeros. Han tardado años en llegar a sus niveles actuales dentro de la organización, en estar en este equipo, en trabajar para ese director o para saber exactamente cómo hacer sus trabajos cada día. Otros pueden resistirse a cambiar a Scrum debido al temor a lo desconocido. "Más vale lo malo conocido que lo bueno por conocer" es su mantra. Y otros pueden resistirse debido a una verdadera aversión o desconfianza hacia el enfoque de Scrum. Puede que estén convencidos de que desarrollar productos complejos, de forma iterativa y sin un fuerte diseño inicial llevan al desastre.

Hay tantas razones para resistirse a Scrum como maneras de resistirse. Una persona puede resistirse con una lógica bien razonada y fuertes argumentos. Otra puede resistirse de forma callada y saboteando los esfuerzos por cambiar. Y otra puede resistirse simplemente ignorando el cambio, trabajando a la antigua en la medida de lo posible y esperando que la próxima moda haga que Scrum desaparezca.

Escrito por Uncle Bob

Traducido por el grupo de contenidos de agile-spain

Artículo Original

Últimamente hay un interes creciente por las Katas de Software. ¿Qué es todo este ruido, y por qué puede ser importante?

Hace varios años Dave Thomas (Pragmatic Programmer) inició un blog especial sobre la programación de katas. La idea era simple: los profesionales practican.

Quizás no se te había ocurrido antes, pero es evidentemente cierto por sí mismo. Los músicos profesionales practican. Los bailarines profesionales practican. Los médicos practican. Los soldados practican. De hecho, cualquier tipo de artesano profesional debe practicar el oficio que ejerce a fin de desarrollarlo bien a la hora de la verdad.

El punto de Dave fue que los programadores profesionales necesitan practicar como cualquier otro profesional. Estableció una serie de sencillos ejercicios y problemas que los programadores podían resolver durante su tiempo de práctica. También sugirió que el tiempo de práctica debía ser planificado y protegido como parte de la rutina normal de un desarrollador de software.