Agile Project Management with Scrum

"Agile Project Management with Scrum" de Ken Schwaber, es un libro que presenta Scrum mediante practicas de administración de proyectos mas tradicionales. No es un libro que explique Scrum desde cero, recomienda que se tenga algún conocimiento antes de abordarlo, pero igual da una pequeña introducción al principio.

Lo que mas me gusto de este libro es que esta contado por experiencias que tuvo Ken para aplicar Scrum en distintas organizaciones, todas relacionadas a una practica de administración de proyecto. Por ejemplo recuerdo que estaba implementando Scrum en una organización muy tradicional donde no podían faltar los diagramas Gantt en los reportes de estado, entonces cuenta como pasar de un backlog a un diagrama Gantt fácilmente.

Otro dato que da también interesante es como vender un proyecto Scrum a clientes que trabajan generalmente con proyectos de costo fijo, da una serie de tácticas y ventajas a enunciar, aunque el autor recalca que no siempre es posible ni siempre es la mejor solución. Scrum es una herramienta mas, un proceso mas, y aunque lo defiende a muerte, sabe que no se puede aplicar en cualquier ocasión.

Lo mas difícil de Scrum, a mi parecer, es como escalarlo para equipos muy grandes, como hacer distintos equipos Scrum, (un Scrum de Scrums) y que eso salga bien, cuando hay muchas interacciones entre equipos, personas compartidas. Realmente explica muy bien varios casos donde fue aplicado de forma diferente.

Sin embargo, la enseñanza principal que me dejo el libro es que Scrum es altamente adaptable, al ambiente, la organización, la gente. Hay que saber utilizarlo, respetando sus reglas, pero cambiando lo necesario en cada proyecto para llegar al éxito.

Los proyectos de costo fijo y la rotación no van de la mano

En los proyectos de costo fijo la retención de la gente es primordial. La razón de mi afirmación es muy simple: en un proyecto de costo fijo uno acuerda la funcionalidad y el precio de antemano. Esta estimación que uno realiza la hace teniendo a personas en mente, aunque inicialmente pueden ser perfiles, con distinto seniority y skills, que luego se traducen en nombres. Cuando se tiene al equipo listo, un contrato firmado, una fecha cerrada, uno comienza a trabajar con el equipo. Si alguien del equipo se va por alguna razón y es reemplazada, existe un gran costo para que la nueva persona llegue a comprender todo lo que la otra persona sabia hasta el momento de irse. Este costo se basa en todo el tiempo que tienen que utilizar otras personas del proyecto para enseñarle a la nueva persona, y todo el tiempo hasta que esta persona es productiva (La famosa ley de Brooks).

No hay forma de ganar plata con un reemplazo, no veo ninguna. Tal vez si se va un júnior, asignar a alguien de mayor seniority para que aprenda mas rápido. O en vez de asignar a una persona, asignar a dos. Se gasta mas eligiendo ambas.

Una empresa que se dedica a trabajar con proyectos de costo fijo tiene que cuidar mucho a la gente, escucharla, hacer lo posible para que estén bien, para minimizar la rotación. Tampoco se puede esperar que no exista la rotación, para eso se debe asignar un tiempo buffer extra en la estimación.

En una empresa donde se realizan proyectos en la modalidad time and materials, o Staff augmentation la rotación no juega un rol muy importante, ya que los clientes pagan una cierto persona por hora, y si esa persona se va, tiene que pagar las horas de aprendizaje de la nueva persona, aunque al cliente no le guste.

Para cerrar este articulo, una imagen muy graciosa que describe la rotación que estamos viviendo hoy en día:

"Talk time" con el cliente

Hace poco entro un nuevo Product Owner en el cliente (ya que el anterior se fue de la empresa) y se hizo cargo de dos productos que están siendo desarrollados por dos equipos que lidero.

Realmente voy a extrañar al anterior Product Owner, porque se notaba que sabia de lo que estaba hablando, y era muy claro en las conferencias, mails y walk throghs del producto.

Cuando presentaron al nuevo Product Owner en una conferencia me asuste un poco porque hablaba muy rápido ingles, y no se le entendía mucho (Es una persona de India). Luego por suerte le comencé a entender.

El otro día charlando por IM (algo que no hacia con el anterior Product Owner), empecé a preguntarle de como se sentía en la empresa, empezamos a hablar de nuestros trabajos anteriores y como se tenia que ir, acordamos calendarizar 'talk time' para este lunes, para conocernos mejor. Esto va a estar muy bueno para tener un contacto mas fuerte con el cliente, para enterarme mejor de sus prioridades, su forma de trabajo y de esa manera poder ayudarlos mejor. Ultimamente me estaba sintiendo medio flojo, ya que en las conferencias se trataban temas que para ellos eran obvios y nosotros no habíamos considerado, por falta de comunicación y de conocimiento de nuestra parte de lo que ellos necesitan.

Sin escribir mas, espero con ansias charlar con el Product Owner el lunes para mejorar el nivel de servicio que le damos en los proyectos que estamos llevando a cabo para ellos.

The 21 Indispensable Qualities of a Leader: Becoming the Person Others Will Want to Follow

Este es el segundo libro de liderazgo que leo de John Maxwell, y realmente lo disfrute mucho. El primero lo comente en un articulo anterior (ver articulo).

Este libro esta organizado en 21 capítulos donde cuenta 21 cualidades que para el autor son indispensables para ser un buen líder. Este libro es muy ameno, se lee muy rápido ya que es altamente entretenido debido a que en el medio de la expoliación de las cualidades, hay infinidad de historias y relatos reales que se basan en lo que esta explicando.

Leer este libro reforzó mi convicción en lo que quiero seguir, me ayudo a remarcar y reflexionar en puntos débiles de mi persona, actitudes en las que debería mejorar. Es un libro tan fácil de leer que pienso que lo voy a leer una vez por año para ver como ando con respecto a lo que recomienda el Sr. Maxwell.

Mail de despedida de mi primer trabajo

Les dejo parte del mail de despedida de mi primer trabajo. Como muchos sabrán, es una costumbre mandar un mail a todos para despedirse formalmente, y para que se entere gente que no es muy cercano a uno. Ahora que lo pienso, no le veo mucho sentido, pero igual es algo que se hace comúnmente.

Como muchos saben, hoy es mi último día.

En esta relación de tres años y dos días (exactamente), destaco todo lo que aprendí y en quien me convertí, ya que al bajar las alfombradas escaleras de Tucumán, a las 1030am de ese 28 de abril del 2005, no sabía quién era, ni que quería hacer en el mundo del software. Durante estos tres años definí un rumbo, un perfil, como profesional, gracias a los proyectos, los clientes y la gente con la que tuve el honor de trabajar.

Seguidamente destaco a la gente, mis compañeros, el ambiente, la cultura y las costumbres de las cuales me va a costar mucho desprenderme. Fue una experiencia invaluable trabajar estos años acá con ustedes, con algunos más tiempo, con otros menos.

Un abrazo grande a todos!!!

Como verán, no es muy emotivo, ni jugado, ni muy involucrado. Realmente raro para mi, ya que los que me conocen bien saben que soy una persona muy emocional, pero todo se debe al momento que estaba viviendo en esa época.

Notas de lanzamiento de un proyecto (Release notes) - Página wiki de Trac

En este articulo les voy a comentar como armaba las notas de lanzamiento o release notes de un proyecto en una página del wiki de Trac (Trac un software de administración de proyectos web que recomendé anteriormente).

Antes, un poco de teoría de las notas de lanzamiento, conocidas como Release notes o changelog en ingles. Cada vez que uno saca una nueva versión de un producto de software, ya sea esta una aplicación de escritorio o una aplicación web hay que sacar notas de lanzamiento, para informarle al cliente o al receptor del producto en que se diferencia la versión entregada con las anteriores (también se hace cuando se entrega la primera versión del producto, el que no haya una versión anterior no quita de que haya que escribir las notas de lanzamiento).

En un proyecto en el cual teníamos que desarrollar una aplicación web que soportaba la creación de una librería de software, el desarrollo de esta aplicación era incremental. Cada versión que sacábamos editábamos una pagina wiki en Trac, incluyendo lo siguiente:

Nombre del producto - Versión x.x - Fecha de lanzamiento: x/x/x

• Nuevas funcionalidades: Estas son las mejoras o nuevas funcionalidades acordadas para esta versión.
  
• Defectos corregidos: Estos son defectos que fueron encontrados en versiones anteriores y fueron arreglados para esta versión.
  
• Problemas existentes ('known issues'): Estos en especial conviene consensuarlos anteriormente con el cliente, para que no se lleve sorpresas. Es posible que se decida retrasar el lanzamiento de la versión para que se resuelva algún problema existente. Estos también podrían denominarse defectos no corregidos, pero esa nomenclatura es mas dañina.
  

Alguna (o mas de una) de las secciones anteriores puede estar vacía. Además de tener esta pagina wiki dábamos la opción de descargar un archivo DOC con la misma información, el cual era guardado en el repositorio.

Lo mas importante de esto es que cada una de las funcionalidades nuevas, los defectos y los problemas existentes esta cargado en la lista de tareas (o tickets) del trac, y automáticamente son referenciados de esta pagina. Para referenciar un ticket, basta solo con escribir #xx, siendo xx el numero del ticket, y el enlace se creara automáticamente. Esto es muy importante para que cualquier persona pueda ir rápidamente a ver de que se trata cada ítem de las notas.

Agile Software Development

Este libro escrito por Alistair Cockburn se trata (como su titulo indica claramente) sobre las metodologías o los procesos de desarrollo de software ágil.

No trata sobre ninguna metodología en particular (aunque usa como ejemplo XP). El objetivo del autor es contar todas las ideas de fondo del movimiento ágil, el porque de seguir este tipo de metodologías.

Se pasa mucho tiempo describiendo la dinámica de equipo de trabajos, la forma en que fluye la información entre la gente, las necesidades de los clientes, como debería sentarse la gente. Este libro no trata de enseñarte ninguna metodología, lo que hace es venderte las metodologías ágiles teniendo en cuenta que problemas resuelven y como se manejan en diversas ocasiones, y el autor lo hace muy convincentemente.

Lo que explica de maravilla es como cada metodología sirve para cada situación, no nos trata de vender que con una metodología ágil liviana se pueden hacer sistemas donde hay posibilidad de que alguien pierda la vida.

El autor cierra el libro comentando la historia de cuando el y otras eminencias mas se unieron para escribir el manifiesto del desarrollo de software ágil, contando lo difícil que fue ponerse de acuerdo en ese momento entre tanta gente y rescatando el aporte de cada uno en esa reunión. Muy recomendable!

Estudio del Multitasking: Hay solución a sus problemas?

Muchos de nosotros estamos asignados a varias tareas y a múltiples proyectos, y esto crece mediante vamos aumentando nuestra experiencia y capacidad. Se toma como algo natural en el crecimiento profesional, pero todo no es color de rosa en el multitasking, que se define como el arte de hacer mas de una cosa a la vez.

“To do two things at once is to do neither.” Publilius Syros -Roman Philosopher – 100AD

Les recomiendo que visiten el siguiente sitio de Mike Sanders, que explora ese concepto en profundidad. Les transcribo lo que me pareció mas importante de su estudio:

Mike estableció unas métricas y se midió durante un año y este fue el resultado:

• Task Loading - There were now twice as many tasks in my queue each week.

• Completed Tasks - I was completing half as many each week.

• Overtime - I was working double the overtime hours each week; many times over 20.

• Health - My health was poorer; I had gained over 30 lbs, did not exercise, and did not sleep regularly.

• Happiness - Had become relatively unhappy; I had less fun time at home, generally disliked my job, and I was not very happy.

• Relationships - Relationships had become strained at work and at home. They had worsened.

También midió los efectos nocivos del multitasking:

1. Lost task switching time results from the physiological time gap we experience each time we switch tasks This could cumulatively be ~5% of your work day.

2. Poor task engagement results from the productivity lag of cognitive and memory ramp-up after a task switch, This could cumulatively be ~20% of your work day.

3. Faulty task prioritization occurs from accidental or careless decisions to work on the wrong task. This could cumulatively be ~50% of your work day.

4. Task performance errors happen when mistakes are made from incorrect task assumptions or facts. This could cumulatively be ~25% of your work day.

Se concluye que el multitasking es malo. Espero que nadie lo dude. Mike propone la practica de Powertasking para solucionar los problemas del multitasking. Acá están los pasos a seguir:

• Determine your life priority. Answer the question "What do you want" (WDYW)?

• Framed by the answer to WDYW, List and Prioritize all your tasks, both personal and business.

• Create task queues (or triggers) when you engage them to help re-engage your tasks at a later time.

• De-engage tasks properly.

• Delete tasks when you can.

• Delegate tasks when you can.

• Transfer tasks when you can.

• Shave tasks when you can.

• Breathe once in a while, look up, take a walk! People actually stop breathing at their terminals over time!

• Get feedback on your progress in real time and then apply it.

En resumen, la idea principal es hacer una cosa a la vez, y hacerla bien. Entrar completamente y luego salir de esa tarea de la misma forma. Como tenes prioridades bien definidas, sabes cómo seguir! Lean atentamente el sitio de Mike Sanders, no tiene desperdicio.

Código del cliente en proyecto de costo fijo: anulación de la garantía!

Hace poco me enfrente a una situación poco usual en un proyecto de desarrollo de software realizado bajo un contrato en la modalidad de costo fijo.

Resulta que el cliente quería acortar los tiempos de entrega entregando parte de la funcionalidad acordada previamente en el contrato del proyecto. Además, una de las razones dadas era que ellos tenían mayor conocimiento del negocio en esa funcionalidad, ya que trabajaban diariamente con el equipo de negocios que requería la aplicación.

A simple vista no le preste mucha atención a esto. Nuestro mayor miedo fue que el código que nos iban a entregar iba a ser desastroso, que íbamos a tardar mas en integrarlo que en hacer la funcionalidad nosotros mismos.

Luego de unos días, uno de los gerentes nos hizo saber otro problema. Nuestro contrato establece una garantía de un año para cualquier defecto que se encuentre luego del cierre del proyecto. Si ellos tocan el código de alguna forma, se anula la garantía. Yo no tuve esto en cuenta (Mal PM Martin, mal PM!). Es como cuando uno compra una computadora, que tiene el precinto de seguridad, si uno la abre, se pierde la garantía. Esto era algo bastante obvio que no se tuvo en cuenta.

Al final, se le acepto el código al cliente (es difícil decirle no a un cliente) debido a que estaban muy apurados y era una situación muy difícil para ellos.

Por suerte el código entregado fue integrado sin mayores problemas, ahora estamos esperando a ver los errores que nos puedan llegar a reportar!

Midiendo la calidad del código: WTFs por minuto

Software y Poesía

Les dejo esta comparación entre desarrolladores de software y poetas que hace Alistar Cockburn en el libro "Agile Software Development". Muy interesante!

What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together. I make this comparison not because I think you have experience in community poetry writing, but because I think you don't. Your imagination will supply you with the sorts of contradictions I am interested in evoking.

Imagine 50 people getting together to write a 20,000-line epic poem on cost and time. What would you expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do their best, without enough talent, time, or resources.

Who are the players in this drama? First, the people who ordered the poem. What do they want? They want something they can use to amuse themselves or impress their friends, not too expensive, and soon.

Next we have the key poem designers.

As you might imagine, this began as a one-person project. But our mythical poet found herself promising much more than she could deliver in the given time frame. So she asked a few friends to help. They designated her the lead poet and poem designer. She blocked out the theme and the poem's sequencing.

Her friends started to help, but then they ran into problems with synchronizing and communicating their work. It also turned out that they couldn't get it all done in time. So they added a couple of clerical people, more friends, and in desperation, even neighbors. The friends and neighbors were not real poets, of course. So our lead designers blocked out sections of the poem that would not require too much talent.

What do you think happened?

There was good news: One person was good at descriptive passages, another was good at the gory bits, and another was good at passages about people. No one was good at emotion except the lead poet, who by now was pulling her hair out because she didn’t have time to write poetry, she was so busy coordinating, checking, and delegating.

Actually, a couple of people couldn't leave well enough alone. Two of them wrote pages and pages and pages of material describing minor protagonists, and our lead poet could not get them to cut it down to size. Another few kept rewriting and revising their work, never satisfied with the result. She wanted them to move on to other passages, but they just wouldn't stop fiddling with their first sections.

As time progressed, the group got desperate and added more people. The trouble was that they were running out of money and couldn't really afford all these people. Communications were horrible, no one had the current copy of the poem, and no one knew the actual state of the poem.

Let's give this story a happy ending...

As luck would have it, they engaged a wonderfully efficient administrator who arranged for a plan of the overall poem, an inventory of each person's skills, a time-frame and communication schedule for each part, standards for versioning and merging pieces of the poem, plus secretarial and other technical services.

They delivered the poem to satisfied clients, well over budget, of course. And the lead poet had to go on vacation to restore her senses. She swore she would never do this again (but we know better). Groups have surely have gotten together to write a long poem together. And I am sure that they ran into most of the issues that software developers run into: temperamental geniuses and average workers, hard requirements, and communication pressures. Humans working together, building something they don't quite understand. Done well, the result is breathtaking; done poorly, dross.

Hug a Developer Today

Impresionante video sobre las penurias de los desarrolladores de software. No se lo pierdan

Developing The Leader Within You

Este es el primer libro de liderazgo que leo, y realmente es muy entretenido e interesante. John Maxwell escribió muchos libros de este estilo (estimo que entre tantos debe haber bastante superposición de temas). El tema principal del libro es desarrollarse uno como persona para enfrentar un puesto de liderazgo o mejorar y dar lo mejor de uno en todo lo que hace.

Personalmente, lo que más rescaté es la forma en que me hizo dar cuenta de la importancia de dar el ejemplo, entre muchas otras cosas. Creo que este libro me marco y me dejo pensando sobre muchas cosas de mi personalidad sobre las que tengo que trabajar para hacer las cosas mejor, y eso lo veo como algo muy valioso.

So Long, and Thanks for All the Fish!

