Sunday, 27 October 2013

Mi página web con Twitter Bootstrap

Hace algunos meses oí hablar de Bootstrap, la herramienta de trabajo que dos trabajadores de Twitter crearon para acelerar los tiempos de desarrollo de nuevas páginas web y disminuir las tareas de mantenimiento haciéndolas más homogéneas. Me decidí a probarla y para ello qué mejor que crear una página web real en la que pudiera publicar contenidos como complemento a este blog.

Crear una página web con Bootstrap no puede ser más sencillo. Descargas las librerías de esta herramienta, la plantilla que te interesa (en mi caso el carrusel de imágenes) y luego las librerías de jQuery. Apenas es necesario programar nada, solo hacer unas modificaciones a los enlaces y las etiquetas del menú y ya tenemos una página web con menús desplegables, carrusel de imágenes, bloque de destacados, etc.

Hasta aquí sólo tenía un html en mi disco duro así que necesitaba un servidor web o una empresa de hosting donde alojar mi página para que estuviera accesible desde Internet. En lugar de eso utilicé el espacio de Google Drive (ver referencias) que viene con mi cuenta de Gmail y creé ahí una carpeta pública donde copié el index.html, las imágenes de la web y otros archivos que necesita Bootstrap.

Ya tenemos la página web publicada en Internet. Google Drive te proporciona un link enorme a esa carpeta pública (https://googledrive.com/host/0B7JU-NBrpaxVaktjOHVkNWM5Vlk/) pero con la ayuda de acortador de urls como el de Google (https://goo.gl/) se puede convertir esa dirección a una url un poco más amigable.

Twitter Bootstrap probablemente no sea de gran ayuda para el desarrollo de aplicaciones web de gestión pero si tienes que construir una página web con un diseño claro y limpio que además siga los estándares actuales de diseño web puedes contar una gran variedad de componentes y plantillas predefinidas en Bootstrap que te harán el trabajo mucho más fácil.

Les dejo aquí un enlace al resultado final enlazada desde mi esta misma web: http://perfil.antoniomartel.com.

Referencias:

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.



Es un ebook en formato Kindle pero no te preocupes si no tienes un lector de libros electrónicos. Una vez comprado seleccionas que lo quieres leer en Kindle Cloud Reader y desde entonces podrás leerlo siempre que quieras sólo con ir a la página read.amazon.com. En tu ordenador de casa, en un tablet o en tu móvil, donde quieras. 



Sunday, 20 October 2013

Administración Pública y las nuevas prácticas de gestión

Somos muchos los que de una manera u otra trabajamos para la Administración Pública, algunos directamente pero otros muchos indirectamente, como proveedores de servicios o productos pero trabajando en este sector al fin y al cabo.

Muchos tratamos de realizar estos servicios o entregar esos productos aplicando técnicas de gestión ágiles como Scrum o Lean Management pero solemos encontrarnos con cierta rigidez en la formalización de los contratos o en los pliegos de contratación de los concursos públicos.

Alguien preguntaba recientemente en un debate del grupo PMP Canarias en LinkedIn si las administraciones públicas estaban preparadas para la gestión de este nuevo tipo de proyectos. En mi opinión, a la Administración Pública Española aún le queda un buen trecho pero creo que ya se comienzan a ver ciertos avances en la aplicación de nuevas formas de gestión como Lean Government, especialmente en otros países.

En el NHS, el sistema de seguridad social británico, con la aplicación de técnicas Lean para eliminar retrasos innecesarios, reducir el papeleo y aprovechar los tiempos muertos de espera para realizar 'actividades útiles' se consiguió reducir la mortalidad en dos tipos graves de fractura de un 22,9% a un 14,6% en solo seis meses. Eso significa que en ese periodo, de media, unos 14 pacientes más lograrían sobrevivir a la operación.

Otro ejemplo de Lean Healthcare se encuentra en un hospital de distrito del NHS. La clasificación de las pruebas de ultrasonido en 'verdes' para las más simples y 'rojas' para las más complejas permitió reducir la lista de espera para estas pruebas de 12 semanas a tan solo 2. Se asignó el tiempo justo para la complejidad de cada prueba y se redujeron los trámites y el papeleo al mínimo para las pruebas más simples con lo que además de la reducción en los tiempos de espera se logró que quedasen más huecos en el calendario para tratar adecuadamente las posibles urgencias.

Mucho más reciente es la actualización de las normas de contratación del Departamento de Defensa de Estados Unidos para declarar 'ilegales' los proyectos en cascada. Parece ser que uno de los proyectos que ha disparado esta decisión fue el proyecto Sentinel en el que después de un proyecto fallido inicial de 170 millones de dólares, retrasos considerables, 6 años de trabajo y 451 millones de presupuesto se consiguió finalmente poner en marcha el nuevo sistema, gracias entre otras cosas, a la aplicación de técnicas ágiles de desarrollo para reducir los tiempos de entrega y los costos de cada funcionalidad entregada.

También en España parece haber un creciente número de instituciones públicas como el Museo Thyssen, el Hospital Clínico de San Carlos en Madrid y su Smart Health Lab o la Agencia Tributaria que están comenzando a usar y aplicar técnicas ágiles como Lean Government en sus negocios. Espero que estas instituciones sean solo la punta de lanza para lograr una Administración Pública más eficiente en estos 'lean times'

Referencias:

Thursday, 17 October 2013

SCRUM Pros and Cons

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

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

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

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


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?

Sunday, 13 October 2013

Keep it Simple, Stupid

Hace poco tiempo, después una conversación con un colega de profesión sobre el mundo IT actual, algo me recordó una viñeta de Andrés Diplotti que vi por primera vez en Google+:

Como programador que he sido durante mucho tiempo, y que en parte sigo siendo, reconozco haber tenido este tipo de soberbia (sin llegar a estos extremos) Supongo que un pecado de juventud que se ha ido mitigando con la edad y que algunos ya teníamos desde la universidad.

Por aquella época recuerdo haber descubierto los patrones de diseño software con el libro de The Gang of Four. Nuestras aplicaciones comenzaron a llenarse de patrones de diseño, cuantos más usabas mejor, en una especie de competición ganada por aquél que usaba el patrón más complejo y difícil de entender. Supongo que esto me ayuda a entender los posts y artículos que veo ahora sobre refactorizar para eliminar patrones de diseño y los costes que esto tiene en algunos proyectos.

Con los años he aprendido en carne propia el principio KISS (Keep it Simple, Stupid) no solo con los patrones, sino también con la personalización de los componentes gráficos que aparecen en pantalla o con los 'requisitos fantasma', denominación que oí en una ocasión a un compañero de trabajo para referirse a esas funcionalidades que nadie te ha pedido pero uno cree importante para el cliente y que 'seguramente' que él terminará necesitando.

Hace mucho tiempo, un director de proyecto en un cliente me comentó que alguien en otro equipo de trabajo le había indicado que era imposible conseguir la funcionalidad que él pedía. Le contesté que prácticamente todo podía conseguirse invirtiendo el tiempo necesario. No fui lo suficientemente claro. Debí haber añadido: ¿es razonable usar todo ese tiempo en ese funcionalidad?  Con casi cualquier lenguaje de programación uno puede enviar un cohete a la Luna pero ¿de verdad se quiere ir a la Luna o se quiere una aplicación terminada en el tiempo previsto?

Sunday, 6 October 2013

Mi ponencia en las V Jornadas de Sostenibilidad

Hace unas semanas la Viceconsejería de Medio Ambiente del Gobierno de Canarias tuvo la amabilidad de invitarme a dar una ponencia en las V Jornadas de Sostenibilidad en Canarias que tuvieron lugar el pasado jueves 3 de octubre. Mi ponencia trató sobre el Sistema de Información de Residuos de Canarias y otros sistemas software que ayudan al Servicio de Residuos a controlar los residuos producidos en las islas. ¡Espero no haber aburrido mucho a los no versados en sistemas de información sobre residuos peligrosos!

Les dejo aquí un enlace a mi presentación del jueves



Las V Jornadas sobre Sostenibilidad en Canarias estaban presididas por la Viceconsejera de Medio Ambiente y tenían como lema los retos en la gestión de residuos en territorios insulares por lo que varios representantes de Cabo Verde asistieron para poder compartir experiencias sobre la gestión de residuos en ambos archipiélagos.
Las ponencias trataron sobre:

  • [Sal, una isla sin plástico] por una representante de la Cámara Municipal de la Isla de Sal en Cabo Verde.
  • [Modelos y plan de residuos en Cabo Verde] por D. Gilberto Silva, Concejal de Medio Ambiente de la Cámara Municipal de Praia.
  • [El Hierro 100% reciclable] por Dña. Fabiola Ávila, Técnico de Medio Ambiente del Cabildo de El Hierro.
  • [El impacto de los residuos en el Cambio Climático] por D. Fernando Herrera, Jefe del Servicio de Prevención y Control de la Contaminación del Gobierno de Canarias.
  • Buenas prácticas en la gestión de residuos a cargo de representantes del Grupo Lopesan y Martínez Cano Canarias.

Podrán encontrar toda la información y algunas fotos del evento en la siguiente dirección: Guacimara Medina inaugura en Las Palmas las V Jornadas de Sostenibilidad en Canarias.

Por último, les dejo un enlace a una entrada en este blog sobre una ponencia previa en las Jornadas sobre Sostenibilidad que tuvieron lugar el pasado mes junio: Gestión avanzada de residuos - Sistema de Información de residuos de Canarias (GUIRRE)