Chess - antoniomartel.com

Archivos de Categoría: English

From Agile 101 book: Real artists ship!

Sometimes, and quite often, we delay delivering our work because we believe it is not ready. We think that we still have things to improve or correct, that we still have to work on it. More often than not, that actually comes out of fear of failure. Fear of our product meeting the market and nobody buying it, because it is not perfect, or it is not good enough.

It can also be fear of our product being criticized, because either the product or the book or our software has some typo or small bug. “I will only publish the latest blog post when there are no possible ifs, ands, or buts.” Other times it’s just perfectionism leading to paralysis.

A pottery teacher in an art school divided his students in two groups and told them what they had to do to get an A+ in his class. He told the first group that they had to do 100 vases in order to get the highest mark. However, he told the second group that to get that A+ they had to make the best vase.

This last group devoted enormous amounts of time and energy to debate and read about the best techniques for creating vases. But the best vases were actually done by the first group. They had devoted their time to practice, practice, practice and made 100 vases. Their technique had improved. It’s the same with your blog, your app or that design you’ve been thinking about. Let them meet the real users and let those users give you a thumbs up.

The world of software is full of products that were developed over years until they had every feature a client could imagine, in the way they were initially designed by their creators. Sadly when the software met the market, the market had its own ideas and needs. Very few people used every feature in those applications. Other features were heavily demanded, but none of the creators had thought about them when those products were first designed.

There is a Spanish proverb: “perfect” is the enemy of “good.” When you have a small but already useful product, ship it, show it to the public, get your first clients. They will tell you what’s missing. Learn about that, launch a second version, then a third. If you can’t get at least a small client base with your first version, maybe it is not the right time or place for your product. At least you’ll learn lots of things you didn’t know yet, and you won’t have wasted months and months of your work.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

From Agile 101 book: The Ant and the Cicada

One summer a cicada was resting in a field, when she noticed a small ant running around here and there.

– “What are you doing?” asked the Cicada.
– “The Queen has asked me to build a new anthill!” replied the Ant.
– “But they already have one there, just a few meters away” offered the Cicada, puzzled.
– “Yes, but it’s getting a bit small, and in winter, with the rain, the things we have collected get wet

The Cicada, ready to learn from her hard-working friends, decided that it would be a good idea to prepare for the winter. The leaves and sticks she used to build her shelter the previous year were getting dry, and it wouldn’t hurt to have a new home to spend the winter in comfort.

She quickly started to plan the wonderful shelter she would build. Now that she had time she would build it with every possible comfort. She would be the envy of the whole meadow. The stories about her new home would be heard far away, further even than the cypress hedge. It would have spacious windows so the light would flood in, and she would design a clever pulley system that would save her many trips to and from the barn to store what she had collected.
The Ant, however, had a plan. In August she would build the first room, which would be the barn. That way, if the rains started early this season, she and the other ants would have at least some extra space to store their grain. Then she planned the rest of the work according to its importance. If she didn’t have enough time to finish it all by the deadline, she would have built at least the most important parts.

In September she would dig a hole that would later become the hall were the first larvae of the year would live. In October she would build an additional room to increase barn capacity. Lastly, in November she would finish the work by digging a hall where she could grow fungi.

In the meantime, the Cicada was worried about having a dining hall that was big enough, and a structure as solid as necessary to hold everything she had imagined. She would run back and forth looking for the materials she would need to build all the things that she had planned in her head.

In October the first rains came, but the Cicada didn’t even have a basic shelter to take cover in. Also, water ruined some of her first constructions that were halfway built, and she had to start again. Then November came and the weather became really ugly. She had to hurry up and started working from sunrise to sunset.

Those first October rains made the Ant think that something could go wrong, and she decided to test whether the work that was already done would be useful. She started to fill her new barn with grain and soon she noticed that the access hole was too small for big leaves, and that it should be a bit higher if they wanted to avoid water or mud coming through. In order to fix this, they had to stop doing other things.

Winter came early that year, and the Ant realized that she wouldn’t have enough time to build the last room, so in the main anthill they decided that they should open an extra entrance, in case the main one got blocked by a stone or an enemy.

The Cicada, however, was surprised by the bad weather. She didn’t really know what was finished and what wasn’t. Also, what she had considered finished had not been tried out, and now there was no time to improve it. Winter was here and no more work could be done.

In her new shelter, under the leaking roof, the Cicada promised herself that this would never happen again: “Next year I’ll start work even before the Ant,” she said to herself.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

How we used Scrum in our software projects

