Agiles 2011 dia 2

Hoy no perdí el anotador, pero me olvidé la fuente, asi que cargué un alargador de seis metros con zapatilla de cuatro tomas con térmica de mas de un kilo en vano.

En lugar de atender a la key note, me puse a preparar una demo para proponer mañana en la open space. Tengo que montar un access point trucho para mostrar los inconvenientes de conectarse a redes desconocidas para integrantes itinerantes de equipos. Tiene que ser algo corto y efectivo, menos de 10 minutos para que haya tiempo para el posterior debate.

Primera charla, Hernán Wilkinson sobre los diez mandamientos de tdd, que resultaron ser mas. Transcribo y decoro mis notas:

Sacar los tests implícitos y efímeros de la cabeza del dev. Hacerlos explícitos, persistentes, repetibles y automatizables.

El buen programador lo es si y sólo si es buen tester.

La tabla de management:

Tdd es un cambio cultural, no automático, no ocurre por si mismo. Hay que proveer el entorno. Pair Programming ayuda. LLeva tiempo, que pata a mediano plazo. Mientras da una detección temprana de errores. No hay que abandonarlo por eventuales retrasos, o al menos hay que hacer explícita la desición. Tdd no es infalible. 100% cobertura no es posible ni tiene sentido. 60 a 80%.

Para medir la calidad de los test Mutation Testing: se invierten las relaciones de cada if y se ejecutan los test. Si no fallan, hay un problema.

No reemplazar QA por TDD. No mezclar Jr con Sr, si Jr con SSr y SSr con Sr. Para lograr el estado "test infected", puede llevar 3 a 4 meses.

Tabla de dev:

Primero se escribe el test.
Cada test debe tener un assert.
Un test a la ves (si estás muy creativo, el resto a una todo list afuera).
TDD no equivale a Unit Testing.
El nombre es el QUE, no el COMO y debe ser tan (ridículamente) largo como sea necesario.
En un test debe haber un solo caso.
No testear dos veces lo mismo.
Los test son otro sistema, keep clean.
No testear desde las interfaces, hacerlo desde el modelo.
No usar DB relacionales (al testear) por performance y por contaminación al modelo de objetos. Esto induce desacoplamiento.
No usar sistemas externos.
No hay que mockear el modelo.
TDD no implica buen diseño.
No preocuparse por la performance al comienzo.

Fin charla.


Luego me salteé el siguiente bloque para intentar levantar el fake AP. Me parece que lo logré, al menos Sergio lo vió. Pero no pude comprobar que funcionara, me quedé sin power. Termino de escribir esto y le doy.

La otra propuesta de sesión parte de que tengo un análisis FODA/SWOT de seguridad para una empresa de software que lleva a una colisión directa y brutal con el principio ágile de "transparencia".


Story Planning con Jeff Patton.

No voy a relatar lo que fue. Me desbordó totalmente, me va a llevar dias de trabajo subconciente asimilar toda la información. O un par de horas terminar de olvidar todo. Afortunadamente Sergio tiene algo parecido para dictar.

Buenas noches.