Así que hemos pensado que hasta estabilizar la situación, dejamos los sprints semanales y hacemos un sprint por cada historia de usuario. Lo primero que se hará con la historia es sacar con la máxima precisión los criterios de aceptación. Escribiremos tests end-to-end al inicio de la historia (siempre que el codigo legado nos lo permita) que validarán su consecución. Así sabremos con exactitud lo que está terminado y sabremos que funciona. Además la figura del middle-man que traduce las charlas con el cliente en historias y criterios de aceptación se diluye un poco y todo el equipo se encarga de analizar y conseguir esos criterios: Más cohesión entre análisis-negocio y desarrollo.

El equipo de QA se convierte en un cuello de botella por deficiencia del proceso (o ausencia). Decidimos que los responsables de QA tendrán un pequeño meeting diario para ver cómo van las incidencias. Los jueves se hará especial esfuerzo en probar todo para confirmar que se puede desplegar en producción.

Además dedicaremos el último pomodoro del día a probar entre todos las tarjetas que están en estado "listo para UAT" para que lleguen más filtradas al equipo de QA.

Es prioritario reducir al mínimo la distancia entre el código que hay desplegado en producción y la rama principal del control de versiones. El ideal es poder desplegar en cualquier momento la rama principal, ya que usamos ramas para funcionalidades que están sin terminar. No obstante, a veces nos gustaria desplegar aunque haya funcionalidad a medias. Por eso vamos a intentar seguir puliendo la técnica de feature branches y además añadir en alguna ocasión feature toggles.

La información del kanban al final de la semana no va a parar a ningún documento histórico ni estadístico. Esto va a cambiar ya, para que tengamos el registro más fiable posible de costes en el corto, medio y largo plazo. Me encargo yo mismo. Esta información lógicamente no será pública

La mejora contínua sigue adelante y en estas semanas hemos avanzado con paso firme en lo siguiente:

• Hay menos interrupciones. Antes de interrumpirnos entre nosotros nos preguntamos por skype o email y al terminar el pomodoro hablamos entre nosotros.
• Estamos más concienciados con probar a mano las tarjetas antes de pasarlas al equipo de QA.
• Cada día nos preocupa más la deuda técnica y pensamos más antes de programar.
• Las reuniones diarias (daily meeting) van cada vez más fluidas, tardamos entre 10 y 15 minutos.
• Las reuniones de retrospectiva son más directas y nos dan más información.
• El número de tests automáticos sigue creciendo y su calidad también. Hemos alcanzado ya los 500 tests con javascript.
• Hemos hecho varias mejoras de arquitectura sin que el cambio sea muy costoso ni traumático.
• Hablamos más unos con otros y discutimos sobre código y arquitectura en el proyector antes de lanzarnos a programar lo primero que se nos ocurre.

El camino es largo, pero vamos mejorando hacia XP. Sólo hay que seguir vigilando para no retroceder y seguir practicando la honestidad, la valentía de hacer lo que es bueno para uno mismo (y eso será lo mejor para el equipo) y el sentido común. Ser consecuentes con lo que se hace y constantes con las prácticas.

• The basics:

In order to send or retrieve objects to or from the database, you need a DataContext instance. This is an instance of a class that inherits DataContext. It is created by Visual Studio with drag and drop. One context is generated for every database you access to. This generated context is inside a .cs file which contains also the classes that map database tables. The mapping is contained in a .dbml file (xml) generated in the same folder. You should not change any of this generated files. If a table changes in the database you must regenerate with the IDE.

Select example:
If the name of the database is ProductionDB, the DataContext will be ProductionDBDataContext.

var context = new ProductionDBDataContext(connectionString);
var userEntity = (from user in context.Users
	where user.name == "carlos"
        select user).First();

Insert example:

var context = new ProductionDBDataContext(connectionString);
var user = new User();
user.name = "manolo"; 
context.Users.InsertOnSubmit(user);
context.SubmitChanges();