These days I have been preparing and updating a Prezi presentation about how we used Scrum (or Agile development) in our software development projects.

You won’t find there a Scrum theory implementation but the process and methods we used to try to become more Agile (whatever that means) and to deliver software regularly and frequently (working software).

Reach the presentation at Prezi: Practical Scrum – How we used it.
or have a look at it here:

Functional tests with Selenium WebDriver

(Sorry, this is a technical post about software testing, but don’t worry, you can find here some of my non-technical blog posts)

A few years ago we used Selenium IDE in a web application project just to check the functionalities developed at that sprint were working as expected but there were some problems with that. I try to sum up them here:

  • Selenium IDE works only with Mozilla Firefox web browser. That was a problem when you did need to test another browser or your web app worked only in MS Internet Explorer.
  • Tests and tests suites used to become red frequently. Firefox updates (on security mainly) made script commands deprecated easily so it was needed to search for a replacement, when available, or to find a workaround (after a few hours in Stackoverflow). To keep them working in order was costly (and time consuming).
  • There was some kind of a mess with script commands: type or typeKeys, click or clickAt, mouseAt or mouseDown. You never knew.
There were also some advantages, of course, like the way the user actions could be recorded by the IDE. You just had to click somewhere, move the mouse or type something that your movements were recorded by the IDE as script commands. It was needed to adapt or fix them after recording it but it used to made things easier. 
These days I have been playing around with Selenium WebDriver. It doesn’t need to inject javascrit code into the web browser and you can use your favourite programming language to write the tests.
I have written a couple of tests to check one of my web applications just to show you some of its main features and how Selenium WebDriver can work on Chrome. At the end of this post you can find a video showing how these tests work.

This first test is a kind of smoke test just to check that the application is working properly and shows the main page when it is requested:

Below you can find how to get the driver variable for Chrome. Using it you can have access to all WebDriver commands. It is written inside the jUnit @Before annotation so it is going to be executed before any other test run. At the @After method there will be a driver.quit(); sentence.

This last test actually checks that 10 questions are asked at each attempt (no more, no less), chooses randomly one of the multiple choice options and ensures that there is a results page at the end.

This is the Selenium/JUnit tests video recording:

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

References:

Agile 101: Scrum’s sprint 0 and the initial design

Sometimes we’re in projects in which we need to prepare a large number of things before starting out. Can we start building without stopping to plan or analyse what we’re about to do?
When we read about Scrum, we get the impression that all texts start directly with development, but…what about environment, team or office preparation tasks? What about design? Shouldn’t we stop to think about the whole design and architecture of what we’re about to build before we start programming?

About preparation or “before” programming. Some people call it “sprint #0”, the sprint where you prepare your tools, install the stuff you need, train the team, etc.. It can be a longer sprint (3, 4 weeks or so). Some detractors criticise this sprint because it is not agile, and because it hides some work that is taken care of in the same way as the rest.

It is true that it can be very comfortable, because we tell the client that we’ll be back in 3 weeks to have the preparation meeting for the first sprint, and by then we have organized it all. I have also used those zero sprints in my first projects, but now I prefer to solve those issues also in an Agile manner.

I try to make every one of those tasks (installing the development server, installing the demo server, creating a project and tasks in Trac or Redmine, installing the Integrated Development Environment or IDE, etc.) part of the first sprint and, if possible, have a set deliverable at the end of each demo.

In that demo, we could show, for example, the project-management tool already installed in the final URL and the task list with the tasks ready to be assigned, or we could launch the IDE in that demo meeting, and check whether the environment has been created correctly and whether Jetty executes a “Hello World” application correctly.

Another important step is the initial architecture design. If we make a huge design with all the application architecture (known as a big up-front design) before we start programming, we will be returning to a waterfall design. Firstly, we analyse everything, three months later we do all the design work during a couple of months, and then we program everything in one go until we finish it six months later. If we finish all work and show it to the clients and they say: “that is not what we discussed a year ago…” then we have a problem.

It is better to design one of the modules of the application, or one of the new features, then draft the specifications, and finally send them to development. While part of the team implements them, analysts can gather requirements for another module or another feature, and go on doing so sprint after sprint.

There will be sprints in which we won’t have new stuff to analyse and others in which the development goes a bit faster than the specifications, but normally there is always some task ready to be carried out while Product Owners sign off the latest requirements, or until those requirements are completely defined.

If we work like that, new modules or features could be regularly deployed to production or preproduction, so users will be able to take advantage of them without waiting until the very last feature of the application has been designed.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad