Así no se hacen las cosas por Ernesto Kiszkurno

Hace un tiempo atrás escribí este post sobre la importancia de pensar en la estrategia de pruebas en ciertos proyectos. Esta semana, gracias a Ariel , pude leer un post titulado Basics Revisited: Test Strategy que está muy alineado con lo que escribí en aquel momento y con lo que pienso sobre la problemática. Si bien vale la pena leer el artículo, extraigo 6 lecciones importantes: Pensar en la estrategia, no en el documento. No burocratizar el proceso. Arrancar con diagramas y esquemas, no con el template de documento. Procurar poner la estrategia en una página . Pensar en para qué testeamos y qué testeamos. Los stakeholders deben ser parte de las decisiones tomadas y deben conocer los riesgos que asumen. Comunicar la estrategia antes para que los que quieran puedan opinar. No enamorarse de la estrategia, cambiarla de acuerdo a la evolución del proyecto si es necesario. Como siempre digo lo importante es vivir el proceso de armar la estrategia y

Continuando con lo que hablaba en aquí sobre tareas, quiero hablar un poco sobre la estructura proyecto-tarea. Como algunos de ustedes habrán notado, hay algunos programas para gestión de tareas que permiten organizarlas en forma de árbol. Esto es armar jerarquías sin un límite de niveles determinado del estilo: Ítem 1 Ítem 1.1 Ítem 1.1.1 Ítem 1.1.2 Ítem 1.2 Esto, que a priori parece ser visto como una ventaja, a mi criterio puede ser una gran desventaja para los seguidores de GTD . Y lo digo principalmente porque va en contra del factor clave del método que es la simplicidad . Enuncio a continuación algunas de las complicaciones que este tipo de estructuras anidadas provocan en una lista de tareas : El concepto de proyecto se hace más complejo. Dado que puedo anidar ítems en la jerarquía puedo tener sub-proyectos dentro de sub-proyectos dentro de proyectos. En este contexto, ¿qué significa terminar un sub-proyecto? El concepto de tarea pod

Hoy hablaba con un colega frustrado que me decía "estoy cansado de los cobardes" refiriéndose a esa gente que primero pide desafíos y luego, cuando se les dan, no los toma como propios y prefiere esconderse en excusas. Mientras escuchaba recordé un ensayo de Seth Godin llamado The Will and the Way que se publicó en el libro Purple Cow . Extraigo el primer párrafo aquí: "I don't think there's a shortage of remarkable ideas. I think your business has plenty of great opportunities to do great things. Nope, what's missing isn't the ideas. It's the will to execute them." Godin habla de ideas, mi colega de responsabilidades y desafíos. Para mi están hablando de lo mismo. El saber popular ha registrado la misma enseñanza con otras dos frases muy conocidas: (1) del dicho al hecho, hay mucho trecho (2) es más fácil decir que hacer. Muchas veces no se trata de talento o de creatividad, aunque tener estas cosas hace el camino mucho más fácil, sino de pe

Yo sé que me voy a ganar algunos enemigos con este post pero ya llevo mucho tiempo con esta idea dándome vueltas en la cabeza y creo que ya es tiempo de que salga. Necesito escribiría o por lo menos empezar a enunciarla y escuchar opiniones por supuesto. :-) En mi trabajo cotidiano es común encontrarme con excelentes desarrolladores, personas inteligentes, preparadas y experimentadas. Excelentes técnicos va. Pero que [muchas|algunas] veces caen en una pequeña confusión. Se enamoran de la programación en si misma perdiendo de vista el verdadero fin de la actividad que es crear software a un costo y en tiempos razonables que pueda usar el usuario . No sostengo que buscar la excelencia sea algo malo, para nada. Está muy bien lograr un buen diseño, tener un buen modelo y trabajar con la mejor tecnología posible pero siempre teniendo en claro el contexto en el que nos movemos y las limitaciones que tiene cada proyecto. Veo muchas veces desarrolladores empecinados en construir el mejor softw

Como todos los años, entre el 25 y el 30 de julio, en la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires, se realizará la edición 2011 de la Escuela de Ciencias Informáticas. A continuación transcribo la comunicación recibida: Los invitamos a colaborar en la difusión de la ECI 2011, que se realizará desde el 25 al 30 de julio y que en esta oportunidad cumple su 25º aniversario. Nos gustaría que desde sus instituciones y/o empresas den a conocer la información de la ECI y recomienden a sus colegas que participen. En el siguiente link pueden descargar las Gacetillas de Prensa, el Afiche y el Folleto (con cursos). Aprovechamos para comentarles algunas novedades de esta 25º Edición: Habrá 10 cursos con temáticas muy variadas: Robótica Móvil, Metabiología, Agromática, Seguridad con Haskell y Python, Análisis estático de aplicaciones .Net, Aprendizaje Automático, Programación con MPI, Modelado y simulación de sistemas físicos y dinámicas mundiales, Inf

En el blog de Google se publicó este post donde se presentan algunos “features” nuevos en Google Apps y hubo uno en particular que me hizo pensar: the default meeting length. ¿Imagínense tener una regla para toda la organización que diga que ninguna reunión puede durar más de una hora ? Y por que parar ahí, no? ¿Por qué no implementarla con clientes y proveedores también? ¿No ganaríamos mucho tiempo? ¿No ganaríamos en productividad? A mi me encantaría … aunque a veces parece algo utópico. ¿Qué creen ustedes? Seguimos pensando..

Apuesto a que si miran en su lista de tareas van a tener alguna tarea del estilo “preparar la gran presentación para el cliente X” o “planear viaje a YY”. Sí, estoy hablando de tareas que son muy difíciles de realizar o más bien imposibles. Cada vez que las vemos nos da pereza empezarlas y que además, una vez que lo hacemos, es casi imposible saber cuándo estarán terminadas. Pero ¿cómo debe escribirse una tarea para que podamos decir que está bien formulada? Bueno, navegando por la web me encontré con un viejo post de Merlin Mann titulado Building a Smarter To-Do List en el que se describe exactamente eso. Fiel a mi estilo recomiendo ir a la fuente y leer el post pero ya que estamos destaco algunas de las ideas más potentes. La primera tiene que ver con lo que debemos pedirle a una tarea bien formulada. The best and most useful to-dos share common qualities: it's a physical action it can be accomplished at a sitting it supports valuable progress toward a recognized go

Me encuentro muchas veces ante la pregunta de si es mejor tener un área (o grupo) de testing independiente o tener gente que hace testing formando parte de los distintos equipos de desarrollo. La idea detrás de la pregunta es que optando por alguna de las opciones (o estrategias) el problema de medir y controlar la calidad está resuelto. El razonamiento me parece equivocado y la razón es que ambas estrategias tienen fines diferentes. El objetivo de un área independiente de testing dentro de un área de sistemas es controlar la calidad con la que liberan software los distintos equipos de desarrollo. Ellos están para medir el nivel de calidad a la salida del proceso de desarrollo. Tener un área permite lograr una visión independiente de la calidad, que no está sesgada por la agenda del equipo de desarrollo, optimizar costos, tener mayor especialización en el tema y hacer más foco en la calidad. El objetivo de tener gente que hace testing formando parte de los equipos de desar