Archive for the ‘Agile’ Category
Compartir la visión de equipo
Para que un grupo de desarrolladores trabaje como un equipo, tal vez sea importante que todos sus miembros tengan el mismo concepto de equipo.
¿Cómo es el equipo que queremos ser? ¿cuáles son las características que nos gustaría que tuviese cada persona del equipo?
Si tenemos una visión diferente de cómo debe funcionar el equipo, no conseguiremos llegar a ella porque cada uno rema en una dirección distinta.
Puede que tan sólo sea cuestión de detenerse un momento, reflexionar y decidir qué significa ser integrante de este equipo. Consensuar con los demás los valores y principios que
nos parecen claves. Y que de ese consenso busquemos prácticas que nos ayuden a ser el equipo que queremos y nos hagamos fuertes.
Un principio que me gusta aplicar es el de hacer con los demás lo mismo que me gustaría que hiciesen conmigo.
Así que voy a pensar cómo me gustaría que fuese un compañero de mi equipo para poner yo mismo en practica esos hábitos.
Voy a hacer mi propia lista de "me gustaría...", la cual podemos completar entre todos los miembros del equipo. Aquí va.
Me gustaria que un compañero... (o compañera, por supuesto)
- Me pudiese cubrir perfectamente cuando estoy enfermo o de vacaciones sin que me tengan que llamar por teléfono contínuamente o pedirme que me conecte remotamente cuando no me encuentro en condiciones para ello.
- Se tomase el tiempo de explicarme lo que sabe para que cuando se marche de vacaciones o se ponga enfermo, no me sienta totalmente perdido.
- Me pidiese ayuda o hiciese programación en pareja conmigo cuando conozco mejor el código o el negocio que él o ella, porque así ganamos tiempo y aprendemos todos a la vez.
- Me pidiese ayuda o trabajásemos juntos cuando sabe que el código que tiene que modificar es complejo y prefiere estar seguro de que no rompemos nada.
- Me enseñase técnicas y prácticas que conoce para ser mejor profesional.
- No me hiciese contarle más de tres veces una técnica de desarrollo sin que la tenga anotada y estudiada.
- Trate de asegurarse por todos los medios que los cambios que ha introducido en el código no rompen funcionalidad existente (no introduce defectos).
- Ejecutase los tests antes de subir su código al repositorio para evitar que me tenga que poner a arreglar tests que se han roto con cambios que no he hecho yo.
- Tuviese la iniciativa de arreglar un test que no ha roto él o ella, cuando el compañero que lo rompió por accidente, ha sido avisado, pero no se puede poner con ello en ese momento. (Si quien ha dejado el test roto no suele romperlos sino que se trata de un caso excepcional).
- Revisase mi código para entenderlo, detectar mejoras o sugerirme alternativas.
- Criticase mi código constructivamente para ayudarme a mejorarlo y a superarme yo mismo.
- Usase las partes de la aplicación que he hecho yo, para darme feedback como usuario.
- Me pudiese sustituir en cualquier momento dándome la seguridad de que lo va a intentar hacer igual de bien que lo intento yo.
- Esté abierto a recibir críticas constructivas y a aprender cada día.
- Reconozca sus errores y se esfuerce por no cometer el mismo muchas veces.
- Se alegre por mi progreso profesional y me apoye para que siga mejorando.
- Tenga la iniciativa de aplicar cambios sobre código que he escrito yo, cuando necesita ser ampliado funcionalmente y yo no lo pueda hacer en ese momento (porque esté ocupado con otra tarea). Que no me haga sentir que soy el cuello de botella sino que me ayude a quitarme la presión de encima. Y que cuando cambie el código se asegure de que todos los tests siguen pasando y ha puesto el mismo nivel de cuidado en el código que el que he puesto yo.
- Cuando tiene que introducir deuda técnica porque no le queda más remedio, lo anote y vuelva al código a saldarla tan pronto como el momento de presión termine.
- Cuando tiene que modificar código de baja calidad se esfuerza por mejorarlo y no sólo por añadir a trancas y barrancas la nueva funcionalidad sobre la maraña.
- Se cuestione si está haciendo lo mejor posible en cada momento y rectifica para ir en esa dirección.
- No haya que repetirle las cuestiones con las que ya en otra ocasión hemos acordado que nos vamos a comprometer.
- Escriba código que puedo entender sin tener que preguntarle a nadie. Y además lo puedo ampliar y testear con facilidad.
- Antes de tomar decisiones que tienen repercusión sobre los demás, las discuta con los implicados.
- Si no está de acuerdo con algo que digo, tenga la sinceridad de decirmelo a la cara en el momento adecuado, mejor que a destiempo.
- Por tanto el equipo que yo visualizo se mueve en bloque, es homogéneo porque comparte unos valores y principios.
En mi visión de equipo no entra esto de "yo hago mi parte y tu la tuya", y cuando pasa algo en la parte que es "tuya" te llamamos para que la arregles tu. En una situación excepcional si, no hay reglas fijas ni matematicas puras para el día a día.
En esta visión tampoco hay tareas que siempre hace la misma persona porque es la única que sabe y parece que siempre va a seguir siendo así.
No puede haber personas que parecen ser imprescindibles. En realidad nadie lo es por muy alto que sea su bus factor. La vida sigue aunque unos marchen y otros lleguen.
Pero mi visión de equipo no sirve si mis compañeros no la comparten.
El compañero al que recuerdo con una sonrisa es el que me lo pone fácil en el día a día. El que no me obliga a verme sometido a presión innecesaria por un trabajo que él o ella ha hecho con neglicencia. Que no me obliga a hacer horas extra por su falta de cuidado.
Ser un amigo no tiene por qué ser lo mismo que ser un buen compañero. Ser un tío majo y agradable no significa ser buen compañero. Es de agradecer tratar con compañeros agradables pero eso no hace un buen equipo por sí sólo.
Puedes rellenar este interesante cuestionario sobre el nivel de agilidad de tu equipo y reflexionar sobre los resultados: http://www.abetterteam.org/new
Animaría a los equipos a redactar su propia lista de cualidades de un miembro del equipo y a colgarla en una pared grande, donde siempre sea visible para todos. Que nuestro ego no se pase por el forro esa lista sin que se note, sino que de el cante y podamos poner a ese ego en su sitio en favor de los valores del grupo.
No es otro que el ego quien causa problemas a individuos y grupos. Hay que vigilarle.
¿De verdad necesitas estar a la última?
La mayor barrera a la que un equipo se enfrenta a la hora de practicar XP o cualquier método ágil, son las personas. La falta de madurez y de compromiso imposibilita la paz sostenible de la que tanto se habla. Ambas, madurez y compromiso pueden a veces inferirse por el nivel de consumismo de los individuos.
Conozco demasiados programadores que van a la última en tecnología, pero que NO lo necesitan.
Probablemente cuando sacan de la funda el último móvil o el último portátil que acaban de comprar se sientan más importantes. Esto es lo que vende la televisión y la publicidad en general de las grandes marcas. Yo sin embargo no puedo evitar pensar que es una persona excesivamente consumista. A su vez eso puede significar que:
- Aún vive con sus padres. Sus niveles de madurez, iniciativa y responsabilidad son mediocres.
- Nunca se ha parado a pensar en el impacto que la fabricación de ese hardware tiene sobre el planeta y sobre los pobres chinos que están explotados fabricandolo. Esto es falta de compromiso con el planeta, que lo está pidiendo a gritos.
- Es muy probable que jamás haya donado dinero para ninguna causa social, animal o medio ambiental. Ni siquiera a su proyecto open source favorito. De nuevo, poco compromiso. Puede que resultase ser un compañero demasiado egoista como para hacer un buen equipo.
- Es demasiado materialista como para importarle el crecimiento personal de sus compañeros lo suficiente.
- Es una persona que compra compulsivamente porque no tiene claras sus metas, no sabe por qué razón se levanta cada mañana.
No tienen que cumplirse todos los puntos, incluso puede que ninguno. Si los lees y te pica, entonces tu sabrás. Pero esto no es malo si te sirve para reflexionar sobre ello. Simplemente significa que tienes que deternete un momento y pensar más en lo que haces y en por qué lo haces. Que lo hagan todos tus amigos no significa que sea correcto. Has venido al mundo para hacerlo un sitio mejor, igual que mejoras el código legado cuando pasa por tu manos, aunque te llegue lleno de mierda hasta las trancas. Esos son los valores que necesitamos para practicar XP.
No necesitas mirar twitter cada 5 minutos. Piensa en la manera en que estas faltando el respeto a la persona que ha quedado para tomar café contigo, cuando estas escribiendo un tweet vació sobre el bonito uniforme del camarero. Los móviles que se vendían hacen pocos años tienen una batería que dura una semana entera. Se habla por telefono de puta madre y se pueden enviar mensajes SMS. ¿Necesitas poder consultar tu email en el tren? Ok, te vendrá bien un smartphone. ¿Pero de verdad no puedes esperar a gestionar tu email con tranquilidad? Seguramente el conductor del autobus se sentirá mejor si al subirte le das los buenos dias en vez de ir escribiendo en tu telefono nuevo. Puedes mandarle un tweet de buenos dias pero es más rápido que se los digas de boca a oreja.
No necesitas que tu portatil tenga 4 núcleos, 8gb de ram y una SSD de 200gb si trabajas con un pc de sobremesa que ya tiene las prestaciones suficientes. Si es tu herramienta de trabajo principal y realmente eres más productivo con ese hardware, adelante, se productivo. ¿Pero es de verdad tu necesidad? Los portátiles que fabricaban hace 6 años siguen corriendo perfectamente Linux y Windows. Con renovar la batería y ampliarle un poco la ram, van de lujo.
Ahora está de moda comprar un portatil Mac. Si vas a un evento y no tienes uno pareces un aficionado. Ya sabemos todos la polémica que hay con la fabricación de los Mac en cuanto al nivel de explotación en las fábricas y a pesar de ello... ¿es de culto tener uno?. Por desgracia pocas serán las marcas que se preocupen por las personas y el medio ambiente. Si eres más productivo con MacOS, está bien pero ¿no te vale con uno de segunda mano? ¿se van a reir de ti tus amigos? Yo no tengo un Mac, porque ahora mismo en el trabajo uso forzosamente Windows y en casa llevo una década usando Linux y encuentro que soy suficientemente productivo con el. Tengo Vim, Emacs y mucho mas! 
Por cierto que el stack tecnologico del trabajo me obliga a usar un pc sobremesa del copon gracias a que Microsoft no repara en recursos con sus sistemas operativos. Intentaremos usar Windows 7 por 20 años porque para la siguiente version, nos va a hacer falta un reactor nuclear. Es otra opción que hay que barajar, no actualizar de version Windows hasta que no quede otro remedio. De hecho Windows XP va estupendo para todo lo que no sea Visual Studio 2010.
¿Esto significa ser antiprogreso? Solo significa tomar las decisiones por motivos bien claros y no por parecer mas geek. Ser más geek mina los proyectos, las relaciones con los clientes, la relación con los compañeros y hasta calidad del software. ¿A ti te pega que Martin McFly llegase a casa con su skate volador y escribiese métodos de 5 lineas? A mí no.
¿Eres tu McFly con los aparatos mágicos? ¿tal vez el Inspector Gadget?
Si no te habías parado a pensarlo, ya sabes que eso no te hace más profesional a los ojos de todo el mundo. Para ser más profesional y una persona más integra, hay que prestar atención y practicar. En ello estamos. Si puedo ayudarte, grita, yo también estoy intentando aprender todo esto
Aquí dejo un video que me parece fenomenal con Joán Melé hablando del dinero y la crisis. Yo la crisis no la estoy percibiendo economicamente en mi trabajo (sí en mi familia) pero sí que percibo una crisis tremenda en el sector por una falta de valores que nos permite ser ágiles de verdad.
RS: Sprint por historia de usuario
Con una entrada de trabajo tremenda los sprints semanales se han ido terminando sin consecución de las metas esperadas. Cada semana con un poco más de atasco y menos objetivos cumplidos. Uno de los factores principales es que los criterios de aceptación no estaban claros y ello provoca trabajo en vano. Por falta de análisis se toman decisiones equivocadas que tienen un alto coste y una estimación imposible (estimar sin saber con precisión lo que se necesita es "duro"). Se hace muy difícil calcular el valor que se aporta al negocio y la prioridad de la tarea. Se invierte un tiempo en planificación y retrospectiva del sprint para que no se termine la tarea.
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.
Un solo valor de retorno
Hay un mal que se esta extendiendo por la aplicación en las últimas semanas. Es el ResponseDTO. Es un objeto plano, tiene un campo "success" de tipo boolean y un campo "message" de tipo string. Debía llamarse Response pero colisionaba, así que se quedó con un mal nombre. Si le hubiesemos llamado ControllerResponse seguramente no se hubiese usado en las otras capas de la aplicación porque hubiese dado más pistas a quienes lo fuesen usar, de que su lugar es la capa controller. Sin embargo se ha colado en muchas capas de backend y no es una buena práctica:
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.
RS: Aprovechar la experiencia
En el sprint de esta semana nos hemos dado cuenta de errores cometidos semanas atrás. Las acciones más importantes ahora para seguir mejorando, son:
- 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
RS: planificación de sprint
Nuestros sprints son de una semana, empiezan el lunes y terminan el viernes. Planificamos en el daily standup meeting del lunes por la mañana. Pero el daily no queremos que pase de los 20 minutos (mejor seria no pasar de los 15). Asi que las últimas dos semanas, terminabamos el meeting sin haber cerrado la planificacion semanal, sin tener las tareas estimadas y por tanto, sin conocer cuál era el objetivo a cumplir. Eso hace que al terminar la semana no sepamos si lo hemos hecho mejor o peor. Dejamos de ser predecibles cuando pasa esto.
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.
RS: Trazabilidad
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.
Javascript, an acquired taste
You hate it, you love it
You start hating it but you might end up having so much fun with Javascript. It takes time to acquire the taste and enjoy the powerful capabilities that annoy you at the beginning. This is my experience learning this popular language.
Take into account that my opinion is based on just a few months of experience with Javascript as a language, not just a tool to manipulate the DOM (html and css). It will probably change along the journey.
The white box
Being used to languages like Python, I'd say Javascript is a white-box language while Python is a black-box one. That is, you don't really need to read books to start coding in Python, you just see some example code, try some lines and usually its execution behaves as you expected. It feels so natural. That is not the case of Javascript, its rules are not natural at a first glance. In fact, you have to know very well how the interpreter makes decisions. If you make a mistake writing some code that wouldn't compile or would raise an exception on other programming languages, Javascript will instead try to execute the code. And will probably traverse all the execution path. Because it doesn't fail, this behavior can be very confusing and hard to detect. You wish the interpreter to tell you that, you made a mistake and you probably didn't want to write what you did, you don't want the execution to continue. That is the feeling at the beginning. On the other hand, as time goes by, these capabilities turn out to be so powerful in terms of implementation choices and performance tuning.
Unfortunately coding for performance tuning leads to code that is hard to understand and maintain.
TDD is a must
We've been pairing and test driving our Javascript code these months using Jasmine. I feel that the impact of BDD on Javascript is bigger than on any other language. It's mandatory. I don't want to write a single line of production code if there is no failing test asking for it. Because Javascript forces me to be smarter than I am sometimes and ocuppies part of my mind with subtle implementation details that moves me away from writing code that expresses the business domain, the semantic of the actual business problem to solve.
If I don't write a test, a specification that clearly states what I expect the code to do and see it pass, I can't bet that it will work just by looking at the production code. It would feel like gambling.
There is a tone of patterns to avoid tipical Javascript mistakes. There are many books on the subject. Experts advise you techniques like, "check the type of the arguments the function receives, to make sure you get what you expect". But then they tell you that "instanceof" operator might not work if the inheritance wasn't implemented properly. It is overwhelming. I tell you a secret... you don't need to master all those patterns if you test drive your code! You don't have to worry about all possible usages of your code if it's you or your team who are going to consume it, because the specifications are already thought, written and are executable.
I always prefer "duck typing" than asking for the type of the arguments. I usually prefer to let Javascript evaluate conditions using its coercion rather than using strict operators like "===" or "!==". Because if you write code for humans, it is better to say:
"if (userExists)"
than
"if (userExists === true)".
So the approach and the concerns are totally different when you test drive the code. The productivity gain is brutal. Javascript is too expensive to work with if you can't guarantee all the time, that your code functions as you inteded it to be.
If for some reason I would not be able to develop with BDD, I would code with Coffescript rather than Javascript
The approach is totally different if you are writing a framework. Frameworks are too general, they are horizontal, not vertical so there is no business semantic on them. So yes, for frameworks you should be a Javascript power ranger.
OOP or Funtional?
Javascript is not a classical objet oriented language. There are no classes. However is a great language for object oriented programming! Don't be confused with this. If you know the object oriented paradigm, you just need to know how to implement polymorphism, composition and so on. The discussion on "there are no classes, there are prototypes", is superfluous. It is an implementation detail I don't care about. I don't think that is really important because I can express behavior with objects and model the domain the same way I would do it in Java. Rather than using "class" and "extends" I would use "constructor stealing along with prototype chainning". But it's the same tool
On the other hand, javascript is a great language for functional programming too It is actually more used as a functional language than as an OOP one. It is very common to pass functions as parameters and things like that.
You can approach different paradigms with Javascript. My advise is to not mix them together though.
Programming the UI is fun again!
I used to write desktop applications using Delphi, pyGTK and Windows Forms at the beginning of the past decade. When the web started getting mainstream, it was sad to say goodbye to all the best practices learned all those years. Used to the power of event oriented programming, rich components, data binding, and design patterns in general, developing for the web felt a step back. During the past decade there have been many attemps to mimic the old desktop in the web; portlets, asp webforms, and so on. None of them made developers happy, so the Model-View-Controller (MVC) pattern came to the rescue. However, dealing with the UI is still something developer don't really use to enjoy. DOM manipulation has been a pain in the ass with every browser having different behavior and API. I've been trying to avoid it until now and, to be honest, I am happy to not have invested my time fighting with problems that jQuery handles for me nowdays.
Now, ECMAScript 5 is supported in all major browsers. jQuery and other frameworks make life easier. And there is something that we didn't have in the old desktop programming: the chance to programmatically interact with widgets (UI controls or components). Well there are some frameworks for that in the native desktop, by they came late. This means that we can write automated tests for UI behavior!
So now, we have the chance again to use event driven programming, to really implement patterns like the "observer" and many others. And we can test drive all of them!
We can develop semantic components that add domain knowledge inside UI widgets and make the user experience way better. There is no need for intrusive frameworks that tell us exactly all the layers to be used and how. Everything is ready to craft the code to make it express as much human knowledge as possible.
So we are taking the chance.
No need for MVC frameworks
In the first two weeks of the project we started using Backbone. In the first spike, we used the whole framework. A bit later, just the models and collections. Nowdays, we have completely got rid of it. It is a great framework, but we don't need MVC frameworks anymore on the client side because they are more restrictive than we need. We don't develop "screens", we try to create "smart components" that can be reused and provide a different level of abstraction. The screen is just a place holder for components that can be injected. With the rich UI programming that Javascript give us today, the paradigm has changed. It is time to retrieve practices from 15 years ago mixed with best practices learned in the latest years. I wouldn't port or copy exactly what we have been doing recently.
RS: enfocados hacia la calidad
Este post de retrospectiva vale por las últimas semanas. Desde el último post de retrospectiva hasta ahora, estamos notando una evolución espectacular en el equipo, tanto en el compromiso que cada uno demuestra escribiendo código de calidad como en la responsabilidad de completar las releases semanales. En la pizarra que usamos en la última reunión de retrospectiva aparecieron más anotaciones positivas que anotaciones de mejora Sin embargo en este post voy a resaltar lo que queremos lograr.
La cuestión es no parar aquí porque sigue quedando muchisimo camino por recorrer. Simplemente seguir trabajando duro con ayuda de esta sensación de progreso que va calando en el equipo.
Lo que queremos hacer:
- Los commits aún más cortos y legibles (tengo pendiente un artículo sobre esto que saldrá en la proxima tirada de agilerecord.com). Evitar que los commits lleven diferencias en tabulaciones y espacios para que no se registren cambios que no son de verdad en código sino en configuración del editor de texto.
- Un branch por feature: tenemos que quitarnos de encima el agobio de que el dia de la subida de versión el branch principal no acaba de estar fino para mezclarlo con estable. Al empezar una nueva funcionalidad iniciaremos un nuevo branch. Cuando se toca código cómun se mezclará con la rama principal y se compartirá para que los demás tengan el cambio disponible lo antes posible.
- Acelerar la velocidad de nuestras máquinas. En compilar el proyecto (.sln) y lanzar los tests se iba un minuto en cada maquina. Insoportable e impracticable para hacer TDD. Hemos cambiado dos máquinas comprando todo el hardware nuevo, doblando la memoria RAM, y poniendo discos duros nuevos. También hemos optimizado la configuración de la compilación. Ahora se tardan 3 segundos en compilar y otros 3 en pasar los tests. Con eso recuperamos más que de sobra la inversión en hardware. Pero aún quedan varios compañeros con equipos lentos. Es muy importante resolverlo cuanto antes.
- No hacer cambios en base de datos sin hablarlo primero con los demás y sin que sea totalmente inevitable. Nuestro objetivo es que la BD sea lo último que se toque, tratando de modelar primero el comportamiento en el código.
- No olvidar pasar todos los tests despues de hacer "merge" y dar la voz de alarma cuando alguno se ha roto.
- Mejorar el tiempo de respuesta de las incidencias.
- Seguir formándonos, leyendo libros y practicando ejercicios. En la sesión formativa de los viernes y en casa.
- Conocer más el código que hacen los demás y la funcionalidad para evitar duplicarla. Tener aún más cuidado en la code review de las mañanas.
- Automatizar la generación de bases de datos de quita y pon, para pruebas de integración.
- Cuando el código legado es abrumador, nos trazamos un mini "backlog" de los cambios que queremos conseguir hacerle y una estimacion de tiempos para irlo haciendo (ej: en 15 minutos, cambiar este método para que en lugar de recibir 7 parametros reciba un objeto).
Logros:
- Aumento de lo concienciado que está el equipo para escribir código más legible y mantenible para los compañeros.
- Despliegues automáticos. Yeah!!
- Estamos priorizando mejor. Nadie ha tenido que hacer ni una hora extra porque hemos afrontado a tiempo todas dificultades y la comunicación va mejorando.
- El número de incidencias va descenciendo.
- Se están haciendo más commits y más pushes (nos acercamos a la media de 3 commits por hora).
- Se hace pair programming cuando es productivo y se programa por individual cuando la pareja se da cuenta que no se está aprovechando bien.
RS: Pomodoros
Esta retrospectiva vale por las dos últimas semanas. Lo que todo el mundo ha visto fácilmente y en consenso es que nos hace falta respetar más los pomodoros, de ahí el título de hoy.
Estamos contentos porque se van notando cambios muy positivos. Los repasamos juntos:
- Refactor sólo donde duele: no tocamos código que funciona, si no tiene bugs (que sepamos) y no hay que ampliar su funcionalidad.
- Refactorizamos siempre para alcanzar "the low hanging fruit": Extract method y Extract constant nos dan beneficio rápido sin apenas coste.
- No nos metemos con tareas que no son de desarrollo funcional salvo que hayamos hecho un estudio claro y concreto de ventajas y desventajas: Mucho cuidado con las tareas de infraestructura u otras que no sean directamente entregar valor a corto plazo.
- Code reviews: Sabemos que no pueden durar mas de 15 minutos al día asi que somos selectivos para combinar con pair programming con el objetivo de la propiedad colectiva del código. Están empezando a dar fruto. Ya sabemos que hay que mirar si el código que queremos hacer, lo ha hecho alguien ya. Reutilizar el esfuerzo de los demas.
- Pair programming: nos damos cuenta cuándo hay que unirse en pareja y también cuándo hay que separarse. A veces nos equivocamos en los dos lados, por no hacerla y por hacerla.
- El bus factor es malo, sabemos que lo tenemos que ir reduciendo poco a poco.
- Un equipo XP entrega valor al negocio constantemente, sin parar.
- El pomodoro nos lo tenemos que tomar todos más en serio. Demasiada interrupción, aunque no para todos, para los que tienen mayor bus factor.
- El daily meeting se hace a su hora, esté quien esté. Ya casi siempre respetamos el tiempo y conseguimos contar lo importante.
- Los meetings fuera del daily, son tóxicos. Mejor dejarlos para el viernes despues de la comida porque nos consumen mucho tiempo y es dificil valorar lo que aportan.
- Nadie escribe código basura a conciencia. Ninguna prisa justifica escribir un código mal sabiendolo hacer bien. Si no se sabe hacer mejor, vale, de eso me voy encargando yo, poco a poco.
- No tenemos tiempo para que todo el mundo aprenda todo lo que nos gustaria que supiera durante las horas de trabajo. Cada uno ha elegido ya un libro de la lista y la empresa ha comprado un Kindle además de libros en papel para continuar con la formación que ya tenemos en el día a día. Los viernes hay exposición aunque hoy nos hayamos comido el tiempo de Jaime con la restrospectiva. Sorry!