Autor: javier

  • Indexados vs Dividendos, una comparativa objetiva.

    En este artículo vamos a tratar de hacer una comparativa lo más objetiva posible entre las estrategias de inversión en indexados y la inversión en dividendos y al final del mismo daremos nuestra opinión sobre cuál es, en nuestra opinión, mejor estrategia de inversión.

    NOTA: Importante, nada de lo que se dice en este artículo es una recomendación de inversión.

    El objetivo de la inversión.

    El objetivo de la inversión no es otro que el poder mejorar la calidad de vida que tendremos cuando lleguemos a la edad de jubilación, cuando la posibilidad de seguir trabajando no exista e incluso en algunos casos cuyo nivel de ahorro y gastos lo permitan, adelantar la fecha de la misma.

    Las estrategias

    Para comenzar vamos a definir en que consisten las dos estrategias que vamos a comparar ya que muchas veces nos encontramos con debates en los que se suele simplificar mucho las estrategias de inversión, esto ocurre especialmente en la estrategia de inversión en dividendos.

    Indexados

    La estrategia de inversión en indexados es lo que se suele llamar inversión pasiva ya que consiste en comprar participaciones de uno o más fondos que de forma automatizada tratan de conservar un porfolio de acciones que replican el índice que tiene como referencia, este tipo de activos financieros es conocido como ETF indexado.

    Aunque existe ETFs indexados que reparten los dividendos cobrados, en este tipo de inversión no se incluyen ya que en caso de hacerlo, dejas de tener la principal ventaja fiscal que este tipo de productos tienen y que es diferir el pago de impuestos.

    Esto puede parecer una forma muy sencilla de inversión y lo es pero todo inversor en este tipo de activos financieros debe, si quiere obtener la mejor rentabilidad posible, estudiar en cuáles empresas esta invirtiendo cada uno de los ETFs que adquiere, si no lo hace, el inversor puede tener la falsa sensación de estar diversificado. También debe saber cuáles son las comisiones que va a pagar por cada uno de ellos pues la ventaja más importante de la inversión pasiva, frente a otras formas de inversión delegada, es que tienen unas comisiones bajas.

    Además debería conocer cuál es la retención por dividendos y la rentabilidad por dividendo de los ETFs que seleccione, de esta parte no se suele hablar cuando se habla de ETFs indexados pero consideramos que es importante para poder hacer una comparativa, lo más ajustada posible, con otras inversiones.

    Por último hay que elegir un bróker adecuado para la estrategia, que en el caso del indexado el bróker elegido no es muy diferente al que debería seleccionar un inversor en dividendos y que comentaremos más adelante.

    Dividendos

    La estrategia de inversión por dividendo muchas veces se reduce, sobre todo cuando alguien trata de vendernos otra cosa, a comprar empresas que reparten dividendos y cuanta más rentabilidad inicial mejor pero esto está muy lejos de la realidad de la estrategia.

    La estrategia consiste, efectivamente, en comprar acciones individuales de empresas que reparten dividendos pero este solo es el primer filtro que un inversor que utilice esta estrategia realiza y quizás el menos relevante a la hora de decidir si una empresa entra o no en la cartera, cuando decimos «el menos relevante», nos referimos a que la rentabilidad por dividendo de la empresa no debe tener un peso importante sobre dicha decisión.

    Para decidir si una empresa entra o no en la cartera, el inversor debe realizar un análisis fundamental de las empresas para evitar comprar empresas que no son adecuadas para la estrategia. Con este análisis el inversor debería dilucidar si la empresa que está analizando realiza un reparto de dividendos adecuado al tipo de empresa, si cree que el negocio de dicha empresa es perdurable en el tiempo, si el precio que va a pagar por la empresa es interesante y un largo etcétera que se resume en si la empresa es buena o no.

    Por último, al igual que al invertir en indexado el inversor debe elegir un bróker adecuado para esta estrategia, todo inversor debe saber cómo gana dinero su bróker y para esta estrategia lo recomendable es que el bróker elegido solo cobre comisiones por compra/venta de acciones y por cambio de divisas y cuanto más bajas mejor. Esto es importante ya que hay brókeres que cobran comisión por mantener las acciones, por el cobro de dividendos o los conocidos como spread, realizar las compras por debajo del precio elegido o en las ventas por encima del precio indicado y la diferencia es la comisión que cobra el bróker, que pueden impedir que las ordenes de compra/venta se ejecuten afectando a nuestra rentabilidad.

    Pros y contras

    En esta sección vamos a enumerar los pros y contra de cada estrategia de inversión para posteriormente formalizar una opinión razonada de porque el redactor se decanta por una u otra estrategia de inversión.

    Indexado

    Pros

    • Una vez decidido los ETFs en los que invertir, no tienes que hacer ningún otro esfuerzo extra más que el de seguir aportando.
    • No se paga impuestos en destino por el cobro de dividendos.
    • Costes bajos.
    • Diversificación máxima, lo que nos reduce los riesgos.
    • Diferir el pago de impuestos

    Contras

    • Se pierden las retenciones en origen de los dividendos.
    • Compras más de lo que más caro está.
    • Compras menos de lo que más barato está.
    • Limitación de la rentabilidad a la propia del mercado.
    • Diversificación máxima, compramos malos negocios que si tuviéramos que elegir empresas de forma individual quizás no compraríamos.
    • Cálculos complejos durante la jubilación, etapa de la vida en la que peor tenemos nuestras capacidades mentales y físicas.

    Dividendos

    Pros

    • En la práctica las empresas que encajan en esta estrategia tienen una menor volatilidad.
    • El cobro de dividendos tiene un efecto psicológico positivo ya que ayuda a ver con claridad el avance de la estrategia cuando comparamos los dividendos cobrados con nuestros gastos.
    • Control del nivel de diversificación, al exigir un análisis de las empresas podemos evitar empresas que claramente son un error. Esto no quiere decir que no se comentan errores.
    • Podemos conseguir mejores rentabilidades que el mercado, no necesariamente de forma recurrente pero si a largo plazo.
    • Poder elegir en qué reinvertir los dividendos y por tanto reducir los riesgos.
    • El tiempo dedicado a las empresas analizadas refuerza la confianza en las inversiones.
    • Posibilidad de salirse de la estrategia. Poder comprar empresas que no reparten dividendo pero que creemos que pueden hacerlo en el futuro o empresas cíclicas cuyo dividendo suele pasar por fases en las que está en riesgo pero que si se compran y venden en el momento adecuado pueden ayudar a reducir el tiempo necesario para llegar al objetivo.
    • En la jubilación, las crisis no afectan tanto al consumo que podemos tener sin poner en peligro la jubilación ya que no reducimos la participación en las empresas a pesar de que puedan reducirse los ingresos.
    • Simplicidad durante la etapa de la jubilación.

    Contras

    • Pago de impuestos desde el primer año, lo que lastra el interés compuesto.
    • Requiere que se dedique tiempo y esfuerzo, tanto en aprender a analizar las empresas como a los propios análisis.
    • La práctica no es lo mismo que la teoría, aunque te formes antes de empezar a invertir, aprenderás muchas cosas que no se explican en la teoría durante tu etapa inversora, por lo que en el inicio tendremos un ratio de errores superior.
    • Menor nivel de diversificación, al requerir dedicar tiempo a las empresas limitaremos el número de empresas que podemos mantener en cartera.
    • Limitación en el crecimiento del patrimonio, las empresas que más crecen, habitualmente no reparten dividendos por lo que quedan excluidas.
    • Parálisis por sobre análisis, corremos el riesgo de no actuar por realizar un sobre análisis.
    • Posibilidad de salirse de la estrategia. Al salirse de la estrategia podemos aumentar mucho los riesgos, por ejemplo al usar opciones financieras.

    Como podemos ver, el listado de pros y contras es bastante más amplio en la estrategia de dividendos pero esto se debe principalmente a que las estrategias activas, como lo es la estrategia en dividendos, al permitirnos un número mayor de posibilidades de actuar también aumenta el número de posibles aciertos y errores.

    Conclusiones

    Para llegar a estas conclusiones, además de lo comentado en el articulo, se ha utilizado esta hoja de calculo en la que podemos realizar distintas comparativas de la rentabilidad de ambas estrategias.

    La clave que objetivamente inclina la balanza hacia un tipo de inversión u otro no es más que el lastre producido por los costes de cada una de las inversiones, las comisiones que pagamos y las retenciones en origen de las empresas que reparten dividendos y que no podemos recuperar en el caso de los ETFs indexado y el tipo impositivo que pagamos por los dividendos en la estrategia en dividendos. Es importante tener en cuenta que los costes de los dividendos en ambas estrategias es sobre el total del dividendo, en cambio la comisión que se paga por el ETF es sobre el total del valor del mismo.

    Con esto sobre la mesa y si no nos ponemos trampas al solitario, eligiendo valores irreales para los distintos parámetros que afectan a los costes, la rentabilidad de la inversión indexada es ligeramente superior a igualdad de rentabilidad total, pues por lo general podemos encontrar ETFs con unas comisiones que no superan la diferencia de costes que tenemos en los dividendos.

    Dicho esto, pensamos que aunque la rentabilidad de la inversión de los indexados es ligeramente mayor que la de la inversión por dividendos los pros y contras de cada una de las estrategias inclinan la balanza hacia la inversión en dividendos, en especial por la complejidad de las estrategias en la fase de la jubilación.

    Por último, indicar que aunque la hoja de calculo en el momento de publicar este articulo solo se centra en la fase de acumulación de capital, la intención es ampliarla con distintos escenarios que reflejen lo que podría ocurrir en cada uno de ellos. Lo que creemos que inclinará aun más la balanza hacia la inversión por dividendos.

  • Scrum

    En este post les traigo parte de la documentación del trabajo fin de grado que realice junto a un compañero, en el que describimos el funcionamiento de la forma de trabajo que utilizamos a la hora de gestionar el proyecto, aunque como verán está metodología está pensada para grupos de trabajo de entre 3 y 8 personas, aunque personalmente no lo aplicaría en grupos de menos de 5 personas.

    Que es Scrum

    Scrum es un marco de trabajo creado por Ken Schwaber y Jeff Sutherland a principios de los noventa, por aquel entonces ellos ya tenían experiencia como desarrolladores, directores de TI y compañías de software. 

    Scrum está pensado para gestionar proyectos complejos de manera incremental e iterativa, permitiendo obtener, en cada iteración, un producto entregable que irá adaptándose a factores que produzcan cambios en los requisitos del producto a desarrollar. Está encuadrada dentro de las metodologías ágiles, y aunque en principio nació enfocada al sector TIC, es aplicable en cualquier proyecto en el que exista una lista de requisitos cambiantes, bloques de trabajo y un equipo de desarrollo asignado a dicha tarea. En la propia guía de Scrum se define como algo:

    • Ligero 
    • Fácil de entender
    • Extremadamente difícil de llegar a dominar.

    El nombre de esta metodología viene de la similitud con la formación que se utiliza para reanudar el juego en un partido de rugby. En una scrum o melé el equipo debe estar perfectamente coordinado, si un miembro del equipo se cae, el equipo completo sufre las consecuencias. 

    Formación Scrum.

    En que se basa Scrum

    Scrum se basa en la teoría de control de procesos empírica que, en pocas palabras, asegura que la experiencia es la clave del éxito. Un control de procesos empírico aumenta la predictibilidad del producto  y proporciona un mejor control del riesgo. Seguir una gestión empírica viene de la mano de tres factores que constituyen los pilares de Scrum: inspección, adaptabilidad y transparencia. 

    La inspección tras cada iteración persigue detectar los elementos que se deben adaptar. Si se detecta algún desajuste frente a los objetivos reales, es posible adaptar el proyecto al final de cada iteración. Esto permite que el resultado final esté más cerca del esperado, pues es más fácil ir adaptando iterativamente, que intentar ajustar el proyecto una vez finalizado. Para que el proceso de inspección tenga sentido, es necesario que haya plena transparencia entre los miembros del Equipo. La situación del proyecto debe ser conocida por todos, en caso contrario podríamos dejar de lado alguna característica del producto que debe ser reajustada. Es importante que los miembros del equipo tengan un lenguaje común y una misma definición de ‘producto terminado’.

    La teoría de control de procesos, el seguir un modelo iterativo y buscar adaptabilidad, transparencia y una inspección regular del producto constituyen sin duda la base para que el producto cumpla los requisitos que se marcaron. Pero Scrum persigue algo más. Scrum persigue la originalidad, flexibilidad, la inspiración, la motivación e innovación. Estos elementos hacen que el equipo trabaje más cómodamente y permite a su vez la autosuficiencia del conjunto de trabajadores. Al no tener que depender de personas ajenas al proyecto, es más fácil la colaboración y conlleva mejores resultados.

    Cada iteración del proceso se denomina Sprint. Un Sprint es un periodo de tiempo, normalmente de entre dos semanas y un mes, en el que se desarrollan unas tareas especificadas previamente. Cada iteración, o Sprint, puede variar, aunque una vez definida la duración del Sprint a iniciar no puede ser alargado ni acortado para mantener la regularidad que busca Scrum, y que es clave en su éxito como marco de trabajo. Scrum se comentará con detalle más adelante, pero es aconsejable tener una idea del concepto para comprender los conceptos explicados antes que él. 

    Componentes de Scrum

    Scrum está formado por algunos componentes que caracterizan este marco de trabajo.  Básicamente, los conceptos más singulares de Scrum son artefactos, eventos y el Equipo Scrum.

     Aunque el equipo sea parte esencial de cualquier grupo de trabajo, la división y los roles que asigna Scrum son característicos de la metodología. Cualquier orden a la hora de explicarlos tiene inconvenientes, pues están estrechamente relacionados, mediantes los conceptos que constituyen la base de Scrum, y conforme uno de ellos es explicado aparecen términos propios de alguno de los otros. 

    Artefactos

    Los artefactos de Scrum son la Lista de Producto (Product Backlog), Lista de Pendientes (Sprint Backlog) y el gráfico Burndown. Las listas representan trabajo y son compartidas por los miembros del equipo para aumentar la transparencia.  Estas listas se modifican iterativamente, facilitando la adaptación del producto. En cambio el gráfico Burndown nos permite ver la evolución del Sprint y se modifica durante el Sprint. Estos artefactos contienen información clave y es necesario que todos tengan acceso a ella, aunque no todos tienen la libertad de modificarlos. 

    Lista de Producto

    La Lista de Producto es un documento que contiene las funcionalidades, requisitos, y necesidades del producto. Estos elementos se ordenan dentro de la propia lista de mayor a menor importancia en base a algún criterio. El responsable de esta lista es el Dueño de Producto.

    La Lista de Producto no estará completa hasta el final del proyecto. Mientras exista el producto en cuestión, y su gestión (desarrollo y mantenimiento) se haga dentro de Scrum, tendrá una lista asociada. La primera elaboración de está lista generalmente contiene los requisitos conocidos y que mejor se entienden, pero, a la vez que el producto en sí, el entorno y las necesidades cambian, la lista aumenta. El propio mercado proporciona retroalimentación y el Equipo Scrum detecta nuevas exigencias a las que dar solución. El entorno es algo cambiante, la introducción de una nueva ley, la entrada en el mercado de un producto, o el paso de una moda a otra, por ejemplo, son factores que condicionan la lista, y en cada iteración la lista de producto debe adaptarse a todo ello para conseguir un producto final acorde a las necesidades que pretende resolver.

    Cada elemento de la Lista de Producto tiene unos atributos concretos: descripción, orden, estimación y valor. En torno a estos se realiza el reordenado. Esto se hace mediante un proceso que en Scrum comúnmente se denomina “refinamiento”. El refinamiento es un proceso que se realiza en cada Sprint. El Equipo Scrum concreta cuando se realizará, y consiste en añadir detalles, y valorar cuantitativamente los elementos para priorizarlos. Generalmente, se utiliza el ROI para dar prioridad a cada requisito de la lista. A mayor ROI (cuanto más devuelva la inversión), mayor prioridad dentro de la lista.

    Aunque es conveniente que los miembros del Equipo Scrum se reúnan y debatan sobre el valor que hay que asignar, y la importancia de cada elemento, el verdadero propietario y responsable de la lista es el Dueño de Producto, y este tiene total libertad para alterarla.

    Lista de Pendientes del Sprint

    La Lista Pendientes del Sprint está formada por aquellos elementos de la Lista de Producto que han sido seleccionados para ser elaborados. Por tanto, existe una Lista de Pendientes por cada iteración del proceso. Aparte de los requisitos, la lista está constituida por un plan que regula cómo se llevará a cabo el objetivo del sprint.

    Visto desde otro punto de vista, este documento es una predicción del Equipo de Desarrollo, del trabajo que es capaz de desarrollar en el periodo de tiempo estipulado para el Sprint. También puede ser interpretado como un resumen del trabajo que el Equipo identifica como necesario para cumplir las metas impuestas por ellos mismo, pues, a diferencia de la Lista de Productos, esta lista pertenece al Equipo de Desarrollo, que se auto organiza libremente y marcan las pautas a seguir en cada tramo temporal.

    En cuanto al contenido de la Lista de Pendientes del Sprint, cabe destacar que es más detallada, pues en realidad es un sublista de la lista anterior. El nivel de detalle es tal, que cada punto podría corresponder al trabajo diario dentro del Sprint, con el fin de, entre todos los miembros del Equipo de Desarrollo, ser capaces de analizar el progreso diario. Pero, como no podía ser de otra forma en Scrum, la lista es dinámica. A la vez que se profundiza en uno de los elementos pendientes, se conoce mejor los pasos a seguir para lograr el objetivo y esto permite acortar o alargar la lista dentro de las limitaciones de tiempo inicial. También pueden influir factores externos tal y como pasaba con la Lista de Productos.

    Grafico burndown

    El gráfico burndown es una herramienta que proporciona información sobre como avanza el proyecto, de lo retrasado o lo adelantado que este va. Esta información ayuda a planificar mejor el próximo Sprint. El eje X de un burndown representa el tiempo en días y el eje Y representa las unidades de trabajo, en el gráfico se representa la evolución del proyecto estimada y lo que realmente está pasando.

    Ejemplo de Burndown Chart

    La imagen anterior representa el burndown de un Sprint, en ella se puede observar (en verde) la estimación que se realizó y lo que realmente ha sucedido (en rojo). Este gráfico indica que algo falló en la planificación del Sprint, quizás se subestimó la capacidad del Equipo de Desarrollo para alguna de las tareas que se realizaron durante este Sprint y se debería tener en cuenta para la planificación del siguiente Sprint o incluso cancelar el proyecto. Otra posibilidad es que alguna o varias herramientas de desarrollo no hayan estado disponible durante el día 22 (se puede observar que apenas se avanzó). 

    En cualquier caso este gráfico muestra que ha habido algún problema que se debe analizar y reparar para los próximos Sprints.

    Equipo Scrum

    Los artefactos dentro de Scrum potencian la adaptabilidad y por tanto la productividad, sin embargo, esto no sería posible sin un equipo que lo gestionase. Dentro de este marco de trabajo se distinguen tres partes diferentes que forman el grupo de trabajo: Dueño de Producto, Equipo de Desarrollo y Scrum Master. La suma de los tres desemboca en el Equipo Scrum, un equipo auto organizado y multifuncional. El propio equipo gestiona el trabajo y no necesita apoyo externo ni para la gestión, ni para cumplir los objetivos. Es autosuficiente. Este esquema de trabajo aumenta la flexibilidad, la creatividad y la productividad, que, como ya se explicó, son objetivos primordiales de Scrum. El equipo completo comparte un objetivo común, algo estrictamente necesario para lograr transparencia. 

    Dueño de Producto

    El Dueño de Producto es una persona física, nunca un equipo o comité, cuya función principal es la gestión de la Lista de Producto. Todo elemento que aparezca en esta lista, o cualquier decisión tomada sobre ella, es únicamente responsabilidad suya. Por tanto se encarga de ordenarla, añadir o eliminar requisitos, asegurarse de que toda persona tiene acceso a ella, etc. Es un miembro activo del equipo y como tal debe estar presente en todos los eventos programados. 

    Dentro de sus obligaciones está la de comunicarse con el cliente. De hecho es el encargado de reunirse con él, de transmitir sus exigencias al resto del equipo, y de transformar sus deseos en tareas y funcionalidades a implementar. El Dueño de Producto debe saber expresar los elementos de manera clara y transparente. De esta manera se asegura que el Equipo de Desarrollo entiende los requisitos al nivel necesario para una correcta implementación ya que, aparte de la gestión de la lista, es responsable del buen uso y entendimiento de esta.

    La organización y el Equipo Scrum en general deben respetar sus decisiones, y no pueden interferir en el contenido de la lista de otra manera que dando su opinión al Dueño. Si este decide tenerlo en cuenta, la sugerencia pasará a formar parte de la Lista de Producto, pero tiene total libertad para no hacerlo. También existe la posibilidad de que el Dueño de Producto otorgue los privilegios sobre la Lista al Equipo Desarrollador, aunque no lo exime de la responsabilidad de esta y será él quien responda ante cualquier inconveniente o contratiempo proveniente de una mala gestión por parte del Equipo.  De cualquier manera, delegue la responsabilidad en el Equipo o no, en su papel está gran parte de la responsabilidad del éxito, y es fácil sentirse abrumado por esta situación. Por ello es importante que el resto del equipo respete sus decisiones y evite complicar su trabajo.

    El Dueño de Producto influye en el trabajo a desarrollar en cada Sprint, hasta tal punto que selecciona el mismo las tareas de la Lista de Producto que deben completarse durante ese periodo, aunque de ninguna manera puede influir en la manera de desarrollarla. Al final de cada Sprint tiene la posibilidad, y a su vez el deber, de decidir si el trabajo desarrollado es aceptable o desechable. 

    Scrum Master

    El Scrum Master es un líder al servicio del equipo Scrum. En la web se pueden encontrar múltiples definiciones o ejemplos para ayudar a entender que función tiene esta persona. Algunos lo consideran el entrenador del equipo, pues es el encargado de sacar el máximo provecho de los integrantes y de conseguir que lo hagan lo mejor posible dentro de sus posibilidades. Otros lo catalogan como el protector debido a que entre sus funciones se encuentra la de asegurarse de que el equipo no es sobrecargado y se fijan objetivos dentro de sus posibilidades. También es usual encontrar comparaciones con un entrenador personal, cuyo objetivo es motivar al equipo y a la vez asegurarse de que no evita hacer tareas duras siempre que estén capacitados para ella.

    La persona que desempeña este rol debe asegurarse de que Scrum es entendido y aplicado. En definitiva esa es su misión, pero la manera de que esto se lleve a cabo es compleja por ello surgen las diferentes comparaciones. Como consecuencia, es el encargado de organizar los eventos necesarios para llevar Scrum a cabo, y a su vez facilitar un día y una hora en la que todos puedan asistir. 

    Para enfocar el proyecto en el marco de trabajo Scrum, debe estar en contacto con toda persona, interna o externa, relacionado con el trabajo. Es el encargado de ayudar a entender que tipo de interacciones con el Equipo de Desarrollo son de utilidad y cuales no. También debe asegurarse de que el Dueño de Producto sabe ordenar la Lista de Producto, que no quiere decir que interfiera en su ordenación, pero debe aportar técnicas eficientes para esta tarea. Guía al Equipo de Desarrollo a ser multifuncional y autoorganizado, y les ayuda a crear productos de alto valor, sacando el máximo provecho a sus habilidades. Para mantener la productividad del equipo en los niveles más altos posible los aísla de interrupciones y de elementos que afecten a su rendimiento.

    Su aportación a la organización consiste en liderar y guiar la adopción de Scrum, algo que no es nada fácil y más si no se tiene experiencia con esta metodología de trabajo. Debe asesorar a toda persona que lo necesite y ayudarle a entender el porqué de usar Scrum y el cómo, haciéndole entender las ventajas que supone frente a otros sistemas. Por tanto es responsable de planificar la implementación. También debe ser él quien motive un cambio de dirección o proponer un reajuste si con ello se incrementará la productividad del Equipo Scrum.

    Respecto a la autoridad del Scrum Master, se puede resumir en que no tiene responsabilidad sobre los miembros del equipo pero si sobre el proyecto. No podría tomar decisiones como despedir a alguien pero si tiene autoridad para establecer la duración de los Sprint por ejemplo.

    Equipo de Desarrollo

    El Equipo de Desarrollo está formado por los profesionales que crean el producto. Sólo ellos intervienen de manera directa en este proceso, pues hay personas involucradas de manera indirecta marcando objetivos, pautas y requisitos, pero es el Equipo de Desarrollo el encargado de transformar las ideas en algo material. Deben disponer de las habilidades necesarias para realizar las tareas propias de este trabajo: análisis, desarrollo, pruebas, diseño, documentación… etc.

    Más importante incluso que las habilidades es la organización del conjunto, pues es la clave para la agilidad que persigue Scrum por definición. El equipo trabaja de manera independiente y auto organizada, algo que lleva a explotar la creatividad de sus integrantes, además su estructura está pensada para optimizar la eficiencia y productividad de los desarrolladores. Ni si quiera el Scrum Master puede entrar en la decisión de cómo se van a convertir los elementos de la Lista de Producto en un producto tangible y con valor para el cliente. Dentro del equipo no hay distinciones en cuanto a roles, ni jerarquía entre ellos. Todos están al mismo nivel y no existen sub-equipos y, aunque cada uno tenga una habilidad concreta o una función particular dentro del grupo, la responsabilidad del éxito del trabajo recae en todos por igual.

    En cuanto al tamaño del equipo, lo ideal es entre 3 y 8 personas, aunque esto es ambiguo y no existe una patrón estricto. El número de personas que componen el grupo se estima en relación al tipo de proyecto, la cantidad y complejidad del trabajo y el plazo de entrega. Se suele decir que el grupo debe ser lo suficientemente pequeño como para ser ágil, y a la vez lo suficientemente grande como para completar una cantidad de trabajo significativa en cada Sprint, aunque, por norma general, se establece que menos de tres miembros reduce la interacción y las ganancias en productividad. También hay que considerar que un grupo demasiado pequeño puede presentar carencias a la hora de afrontar un objetivo debido a la falta de profesionales especializados en la materia en cuestión. Es lógico pensar que un equipo demasiado numeroso es complicado de gestionar y frenaría la toma de decisiones entre ellos, incrementaría los tiempos de sincronización y, como consecuencia, reduciría la agilidad del equipo. Como comentario final, es importante recalcar que para contabilizar los miembros del Equipo no se deben tener en cuenta al Scrum Master y al Dueño de Producto a no ser que intervengan a la hora de decidir la Lista de Pendientes del Sprint.

    Otros roles

    Los roles auxiliares en el Equipos Scrum son aquellos que no participan de manera activa en el proceso Scrum, pero no por ellos hay que dejar de tenerlos en cuenta. Para que el proceso resulte ágil y efectivo es importante tener en cuenta durante el proceso a clientes, expertos y usuarios finales del producto. La retroalimentación que aporta este subconjunto es vital para alcanzar la adaptabilidad y aumentar el valor final de lo que se está produciendo.

    Los roles en Scrum.

    Eventos

    En el marco de trabajo Scrum existen eventos definidos que buscan crear regularidad y una rutina de trabajo eficaz en los miembros del proyecto. El hecho de reuniones predefinidas busca a su vez reuniones improvisadas o sin planificar que son mucho menos eficientes y productivas.

    Se define un evento como un bloque de tiempo, de duración máxima y fija. Cada uno de ellos es una oportunidad para la inspección del producto y el reajuste de algún elemento que se desvíe de lo estrictamente deseado por el cliente. Por el contrario, la ausencia de alguno de ellos, reduce la transparencia y significa perder una oportunidad para llevar el producto por el camino adecuado.

    Dentro de los eventos, se diferencian dos tipos según el objetivo de cada uno de ellos. Se denominan Sprints y Reuniones.

    Sprint

    El Sprint es un bloque de tiempo de entre dos semanas y un mes en el que se desarrolla una parte del producto, algunas personas lo consideran un proyecto dentro del propio proyecto. La duración de un Sprint no debe exceder el mes pues la complejidad y el riesgo de desajuste incrementa.Tampoco se recomienda una duración menor a las dos semanas pues el coste aumenta considerablemente debido a las reuniones que se realizan durante el Sprint. 

    Para cada Sprint se realiza una Lista de Pendientes del Sprint, que contendrá aquellos elementos de la Lista de Productos escogidos para completar durante la iteración. El contenido de esta puede ser renegociado con el Dueño de Producto a medida que se profundiza y se obtienen conocimientos sobre los temas que se deben abordar. Aunque exista cierta flexibilidad en cuanto a la Lista de Pendientes, no se permite realizar cambios que involucren disminución de la calidad del producto, ni que cambien el Objetivo del Sprint.

    Las Reuniones predefinidas en Scrum tienen lugar durante los Sprint. Por definición esto no podría ser de otra forma, pues un Sprint empieza seguidamente acaba el anterior, por tanto el ciclo de desarrollo del producto es una sucesión de Sprints y cualquier evento debe situarse dentro de alguno de ellos. 

    Un Sprint puede ser cancelado, algo que raramente ocurre. El Dueño de Producto es la única persona que tiene poder para hacer esto, aunque para ello puede ser influenciado por el propio equipo, el Scrum Master u otra persona relacionada con el proyecto. La única razón por la que se debe cancelar un Sprint es que el Objetivo marcado carezca de sentido. Esto ocurre si las condiciones de mercado cambian, se produce algún avance tecnológico, la entrada de alguna nueva ley… etc y el Objetivo queda obsoleto.

    Reuniones

    En Scrum existen un conjunto de reuniones predefinidas que deben respetarse dentro de cada Sprint. En concreto Scrum define cuatro tipos para asegurar que el equipo sea regular y constante. 

    Planificación del Sprint

    Este evento está programado al inicio de cada Sprint y tiene como fin establecer el trabajo que debe completarse durante esa iteración. Si el Sprint tiene programado un mes de duración, este evento debe durar aproximadamente ocho horas pero nunca más. Si el Sprint es más corto la duración del evento disminuye proporcionalmente.

    La reunión debe enfocarse a responder dos cuestiones claves: qué se va a terminar y cómo se conseguirá completar el trabajo. Como resultado se produce la Lista de Pendientes del Sprint que contiene elementos seleccionados más el plan para abordar el objetivo.

    Para responder a la primera cuestión, hay que aclarar que funcionalidades se van a desarrollar. Esta es una decisión conjunta entre el Dueño de Producto, que decide qué elementos deberían empezar a producirse, y el Equipo de Desarrollo, que selecciona el número de ellos que piensan que tienen la capacidad de afrontar. A la hora de tomar esta decisión influyen ciertos factores como el resultado del anterior Incremento, la capacidad del Equipo de Desarrollo en base a resultados anteriores, el rendimiento mostrado hasta entonces… etc.

    En cuanto a la segunda cuestión, la meta a alcanzar es un plan que describa de forma detallada cómo se procederá con cada uno de los puntos que componen la Lista de Pendientes del Sprint. El nivel de detalle es tal que habría que descomponer cada requisito en unidades de trabajo cuyo tiempo estimado para completarlos sea de 24 horas aproximadamente. Básicamente consiste en describir el día a día que les espera mientras desarrollan el proyecto.

    Al final de cada Reunión el Equipo de Desarrolladores debe ser capaz de explicar y convencer al Scrum Master y al Dueño de Producto de cómo van a gestionar las tareas que se le han asignado

    Scrum diario

    Durante el Sprint, el Equipo de Desarrollo se reúne a diario durante no más de 15 minutos para replantear el trabajo a realizar durante ese día, siempre tratando de alcanzar los objetivos marcados.

    Este evento está pensado para que los desarrolladores pongan en común su experiencia hasta entonces en el trabajo que están abordando. Deben comentar lo que se hizo en las últimas 24 horas a favor del proyecto y lo que se planea hacer en las próximas para contribuir a él.

    Revisión del Sprint

    En la revisión del Sprint se reúne el Equipo Scrum durante no más de 4 horas para juntos revisar qué es lo que ha pasado durante el Sprint, esto incluye el que se ha realizado, si está o no completo, si es o no usable. Las partes que no se puedan añadir como una funcionalidad más volverán a la Lista de Producto como “aún por realizar”. 

    Pueden surgir nuevas oportunidades o retos durante la revisión del Sprint que se verán representadas en nuevas funcionalidades o modificación de alguna de las existentes.

    La revisión del Sprint puede concluir con alguna o varias de las siguientes decisiones:

    • Comenzar a utilizar las nuevas funcionalidades.
    • Decidir qué hacer durante el siguiente Sprint y prepararse para ello.
    • Cancelar el proyecto.

    En cualquier caso el riesgo del proyecto está controlado en cada Sprints.

    Retrospectiva del Sprint

    Si durante la revisión del Sprint se decidió continuar, todos los miembros del Equipo Scrum se reúnen durante 4 horas como máximo para formular mejoras en el trabajo, lo que incluye los siguientes puntos:

    • Si los miembros del equipo han trabajado bien o no y por qué.
    • Si se hizo más o menos de lo esperado y por qué.
    • Si el equipo tiene las habilidades y facilidades para realizar el trabajo.
    • Si los desarrolladores entendieron o no los requisitos y por qué.
    • Si el equipo es capaz de completar el Sprint con los objetivos marcados, y si no lo es, por qué.
    • Qué se puede mejorar o abandonar en el próximo Sprint y por qué.
    • Qué piensa el equipo del uso de Scrum.

    Lo siguiente es identificar las cosas que se deben hacer de forma diferente en el próximo Sprint para incrementar la creatividad, efectividad y productividad. En general que se puede mejorar en el Equipo Scrum.

    Descripción gráfica de los eventos de Scrum

    En el gráfico se aprecian todos los eventos de Scrum que han sido descritos a lo largo del capítulo. Lo que a simple vista se aprecia es un Sprint, que se genera a partir de la Lista de Producto. Los elementos que sigan permaneciendo en esa Lista provocan una reunión al principio del Sprint para determinar los objetivos, es lo que aparece como Sprint Backlog dentro del gráfico. Entre 2 y 4 semanas, el Equipo de Desarrollo elabora el producto, manteniendo reuniones diarias (Daily Sprint meeting) para comentar los progresos. Al final del Sprint, el Equipo completo vuelve a reunirse para determinar qué elementos van a ser publicados, que ha ido como se esperaba y que inconvenientes o problemas ha habido para evitarlos en la próxima iteración. Después de esto, si todo ha ido bien, se obtiene una nueva versión del producto.

    Conclusiones y aclaraciones

    Scrum es una forma de gestionar proyectos complejos de cualquier tipo, no solo software, para proyectos simples suele ser más eficaz la metodología tradicional en la que se planea el proyecto completo al principio del mismo. 

    Está basado en la experiencia obtenida previamente y durante su uso por lo tanto no garantiza el éxito del proyecto pero si disminuye el riesgo en el que se incurre al tener la posibilidad de reencaminar o de cancelar el proyecto al final de cada Sprint.

    BIBLIOGRAFÍA

    https://www.scrum.org

    http://www.proyectosagiles.org/que-es-scrum

    http://es.wikipedia.org/wiki/Scrum

    http://www.proyectalis.com/servicios/formacion/scrum/

    http://www.proyectosagiles.org/control-predictivo-control-empirico

    http://www.dosideas.com/noticias/reflexiones/431-las-10-tareas-de-un-dueno-del-producto.html

    http://www.proyectosagiles.org/facilitador-scrum-master

    http://www.mountaingoatsoftware.com/scrum/scrummaster/

    Ken Schwaber and Jeff Suntherland: Software in 30 days. Wiley (2012)

  • ¿Qué es esto?

    En este blog podrán encontrar las reflexiones y experiencias en todo tipo de ámbitos en los que está metido un tal Javier Pachón, desde temas relacionados con la informática, las telecomunicaciones, la cocina o la fabricación aditiva por mencionar algunos.

    El idioma principal del blog es el español pero podrá ver algunos de los artículos en otros idiomas que el editor está tratando de aprender, aunque este concretamente está traducido usando una de las muchas herramientas de traducción disponibles.