En este articulo doy por cerrada una etapa de alta dedicación al Blog. Luego de cuatro meses con por lo menos un articulo por día, decidí tomarme esto con mayor tranquilidad, sin la obsesiva necesidad de escribir tanto.

Voy a seguir escribiendo artículos, voy a seguir leyendo libros, y obviamente voy a seguir trabajando en el apasionante mundo de la ingeniería de software.

Esto recien es el comienzo!

Facts and Fallacies of Software Engineering

Facts and Fallacies of Software Engineering es un reciente (2002) libro de Robert Glass donde enuncia 55 hechos y 10 falacias de la ingeniería de software, cuidadosamente indicando las fuentes de cada uno de ellos y antes presentando una discusión y controversias sobre el tema.

Es un libro muy valioso, porque realmente te abre la cabeza. Hay pocas verdades que pueden llegar a sorprender a cualquier persona que esta en el mundo del software hacer rato, es mas, hay verdades que pueden herir a mas de uno. Yo no estuve muy de acuerdo con varias de ellas. Lo mejor fue que muchas me sorprendieron gratamente, entre ellas verdades sobre el mantenimiento de las cuales escribí ayer.

El objetivo de este libro es hacer pensar a la gente, presentar estos hechos para que se pueda discutir y actuar sobre ellos para progresar. Lo considero esencial para cualquier practicante de la ingeniería del software.

Les dejo los hechos resumidos en una oración que obtuve del Blog Coding Horror:

People

1. The most important factor in software work is the quality of the programmers.
2. The best programmers are up to 28 times better than the worst programmers.
3. Adding people to a late project makes it later.
4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

5. Hype (about tools and technology) is a plague on the house of software.
6. New tools and techniques cause an initial loss of productivity / quality.
7. Software developers talk a lot about tools, but seldom use them.

Estimation

8. One of the two most common causes of runaway projects is poor estimation.
9. Software estimation usually occurs at the wrong time.
10. Software estimation is usually done by the wrong people.
11. Software estimates are rarely corrected as the project proceeds.
12. It is not surprising that software estimates are bad. But we live and die by them anyway!
13. There is a disconnect between software management and their programmers.
14. The answer to a feasability study is almost always "yes".

Reuse

15. Reuse-in-the-small is a solved problem.
16. Reuse-in-the-large remains a mostly unsolved problem.
17. Reuse-in-the-large works best in families of related systems.
18. Reuseable components are three times as hard to build and should be tried out in three different settings.
19. Modification of reused code is particularly error-prone.
20. Design pattern reuse is one solution to the problems of code reuse.

Requirements

23. One of the two most common causes of runaway projects is unstable requirements.
24. Requirements errors are the most expensive to fix during production.
25. Missing requirements are the hardest requirements errors to correct.

Design

26. Explicit requirements 'explode' as implicit requirements for a solution evolve.
27. There is seldom one best design solution to a software problem.
28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

29. Designer 'primitives' rarely match programmer 'primitives'.
30. COBOL is a very bad language, but all the others are so much worse.

Error removal

31. Error removal is the most time-consuming phase of the lifecycle.

Testing

32. Software is usually tested at best to the 55 to 60 percent coverage level.
33. 100 percent test coverage is still far from enough.
34. Test tools are essential, but rarely used.
35. Test automation rarely is. Most testing activities cannot be automated.
36. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
38. Rigorous inspections should not replace testing.
39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
42. Enhancements represent roughly 60 percent of maintenance costs.
43. Maintenance is a solution-- not a problem.
44. Understanding the existing product is the most difficult maintenance task.
45. Better methods lead to more maintenance, not less.

Quality

46. Quality is a collection of attributes.
47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

48. There are errors that most programmers tend to make.
49. Errors tend to cluster.
50. There is no single best approach to software error removal.
51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

52. Efficiency stems more from good design than good coding.
53. High-order language code can be about 90 percent as efficient as comparable assembler code.
54. There are tradeoffs between optimizing for time and optimizing for space.

Research

55. Many researchers advocate rather than investigate.

Para cerrar el artículo de hoy les dejo las 10 falacias:

1. You can't manage what you can't measure.
2. You can manage quality into a software product.
3. Programming can and should be egoless.
4. Tools and techniques: one size fits all.
5. Software needs more methodologies.
6. To estimate cost and schedule, first estimate lines of code.
7. Random test input is a good way to optimize testing.
8. "Given enough eyeballs, all bugs are shallow".
9. The way to preduct future maintenance costs and to make product replacement decisions is to look at past cost data.
10. You teach people how to program by showing them how to write programs.

No hay que desmerecer a los proyectos de mantenimiento

Estoy leyendo un libro titulado "Facts and Fallacies of Software Engineering" de Robert Glass y encontré unos hechos o "facts" sobre el mantenimiento en la ingeniería de software que me parecieron interesantes y compartí con el equipo del proyecto en cual trabajo (Que se trata sobre mantenimiento de varias aplicaciones) y tambien quiero compartir aca.

En este libro el autor presenta hechos y falacias, luego discute, luego cuenta las controversias alrededor del mismo y finalmente cita las fuentes.

Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Corolario: Old hardware becomes obsolete; old software goes into production every night.

Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.

The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal.

Maintenance is a solution, not a problem.

Far too many people see software maintenance as a problem, something to be diminished and perhaps even "obliterated." In saying that, they are really expressing their ignorance. The only way that software maintenance could be a problem would be if nearly all of it were about fixing errors. And we have already seen that it's not. Far from it, in fact. Maintenance, instead, is software's unique solution to the problem "we built this thing, but now we wish we had built something a little different."

In examining the tasks of software development versus software maintenance, most of the tasks are the same-except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.

Maintenance life cycle:

• Defining and understanding the change-15 percent
• Reviewing the documentation for the product-5 percent
• Tracing logic-25 percent
• Implementing the change-20 percent
• Testing and debugging-30 percent
• Updating the documentation-5 percent

Better software engineering development leads to more maintenance, not less.

Systems built using "modern development methods" were more reliable than those built using older ways. They required repair less often. But those systems required more time tomaintain them. How could that be?