• The main issue:

The same context instance have to be used for all the operations performed on a relational object instance. This would throw an exception:

var context = new ProductionDBDataContext(connectionString);
var userEntity = (from user in context.Users
	where user.name == "carlos"
        select user).First();
// Imagine this is part of another method in another place
// but with the same userEntity instance that was passed through:
userEntity.age = "30";
var otherContextInstance = new ProductionDBDataContext(connectionString);
otherContextInstance.Users.InsertOnSubmit(user);
otherContextInstance.SubmitChanges();

So you can't just pass relational objects from one method or layer to anoter, you have to always cope with the "same context instance problem".

•  Solutions

1. Pass the context instance along with the relational objects, in all the places where you need to perform database access:   someMethod(user, context);
   Bad choice: This leads to spaguetti code quickly. Why  does my business layer have to know about a database context?
2. Ok so we can make a Singleton for the context instance and make sure it is the same for all the application:
   public static ProductionDBDataContext AppContext = new ProductionDBDataContext(connString);
   Bad choice: When more than one request hit the server at the same time you get concurrency problems. The context will be trying to insert in one thread while trying to update or select in other. Weird race conditions happens and exceptions are thrown.
3. Create a context for every thread. Every thread will have its own context Singleton. We found this solution thanks to Rick Strahl and his great post. However Rick's code can be simplified this way:

public class ContextFactory
{
	[ThreadStatic]
	private static ProductionDBDataContext context;
	private string connString = "settings to access the database ...";
 
	public static DataContext Context(){
		if (context == null)
			context = new ProductionDBDataContext(connString);
		return context;
	}
}

The ThreadStatic attribute ensures that every thread will access a different instance. So the "context" is not shared amont threads. This simplifies Ricks's code. But our problems didn't stop here unfortunatelly

You might expect the thread to die when the response is sent back to the client side, but it doesn't. Sometimes IIS reuses the thread for other requests, and the context is not a new, fresh instance. Moreover, the context caches some queries and that leads to several issues:

1. The optimistic concurrency control nightmare. The default behavior is for "Linq to Sql" to check every db column on update, to see if there are more than one simultaneous attemp to persist the entity. If so, it raises the ChangeConflictException. This can be avoided by editing the dbml and marking every column with "Never" in the UpdateCheck property. Guess that.... when you regenerate the dbml file, this is overwritten and you loose your configuration. More information on conflicts here.
   One way to deal with conflicts is to catch the exception and force the update:

   var someEntity = ... // query here
   try
   {
       context.SubmitChanges(ConflictMode.ContinueOnConflict);
   }
   catch (ChangeConflictException e)
   {
      context.Refresh(RefreshMode.KeepCurrentValues, someEntity);
   }

   However, this does not avoid the cache invalidation problem.

2. The cache invalidation problemis the last one we have found and solved so far. The solution is to drop the cache as the new request enters the server. To refresh the cache just create a new instance of the context:

   public class ContextFactory
   {
   	[ThreadStatic]
   	private static ProductionDBDataContext context;
   	private string connString = "settings to access to database ...";
    
   	public static DataContext Context(){
   		if (context == null)
   			context = new ProductionDBDataContext(connString);
   		return context;
   	}
   	public static void FlushContext(){
   		context = new ProductionDBDataContext(connString);
   	}
    
   }

   Then, in the first layer of the server side (where the request is received) we call FlushContext to make sure it is new for this request. (For us is our JsonRpcController, a custom make controller hierarchy).

For now, we can rest assured that our DataContext is:

• Unique for every thread so it is thread-safe.
• Unique for every request so there are no cache problems among different requests.
• If two different parts of the application need a context's instance in the same request, our factory gives a single reference (Singleton), making sure that only the first access initializes it (because we check whether it is null before instantiating).

