More on this book
Kindle Notes & Highlights
El correo también es una mala herramienta para hacer un documento entre varios.
tener una audio conferencia mientras el “dueño” del documento lo comparte mediante join.me (por ejemplo, también se puede usar Skype, Lync o Webex) permite que todo el mundo vea a la vez los cambios de los demás y pueda haber debates.
El correo es bueno cuando no podemos tener una comunicación síncrona con nuestro interlocutor (o interlocutores) y necesitamos pedir algo.
deberíamos explicar el contexto, el problema que tenemos, la solución que proponemos (si la tenemos) y lo que estamos pidiendo (puede ser la propia solución, una autorización, un dato, una reunión, etc.). Y el correo si breve, dos veces bueno.
Los chats (como Skype o Lync) también son útiles para resolver dudas rápidas en el momento.
la técnica Pomodoro
El código fuente como medio de comunicación
acordar una línea editorial, una guía de estilo que describa cómo nombrar las variables, las clases y demás. También es necesario que tengamos una estructura para ese código fuente (igual que cuando se divide un libro en secciones o capítulos), empezando por la organización en carpetas y módulos que tendrá el proyecto.
esta organización debería ser la misma en todos los proyectos que usen esa tecnología concreta, de tal manera que sea más fácil que un programador se pueda mover de un proyecto a otro con impacto mínimo.
acuerdo en cuanto a las librerías que vamos a utilizar (sean comerciales, open source o desarrolladas en otros proyectos internos), así como servidores de aplicaciones, bases de datos, ORM, etc. Y estos acuerdos tienen que estar en ese sitio donde compartimos los documentos
necesitamos que este conjunto de letras y números sea auto explicativo en la medida de lo posible. Eso implica:
Comentar en el código las clases y los métodos, con los parámetros de entrada y salida correspondientes.
cuando haya un fragmento de código particularmente complejo, deberíamos aclarar por qué está así implementado
marcar las cosas que se han dejado pendientes de alguna manera especial (la etiqueta TODO está bastante extendido).
el código no puede explicarlo todo y de ahí que necesitemos también diagramas de arquitectura y de flujos para explicar cómo interactúan las diferentes partes del código entre sí,
que cuando lo subamos al control de versiones, todo el mundo sepa por qué lo hemos subido: ha sido para arreglar el bug AAA, para mejorar la documentación, para implementar la funcionalidad XXX correspondiente a la tarea YYY del Sprint, hemos hecho un refactor del módulo ZZZ, etc. Esto podría facilitar el tener un changelog
La comunicación debe ser bidireccional
el inicio de la comunicación puede partir de cualquiera de ambas partes: yo puedo decir cómo va mi tarea o puede ser el Scrum Master / jefe de proyecto el que esté todo el rato invitándome a compartir con el resto del equipo cómo voy con mis tareas.
promueve la filosofía Agile1 es la comunicación constante:
reuniones breves diarias del equipo para ver el estado de las tareas y los posibles bloqueos,
Sprint plannings para que todo el mundo sepa las tareas a ...
This highlight has been truncated due to consecutive passage length restrictions.
cuáles de ellas se van a tener completadas al final del Sprint y tenemos comunicación con el cli...
This highlight has been truncated due to consecutive passage length restrictions.
en metodología Lean2 lo que hacemos es buscar más información por parte del cliente para saber hacia dónde dirigir nuestro producto,
ofreciéndole una mínima funcionalidad en un principio para luego ir orientando dicho producto a cubrir las necesidades detectadas, incluso a veces cambiando radicalmente el objetivo inicial del producto (o el segmento de mercado). Lean además nos propone eliminar todo lo sobrante, lo que podríamos aplicar también a las reuniones no productivas
tenemos que dar visibilidad siempre de las tareas que estamos haciendo (por si hay cosas más prioritarias) y de los posibles bloqueos que detectemos. Y eso implica pedir ayuda para resolver esos bloqueos y aceptar feedback sobre lo que estamos haciendo.
no solo se trata de saber cómo van las tareas, sino cómo se siente la gente dentro del proyecto.
la comunicación es tan importante como una buena arquitectura o unas buenas prácticas de desarrollo.
7. cómo la programación genérica puede ayudar a reducir el volumen de código por Jesús Manuel González Espinilla
Los plazos reducidos y los requisitos que cambian continuamente hacen que en ocasiones el desarrollador se vea obligado a introducir workarounds (soluciones de contingencia) en la codificación dejando de lado las buenas prácticas
a medio y largo plazo el proyecto adquiera una deuda técnica que ponga en peligro la evolución del software e incluso haga imposible su modificación.
es necesario introducir etapas de revisión del código (refactoring) pensando en la arquitectura de forma genérica,
El peligro del “copy-paste-modify”
developer que se ha fijado en otro código para poder aprender y obtener ideas
plazos de entrega o unos tiempos excesivamente acelerados que hacen tomar estos atajos de manera que “lo dejamos así y ya lo revisamos más tarde”.
developers inexpertos que no afrontan una forma de pensar más crítica
Sin querer entrar en otros problemas como la falta de orden y estructuración que nos lleve al spaghetti code, esta mala praxis simplemente hace que nuestro código sea excesivamente grande,
Java Reflection (aunque se podría haber utilizado cualquier otra técnica como polimorfismo, templates, etc…) conseguimos abstraer qué datos estamos manejando en un caso determinado para resolver el problema de forma genérica:
Hay que tener en cuenta la estructura de nuestra arquitectura y adelantarse a las probables aunque desconocidas evoluciones futuras del sistema.
la programación genérica es el método con el que debemos pensar los nuevos desarrollos, el refactoring es la forma de poder aplicarlo en el software existente. Por contra, las pruebas de regresión son el precio a pagar para no acabar con una deuda técnica que a medio plazo haga imposible evolucionar nuestro sistema.
batería de pruebas automatizada correctamente mantenida,
lo más razonable es realizar un proceso iterativo de mejora continua del software, manteniendo un equilibrio entre las necesidades concretas de una versión y las reformas mediante refactoring y programación genérica que hagan que dicha versión pueda evolucionar de forma sencilla.
El ser humano en general tiene siempre la tendencia a buscar su desarrollo individual, para que se pueda sentir más realizado personalmente y también tener reconocimiento y prestigio dentro del grupo humano en el que se mueve.
Visualiza tus objetivos Un ejercicio muy interesante que podemos hacer de cara a concretar hacia dónde queremos evolucionar,
los deseos mencionados anteriormente representan nuevos aprendizajes y conocimientos que nos gustaría adquirir o cosas relacionadas con nuestras características personales que queramos pulir, consolidar o eliminar.
clasificarlos por conocimiento técnico y por habilidades no técnicas.
aunar varias cosas en una, o que incluso no estamos interesados en algo que anteriormente habíamos apuntado en los post-its.
si vemos que un deseo resulta demasiado grande, quizás sea mejor desmenuzarlo en piezas más pequeñas que apuntaremos en los post-its.
priorizar la lista de nuestros deseos y, si es necesario, detallamos un poco más cada uno de ellos.
parece mucho, apartamos unos cuantos post-its de prioridad más baja, hasta que nos sintamos cómodos con lo que nos queda por hacer.
no quiere decir que nos quedemos con cosas que consideramos prácticamente ya hechas o de poco valor, sino con las que pensamos que realmente nos van a beneficiar y que estamos convencidos de poder acometer.
