Así no se hacen las cosas por Ernesto Kiszkurno

La elaboración de una estrategia de pruebas en un proyecto puede ser una actividad crítica para su éxito. Lograr la satisfacción de los stakeholders involucrados tiene mucho que ver con entender el nivel de calidad que ellos esperan y luego con alcanzarlo. No obstante, la literatura de testing de software ha tratado poco este tema. Este post presenta algunas preguntas iniciales relacionadas con dicha actividad. #1 ¿Qué es una estrategia de pruebas? Una estrategia de pruebas es un documento formal que determina entre otras cosas el nivel de calidad pretendido y los mecanismos a utilizar para garantizarlo. También es un contrato entre partes puesto que es producto del trabajo conjunto de todos los involucrados en el proyecto. Su alcance usualmente es un proyecto en particular, aunque también pueden aplicarse estos conceptos a un programa, a un área o a una organización. #2 ¿Por qué es importante tenerlo? Tener definida una estrategia de pruebas nos permite, entre otras cosas: Def

Leyendo este post en el blog de Luciano Tourn me enteré de la existencia del Independent Activities Period en el MIT. Como dice Luciano, el IAP está destinado a que los miembros del instituto pueden realizar actividades independientes de índole diversa, no asociadas a la agenda académica. La iniciativa se apoya en la idea de que un ambiente descontracturado, libre e independiente aumenta la probabilidad de tener pensamientos disruptivos y de generar innovación . Pensando en esto me vinieron a la cabeza dos ejemplos más de la misma situación. Ejemplo 1 Google, con otro estilo, también busca promocionar "momentos" para tener pensamientos disruptivos. En la página de Google en Wikipedia explican: "As a motivation technique (usually called Innovation Time Off), all Google engineers are encouraged to spend 20% of their work time (one day per week) on projects that interest them." Ejemplo 2 En una charla de Richard Hamming , él mismo comenta que también se hi

Leyendo el libro La ética del hacker y el espíritu de la era de la información de Pekka Himanen encontré varias referencias al Jargon File . Para los que no lo conocen este archivo se define a si mismo como a comprehensive compendium of hacker slang illuminating many aspects of hackish tradition, folklore, and humor. Navegando un poco en su contenido me encontré con una breve historia que me resultó muy simpática llamada A story about Magic . Luego de arduas reflexiones determiné que el origen de esta simpatía proviene de dos pensamientos: Mientras leía la historia y trataba de situarla en "algún lugar" - uno hace eso cuando lee -, no pude evitar imaginarme que esto tranquilamente podría haber transcurrido en el Pabellón 1 de Ciudad Universitaria allá por el año 1994 cuando usábamos el Mosaic y pasaban por mis manos las primeras máquinas Unix. En más de un sentido me caen muy bien los Hackers y me identifico con algunas de sus cosas.  Seguimos pensando.. PD: Para en

El concepto de fábrica en servicios está un poco "sobrecargado". La gente le dice fábrica a muchas cosas. O lo que es muy parecido, cada uno de nosotros, cuando habla del concepto "fábrica", lo hace con una definición propia y diferente de la de los demás. En el caso de fábricas de testing de software por ejemplo, usualmente se habla de fábrica cuando se quiere hablar de servicios remotos, tercerizados y estándarizados. No obstante, al estar hablando de servicios, las variables y variantes para configurarlos son infinitas (como sabemos, los servicios se producen al mismo momento que se consumen, son intangibles, son eternamente modificables, etc.). Se produce así una contradicción. Por un lado se espera lograr una "fábrica" con estandarización, economía de escala y precios bajos; y por el otro se espera consumir servicios flexibles y ajustados a la realidad de cada cliente. ¿Qué es una fábrica para nosotros? La respuesta a este dileman no es sencilla

Hace unos días terminé de leer Design de Tom Peters a modo de reconciliación con él, luego de su faltazo al World Business Forum Buenos Aires del año pasado. Design es parte de una serie titulada "Essentials". Talent, Trends y Leadership son los que la completan (todavía no los leí). Vienen en una linda edición, pocket ideal para leer en cualquier lado. Como mi anterior lectura de Tom Peters fue "In search of Excellence" mis expectativas eran altas y debo decir que me quedé un poco con las ganas. Me encontré con un libro escrito en una forma inusual, muy sintética. Me hubiera gustado más desarrollo de algunas ideas y una escritura que permitiera una lectura más fluida. No obstante, destaco 3 ideas sobre el futuro de las empresas que me entusiasmaron. Las empresas estarán dirigidas por el diseño . El diseño como generador de valor. El precio, los costos, la funcionalidad, todo será un piso necesario del cual partir. Las diferencias se verán en la estét

