Ajedrez - antoniomartel.com

Archivos por Etiqueta: EN

SCRUM Pros and Cons

jueves, 17 octubre 2013 19:55
antoniomartel
0 Comentarios

If you are considering SCRUM as a working method but you do not know very well what SCRUM is all about. You’ve heard a lot of people talking about the benefits of this system but, how many technologies and techniques have appeared quickly and disappeared even faster? All of them promised to be revolutionary. When we hear so much hype about a new one we bow in critical eyebrow .

A few months ago I published a prezi to explain the advantages and disadvantages of implementing SCRUM in an organization (I tried to be impartial, I promise):

In this post I will explain this prezi using words instead of pictures.

The team may be tempted to take the shortest path

You have to deliver things every two weeks. At the last delivery the team was not able to complete all planned functionality. The team velocity does not predict that you will finish on time this time. It is then when a new problem arise: the team may be tempted to resolve pending tasks in a hurry leaving behind them technical ‘debts’. Apparently everything goes well, more functionality made​, new ones are started, and the customer is happy because they are on schedule.

But whenever a blur is left behind you can be sure that you will have to face it sooner or later. If new things are built on this blot, the ‘debt’ begins to multiply. Soon you’ll have to stop everything and commit to repay the debt (with interest rate). The project does not come to an end when there was little to finish it: burndown chart seems to have a horizontal asymptote at 0 (sorry, some Maths)

Do you need dates of delivery well in advance?

This is one of the most common critics to SCRUM. In a way it makes sense, it is not possible to predict when you’re going to end if what you are going to build may change and vary over time. But do you prefer a product that is known with certainty to be completed in 10 months but it is built on the ideas and opinions you had 10 months ago? Maybe you prefer a product that could be finished within similar time but it can evolve to your real needs.


Stress!

We can not spend our lives sprinting. As soon as we deliver a new functionality, we are committed to the following one, which is only a couple of weeks away. Then another and another one. If we had to travel many miles, we can begin with a quick sprint to reach the first goal but we’ll be walking slowly to reach the last one.

Is your team self-organized?

One of the principles of Scrum is that the team should make their own decisions and manage themselves. Furthermore, it requires that there is no members of the team focused only in specific tasks such as analysis or testing. Inside the same team you should have someone able to test, to code, to write a specification, to analyse, and so on. Do you always have a team like that? What if we do not have it?

It is certainly a problem but, is there any methodology that can finish projects successfully not having at hand people with the required skills?

IV Conference on Sustainability

jueves, 17 octubre 2013 19:04
antoniomartel
0 Comentarios

Last Thursday I had the honor of giving a presentation on Phase 2 of the Canary Islands Waste Information System (GUIRRE) at the Fourth Conference on Sustainability inside the activities for the World Environment Day.

GUIRRE is a very special project for me for several reasons: It was the first time we run a project using continuous integration (Jenkins) and automated tests using Selenium IDE.

At the beginning of the project, before starting to program, we defined a section called ‘How to test it’ for every feature we had to develop. We recorded tests with Selenium, following the steps of the ‘How to test it’ section. Those tests helped to show that the new feature worked properly. If we found a bug, we recorded also a test to reproduce it. When the test became green, we had fixed it.

Every two weeks, we recorded all tests of the current Sprint on a Selenium ‘suite’. Every night, the continuous integration server, Jenkins, ran the suite and all suites from previous Sprints and reported if there had been mistakes. If the previous morning someone had modified a piece of code affecting a functionality developed some months ago, Jenkins showed us some dark clouds.

The other reason GUIRRE is a dear project to me is because we managed to finish under budget (yes, those projects exist) despite we fully assumed the cost of learning Jenkins and Selenium, and that the budget was very adjusted. Quite a challenge.

I leave below a few pictures of the event and a link to the paper I presented. Hope you find it of interest.

More about estimations

jueves, 17 octubre 2013 18:48
antoniomartel
0 Comentarios

When talking about estimations ysing Agile techniques, there are certain things that are hard to accept for those who, for a few years, have already been planning and calculating times and dates.

We can find many planning techniques Agile: Planning Poker, clothing sizes ( S , M , L , XL , etc. . ) or the Team Estimation Game but, admittedly, all of them are difficult to integrate into a traditional development environment and even less for the customers of our products (at least those I’ve been working with)