Los metodos y funciones deben devolver un solo resultado y en ocasiones, ninguno (void). ResponseDTO se puede considerar "un solo resultado" cuando los campos "success" y "message" se necesitan el uno al otro, tal que no tiene sentido el objeto sin los dos campos. Es decir cuando el objeto es lo más atómico que la operación puede devolver. ResponseDTO se ideo para enviar a cliente (js) respuesta a determinados comandos que solicita al servidor pero no debería usarse en las otras capas de la aplicacion.

¿Dónde lo usamos mal? Tenemos métodos con un nombre interrogativo que denotan retorno boolean y sin embargo devuelven uno de estos ResponseDTO:

• IsExistingUser
• DoesPolicyExists
• IsValidInput

Para cualquiera que lea la API, no es intuitivo. ¿Para qué sirve el "message" del objeto cuando el método "IsExistingUser" retorna? Para nada.

En la validación, puede tener sentido este objeto response dependiendo del contexto: Si el error de validación puede considerarse una circunstancia excepcional, entonces lo mejor es lanzar una excepción que alguien de nivel superior recogerá. Por tanto, sobra el objeto response ya que la excepción llevará el mensaje de validación particular. Si un problema de validación no se considera una circunstancia excepcional, entonces puede estar bien devolver el response con su success puesto  a false y su mensaje concreto.

Más sitios donde lo usamos mal: Métodos que disparan acciones hacia fuera de nuestro sistema

•  SendEmail
•  SaveUser

Los métodos que provocan acciones que salen de los límites de nuestro código (acceso a BD, a un servidor de correo, etc) no pueden garantizar la correcta consumación de la acción. Por tanto, jugar a devolver boolean para exito o fracaso es engañarnos.
Es preferible un método void que funciona sin hacer ruido cuando todo va bien y que lanza excepciones cuando se encuentra con una situación inesperada. Por ejemplo, el método que solicita el envio de un email, puede defenderse de excepciones que provoque la libreria de SMTP y traducirlas en excepciones de nuestro dominio, tales como EmailSendFailure (una excepción nuestra que hereda de ApplicationException).

¿Y es tan grave que usemos el ResponseDTO? Sí que lo es porque el código que consume esos métodos se convierte en spaguetti:

var isNotValidData = !InputValidator.ValidateUserData(
                          policyHolder.Person).success;
if (isNotValidData)
{
	response.message = Strings.T("Los datos son incorrectos.");
	return response;
}

Del método "ValidateUserData" sólo nos interesa el campo "success", el mensaje lo está generando el llamador. No sólo es raro de leer sino que es un coñazo a la hora de escribir tests de interacción. Cuando queremos que en un test de colaboración, este método devuelva falso, tenemos que especificar que devuelva un objeto con un campo a falso. Si fuera boolean, no tendriamos que especificar nada porque el valor por defecto sería false. Esto va al hilo del posts de los tests de interacción limpios.

En el caso de métodos de acción como el envio de email, es incluso peor porque quien consume el método pensará que con un resultado verdadero el email ha llegado a su destino, como si eso lo pudiesemos asegurar de alguna manera.

Para saber qué debe devolver un método, este debe tener una única responsabilidad y debemos saber cual es. Y la mejor manera de saberlo, para mi siempre es escribir el test antes que el código.

In order to write cleaner interaction tests (those which use test doubles; mocks, spies, stubs) you should understand how your test doubles framework works. Interaction tests can be extremely difficult to read and maintain and very fragile if you don't pay enough attention. We will review Mockito, Moq, Jasmine and pyDoubles.

Mockito and Moq create a double object by inheriting the original and overriding its methods. pyDoubles uses interception rather than inheritance. Jasmine is different because it does not double the whole object, but just the method you spy on. So there is a big difference: Mockito, Moq and pyDoubles replace the whole object while Jasmine replaces just one method.