Como muchos saben, los temas relacionados con Web 2.0 ocupan gran parte de mi CPU últimamente. Por eso cuando hoy leía el post de Martín Mendez titulado Managemente Innovación 2.0: co-creando valor , y luego la conversación planteada por Juan Carlos Lucas en este post y Sebastián Paschmann en este , mi cabeza generaba ideas en cantidad. En particular uno de los temas en los que pensaba está relacionado con la forma de bajar a la práctica el tema de la Innovación en la empresa . Supongo que sería como hacer un doble-click en el tema de Innovación planteado por Martín. Para romper el hielo voy a decir que "Innovar no es una opción sino un deber " . En el mundo actual es necesario innovar para poder sobrevivir. No hacerlo nos hace retroceder frente a nuestros clientes, nuestros empleados y la competencia. ¡Seth Godin diría que no hacerlo es volverse aburridos! Pero ¿cómo hace el mismo grupo de personas que todos los días interactúa por temas operativos para cambiar su mode

Cerca de la oficina hay un restaurante donde dejan encuestas de satisfacción para completar. Como no hay muchos lugares para comer donde sucede esto, me sorprendí para bien y completé el formulario. En realidad completé la encuesta en 2 ocasiones pensando en que por ahí mi próxima visita al lugar sería más placentera. Ya transcurrió un tiempo de la última vez que completé la encuesta y veo que el nivel de servicio es el mismo y las cosas que me molestaban del lugar siguen allí. La conclusión obvia es que no leyeron mi respuesta o si la leyeron, decidieron no actuar sobre ella. Cuando uno está en el negocio de dar servicios tiene que hacer encuestas de satisfacción. Son imperfectas y a veces las respuestas son injustas pero la información que dan es importante y la señal que transmiten al cliente también. Cuando la respuesta es positiva, nos inyecta energía y nos orientan en el camino de la mejora. Cuando la respuesta es negativa, nos permite actuar de alguna manera y cambiar la histo

Ayer terminé Brain Rules de John Medina. Un libro interesante aunque por momentos un poco detallado y técnico (si quieren tener un panorama de que trata pueden ir al sitio , vale la pena). Anyway, en el cierre hace una reflexión con la que estoy muy de acuerdo. The greatest Brain Rule of all is something I cannot prove or characterize, but I believe in it with all my heart. As my son was trying to tell me, it is the importance of curiosity. La curiosidad es una fuerza importante para desarrollarnos profesionalmente. Es un motor que nos lleva de un lugar a otro, que nos saca de la "zona de confort". Sin ella nos quedamos y si nos quedamos, retrocedemos (como en la cinta de los aeropuertos). Eric Sink tiene un post que leí hace muchos años llamado Career Calculus donde define una ecuación lineal para nuestra carrera y nos alienta a trabajar sobre ella. C = G + LT C is Cluefulness . It is defined as an overall measure of your capabilities, expertise, wisdom and knowledge

Las metodologias agiles están de moda. En desarrollo de software son una corriente fuerte que gana terreno aceleradamente en empresas y equipos de trabajo. Pero lejos de quedarse en el ámbito del desarrollo de software, es posible encontrar multiples iniciativas orientadas a extrapolar los principios ágiles a otras disciplinas o simplemente generalizar el uso de estos módelos, técnicas y metodologías. En el libro Scrum Manager - Gestión de Proyectos hay una interesante discusión sobre las diferencias entre la gestión de proyectos predictiva y la gestión ágil. Allí se comenta que la gestión predictiva tiene dos premisas fundamentales: Todos los proyectos mantienen características y comportamientos regulares. El objetivo de la ejecución de un proyecto es lograr el producto previsto en el tiempo planificado, sin desbordar los costes estimados. Por el otro lado comenta que La gestión ágil surge al cuestionar la validez de las premisas de la gestión tradicional: no hay una forma ú

Para poder usar un teléfono celular prepago hay que pagarlo anticipadamente. True. De esto se deduce que si la gente no puede pagar, no puede hablar y entonces la empresa pierde ganancias (la máxima dice "minuto que no se habla, minuto que no se cobra"). En algunas empresas además, las facturas prepagas se deben pagar por internet. Esto está muy bien pero ¿qué pasa cuando la página donde uno tiene que pagar no funciona? Si, acertaron. Por el párrafo anterior, si la página no funciona, la empresa pierde ganancias [1]. Me permito traer esta escena de la vida cotidiana - es de estos días y de una empresa que funciona en el mercado local - para mostrar una forma de razonar sobre las implicancias de no testear. Si no testeo - sistemáticamente - corro el riesgo de que la página de facturación no funcione y si esto ocurre cada minuto que la página está caída representa para mí una suma de dinero conocida que la empresa pierde (además de otra suma desconocida que la empresa tam