These systems took longer to maintain than the others because more modifications were being made to them. And more modifications were being made because it was easier to enhance these better-built systems. Most organizations have a long backlog of enhancements to be made to their software products (Software 1988). The better-built systems were simply making their way through those enhancement queues faster than their more poorly built brethren.

Referencias: Facts and fallacies of software engineering, Robert Glass, 2002

Historial de versiones en una página Wiki de Trac

En este articulo voy a dejarles el simple código para armar una tabla con el historial de versiones en una página del wiki de Trac (Trac un software de administración de proyectos web que recomendé anteriormente).

Historial de versiones en una página de Trac

Siempre es recomendable mantener información de versiones en los wikis para ver rápidamente quien agrego que cosa, aunque también esta información esta accesible viendo la historia de este wiki (ya que Trac trabaja con control de versiones sobre los wikis).

Les dejo el código para que ingresen sobre todas sus paginas wikis en Trac. Para agregar una nueva linea, simplemente hay que copiar la ultima y cambiarle los datos.

===== Revision History =====
||Version||Date ||Author||Notes||
||1.0 ||2006.08.17||John||First draft||
||1.1 ||2006.08.31||Jane||Added this and that||

-----

Matemática... ¿Estás ahí?

Realmente me cuestan las matemáticas. No es algo que oculte. Debido a que me cuestan, siento rechazo por ellas. Es común sentir miedo o emociones negativas a algo que desconoce o que le cuesta. Igual siempre le vi un atractivo a ellas y este libro me ayudo a encontrarles un lado muy interesante.

En este libro, Adrián Paenza, quien es licenciado, doctor en matemática, y periodista, pretende contarle al lector sobre diferentes temas atrapantes de la matemática, dando a conocer distintos problemas de cierto interés y contándole al lector sobre diferentes propiedades y teorías pertenecientes a la matemática que podrían ser calificadas como divertidas; y declara que pensar puede ser algo entretenido. Como se señala en el resumen del libro, entre estos conceptos, problemas y demás relacionados con la matemática, Paenza le habla al lector de temas tan diversos como de los diferentes tipos de infinitos, de los números primos, la división por cero, las apuestas y las probabilidades, etcétera.

Hay tres libros en la serie. Hasta ahora leí los primeros dos, tengo que comenzar a leer el ultimo. Por suerte todos los libros están disponibles para bajarse gratuita y legalmente para uso personal. Les dejo los links:

Matemática... ¿Estás ahí?
Matemática... ¿Estás ahí?: Episodio 2
Matemática... ¿Estás ahí?: Episodio 3,14

When you ASSUME you make an ASS out of U and ME

Olvidándonos de la frase que titula a este articulo, todos los días hacemos asunciones, ya que son una parte natural y lógica del proceso de toma de decisiones. El problema se encuentra en:

1. Hacer asunciones en vez de tomar decisiones precipitadas: Cuando no puedo investigar algún tema tengo que tomar una asunción. Si puedo encontrar información fácilmente, demuestra que no hice mis deberes y tome una decisión precipitada.
   
2. Comunicar las asunciones al equipo: El equipo va a poder detectar errores!
3. Realizar seguimiento de las asunciones: El equipo va monitorear las asunciones que les comunicaste y va a saber cuando consultarte para revisar una decisión que tomaste cuando surge un problema
   

Para mas sobre este tema, les recomiendo que lean: Real World Decisions III: Making assumptions and jumping to conclusions

The Five Temptations of a CEO: A Leadership Fable

Este libro de Patrick Lencioni esta escrito en forma de fabula. Cuenta como un CEO de una empresa que tiene la reunión anual con los accionistas de la empresa al día siguiente se encuentra con unos extraños personajes en el tren, que le comentan las cinco tentaciones en las que puede caer un CEO. Realmente es un libro muy entretenido que te deja reflexionando sobre la forma en que uno actúa ante ciertas situaciones en la vida laboral (sea o no sea uno un CEO). Les dejo las cinco tentaciones de una crítica al libro, aunque igual les recomiendo que lo consigan y lo lean ya que van a poder entender cada una de ellas mucho mejor.

1. Soft-pedaling your drive to achieve results, tending instead to avoid making decisions that might damage your ego or reputation;