So Jasmine leaves space for a bad testing practice: Spy on one method of the object while testing other method of the same object. Interaction tests are intentded for object collaboration. Testing that one method calls another method within the same object is not recommended. It means that the object has more than one responsibility or that you want to know more about the object's inner behavior than you should, so you are breaking encapsulation. This is not a Jasmine problem, the problem is yours if you don't use the tool properly.

There are three primary reasons to replace method calls on collaborators:

1. You want to avoid a database call just to keep the test unit fast and repeatable (stub the method - use a stub object)
2. You want the method to return some value to simulate the response (stub the method - use a stub object)
3. You want to make sure that a call is made (spy or expect the call - use a spy or a mock object)

For case numer 1, you don't have to specify the returned value. Just use the stub object and let the framework return whatever it wants. Mockito and Moq, return the default value for the method, when no other behavior is specified:

• If the method returns an integer, a call to that method in the stub object, will return cero (default value for integers)
• If the method returns an object (reference type), a call to the stub method will return null (default for objects)
• False for booleans and so on...

However, be careful with Moq because in C#, if the original method is not virtual (contains the virtual keyword), Moq can't stub it out, so the original will be called. Moq fails if you specify a behavior on that method but if you don't, it calls the original instead of returning the default value.

pyDoubles always returns None no matter the method signature.

For case numer 2, you define what the returned value should be. Using "when" in Mockito and "Setup" in Moq.

For case numer 3, you verify that a call was made:

• Mockito: verify(double).method();
• Moq: double.Verify(x=>x.method());
• pyDoubles: assert_that_method(double.method).was_called()
• Jasmine: expect(double.method).toHaveBeenCalled()

You might want to know what parameters were passed in too. In this case you can use Matchers in Mockito, Moq and pyDoubles.

Moq sample:

userRepository.Verify(x => x.SaveNewUser(
        It.Is<Person>(
        p => p.PersonalIdentificationCode == "TEST_CODE")));
 

pyDoubles sample:

assert_that_method(double.method
         ).was_called().with_args(obj_with_fields({
                            'id': 20,
                            'test_field': 'OK'}))

For Mockito samples I am waiting for my friend @regiluze to write a post on it I will link it here when written.

Jasmine sample:

spyOn(double, "method").andCallFake(function(){
      expect(arguments[0].name).toEqual("Carlos");
});

Test collaborations one to one:

If the object under test has more than one collaborator, tests can be really hard to understand. I recommend expressing every collaboration in a single test:

• A talks to B (test 1)
• A talks to C (test 2)

• For test1, B will be a spy o mock (you use Verify at the end). Also for test1, you don't care about C, C is just a dummy. Calls to C don't need to be configured in the double, let the framework return the default value.

• For test2, C is the spy or the mock, you verify interaction between A and C, and do't care about B. Calls to B don't need to be configured, let the framework return whatever.
• For test1, if the value returned by C, is necessary for the collaboration between A and B, then Ok, specify the stub result for that call to C, and verify on B.

Group the tests by setup:

Should I have a test class for every class in the production code? NO.  Tests must be grouped by their setup. This is, put those which have the same arrangement in the same test case (test class). If there are two or more interaction tests in a class, the creation of the SUT and the doubles, should not be in every test. It must be in the setup, along with the injection (doubles, are injected to the SUT as collaborator). So, if you find yourself injecting the test double to the SUT in more than one test, watch them again carefully.

Cada cambio era una patada a mi ego, porque me sacaba de la zona de confort y me hacía sentir que perdía mi valía, la maestría de la herramienta que tanto me habia trabajado.

Y resulta que en lugar de perder, estaba ganando. Si no hubiese tenido que pasar obligado por todos estos cambios, no tendría la visión que tengo hoy en día sobre patrones, técnicas de programación, arquitecturas ... la tranquilidad de que me cuesta muy poco adaptarme a una nueva plataforma porque siempre contiene elementos de otras que ya conozco. Me da seguridad en mi mismo y me ha quitado por completo el apego a las herramientas. Programo en lo que sea y estoy deseando seguir aprendiendo lenguajes, frameworks.

