This time I will comment on «Java By Comparison: Become a Java Craftsman in 70 Examples», a book aimed at the reader to improve his skills as a Java 8 developer. This is the first book that I read from the publisher, «The Pragmatic Bookshelf», which specializes in books focused on the knowledge and improvement of the different areas of software development. This book has helped me to review those refactoring techniques that I already knew, and to learn others that I didn’t know. To establish a comparison, we could say that this title is a much shorter and lighter version of the famous book «Clean Code».
The book consists of seventy examples grouped into nine chapters in which, first, a code fragment is shown that presents one or more elements that can be improved, and then a second fragment is shown that is refactored with the proposed solution. This format allows you to compare at a glance, the changes and improvements applied to the code by the authors.
Some of the areas that the book focuses on are exclusive to Java version 8, such as the use of the «Optional» object to avoid Null Pointer type exceptions or the optimization of the code through the use of Lambdas expressions. Other chapters, however, are applicable to previous versions of the language, and even to other languages, such as those dedicated to the correct naming of methods and variables, the handling of exceptions, the design of objects, or the improvement of unit tests, among many other examples up to seventy. The last chapter breaks this trend to present, in a more theoretical way, the concepts and tools used in modern software development, such as static code analysis tools or continuous integration.
In short, it is a book that, although it may be a little basic for an experienced developer, is well written and its explanations are clear and concise. It is a recommended book to consolidate or, depending on the reader’s previous knowledge, to acquire new skills in Java code refactoring.
Title: Java By Comparison: Become a Java Craftsman in 70 Examples Authors: Simon Harrer, Jörg Lenhard, Linus Dietz Editor: The Pragmatic Bookshelf Year: 2018 Language: English Pages: 302
En esta ocasión voy a comentar «Java By Comparison: Become a Java Craftsman in 70 Examples», un libro destinado a que el lector mejore sus habilidades como desarrollador de Java 8. Este es el primer libro que leo de la editorial, «The Pragmatic Bookshelf», especializada en libros enfocados en el conocimiento y perfeccionamiento de las distintas áreas del desarrollo de software. A mí particularmente, esta obra me ha servido para repasar aquellas técnicas de refactorización que ya conocía, y para aprender otras que desconocía. Por establecer una comparación, podríamos decir que este título es una versión mucho más breve y ligera del famoso libro «Clean Code».
El libro consta de setenta ejemplos agrupados en nueve capítulos en los que, primero se muestra un fragmento de código que presenta uno o varios elementos factibles de ser mejorados, para a continuación mostrar un segundo fragmento refactorizado con la solución propuesta. Este formato permite comparar de un vistazo, los cambios y mejoras aplicadas al código por los autores.
Algunas de las áreas en las que se centra el libro son exclusivas de la versión 8 de Java como el uso del objeto «Optional»para evitar excepciones de tipo Null Pointer o la optimización del código mediante el uso de expresiones Lambdas. Otros capítulos, en cambio, son aplicables a versiones anteriores del lenguaje, e incluso a otros lenguajes, como pueden ser los dedicados al correcto nombrado de métodos y variables, el manejo de excepciones, el diseño de objetos, o a la mejora de los test unitarios, entre otros muchos ejemplos hasta sumar setenta. En el último capítulo se rompe esta tónica para presentar, de una manera más teórica, los conceptos y herramientas que se usan en el desarrollo de software moderno, como pueden ser las herramientas de análisis de código estático o la integración continua.
En definitiva, es un libro que, aun pudiendo tener un nivel un poco básico para un desarrollador experimentado, está bien escrito y sus explicaciones son claras y concisas. Es un libro recomendable para afianzar o, dependiendo de los conocimientos previos del lector, adquirir nuevas habilidades en la refactorización de código Java.
Título: Java By Comparison: Become a Java Craftsman in 70 Examples Autores: Simon Harrer, Jörg Lenhard, Linus Dietz Editor: The Pragmatic Bookshelf Año: 2018 Idioma: Inglés Páginas: 302
When carrying out a software project, we can find organizations that only use the roles and techniques of Agile methodologies, others that, instead, follow a classic model in cascade – with a Project Manager as the visible head of the project – and finally, those that follow a hybrid model in which they combine, or try to combine, elements from both worlds.
One of the most popular project management methodologies is PRINCE2, which, faced with the emergence of Agility in the business world, has decided to remove the label of «methodology for traditional cascading projects», opting for a combination of the principles, behaviours and techniques of Agile, with the principles, themes (knowledge areas) and processes of PRINCE2. This is why AXELOS, the organisation that manages the body of knowledge in PRINCE2, has developed PRINCE2 Agile.
But why would an organisation using Agile methodologies want to incorporate PRINCE2 into its working methodology or vice versa? According to AXELOS, Agile methodologies can be very effective in building a product, but they are insufficient to manage a project, especially if it has a certain complexity. And this is where PRINCE2 Agile comes into play. It should be clarified that this is not an attempt to create a new methodology to replace PRINCE2, but rather an orientation or set of good practices to combine Agility with Governance when carrying out a software project.
prince2agile.wiki
A project according to PRINCE2 consists of three levels of decision making: Project Management, Project Management and Product Delivery. It is in this last layer that Agile methodologies such as Scrum, Kanban etc. best fit. If we understand Agility as a scale on which we can move, and not as something binary, a company that applies PRINCE2 Agile will be somewhere in between. This degree of Agility will be determined by the so-called Agilometer, which is nothing more than a set of indicators – flexibility in deliveries, level of collaboration etc. – to which we must assign a score from 1 to 5 at the beginning of the project, to know where we start from, how to best adapt PRINCE2 and what corrective actions we can take to improve these indicators.
Axelos
However, no matter how much agility you want to apply, some limits must be established if you want to continue applying PRINCE2. For example, although the development teams may have enough autonomy to deliver the requested functionality, this self-organization will never be complete. It will be the Project Manager or the Project Board who will have the last word on major decisions that may affect the project as a whole. Another example would be the combination of roles: PRINCE2 Agile offers several alternatives for combining the roles of Scrum Master and Product Owner, with the classic roles of Project Manager or Team Leader. Each of these combinations will be appropriate for the degree of Agility that we want to give to the project, but in no case does the figure of the Project Manager disappear.
In short, although the PRINCE2 Agile manual makes some controversial statements such as that Scrum, or other Agile methodologies, are not in themselves sufficient to manage a project and that they are focused primarily on the maintenance of products and services (Business As Usual), its application can be useful for those organizations that want to start applying a certain degree of Agilityto their projects, without having to modify their way of working excessively.
Certification
Finally, it should be noted that there is an official AXELOS exam that certifies you as a PRINCE2 Agile Practicioner, in which it is necessary to apply the concepts and recommendations of the book to a practical case. However, before you can take this exam you must be certified as PRINCE2 Foundation.
A la hora de llevar a cabo un proyecto software, nos podemos encontrar organizaciones que únicamente emplean los roles y técnicas propias de las metodologías Ágiles, otras que, en cambio, siguen un modelo clásico en cascada – con un Jefe de Proyecto como cabeza visible del mismo – y finalmente, aquellas que siguen un modelo híbrido en el cual combinan, o lo intentan, elementos de ambos mundos.
Una de las metodologías de gestión de proyectos más populares es PRINCE2, que ante la irrupción de la Agilidad en el mundo empresarial, ha decidido quitarse la etiqueta de «metodología para proyectos tradicionales en cascada», apostando por una combinación de los principios, comportamientos y técnicas Ágiles, con los principios, temas (áreas de conocimiento), y procesos de PRINCE2. Es para ello que AXELOS, la organización que gestiona el cuerpo de conocimiento de PRINCE2, ha elaborado PRINCE2 Agile.
¿Pero, por qué querría una organización que usa metodologías Ágiles incorporar PRINCE2 a su metodología de trabajo o viceversa? Según AXELOS, las metodologías Ágiles pueden ser muy efectivas en la construcción de un producto, pero son insuficientes para gestionar un proyecto, especialmente si este reviste cierta complejidad. Y es aquí donde entra en juego PRINCE2 Agile. Hay que aclarar que este no es un intento de crear una nueva metodología que intente sustituir a PRINCE2, sino que es una orientación o conjunto de buenas prácticas para combinar la Agilidad con la Gobernanza a la hora de llevar a cabo un proyecto software.
prince2agile.wiki
Un proyecto según PRINCE2 consta de tres niveles en la toma de decisiones: Dirección del Proyecto, Gestión del Proyecto y Entrega del Producto. Es en esta última capa donde mejor encajan las metodologías Ágiles como Scrum, Kanban etc. Si entendemos la Agilidad como una escala en la cual podemos movernos y no como algo binario, una empresa que aplique PRINCE2 Agile se encontrará en algún punto intermedio de la misma. Este grado de Agilidad vendrá determinado por el llamado Agilómetro, que no es más que un conjunto de indicadores – flexibilidad en las entregas, nivel de colaboración etc. – a los cuales debemos asignar una puntuación de 1 a 5 al inicio del proyecto, para saber de dónde partimos, cómo adaptar mejor PRINCE2 y qué acciones correctoras podemos tomar para mejorar estos indicadores.
Axelos
Sin embargo, por mucha Agilidad que quiera aplicarse, deben establecerse algunos límites si queremos seguir aplicando PRINCE2. Así por ejemplo, aunque los equipos de desarrollo puedan tener bastante autonomía a la hora de entregar las funcionalidades pedidas, esta auto-organización nunca será completa. Serán el Jefe de Proyecto o la Junta del Proyecto, los que tengan la última palabra en las decisiones de mayor calado que puedan afectar al proyecto en su conjunto. Otro ejemplo sería la combinación de roles: PRINCE2 Agile nos ofrece varias alternativas para conjugar los roles de Scrum Master y Product Owner, con los clásicos de Jefe de Proyecto o Jefe de Equipo. Cada una de estas combinaciones será adecuada según el grado de Agilidadque queramos imprimir al proyecto, pero en ningún caso desaparece la figura del Jefe de Proyecto.
En definitiva, aunque el manual de PRINCE2 Agile hace algunas afirmaciones polémicas tales como que Scrum, u otras metodologías Ágiles, de por sí no son suficientes para gestionar un proyecto y que están enfocadas primordialmente al mantenimiento de productos y servicios (Business As Usual), su aplicación puede ser útil para aquellas organizaciones que quieran empezar a aplicar un cierto grado de Agilidada sus proyectos, sin tener que modificar excesivamente su manera de trabajar.
Certificación
Por último, señalar que hay un examen oficial de AXELOS que te certifica como PRINCE2 Agile Practicioner, en el cual es necesario aplicar los conceptos y recomendaciones del libro a un caso práctico. No obstante, antes de poder realizar este examen hay que poseer la certificación PRINCE2 Foundation.
In «The Programmer’s Black Book», its author Rafael Gómez Blanes, based on his extensive professional experience, makes us reflect on the habits, factors and circumstances that can lead to a successful software project or, on the contrary, ruin it. But what is a successful software project? When do we consider that a development has been a success? Do we only refer to delivering it within the stipulated time and budget? No, that is no longer enough. In this sense there is a definition in the software book that I liked very much. A project ends successfully when its result is software that is easy, and therefore cheap, to evolve and maintain.
Because, as the author points out, would you like to buy a car that would be an odyssey to maintain or repair? Obviously not. Well, with software it shouldn’t happen either. Backing up the software with tests, applying design patterns, following the SOLID development principles, etc. are practices that help us prevent that, over time, modifying a product will be so expensive that it will directly be cheaper to «throw it away» and start over. Or what is the same, they help us avoid the so common Pareto principle in software construction: 80% of the time spent on maintenance tasks and 20% on developing new functionalities.
In my own professional experience, I have been able to verify this lack of culture in testing that the book comments on. First, because in most cases they are not required, and second, and perhaps more importantly, because we are not in the habit of performing them before – TDD – or after building a new functionality. Besides, it is also difficult to justify to your manager that a good part of your development time – in the book he estimates that it can be more than half of it – is going to be spent in developing tests that, although initially they are a cost of time and money, really it is an investment, since the software will have less errors and therefore it will be necessary to spend less time to correct them.
From a team management point of view, there are certain habits that will favor the success of a project, such as trying to maintain a relaxed and friendly atmosphere, avoiding constant interruptions, trying to prevent a high rotation of team members or not assuming as a custom to do extra hours in our working day. That’s why in the author’s opinion, and mine too, a software project manager should, not be a computer engineer or have performed technical tasks, but at least know the nature of software development and the peculiarities involved. Good software project management, like learning a new technology or a new programming language, is a skill that can be learned and perfected with practice and effort.
In short, «The Programmer’s Black Book» is a book that will be useful, and also enjoyable, for anyone involved in software development and who wants to continue along the path of continuous improvement in their profession. It has motivated me personally to continue deepening in the good practices that it recommends.
Title: El Libro Negro del Programador Author: Rafael Gómez Blanes Editor: CreateSpace Year: 2017 – Second Edition Language: Spanish Pages: 236
En «El Libro Negro del Programador», su autor Rafael Gómez Blanes, partiendo de su dilatada experiencia profesional, nos hace reflexionar sobre los hábitos, factores y circunstancias que pueden llevar a buen puerto un proyecto software o, por el contrario, arruinarlo. ¿Pero qué es llevar a buen puerto un proyecto software? ¿Cuándo consideramos que un desarrollo ha sido un éxito? ¿Nos referimos únicamente a entregarlo dentro del plazo y presupuesto estipulado? No, eso ya no es suficiente. En este sentido hay una definición en el libro software que me ha gustado mucho . Un proyecto termina con éxito cuando su resultado es un software fácil, y por tanto barato, de evolucionar y mantener.
Porque, tal y como señala el autor, ¿te gustaría comprar un coche que fuera una odisea mantener o reparar? Obviamente no. Pues con el software tampoco debería suceder. Respaldar el software con pruebas, aplicar patrones de diseño, seguir los principios de desarrollo SOLID etc. son prácticas que nos ayudan a prevenir que, con el paso del tiempo, modificar un producto sea tan caro que directamente salga más barato «tirarlo a la basura» y comenzar de nuevo. O lo que es lo mismo, nos ayudan a evitar el tan habitual principio de Pareto en la construcción de software: 80% del tiempo empleado en tareas de mantenimiento y un 20% en desarrollar nuevas funcionalidades.
En mi propia experiencia profesional, he podido comprobar esta falta de cultura en la realización de pruebas que comenta el libro. Primero porque en la mayoría de las ocasiones no se exigen, y segundo, y puede que más importante, porque no tenemos el hábito de realizarlas antes – TDD – o después de construir una nueva funcionalidad. Además también resulta difícil justificar a tu responsable que buena parte de tu tiempo de desarrollo – en el libro estima que puede llegar a ser hasta más de la mitad – se va a emplear en desarrollar pruebas que, aunque inicialmente sean un coste de tiempo y dinero, realmente es una inversión, ya que el software tendrá menos errores y por tanto habrá que dedicar menos tiempo a corregirlos.
Desde un punto de vista de gestión del equipo, hay ciertos hábitos que favorecerán el éxito de un proyecto, como por ejemplo intentar mantener un ambiente relajado y de compañerismo, evitar las interrupciones constantes, intentar prevenir una alta rotación de los miembros del equipo o no asumir como costumbre hacer horas de más en nuestra jornada laboral. Es por ello que en la opinión del autor, y en la mía también, un responsable de de proyecto software, debería, no ya ser ingeniero informático o haber desempeñado labores técnicas, pero sí al menos conocer la naturaleza del desarrollo de software y las peculiaridades que conlleva. La buena gestión de un proyecto software, al igual que aprender una nueva tecnología o un nuevo lenguaje de programación, es una habilidad que se puede aprender y perfeccionar con práctica y esfuerzo.
En definitiva, «El Libro Negro del Programador» es un libro que resultará útil , y además ameno, para cualquier persona vinculada al desarrollo del software y que desee continuar por el camino de la mejora continua en su profesión. A mí personalmente me ha motivado a seguir profundizando en las buenas prácticas que recomienda.
Título: El Libro Negro del Programador Autor: Rafael Gómez Blanes Editor: CreateSpace Año: 2017 – Segunda Edición Idioma: Castellano Páginas: 236
Disciplined Agile Delivery is a book written by Scott Ambler and Mark Lines, in which the authors explain in detail this Lean-Agile framework and how it fits into the operation of a company that develops software solutions. Disciplined Agile Delivery – abbreviated as «DAD» – unlike other methodologies, it does not focus exclusively on the process of building a software project, but covers its entire life cycle, from conception to production.
Although the style of the book is clear and direct, it is highly recommended to have previous knowledge about the most important Agile-Lean methodologies, such as Scrum or Extreme Programming, since the authors mention them throughout the book but without going into detail.
Structure
The book is structured in six thematic parts in which it covers the different existing roles, the three stages of life of a DAD project – Origen, Construction andTransition – and Agile Governance of a company’s IT department.
In the first part, «Introduction to Disciplined Agile Delivery», the authors make an introduction to the framework, describing the Agile and Lean principles from which it starts, as well as the different methodologies or techniques, – Scrum, Extreme Programming, Agile Modeling, Unified Process, Agile Data y Kanban – which DAD uses and which combines according to the particular needs of each project.
In the next block, «People First», the roles within a DAD project are exposed along with their rights and responsibilities, although as the authors themselves point out, at the end of the day «we work in companies, not in democracies». It also explains the separation between primary and secondary roles, for which the authors have decided to use generic names and avoid Scrum terminology: for example, the Scrum Master role is called Project Leader.
In the third part called «The Starting Phase», the initial phase of a DAD project is described. The authors emphasize that this phase should be as short as possible and that the main objective is to agree on a common vision of the project at a high level with the stakeholders, or interested parties, in the most efficient way possible. Understanding the vision as the scope, the schedule, the budget, possible relevant constraints, key risks and the architecture of the solution. Always assuming that the details will evolve as the project does. They also urge you to start building our team at this stage, planning its composition and whether any additional members will be needed.
In the block «Building a Consumable Solution in an Incremental Way», it is explained how Scrum and Extreme Programming techniques are adopted -among others- to apply them in a coherent way. It also emphasizes the importance of regular retrospectives and demonstrations to stakeholders, as well as the importance of the team addressing technical risks as early as possible. For example, confirming that the chosen Technical Architecture is adequate by delivering end-to-end functionalities from the first iterations.
In the fifth part entitled «Launching the Solution», the last phase of the cycle, called the Transition phase, is detailed. In this phase, the last acceptance tests must be passed and the interested parties must be prepared to put the solution into production. This can include activities such as securing the production environments, notifying users that a new version of the solution will be available, and even providing training if necessary.
In the sixth and last block, «Disciplined Agile Delivery in the Enterprise», first Governance is defined as «the activity that observes the team from the outside as a system to which it must provide the appropriate processes and structure», as opposed to Managemen that occurs within the team. According to the authors of the book, governing an Agile team is simpler than governing a traditional one, but for that, relevant metrics must be gathered and Governance must be focused not as a team control activity, but as an employee training one.
Certification
Finally, comment that DAD consists of a four-level certification program. With the reading of this book and the subsequent exam we can get the second level Certified Disciplined Agilist. This means that even though it is a long book, its reading is more valuable.
Title: Disciplined Agile Delivery Authors: Scott W. Ambler y Mark Lines Editor: Prentice Hall Year: 2012 Language: English Pages: 544
Disciplined Agile Delivery es un libro escrito por Scott Ambler y Mark Lines, en el que los autores explican con detalle este framework Lean-Agile y cómo encaja en el funcionamiento de una empresa que desarrolle soluciones software. Disciplined Agile Delivery – abreviado como “DAD” – a diferencia de otras metodologías, no se centra exclusivamente en el proceso de construcción de un proyecto de software, sino que abarca todo su ciclo de vida, desde su concepción, hasta su puesta en producción.
Aunque el estilo del libro es claro y directo, es muy recomendable tener conocimientos previos sobre las metodologías Agile-Lean más importantes, como pueden ser Scrum o Extreme Programming, ya que los autores las mencionan a lo largo del libro pero sin llegar a entrar en detalles.
Estructura
El libro está estructurado en seis partes temáticas en las que abarca los diferentes roles existentes, las tres etapas de vida de un proyecto DAD – Origen, Construcción y Transición – y la Gobernanza Ágil del departamento TI de una empresa.
En la primera parte, “Introducción a Disciplined Agile Delivery”, los autores hacen una introducción al framework, describiendo los principios Agile y Lean de los que parte, así como de las diferentes metodologías o técnicas, – Scrum, Extreme Programming, Agile Modeling, Unified Process, Agile Data y Kanban – que emplea DAD y que combina de acuerdo a las necesidades particulares de cada proyecto.
En el siguiente bloque, “La Gente Primero”, se exponen los roles dentro de un proyecto DAD junto con sus derechos y responsabilidades, aunque como los propios autores señalan, al final del día “trabajamos en compañías, no en democracias”. También se explica la separación entre roles primarios y secundarios, para los cuales los autores han decidido usar nombres genéricos y evitar la terminología Scrum: por ejemplo al rol del Scrum Master lo denomina Project Leader o Líder del Proyecto.
En la tercera parte denominada “La fase de Comienzo”, se describe la fase inicial de un proyecto DAD. Los autores nos recalcan que esta fase debe ser lo más corta posible y que el objetivo principal, es el de acordar una visión común a alto nivel sobre el proyecto con los stakeholders, o partes interesadas, de la manera más eficiente posible. Entendiendo la visión como el alcance, el cronograma, el presupuesto, posibles restricciones relevantes, riesgos clave y la arquitectura de la solución. Asumiendo siempre que los detalles evolucionarán a medida que lo haga el proyecto. También se apremia a empezar a construir nuestro equipo en esta fase, planificando su composición y si hará falta contratar a algún miembro adicional.
En el bloque “Construyendo una Solución Consumible de manera Incremental”, se explica cómo se adoptan técnicas de Scrum y Extreme Programming -entre otras – para aplicarlas de manera coherente. Asimismo se remarca la importancia de las retrospectivas y las demostraciones periódicas a las partes interesadas, así como la importancia de que el equipo afronte los riesgos técnicos lo más pronto posible. Por ejemplo, confirmando que la Arquitectura técnica escogida es la adecuada mediante la entrega de funcionalidades end-to-end desde las primeras iteraciones.
En la quinta parte titulada “Lanzando la Solución”, se detalla la última fase del ciclo, llamada fase de Transición. En esta fase se deben superar las últimas pruebas de aceptación y preparar a las partes interesadas para la puesta en producción de la solución. Esto puede incluir actividades como asegurar los entornos de producción, avisar a los usuarios que van a disponer de una nueva versión de la solución, e incluso proporcionar formación si fuera necesario.
En el sexto y último bloque, “Disciplined Agile Delivery en la Empresa”, primero se define la Gobernanza como «la actividad que observa al equipo desde el exterior como un sistema al cual debe proporcionar los procesos y estructura oportunas», a diferencia de la Gestión o el Management que ocurre dentro del equipo. Según los autores del libro, gobernar un equipo Ágil es más simple que gobernar a uno tradicional, pero para ello se deben recabar las métricas que sean relevantes y enfocar la Gobernanza no como una actividad de control de los equipos, sino de capacitación de los empleados.
Certificación
Finalmente, comentar que DAD consta de un programa de certificación de cuatro niveles. Con la lectura de este libro y el consiguiente examen podemos sacar el segundo nivel Certified Disciplined Agilist. Lo que hace que, aún siendo un libro extenso, su lectura tenga un mayor valor.
Título: Disciplined Agile Delivery Autores: Scott W. Ambler y Mark Lines Editor: Prentice Hall Año: 2012 Idioma: Inglés Páginas: 544
