The Scrum Guide 2020 is out, in Italian too!
]]>
The Scrum Guide 2020 is out, in Italian too!
]]>
On May I attended a two-day Agile Project Management course held by Arie van Bennekum and I did the certification exam.
Few days ago I received the certificate. I am very glad to have passed the exam at the first attempt.
]]>
As an Italian programmer who continuously wants to learn and improve his English I’d like to share this beautiful interview with Pulitzer Prize-winning novelist Jhumpa Lahiri.
For programmers English is a very important skill. Lots of -the- programming resources available on the Internet are in English: posts, articles, manuals, books; and also video of conferences, meetings and events. Not considering programmers who work abroad or in a multicultural environment.
In this blog I try to write in English because it’s a way to keep me trained with written English. Even if I put my mind to it, I know I make lots of errors. Not only grammar errors but also errors using linguistic structures that a native English would never use. So please excuse any mistakes.
In this context it sounds quite familiar when Jhumpa says «It’s a language that I’m borrowing and that I work with differently. It’s much more delicate relationship, but it’s also shameless.». In fact, every once in a while I can’t avoid feeling a bit uncomfortable fearing the judgment of readers with a better English.
However I can cope pretty well with this uncomfortableness, because writing posts in English is a deliberate choice I’ve made. So I don’t usually feel uncomfortable, just a little shameless :)
In the video interview Jhumpa speaks about the anxiety she felt because of the distance between her own language and Italian. I’ve found very interesting how she was able to calm this anxiety down by accepting that distance and appreciating the good it brought to her: «my gut tells me that this distance is too painful. I want to destroy this distance but it’s not possible. The more I go ahead, the more I try to relax and appreciate the good».
In this post I just wanted bringing to light a little of the emotional element involved in learning a language, or more broadly, approaching a different culture. Jhumpa tells us about her experience in the video above, so don’t miss it.
I hope you enjoyed the video and liked this post :)
]]>Here you are some of my impressions about this fantastic experience.
The most valuable part of the courses organized by Technology Transfer is the opportunity to hear teachers and speakers who are experts in their area and whose contributions has been widely acknowledged at the international level.
The organization of this course was excellent:
This course was one of the best I’ve ever attended. I really appreciated the opportunity to get a certification.
Arie taught with an energetic and interactive style. He set a rhythm that kept our attention alive by alternating talks and exercise sessions.
During the talks, Arie explained various concepts, accompanying the most relevant ones with an example from his work experience.
The exercises were in groups of: two to four people each, depending on the exercise. Sometimes, before an exercise started, he asked people to mix among the groups.
Arie introduced our first exercise by showing us the fun and interesting spaghetti-marshmallow tower video by Tom Wujec. In the exercise, we had to build a tower using only: dry spaghetti, one yard of tape and a marshmallow. 
In this exercise, we started discussing some building strategies. From my engineering studies, I knew that the triangle is the most stable structure, so I proposed my idea. My teammates agreed with me about the triangle but remained perplexed about my idea.
They instead had already built a structure which let the tower gain height. I recognized the value of such solution, so I helped them. A bit later we were having some stability problems when I got an intuition, like a bolt from the blue! I realized how to adapt my original idea to our tower under construction: not vertical triangles, but horizontal triangles, larger at the base, smaller proceeding towards the top.
The best reward was looking at our unexpected solution standing tall and (quite) stable. (Thanks to Benedetta Capasso for the spaghetti-marshmallow photo).
During the afternoon of the second day, we were split in two teams and each team played a role game that aimed to put into practice everything we had covered in the course.
The SMART objective of the game was building a playground in five sprints, which last fifteen minutes each, with five minutes for the retrospective at the end of each sprint.
We were provided with all the material necessary to play: the playground base, straws, post-its, scissors, a Kanban board, Planning Poker cards, already written cards about epics, user stories, tasks and acceptance requirements.
We began identifying the Business Foundations, Solution Foundations and Management Foundations by sticking each card on the appropriate section of the Kanban board. Then we had a planning poker session during which we estimated each user story.
At that point, we started the first sprint. We did “pair building” (equivalent to pair programming) to avoid information silos. Just before the end of the sprint, we asked to our Business Ambassador (similar to the Scrum’s Product Owner) to verify if tasks met all their acceptance requirements, so that they could have been declared Done. During the sprint, we were transparent about our progress by appropriately moving the various tasks on the Kanban board.
We had the greatest Business Ambassadors available on the market :-) because Arie and Vesselina Andreeva played the game in such role, coaching us during the sprints. (Thanks to Arie and Vesselina for the course photos).
We skipped the Demonstration and Refinement, both to save time and because the role game was intentionally a simplification, but we were still able to be transparent about the project’s progress by drawing a Burndown Chart and keeping it up to date throughout the various sprints.
I came into the “Agile Project Management” course with some expectations, mainly due to my previous ScrumMaster® certification, but I soon realized that those expectations were wrong.
Because Scrum focuses on one team only, I was a little afraid, since I knew that to scale up we would need another framework, like LeSS or Nexus. Instead, Arie made me reflect on how to scale up by including Business roles in the team at project level too, as described in the DSDM team role and responsibility model, also known as “the snowman”.
I discovered the Integrated Agile Transformation Model, the Arie’s plan that make effective the paradigm shift to Agile for organizations.
I gained a deeper comprehension about the importance of the discipline (rituals, Definition of Done and WIP limits) and how discipline helps achieve high quality.
On the whole I reached a new point of view about Agile practices adoption and I gained a more mature knowledge of Agile in general.
I’ve already read “User Stories Applied: For Agile Software Development” by Mike Cohn and now I want to read about the seven product dimensions to slice user story.
I also want to read something about group development, starting from the forming–storming–norming–performing model.
That’s all. Thanks for reading. I hope you liked this post :)
]]>
The following monitoring shows that, in the last semester, twelve Italian Regions have reduced advertisement of proprietary PDF readers on their website.
]]>
On August I passed the Certified ScrumMaster exam at SCRUM Alliance. To get ready for the exam I had studied the Scrum Guide and I had noticed that it was available in Italian too.
Reading the Italian translation I realized that I could have contributed to improve it further. Therefore on July I got in touch with Francesco Lomonaco, the maintainer of the Italian Scrum Guide, who very kindly gave me his willingness to cooperate for an update of the translation.
]]>
I have always been enthusiastic about the ThoughtWorks Technology Radar both because of the idea in itself and because of its implementation in the form of radar.
The Technology Radar is a document which gathers substantial changes in IT technologies of interest to various ThoughtWorks teams. The Radar is written by the ThoughtWorks Technology Advisory Board (TAB), made up of senior technologists at ThoughtWorks, which regularly meet themselves to talk about technology trends that significantly impact our industry.
The implementation in the form of radar is characterized by four quadrants: techniques, platforms, tools, languages & framework; and four concentric levels (from outside to inside): hold, assess, trial, adopt. The various moving technologies appear on the Radar as blips: the closer the blip is to the center, the more it is qualified to be of worth by ThoughtWorks.
The ThoughtWorks Radar contents summarise the essence of the TAB meetings, and its format effectively communicate contents to a wide range of stakeholders, from CIOs to developers.
As I did last year, this year too I contributed to the Italian translation of the ThoughtWorks Radar.
]]>
The following monitoring shows that, in the last semester, eight Italian Regions have reduced advertisement of proprietary PDF readers on their website, and that a Region has increased its support for Free Software PDF readers.
]]>
The Builder pattern [1] is a good choice when designing classes whose constructors have more than a handful of parameters, not only because is less error prone in case of identically typed parameter, but also because it is more readable from the client [2]. For example, instead of instantiating an Application object with its constructor:
public class Client {
...
Person legalRepresentative = getLegalRepresentative();
Company beneficiary = getBeneficiary();
Person notary = getNotary();
Person localOfficial = getOfficial();
Company centralOffice = getOffice();
Application application = new Application(
legalRepresentative,
beneficiary,
notary,
localOfficial,
centralOffice);
...
}
we could use an ApplicationBuilder or, if the builder is an Application inner class, an Application.Builder as:
On June I attended a three-day Scrum Master course held by Craig Larman and today I did the exam at SCRUM Alliance to became a Certified ScrumMaster.
I am very glad to have passed the exam at the first attempt scoring 34/35.
]]>I agree on the fact that developers might feel slowed down when tests execution on the development machine takes too long. Comprehensibly they might tend to not executing tests before commit, relying on tests running later on a continuous integration server. That fact might slowly drift developers off good Agile practices.
The article reports some «conventional strategies to shorten test automation» before describing «Test Impact Analysis». Test Impact Analysis (TIA) is a technique that helps determine which subset of tests execute for a given set of source code changes. The way by which the tests subset is determined starts with a code coverage or instrumentation phase, and finishes building a map which associate, for each entry, a test with the source code methods it will cover during its execution. TIA avoids executing all tests because it enables only the execution of the relevant ones.
]]>
I have just came back from a three days Scrum Master course taught by Craig Larman.
The teacher told us so many things, and some of his experiences and insights, that is quite impossible reporting all of them in a blog post. However I share with pleasure one of his clarification about the meaning of the Scrum value: commitment.
]]>
I added some new functionalities to a Spring-based web application.
After some changes a unit test failed. The cause was a missing bean which stopped the auto-wiring process while Spring was loading the application context.
The test declared its own application contest, by using the annotation @Configuration on a static inner class; there were some mocked beans, so I added the missing bean:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class MyClassTest {
...
@Configuration
static class ContextConfiguration {
@Bean
public MissingBean missingBean() {
return new MockMissingBean();
}
@Bean
public ThatBean thatBean() {
return new MockThatBean();
}
@Bean
public ThisBean thisBean() {
return new MockThisBean();
}
...
}
}
Then I changed other classes adding other auto-wired beans, new methods, etc., until when the same test that had failed before failed again!
]]>
The following monitoring shows that, in the last semester, nine Italian Regions
have reduced advertisement about of proprietary PDF readers on their website, and
that a Region has raised increased its support to for Free Software PDF readers.
I have always been enthusiastic about the ThoughtWorks Technology Radar both because of the idea in itself and because of its implementation in the form of radar.
The Technology Radar is a document which gathers substantial changes in IT technologies of interest to various ThoughtWorks teams. The Radar is written by the ThoughtWorks Technology Advisory Board (TAB), made up of senior technologists at ThoughtWorks, which regularly meet themselves to talk about technology trends that significantly impact our industry.
The implementation in the form of radar is characterized by four quadrants: techniques, platforms, tools, languages & framework; and four concentric levels (from outside to inside): hold, assess, trial, adopt. The various moving technologies appear on the Radar as blips: the closer the blip is to the center, the more it is qualified to be of worth by ThoughtWorks.
The ThoughtWorks Radar contents summarise the essence of the TAB meetings, and its format effectively communicate contents to a wide range of stakeholders, from CIOs to developers.
Over the years the Thoughtworks Radar has evolved in the contents, in the graphic layout, and in the distribution in various languages; but it hasn’t been available in Italian yet. Last year, when I discovered that ThoughtWorks has an office in Bologna, the city where I work in, I wrote an email asking if I might have contributed to the Italian translation of the ThoughtWorks Radar. I received a reply from Matteo Vaccari:
]]>Software always had bugs and always will”. Tired of this defeatist attitude? With Design by Contract, invented by Eiffel Software and one of the most widely recognized breakthroughs in the history of software engineering, you can write complex software and not wake up at night fearing that something, somewhere will go wrong. Design by Contract brings science to the construction of correct and robust software.
From this point of view, unfortunately, Java is not Eiffel. Therefore, even if I would have follow this Bertrand Meyer valuable concept, I had to cope with the language itself. I know in the past years some Java frameworks which implement Design by Contract have been proposed, but I have never had the chance to try them seriously. So what I do is simply checking input method parameters.
]]>
Last January I was selected from Manning as one of the technical reviewers of the book “Functional Programming in Java” by Pierre-Yves Saumont. In these days the book has been released to the public therefore I can publish this post without violating the reviewer agreement.
The book teaches functional concepts by lots of examples and exercises which develop in the reader both a knowledge background and a natural instinct to functional programming paradigm.
]]>I have created the following code template:
private static final ${LOGGER_TYPE type="org.slf4j.Logger" default="Logger" editable=false} LOGGER = ${LOGGER_FACTORY type="org.slf4j.LoggerFactory" default="LoggerFactory" editable=false}.getLogger(${CLASS editable="false" currClassName}.class);
and I have associated it to the abbreviation log. Than at the cursor:
public class MyClass {
|
...
I type log + TAB and NetBeans expands the text:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
public class MyClass {
private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
...
I have also defined the shortcuts:
logd + TABlogw + TABlogi + TABloge + TABdefined as:
${LOGGER_CONST default="LOGGER" editable=false}.debug("${logMessage}");${LOGGER_CONST default="LOGGER" editable=false}.warn("${logMessage}");${LOGGER_CONST default="LOGGER" editable=false}.info("${logMessage}");${LOGGER_CONST default="LOGGER" editable=false}.error("${logMessage}", ex);which generate:
LOGGER.debug("logMessage");
LOGGER.warn("logMessage");
LOGGER.info("logMessage");
LOGGER.error("logMessage", ex);