Disfruto programando cualquier lenguaje y sé qué elementos me interesan usar de un framework y qué otras partes me puedo saltar. Solo porque he tenido que trabajar en muchos.

Ahora que estamos buscando gente para que se una a nuestro equipo, donde usamos mayormente .Net con C# y por otro lado Javascript, sé que mucha gente no tiene interes porque no quiere abandonar su stack tecnológico de siempre. Parece que programar .Net fuese lo peor del mundo, cuando es tan solo una copia de Java que lo mejora en muchos aspectos. Se van copiando el uno del otro. Además puedes usar F#, IronPython, IronRuby, Boo, y aprender de algunos de los programadores más increibles del planeta.

Me parece muy bien que la gente tenga predilección por frameworks como, Django, Symfony, Rails o Grails pero la negativa a usar otra cosa, tal como yo lo veo, es una cuestión de apego  poco racional. En algunos casos, yo diría que inmadurez. Además, los proyectos no duran para siempre, son etapas, son transiciones como la vida misma.

Todos los que me habeis dicho personalmente (amigos mios) que nos veníais por el stack tecnológico, creo que aún teneis que seguir madurando profesionalmente.  Y yo tambien, por supuesto. Lo digo sin rencor ni enfado de ningun tipo.

Contínuamente me digo a mí mismo... no dejes que el ego frene tu aprendizaje

Typical way to stub out a method call with mockito:

when(colaborator.method(argument1)).thenReturn(whateverIwant);

Same with Moq:

colaborator.Setup(x => x.method(argument1)).Returns(whateverIwant);

Obviously, the mockito way is nicer. I believe this is because of Java capabilities but I am not sure. I would like to dig into mockito's source code to see how is this possible. I will do it and blog about it soon. I used to think that it was because of the kind ot late binding supported by Java, but I am not sure.

Moq uses a lambda expression (anonymous method inlined) to tell the framework which method and how is expected to be called). The reason I use "x" for the object in the anonymous method is because it refers to "colaborator" itself so there is no point in adding more names.

The other important difference relates to the "virtual" keyword in C#. Methods in C# are final by default. You can't override them unless they contain the keyword "virtual" on its signature. Both, Mockito and Moq create test doubles by subclassing on runtime, overriding methods and implementing the fake behavior on them (as far as I know). So, if the method you want to stub is not virtual, Moq will throw a runtime exception. If it is not virtual but you don't specify any fake behavior on it, it will not throw exceptions, but worse, it will call the actual implementation. So you might be hiting the database in your unit tests inadvertedly. What I do, is that all my methods are virtual by default (I write "virtual" on their signature).

There will be more posts on this topic

• Que cuando reimplementemos una funcionalidad (o una similar a otra que ya tuviesemos), contemos con las personas que desarrollaron la primera versión. Lo ideal es que las personas que estuvieron en el primer desarrollo estén haciendo pareja con quienes se enfrentan al problema por primera vez. Si no es posible, al menos deben sentarse a hablar de las dificultades que surgieron con la primera implementación y las soluciones que se encontraron.
  Lo primero será tratar de evaluar si se puede reutilizar parte del código existente. No siempre es fácil tomar esta decisión pero por lo menos hacer un estudio rápido de la situación. En caso que se pueda reutilizar, estudiar qué se debe refactorizar y a qué se le pueden añadir tests. En caso que haya que reescribirlo todo por completo, tener presentes las ideas que ayudaron más al buen funcionamiento de la primera implementación. Esto es: aprovechar la experiencia que ya tenemos.
• Separar muy bien lo que es importante de lo que es urgente. Si todo es urgente, dejamos de saber lo que es importante. Nos ha pasado y nos ha perjudicado. Cuando digamos que algo es urgente, tendremos que saber que corremos peligro de dejar atrás lo imporante.
• Tratar de evitar la entrada de imprevistos durante el sprint. Tiene que ver con lo anterior. Si surge una necesidad el jueves y no es bloqueante, debemos plantearnos esperar a abordarla el lunes, es decir, en el siguiente sprint. La idea es no romper la planificación semanal. Cuando la rompemos, nos distanciamos de los objetivos propuestos y entonces dejamos de ser predecibles. Ser predecibles es una de nuestras metas porque así sabremos cada vez mejor, cuánto podemos tardar en entregar funcionalidad con valor para el negocio.
• Evitar hablar de "terminar tareas" y hablar más de poner en producción tareas que suman valor. No sirve querer terminar, sino querer desarrollar piezas que mejoran la experiencia del usuario. Cuando pensamos en terminar, es más fácil hacerlo mal (porque lo urgente quita de enmedio a lo importante). Rara es la semana que no se introducen nuevos requisitos en funcionalidad que estaba "terminada".

Esta semana estoy muy contento con la labor técnica del equipo:

• Se ha respetado en todo momento que todos los tests pasen
• Se han añadido tests para demostrar bugs
• No recuerdo que se hayan escrito métodos nuevos de más de 10 líneas.
• No se han introducido números mágicos ni código duplicado
• Se ha prestado bastante atención a la code review y los commits han sido muy claros.

Es importante vigilar bien que sigamos por el buen camino, porque estamos en un punto en que retroceder lo andado no es muy dificil.

Buen comienzo de semana a todos

Por este motivo, la reunion del lunes podrá estirarse hasta un máximo de una hora con tal de que todos podamos estimar y comprometernos a entregar determinada funcionalidad el viernes, o por lo menos a intentarlo.

Aunque nuestra hora de meeting son las 9.30am, el lunes desplazaremos la hora lo que haga falta para que estemos todos. Esta semana faltaron personas que al no estar en el meeting de planificación no pudieron aportar su conocimiento. Eso llevó a que yo escogiera como prioritaria una tarea que en realidad no lo era, porque ya teniamos una funcionalidad parecida, hecha en código existente pero no lo sabíamos. Era una funcionalidad que conocía la persona no estaba. La tarea que se ha implementado hacía falta pero no era tan prioritaria en el sprint de la semana que ha terminado.

Por otro lado existe preocupación porque no estamos colocando las clases en los namespaces más adecuados, ni los ficheros en las carpetas adecuadas. El problema es que si no están en un lugar intuitivo podemos repetir funcionalidad. Para esto la code review juega un papel importante, por lo que hay que seguir haciendo incapié en ella. A parte de eso, la persona que detecte que se ha puesto un fichero en el sitio incorrecto o un namespace que no corresponde, debe actuar de manera concreta, bien modificando el código o bien avisando por email a los compañeros, diciendo exáctamente por qué no es correcto y cómo solucionarlo.

En el código legado sigue habiendo horrores que nos están haciendo daño pero la preocupación por la ubicación de clases y ficheros es un tema recurrente así que vamos a intentarla solventar, tomando acciones concretas y constructivas.

Esta semana hemos resuelto graves problemas de concurrencia que teníamos. El trabajo ha sido duro porque hemos invertido mucho tiempo y escrito pocas líneas de código y eso da mala sensación, pero el resultado es muy bueno. Hemos aprendido bastante y sabemos qué cuestiones debemos considerar desde ya, para que nuestro código esté preparado para la concurrencia. Escribiré un post sobre nuestros descubrimientos con Linq2Sql y concurrencia pronto.

En las últimas semanas hemos hecho muy poco pair programming porque buena parte del equipo pensaba que así avanzaríamos más teniendo la fecha de entrega muy cercana. La realidad es que no podemos cuantificar si ha salido adelante más trabajo o no, pero lo que sí hemos hecho es introducir deuda técnica y aumentar en desconocimiento de lo que los demás hacen, lo que lleva a la duplicidad del código. Falta comunicación. Sabemos que la próxima semana volvemos a nuestro ritmo habitual, intentando hacer las cosas lo mejor posible y sabiendo que cuando dos personas trabajan juntas y bien concentradas, nos acercamos más a ello.

Bloque teórico-técnico:

• ¿En qué consiste el patrón Singleton? ¿Cuándo lo usarías?
• ¿En qué consiste el patrón Factory? ¿Cuándo lo usarías?
• ¿Qué es la inyección de dependencias?
• ¿Qué diferencia hay entre mock y stub?
• ¿Cómo es el algoritmo TDD?
• ¿Qué significa SOLID?
• ¿Por qué motivo harías una clase abstracta?
• ¿Qué libros técnicos has leido y recomendarías leer?

Bloque sobre habilidades personales (si hizo delante de nuestro tablón kanban):

• ¿Cómo crees que funciona nuestro panel?
• ¿Qué información puedes obtener mirandolo?
• En medio del desarrollo de una tarea que has iniciado, se acerca el dueño de producto y te pide que añadas nuevos requisitos ¿Qué haces?
• ¿Qué actitud de un compañero te puede llegar a irritar?
• ¿Qué haces si detectas un conflicto abierto entre dos compañeros tuyos?
• Un compañero se salta deliberadamente las convenciones y buenas practicas adoptadas en el equipo ¿qué harias?

Muchas gracias a todas las personas que escribieron mostrando interes por venir a hacer la entrevista y sobre todo a las dos personas que al final vinieron.

Ahora continuamos rumbo a la excelencia técnica y de producto. El lanzamiento de producto que hemos hecho esta semana, es el primer salto hacia una nueva etapa de la empresa y del equipo. A por ello!

En la retrospectiva de esta semana hemos hablado sobre todo del proceso de desarrollo. Nuestro proceso se apoya en kanban, no hacemos scrum. Scrum es demasiado lento para la velocidad con que nos entran peticiones de cambio de funcionalidad. Nuestros sprints son de una semana y el objetivo es la entrega constante.

Lo que ha sucedido esta semana es que las tareas terminadas se han acumulado a las de sprints anteriores y hemos perdido la información de qué funcionalidades se estaban entregando. La solución que se nos ocurre es que la persona que recoge las incidencias y se encarga de notificar a los clientes de su resolución y de nuevas funcionalidades, esté presente en las reuniones 

diarias (daily stand up meeting). Además las tarjetas del kanban estarán tambien en nuestro trac, cuando coincidan con historias de usuario (hay tarjetas más pequeñas que una historia de usuario). Intentaremos que todo el mundo conozca el estado de una funcionalidad desde que se escribe la historia de usuario hasta que se notifica al usuario su puesta en producción. Para ello, todo el mundo es responsable de ayudar a definir bien las historias de usuario, si van a entrar en el WIP (work in progress) y nuestro dueño de producto no ha tenido tiempo de estudiarlas a fondo. Cada uno se reponsabiliza al coger una tarjeta para implementar, de que se finaliza, de que no se queda nada atrás y también de que se avisa de cuándo está subida a producción.

Esta semana toca hacer pruebas de carga de nuestros sistemas para estar seguros de la cantidad de conexiones que podemos aguantar con la puesta en marcha de nuestro nuevo producto. El objetivo de las pruebas de carga no es lanzar muchas peticiones contra el servidor y ver que aguanta, sino hacerle peticiones hasta que se caiga, y entonces tener la medida más precisa posible de hasta cuánto aguanta. Lo contrario sería un falso positivo.

Por otra parte, el haber elegido javascript como lenguaje principal para las nuevas aplicaciones, ha aumentado temporalmente el bus factor y los viernes estamos haciendo sesiones formativas sobre el lenguaje, aunque necesitamos que todo el equipo lea libros en su tiempo libre. En otras circunstancias no pediría al equipo que leyese en su tiempo libre temas profesionales pero siendo una empresa de poco tamaño que tiene metas tan fuertes, no queda más remedio.