2. Wanting to be liked by peers and direct reports (It is lonely at the top, isn't it?), therefore shying away from holding them accountable;

3. Hesitating to take decisive action, (and/or hold direct reports accountable), until more information is in hand. In a world of imperfect and ever-shifting information, the CEO can project vague and hesitant direction to his/her reports, at the risk of paralysis;

4. Restricting "productive ideological conflict" among the management team during decision-making, a temptation motivated by a desire for harmony and/or a fear of conflict; and,

5. Overtly or unconsciously portraying himself/herself as invulnerable, discouraging direct reports from challenging his/her ideas, in turn preventing the foundation of trust that can steady an organization through hard times.

Gracias Ivo por la recomendación!

Las leyes de Murphy generales y para IT (Murphy's Laws of Information Technology)

Las famosas e infames leyes de Murphy son conocidas por todo el mundo. Se aplican a todas las disciplinas humanas, pero estoy seguro que al software le afecta mas de lo común, debido a la juventud de esta actividad. Les dejo las principales leyes de Murphy:

• Nothing is as easy as it looks.
• Everything takes longer than you think.
• Anything that can go wrong will go wrong.
• If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
• You never run out of things that can go wrong.
• If anything simply cannot go wrong, it will anyway.
• If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
• If everything seems to be going well, you have obviously overlooked something.
• It is impossible to make anything foolproof because fools are so ingenious.
• Whenever you set out to do something, something else must be done first.
• Every solution breeds new problems.

Dejando atrás las leyes generales, entremos en las leyes de Murhpy aplicadas a IT, que son las originales extrapoladas a este campo.

Sobre Hardware:

• Law of Inconvenient Malfunction: A device will fail at the least opportune possible moment.
• Law of Cable Compatibility: If you choose a cable and a connector at random, the probability that they are compatible is equal to zero.
• Law of Hardware Compatibility: The probability of a given peripheral being compatible with a PC is inversely proportional to the immediate need for that peripheral.
• Law of Bad Sectors: The probability that an untested diskette will have bad sectors is directly proportional to the importance of the data written onto the diskette.
• First Law of Selective Gravitation: When an object is dropped, it will fall in such a way as to cause the greatest possible damage to itself and/or other objects on which it lands.
• Second Law of Selective Gravitation: The tendency for an object to be dropped is directly proportional to its value.
• Law of Reality Change: Unalterable hardware specifications will change as necessary to maximize frustration for personnel affected by said specifications.
• Law of Noise: Noise bursts occur so as to cause the most, and/or most serious, errors in data communications, regardless of the actual amount of noise present.
• Law of Expectation: Consumer expectations always outpace advances in hardware technology.
• Law of the Titanic: If a device cannot malfunction, it will.

Sobre programación:

• Law of Debugging: The difficulty of debugging software is directly proportional to the number of people who will ultimately use it.
• Law of Neurosis: The chances of software being neurotic (developing bugs spontaneously without apparent reason) is directly proportional to the confusion such neurosis can cause.
• Law of Available Space: If there are n bytes in a crucial software program, the available space for its convenient storage or loading is equal to n-1 bytes.
• First Law of Bad Sectors: The probability of software being mutilated by bad sectors is directly proportional to the value and/or importance of the programs.
• Second Law of Bad Sectors: When a program is mutilated by bad sectors, the damage will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Noise: When a downloaded program is corrupted by noise, the corruption will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Software Compatibility: If two programs are chosen at random, the probability that they are compatible is equal to zero.
• Law of Option Preferences: When two people share a computer, their software option preferences will differ in every possible way.
• Law of Expectation: Consumer expectations always outpace advances in software technology.
• Law of the Titanic: Bug-free software isn't.

Ver Referencia.

No lo van a leer!! (TAGRI)

Continuamos con los principios. Este esta relacionado con la documentación. TAGRI significa They ain't gonna read it. No creo que haya alguien que dude este principio, la documentación no siempre se lee (¿Es gratificante hacer la documentación para usuarios?).

Este concepto se complementa con el que enuncie ayer, YAGNI. La idea de las metodologías ágiles es crear documentación 'ágil' que refleje las necesidades reales de la audiencia de la documentación. La mejor manera de hacerlo es trabajar lo mas cercanamente posible con la gente para la cual uno esta documentando.

Estos son problemas típicos de la documentación en el software:

• Projects with detailed requirements specifications fail and/or to have the development team ignore portions of the specification because they believe they know better.
• Detailed architecture documents be created by a project architect only to have the developers take their own approach anyway, even when the original architecture was pretty darn good.
• Detailed test documents created only to be discarded at the end of the project because the development team has run out of time.
• Documents created put on the shelf and ignored after they passed the documentation review.

La solución se basa en cumplir las siguientes reglas:

• Treat documentation like any other requirement. Any document, even if it's IT related, should be costed, prioritized, and treated like any other system requirement.
• Create documents with a clear audience.
• Work with the true audience to identify their actual needs.
• Write agile documentation: any documentation that you do write should be just good enough for your current situation.
• Single source information: When you single source information you strive to record it in one place and one place only.
  

Les recomiendo que lean la fuente de este articulo, que contiene cuatro anectodas muy interesantes.

YAGNI!

YAGNI, o "You ain't gonna need it" es un termino que fue utilizado por primera vez por la gente que apoya XP (Extreme Programming). Es una practica que argumenta lo siguiente:

"Always implement things when you actually need them, never when you just foresee that you need them."

Este principio consiste en que no se debe nunca agregar funcionalidad excepto que sea necesario. La tentación de escribir código que no es necesario, pero que puede serlo en un futuro tiene desventajas. Estas son las principales razones para respetar el principio\:

• You save time, because you avoid writing code that you turn out not to need.
• Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.

Fuentes: Wikipedia; ExtremeProgrammingRoadmap

El principio KISS

El principio KISS ('keep it simple, stupid') enuncia que la simplicidad en el diseño del software (u otra disciplina) debe ser un objetivo clave y que la complejidad innecesaria debe ser evitada. Este principio es utilizado en las metodologías de desarrollo ágil, ya que el diseño es incremental y se refactoriza el código constantemente, sin tomarse mucho tiempo al principio para tener un arquitectura para toda la aplicación, como se suele hacer en las metodologías de software clásicas.

Esto es algo muy básico, pero hay veces que es olvidado, demasiadas veces. Cuando uno evita por alguna razón u otra la solución mas simple a un problema, se va a encontrar con cuestiones a resolver inesperadas, que generalmente superan en recursos y en tiempo al camino mas simple, y el resultado es el mismo o peor.

Siempre sigan el camino mas simple, las soluciones rebuscadas no ayudan en nada!

Poniéndose el equipo al hombro

Hoy voy a recordar una conversión que tuve con un directivo de la empresa en mi primer trabajo que cambio mi forma de pensar sobre mi rol de líder de proyecto y la forma de afrontar situaciones. Todo surgió por un problema en la paga de un equipo externo que trabajaba en un proyecto de creación de una librería de software.

El tema fue que se les había prometido algo, pero debido a cambios en la empresa (Léase fusión) no pudieron cumplirse. Era un tema de recursos humanos, entonces yo estaba esperando que el encargado de recursos humanos (que se encargaba de la liquidación de sueldos) les comentase sobre el tema.

El equipo había venido a la empresa por una reunión de entrenamiento y querían saber en que estado estaba el cumplimiento de la promesa, y yo sabia que no se iba a cumplir, pero opte por pedir ayuda a la persona de recursos humanos para que venga a hablar con ellos del tema ya que con su experiencia en el área estaría mejor capacitado para manejar ese tipo de situaciones. La cosa es que como eran diez personas, la persona de recursos humanos opto por no ir y resolver el tema luego para evitar problemas (Léase diez personas juntas enojadas por la rotura de la promesa).

Luego tuve la conversión con un directivo de la empresa que me comento que si era mi equipo, yo me tenia que encargar de notificar cualquier cosa, sea tema del proyecto, paga, lo que sea. Realmente esa charla me sirvió, porque yo antes evitaba estos temas y al encargarme pude sentirme mejor con respecto a la gente. Les conté uno por uno como era la situación y sentí un inmenso alivio, ya que no había mas nada que ocultar.

Mi consejo es que sea cual sea el problema, hay que comunicarse siempre, ir con la verdad y ver luego que rumbo seguir. En este caso el tema ya estaba resuelto, no había nada mas para hacer, pero gane mas confianza con el equipo y aunque estaban descontentos en ese aspecto, siguieron trabajando sabiendo que yo había hecho todo lo posible.

Don't Make Me Think: A Common Sense Approach to Web Usability

Uno de los últimos proyectos en los cuales trabaje en mi primer trabajo fue en un desarrollo de un sitio web de "venta" (en realidad leasing) de autos. Era un sitio que mucha gente utilizaría entonces se le prestaba especial atención a cualquier tema que podría parecer mínimo, como la ubicación de las cosas, los colores, etc.

Realmente el cliente tenia muchas buenas sugerencias y yo me ponía mal porque no había pensado en ellas! Entonces decidí buscar algo sobre diseño y usabilidad web y me encontré con este libro de Steve Krug, que es uno de los mas famosos del genero.

Realmente es un libro muy divertido para leer y comienza a explicar como realmente usamos la web (Leer capitulo gratuito del tema) y luego da muchas sugerencias de la forma de organización, navegación y toda la interacción con un usuario en un sitio web.

Estoy muy de acuerdo con el autor en que la gente busca información en la web, estamos todos muy apurados y nos molesta tener que dar datos sin sentido, ni que nos llenen la pagina de fuegos artificiales que no sirven para nada. El autor termina el libro con unos mails genéricos para mandar a los managers para convencerlos de porque eso es malo. Imperdible para cualquier persona que le interese el tema de usabilidad y también diseño web.

Assembla - Accelerating Software Development

Una herramienta web muy popular para albergar proyectos de software gratuitamente es Assembla. También existen versiones comerciales con muchas mas funcionalidades (ver comparacion). Es muy interesante para hacer trabajos prácticos para la facultad.

Estos son algunos de los servicios que provee la versión gratuita:

• Ilimitada cantidad de miembros de un equipo.
• Subversion (Repositorio de hasta 500MB).
• Trac (Tickets y administración de proyectos).
• Wiki.
• Foro de discusiones.
• Alertas por mail, RSS..
• Chat.
• Seguimiento y reporte de tiempos.

Esta herramienta es altamente recomendable para utilizar para hacer cualquier tipo de proyecto de software en equipo.

Llamada inesperada: en la cuerda floja

La segunda vez que salimos a comer afuera en nuestros almuerzos semanales que comente ayer, tuvimos un llamado urgente que lo interrumpió. Nuestro gerentes de ventas estaba en Estados Unidos para lanzar un proyecto que veníamos haciendo, realmente hace muy poco, con pocos recursos y donde los problemas eran muy comunes.

El tema era que la primera versión no funcionaba. Eramos muy jóvenes es esa época, no seguíamos ningún proceso de desarrollo ni teníamos a alguien de QC asignados. La versión la habíamos lanzado el lunes bien tarde y falto aplicarle un Stored Procedure ala base de datos, que impedía que el programa cumpla con la función principal para el cual fue diseñado. Realmente un error trágico.

El líder técnico y yo abandonamos al resto de los comensales, nos pusimos los trajes de bomberos y el casco y fuimos a la empresa a ver que pasaba. Por suerte luego de unos momentos muy tensos, solucionamos el problema, el gerente de ventas se las arreglo para que el cliente no nos cancele el contrato y ese proyecto fue muy exitoso, aprendimos mucho y nos trajo muchas alegrías hasta su cancelación.

Almuerzos semanales con el equipo y otros compañeros de la empresa

A principio del 2006, propuse a mis compañeros de Isla (y a cualquier otra persona que se prendiese) a romper la rutina e ir a comer todas las semanas un día afuera, ya que siempre comíamos en la oficina. Realmente fue una propuesta muy exitosa que realmente disfrute durante mi estadía en mi primer trabajo y en el comienzo del segundo. Así realice la propuesta:

Gente,

Propongo que una vez por semana, podría ser el viernes, salgamos a almorzar todos los de la isla (Puede venir gente de otra isla si quiere). Estaría bueno que cada semana alguien proponga un lugar distinto. Como yo sugerí esto, y además como hace mucho tengo ganas, propongo ir a este viernes al Subway que esta por florida, llegando a plaza de mayo.

Saludos!

Como veran tiene tiempo, ya que el local de Subway fue cerrado. El viernes pasado se fueron de la empresa de mi primer trabajo las ultimas dos personas con las que seguía juntándome ya que mi nuevo trabajo queda muy cerca. Ahora estaremos separados y no nos juntaremos tan seguido. Voy a extrañar mucho nuestras reuniones.

Realmente fue una muy buena idea juntarnos a comer seguido, realmente afianzo al equipo y también a otras personas de la empresa.

Sin comunicación con el cliente: naufragio inminente

En el proyecto mas largo que participé (en mi primer trabajo), en los últimos 9 meses de sus casi 2 años de duración, la comunicación con el cliente era muy escasa, prácticamente inexistente. Realmente era muy raro, ya que llegaban los pagos (muy jugosos de por cierto), nosotros realizábamos las entregas que estaban programadas y no obteníamos nada de feedback.

El proyecto se basaba en la creación de una librería de archivos para ser utilizada en un programa de identificación de software, de "License compliance" o "Software Asset Management". Por lo poco que sabíamos, nuestra librería iba a ser adoptada en una futura versión de ese programa y las pruebas de identificación que habían realizado no eran muy exitosas que digamos.

Corregíamos las pocas cosas que nos decían, y seguíamos trabajando para mejorar el producto, pero en los últimos 9 meses no hubo mucha comunición. Se notaba preocupación en el ambiente, y nos recomendaban que no nos contactemos con el cliente al menos que sea absolutamente necesario, ya que mientras llegase el dinero, los directores estaban tranquilos. No querían que se den cuenta que el proyecto seguía en curso, no querían despertar al monstruo. Igual sabían que tarde o temprano iba a terminar, debido a el poco interés del cliente. Como dice el titulo (el primero de este blog que me sale con rima), si no hay comunicación con el cliente, espera un naufragio inminente.

Pueden leer la historia de la cancelación de ese proyecto acá, y ver el maravilloso equipo que formo parte del proyecto acá.

Features are a one-way street

Hace poco me encontré con este interesante artículo que comentaba sobre una funcionalidad que se había agregado al sitio de Netflix (Es un servicio de alquiler de películas web).

Luego de unas semanas de haber puesto el servicio en producción, lo sacaron porque les parecía ser muy confuso y no le veían valor.

Pero fue demasiado tarde. La gente se enojo. El anuncio del cancelamiento de esta funcionalidad en el blog recibió 1287 comentarios. Netflix cambió de parecer y publico la funcionalidad nuevamente.

La lección es que cuando tenés una gran cantidad de usuarios, no podes sacarles funcionalidades. Sea buena o mala la nueva funcionalidad, una vez que lo lanzaste, es como un contrato con tus usuarios, que si son numerosos, seguro que una buena porción de ellos la utilizara sea o no sea buena.

Lean el comentario de un cliente furioso que cancelo su subscripción a Netflix:

I was so pissed about this I immediately called my wife and we agreed to cancel. They sent me a generic BS email a couple of days later saying “You spoke, we listened…”. But they didn’t think far enough ahead to make an offer to people like me to actually re-sign up. I sure ain’t gonna go out of my way to sign up again so they messed up twice.

Managing Software Development with Trac and Subversion

El libro "Managing Software Development with Trac and Subversion" de "David J Murphy" es el primer libro de Trac que salio, y debido a mi gran amor por Trac, tuve que conseguirlo. Realmente me desilusiono bastante, porque es muy corto y no entra en muchos detalles sobre Trac (un software de administración de proyectos web que recomendé anteriormente).

El libro empieza con practicas básicas de administración de proyectos y luego cuenta como llevarlas a cabo con Trac. Debido a mi experiencia con el sistema, conocía la mayoría de lo que se comentaba en el libro, pero me sorprendí de varias cosas que desconocía.

Para un principiante en Trac se los recomiendo, ya que además tiene una muy buena guia de instalación. Les dejo el articulo libre "Software Documentation with Trac" del libro.

Lanzamiento de Trac 0.11!

Estoy muy contento de anunciar que ya salió Trac 0.11. Trac es un software de administración de proyectos web que recomendé anteriormente. Les dejo el anuncio oficial de Jonas Borgström del grupo de Trac en Google:

Trac 0.11
=========

We're happy to announce the much awaited Trac 0.11 release.

You will find this release at the usual place:
http://trac.edgewall.org/wiki/TracDownload

Here are some of the features you can expect from this version:

* New template engine for generating content (Genshi)
* New configurable workflow in the ticket subsystem
* Finer-grained control of permissions
* Support for Pygments as the default syntax highlighter
* Improved repository browser ("blame" support, dynamic in-place
expansion of folders)
* Improved user preferences subsystem, among which the possibility
for any user to select their time zone and disable access keys
* The WebAdmin plugin is now an integral part of Trac

You can find a more detailed release note at:
http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11

Acknowledgements
================

Many thanks to the growing number of people who have, and continue to,
support the project. Also our thanks to all people providing feedback
and bug reports that helps us make Trac better, easier to use and more
effective.
Without your invaluable help, Trac would not evolve. Thank you all.

Finally, we offer hope that Trac will prove itself useful to like-
minded programmers around the world, and that this release will prove an
improvement over the last version.

Please let us know. :-)
/The Trac Team http://trac.edgewall.org/

Asignando desarrolladores Juniors para realizar tareas complejas: Cuando el cliente se da cuenta

En mi primer trabajo, en un proyecto en el cual teníamos que hacer unas tareas de mantenimiento para un cliente, me asignaron a mí para comunicarme con él y un desarrollador junior para llevar a cabo la tarea. Luego de unos días de trabajo recibo por IM lo siguiente del cliente:

I'm a little concerned right now because once the fields are known, the process to import the data shouldn't take very long. I'm starting to question what the team has been doing for so many days.

El cliente tenia razón (¿no la tiene siempre?). No era una tarea muy compleja, un desarrollador con más de un año de experiencia la sacaba en unas horas y ya llevábamos varios días. Estas son situaciones difíciles para los Project managers. A uno le asignan recursos, y a veces tiene que tratar de alargar los tiempos lo más que pueda con el cliente. En esta situación lo que hice fue comunicar esto a mi superior y asignamos a alguien para que resuelva la tarea y lo pudo hacer en unas horas. Yo había avisado que estábamos bastante atrasados, había cumplido con mi deber.

Esta es una de las tantas situaciones incomodas que los Project managers tienen que enfrentarse. La única solución que veo es escalar para arriba si uno no maneja los recursos de la empresa (siendo Project manager es imposible controlar esto).

Desarrollando software de a tres empresas

En el proyecto de creación de la librería de software para un producto de “Software Asset Management / License compliance” nosotros nos encargábamos de armar la librería (que era una base de datos que era procesada por una página web de validación de datos) y un equipo en la empresa del cliente estaba desarrollando el producto que iba a utilizar nuestra librería. Realmente la comunicación entre los líderes técnicos de ambos proyectos eran conflictivas. Este podría ser el esquema:

El líder técnico del cliente no se esforzaba por entender nuestros conceptos, y nosotros no podíamos transmitirlos de la mejor manera. Entonces el Sponsor del proyecto contrato a un consultor externo de una empresa ubicada cerca de la empresa cliente que sabia ingles. Esto realmente soluciono todos nuestros problemas y durante el tiempo que trabajo, ayudo a armar la comunicación entre la librería y el producto y quedamos todos contentos como se puede ver en el siguiente esquema:
Obviamente que no podemos culpar solo al líder técnico del cliente, ya que seguro que de alguna forma nosotros fallábamos al no poder hacernos entender. La contratación de un tercero podría haberse prevenido si no hubiesen existido los problemas de comunicación, pero hay veces que estas cosas son necesarias y miradas frescas influyen positivamente en los proyectos.