Most of us are not used to see a team ‘playing cards’ for a session of Planning poker (at least I’m not) However, I agree with the philosophy behind these techniques and I think the fact that they are becoming increasingly popular it is, in part, because they are attempting to banish certain beliefs about the estimates:

Wrong estimations

Can we get it right? Estimate is to make a prediction about what would take to do a task or the materials we need to do a job. When we estimate with a high uncertainty, as when we do it based on some procurement specifications, rather than a prediction is a gamble.

It is obvious that we need to estimate. We try to predict what will happen to make decisions, but unless you have done the same task many times before and we have done it with the same team and under the same circumstances, we must know that there are high chances of being wrong.

The more effort you devote to the estimate we approach reality

To estimate has a cost and a it is a high cost. When we do not know the detail of every feature of the work, Does it make sense to devote hours and hours to elucidate tasks that do not know well? Make an exercise for me, when you finish your next project check the time recorded in each task. You will see that where you estimated 20 took 100 to you and where you estimated 100 hopefully only took 20 to complete the task. You will also see other tasks with no imputed hours. Simply they were not needed. However, how many hours were logged on tasks, which nobody thought about them at the initial estimation.

With this or that technique will estimate better

There are many estimation techniques but few will be as useful as a simple comparison of the time that took to do similar projects, the simple breakdown into smaller tasks or the expert judgment.

To use complex estimation techniques can give us a false sense of security about our estimation but it may not provide much higher reliability .However it can lead us to incur a very high cost (see above) and to invest a precious time that we could have used better in other things (such as reducing uncertainty)

My communication at the V Conference on Sustainability in the Canaries

jueves, 17 octubre 2013 18:22
antoniomartel
0 Comentarios

A few weeks ago, the Canary Islands Department of Environment was kind enough to invite me to give a talk at the V Canary Sustainability Conference in held on Thursday October 3. My paper was on the Waste Information System of the Canary Islands and other software systems that help the Waste Department to control the produced waste in the islands. I hope I have not bored much to those not versed in information systems for hazardous waste!

I leave here a link to my presentation on Thursday:

The V Conference on Sustainability in the Canaries were chaired by the Deputy Minister of Environment of the Canary Islands Government and had as its theme the challenges in waste management on islands so several representatives of Cape Verde attended to share experiences on the management of waste in both archipelagos.
The presentations focused on :

  • [Sal, an island with no plastic] with a representative of the City Council of the Island of Sal in Cape Verde.
  • [Models and waste plan in Cape Verde] by Mr. Gilberto Silva, Councillor for the Environment of the City Council of Praia.
  • [El Hierro 100 % recyclable] by Ms. Fabiola Avila, Environmental Technician Cabildo de El Hierro.
  • [The impact of waste on Climate Change] by Mr. Fernando Herrera, Head of Prevention and Control of Pollution of the Canary Islands.
  • Best practices in waste management by representatives of the Group Martinez Cano and Lopesan Islands.

You can find all the information and some pictures of the event at the following address: Guacimara Medina opens the V Sustainability Conference in the Canaries.

Keep it Simple, Stupid

jueves, 17 octubre 2013 17:53
antoniomartel
0 Comentarios

Recently, after a conversation with a professional colleague on the current IT world, something reminded me of a Andres Diplotti cartoon I saw first time in Google+:

As a programmer I have been for a long time, and partly still I am, acknowledge that I have had this kind of arrogance (without going to these extremes) I guess it is a sin of youth that has been mitigated with age and that some of us already had since college.
By that time I remember to have discovered the software design patterns book from The Gang of Four. Our applications began to fill with design patterns, the more you used the better, in a kind of competition won by the one who used the more complex and difficult pattern. I guess this helps me to understand the posts and articles I see now on refactoring to eliminate design patterns and the cost of all these changes in some projects.
Over the years I learned firsthand the KISS principle (Keep it Simple , Stupid) not only with patterns, but also when customizing graphical components on screen or with the ‘ghost requirement’, a name that I heard on a rise to a co-worker to refer to those features that nobody asked but one believes important to the customer and that ‘for sure’ he would end up needing.
Long ago, a project manager on a client told me that someone in another team had indicated that it was impossible to get the functionality he asked. I replied that practically everything could be achieved by investing the necessary time. I was not clear enough . I should have added, Is it reasonable to use all that time on that functionality? With almost any programming language one can send a rocket to the moon but do you really want to go to the moon or do you want a working application on time?

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. 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