Colaboración
- Ayudar a otros es una prioridad. Echaremos un cable siempre que nos sea posible a un compañero.
- Respetamos el flow de los compañeros, aprovechando los momentos ideales para interrumpirlos como puede ser a primera hora, después del almuerzo, etc).
- Las personas cometemos errores, esto es normal. Cuando sucede, somos transparentes y honestos para buscar así la mejor solución posible entre todos. (1)
- El código mergeado pertenece al equipo, no al individuo. Todos somos responsables del mismo y nuestro lenguaje debe reflejarlo ("nuestro" en lugar de "mío"). (2)
- Estamos obligados a ponernos al nivel del resto del equipo. Tener siempre el apoyo de un compañero debe servirnos para mejorar más rápidamente y poder así depender menos de esta ayuda en el futuro.
Calidad
- Revisamos nuestro código vía Pull Requests. Nada pasa a master sin que haya sido aprobado por al menos otro miembro del equipo.
- Testamos nuestro código, o justificamos por qué en un caso concreto no es necesario hacerlo.
- Siempre tratamos de dejar el código mejor que cuando lo encontramos por primera vez.
- Siempre dejamos el código legible para el resto del equipo y nuestros yos del futuro. Generalmente haremos caso a las herramientas automáticas, que están basadas en convenciones con sentido y ampliamente extendidas, pero lo ignoraremos cuando su versión deje el código menos legible.
- Cuidamos la imagen que proyectamos al exterior entregando productos de los que nos sentimos orgullosos. Para ello es fundamental ponernos en el lugar del usuario y pensar en cómo va a utilizar cada nueva funcionalidad para hacerle la vida lo más fácil posible.
Eficiencia
- Desarrollaremos siempre la solución más sencilla posible. Nos ceñimos al ámbito de la tarea y tratamos de evitar a toda costa bañarla en oro.
- Preferimos los cambios pequeños e incrementales a complicados deploys. Subimos código en cuanto tenemos la mínima funcionalidad que aporta valor al usuario.
- El resultado es más importante que el proceso. Más allá de los PR reviews, no tenemos procesos rígidos que impidan subir código a producción.
- Lo perfecto es enemigo de lo bueno. Una vez cubierta la funcionalidad deseada con el nivel de calidad exigido, priorizamos lanzar al mundo real para obtener feedback rápido antes que perder mucho tiempo en perfeccionar hasta el mínimo detalle.
- Somos ágiles resolviendo problemas. Nuestros deploys continuos y nuestra orientación a resultados pueden conllevar que rompamos cosas. Tenemos que ser igual de ágiles para solucionarlas que para romperlas.
Confianza / Autonomía
- Confiamos en que aplicarás tu buen juicio para elegir la mejor vía para solucionar un problema.
- No nos echamos en cara los errores del pasado. Si hemos aplicado nuestro buen juicio, equivocarse es tan sólo una forma más de aprender.
- Nos cuestionamos lo que hacemos. Si no tenemos claro el valor que aporta una historia tenemos derecho a levantar la voz y que nos lo expliquen.
- Somos responsables y no delegamos hacia arriba. No esperamos que otros se hagan cargo de nuestros problemas.
Altruismo
- Somos accesibles a las necesidades de otros miembros del equipo y la organización.
- El equipo es más importante que nosotros. La empresa es más importante que el equipo. Nuestras decisiones deben estar alineadas con los objetivos del conjunto.
- Progresamos atendiendo a las críticas y utilizándolas para mejorar la forma en la que trabajamos.
- Comprendemos que trabajamos en un entorno cambiante y tenemos que estar dispuestos a aceptar el cambio con rapidez.