Comunicando impedimentos a traves de Andon

¿Viste esos momentos en los que estamos profundamente inmersos en la resolución de un problema técnico en un proyecto?

Muchos de estos momentos son importantes ya que comunmente nos ofrecen grandes desafíos intelectuales, y una vez resueltos nos brindan momentos de gran satisfacción para nuestro sistema mental de recompensas. Siendo que muchas veces, especialmente cuando se trata de un proyecto solo, realmente no hay otra forma, tenemos que tener esta actitud heroica para ser "asesinos de problemas" en el proyecto, lleve el tiempo que fuese necesario (en minutos, horas o días), y a cualquier costo, al final sino las cosas no caminan.

Leer más...

Ágil es cultura no un proceso

Jeff Patton sugiere que Agil es una cultura que genera procesos y no sólo un proceso y debe afectar directamente la forma de enseñar a otros para adoptar Ágil. Introduce esta idea en una conversación:

Sentado con mi amigo Jonathan en el almuerzo la semana pasada, hablabamos sobre cambios en el proceso que él se sintió obligado a hacer. Agregó más equipos y los equipos fueron en aumento. Las cosas necesitaban cambiar. Jonathan, con razón, estaba preocupado con el hecho de que todos los nuevos procesos que se estaban añadiendo derrumbarían la comunicación fluida y el trabajo en equipo, el cual había trabajado tanto para promover. "¿Cómo mantenes estas cosas en tu proceso?", Preguntó.

Leer más...

Las 6 características de una buena historia de usuario

UsuarioUna historia de usuario describe funcionalidad deseada desde la perspectiva del cliente (el usuario). Una buena historia de usuario describe esta funcionalidad, quién la necesita, y cómo y porqué se va a utilizar. Los componentes básicos de una Historia de Uusario se pueden resumir en tres elementos:

Leer más...

Kanban en acción

KanbanNuestro proceso de construcción de sistemas no funciona con una metodología ágil "tradicional" con iteraciones de dos semanas (o Sprints). En cambio, usamos un sistema de Kanban para realizar los Pedidos de Cambio (PdC). Cuando se completa un PdC permanece en el estado Listo para Entregar, hasta que ocurre la próxima entrega planificada cada dos miércoles.

Aunque llevamos todas las PdC con Team Foundation Server, el trabajo del día-a-día ocurre sobre una pizarra con notas Post-It que se usan como tarjetas de Kanban.

Leer más...

Extendiendo la Integración Continua: el Despliegue Continuo

Producto de SoftwareJosé terminó de hacer un refactor en parte del código en el procesamiento de un sitio web. Como era un arreglo menor, José la terminó y siguió con la tarea siguiente.

Cuando se desplegó el código en producción dos semanas después, todo el sitio se cayó. Un único caracter mal escrito, que no se detectó con las pruebas automatizadas, ocasionó una falla en cascada que provocó la caida general. Llevó ocho horas poder aislar el problema, arreglar este único caracter mal escrito, desplegarlo y volver a tener el sitio productivo en linea. ¿Podrá hacer algo José para evitar que estos problemas vuelvan a ocurrir?

Leer más...

Cómo aplicar Programación en Pareja con éxito

Pulgar arribaHoy en día es muy común escuchar hablar de la Programación en Pareja. En general, la mayoría de los desarrolladores nunca tuvieron la oportunidad de trabajar correctamente de a pares, ni tienen ganas de hacerlo. Y para empeorar las cosas, la gente del negocio sigue pensando que dos desarrolladores en una única máquina es un desperdicio... ¿cómo será puede lograr una implementación exitosa?

Leer más...

Errores frecuentes en el Scrum Diario

Reunión de paradoLa reunión de diaria de scrum es un encuentro muy útil. Todos se enteran acerca del estado y los problemas de los otros miembros del equipo. Si el equipo está usando simplemente un afiche en la pared como backlog del sprint para seguir el trabajo restante, esta reunión también le recuerda a todos que reestimen sus tareas.

Acá dejo algunos errores típicos que la gente comete en el scrum diario:

Leer más...

Está demostrado: TDD mejora la calidad del software

TestingUn estudio publicado por la Empirical Software Engineering demuestra que TDD puede ser aplicado en distintos dominios y puede reducir de forma significativa la cantidad de defectos del software sin reducir la productividad de los equipos de desarrollo. El estudio compara a 4 proyectos en IBM y Microsoft que usaron TDD contra proyectos similares que no no usaron TDD.

Leer más...

¿Y qué pasa con los casos de uso en los proyectos Ágiles?

dibujoDean Leffingwell, autor de Scaling Software Agility, nos explica que los Casos de Uso son una herramienta valiosa para modelar requerimientos en proyectos Lean/Ágiles de gran envergadura. No es común encontrar casos de uso en los proyectos Lean/Ágil (especialmente en XP y Scrum), en donde se suele utilizar historias de usuario para recolectar los requerimientos.

Leer más...

El difícil trabajo del Dueño del Producto

lider de equipoEn Scrum, el rol del Dueño del Producto en Scrum es sumamente importante. Este trabajo no es fácil y requiere de mucho esfuerzo. De hecho, el Dueño del Producto es probablemente la persona más importante en el equipo de Scrum, ya que tiene que gestionar por si solo la responsabilidad de indicarle la dirección al equipo.

Leer más...

Examinando la aceleración ágil

lupaHace poco vimos el concepto de Aceleración como medida ágil de productividad en los equipos. La aceleración nos servía para ver cambios en la productividad de un equipo sobre un período de tiempo determinado.

Ahora vamos a analizar más en detalle algunas cuestiones relacionas con el uso de este indicativo para mejorar el rendimiento de los equipos ágiles de software.

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw