Los roles de Scrum

Los roles de Scrum

por | Jul 14, 2018

Scrum es un framework en el cual son necesarios la implicación de varias personas, que se agrupan en tres roles bien diferenciados.

Por una parte tenemos al Product Owner, que buscará introducir nuevas funcionalidades en el producto para añadirle valor. Por otra parte tenemos al equipo de desarrollo que implementará las ideas del Product Owner, y entre ambos estará el Scrum Master que engrasará todo el proceso para mantener motivado al equipo y satisfecho al Product Owner.

Estos tres roles conforman lo que se denomina el Equipo Scrum, el núcleo del desarrollo del proyecto.

El equipo Scrum se relaciona con el exterior mediante el Product Owner. La persona que desempeñe este rol se comunicará con los clientes o stakeholders, para intentar plasmar lo más concretamente posible sus ideas de una forma que todo el Equipo Scrum las pueda comprender. El Equipo Scrum tambien desarrolla unas relaciones internas que en el mejor de los casos sirven para crear un ambiente de confianza y camaradería muy utiles para el desarrollo. De estas relaciones se debe ocupar el Scrum Master, quien debe facilitar el trabajo principalmente al equipo de desarrollo, pero cuyas acciones y formas de liderar podrán tener un efecto positivo tambien el el Product Owner.

Scrum es una forma de trabajar que presta mucha atencion a la aplicacion de ciertas rutinas y el correcto desempeño de los roles. Saber como implementar esta forma de trabajar en la empresa puede mejorar mucho la productividad en proyectos complejos y cambiantes.

 

¿Qué es y por qué usar Scrum?

¿Qué es y por qué usar Scrum?

por | Jul 14, 2018

Posiblemente si estas leyendo este texto, es porque has escuchado recientemente este conglomerado de consonantes asociado a un entorno de trabajo, y no sabes de qué diablos es. O posiblemente ya habías escuchado o leído algo de metodologías ágiles y quieres profundizar de qué tratan y que ventajas poseen.

La era de la informacion ha traído consigo una nueva forma de comunicarse, relacionarse y tambien de producir. Todo se mueve y cambia con una rapidez extraordinaria y si en algun momento queremos implantar nuestro producto en un mercado que evoluciona a una velocidad tan vertiginosa, no podemos asumir la forma de produccion de la segunda revolución industrial. Hoy en día no es dificil oír hablar de la venta de servicios y no de productos. Se habla de la venta de algo cambiante, dinámico, en continuo cambio y expansión. Hoy en dia estancarse es morir y ya no podemos pensar (al menos en el campo de la tecnologia y software) en sacar productos a diez años vista porque los requerimientos del mercado habrán cambiado drásticamente para ese entonces.

Scrum es una metodología ágil, una categorización bajo la cual se encuentran otras muchas otras con algunas diferencias, pero con esencialmente las siguientes características:

  • Orientada al crecimiento de un producto o servicio de forma continua, proveyendo siempre una version estable pero no completa del mismo en cada ciclo de desarrollo.
  • Integra al cliente en el desarrollo del producto y lo satisface rapidamente con una version funcional en un periodo relativamente corto de tiempo.
  • Mejora la creatividad, comunicacion y satisfaccion del equipo de desarrollo al disponer de mayor libertad, disposicion de su tiempo y tener siempre un objetivo claro a corto plazo.

Aunque las metodologías ágiles se asocian por defecto con empresas de desarrollo de software, no son las únicas que pueden implementarlo. Al fin y al cabo, las herramientas roles y filosofía de trabajo es extrapolable a otros muchos ámbitos, como el emprendimiento de start-ups.

Desarrollo en cascada vs. Scrum

Anteriormente decíamos que no podiamos asumir la forma de producción de la segunda revolucion industrial para según que productos enmarcados dentro de un mercado cambiante y dinámico. Es obvio que existen otras muchas formas de producción, y en este apartado vamos a difereniciar entre dos de las metodologías más populares para realizar proyectos.

La metodología en cascada se caracteriza por un desarrollo en etapas para llegar al resultado final. Primero se toman en cuanta los requerimientos, luego se diseña, se desarrolla el producto, se testea y por ultimo se lanza al mercado. Es un proceso ordenado y con etapas bien diferenciadas, con un inicio y un final y con una duracion variable. No es un proceso cíclico ni tiene por qué integrar durante todo el ciclo de desarrollo al cliente. Además tiene una contraprestación, y es que si una parte fundamental falla, todo lo que deriva de ella no servirá de nada. SI no hemos hecho una investigacion exhaustiva y un diseño correcto, podemos llegar a la fase final del proyecto con un producto sin las caracteristicas necesarias y un montón de horas de trabajo perdidas. Además, habrán personas que no estarán en todos los momentos de la producción trabajando. Si una empresa no tiene ningun proyecto iniciado, es posible que los diseñadores o las personas que se entrevistan con el cliente para los requerimientos estén paradas y eso suponga una fuga de capitales importantes.

Usar Scrum adecuadamente

Aunque Scrum es una de las metodologías más populares en empresas de todo tipo, tal y como vemos en el cuadro de arriba, hay proyectos que no siempre se pueden realizar bajo su paraguas. Incluso es posible que aunque hayas decidido implantar esta metodología para proyectos que efectivamente, resultan más eficientes de desarrollar de esta manera, pero no hayas encontrado los resultados que buscabas. Scrum no es solo una metodología. Scrum es un enfoque integral de las relaciones entre empresa, trabajadores y clientes. Para usar adecuadamente Scrum los trabajadores tienen que saber expresarse en publico, ser responsables, estar motivados y es deseable que existan buenas relaciones entre ellos, los clientes tambien tienen que estar comprometidos y disponibles y el Scrum Master, una figura que veremos más adelante, tiene que saber rodearse de buenos profesionales dentro y fuera de la empresa para conseguir que todos los actores involucrados realizen sus tareas cómodamente.

SOLID – Principio de Inversion de Dependencias

SOLID – Principio de Inversion de Dependencias

por | Jul 1, 2018

El principio de inversion de dependencias nos dice que los sistemas son mas escalables y mantenibles si las dependencias de un módulo dependen de abstracciones y no de elementos concretos. El motivo de esto es la diferencia de volatibilidad de ambos. Mientras que una abstraccion apenas requiere cambios y estos se propagan a las implementaciones concretas, las implementaciones concretas tienden a acambiar con más facilidad. Esto implica que todos los módulos que dependan de elementos concretos sean más propensos al cambio en cascada, dificultando el mantenimiento del código. Por eso, es necesario aplicar una serie de prácticas siempre que sea posible:

  • No remitirse a clases concretas que cambien con facilidad: Nadie te niega que uses un String o una clase concreta nativa de Java, pero evita usar referencias a tus propias clases en desarrollo para evitar implantar cambios a cada minuto en las clases que la implementan.
  • No realizar herencias desde clases concretas volátiles: Por el mismo motivo del caso anterior, es mejor no usar la herencia a no ser que estemos realmente necesitados de esta relación.

Las ventajas de usar este principio de diseño son varias y en distintas fases del desarrollo:

  • Durante la fase de desarrollo de la aplicacion, no depender de concreciones nos facilitará el no reescribir varias veces código de módulos que dependan de ellos.
  • Durante la fase de test, la interdependencia entre clases evita un buen desempeño a la hora de realizar pruebas unitarias.
  • Durante la fase de mantenimiento, es mucho más sencillo realizar los cambios convenientes en los distintos módulos e incluso comprender sus dependencias.
Inyeccion de dependencias

Es posible que hayas escuchado alguna vez la expresion «inyección de dependencias» o «inversion de control». Si crees que tiene algo que ver con este principio, has acertado de pleno. La inyección de dependencias es un patrón de diseño central para algunos frameworks como Spring, que nos ayuda a desacoplar la creacion de los objetos de su utilizacion. Spring por ejemplo nos provee de un contenedor que se encarga de buscar y manejar el ciclo de vida de un determinado tipo de clases denominadas beans. Gracias a este contenedor podemos beneficiarnos de todo lo que supone seguir el DIP (Dependency Inversion Principle) que comentamos más arriba.

En este enlace puedes leer más sobre el Spring Container y la inyeccion de Dependencias.

SOLID – Principio de Segregacion de Interfaz

SOLID – Principio de Segregacion de Interfaz

por | Jul 1, 2018

Posiblemente este sea el principio más fácil de definir de todos los SOLID.

En pocas palabras aconseja crear interfaces específcas para cada actor y no grandes interfaces con métodos comunes a varios actores.

¿Por qué es útil el principio de segregacion de interfaces?

Imagina que tienes un módulo A que permite muchas operaciones en una única inerfaz y creamos una serie de módulos que use algunos de los métodos provistos por A. ¿Que pasa si queremos añadir nuevas funcionalidades en A y añadirlas a su superinterfaz? Las clases que dependen de A y usen esa interfaz para comunicarse tendrán que proveer algún tipo de código para esos métodos, aunque no los vayan a utilizar nunca. Segregando esa gran interfaz en funcion del actor que vaya a utilizarla, evita que otros actores tengan que implementar métodos que nunca van a usar.

Como quizás habrás podido observar, al hablar de actores y el nivel de conocimiento de estos, puede que te haya recordado vagamente al de responsabilidad única… y es que los principios de SOLID no son estancos entre sí.
SOLID – Principio de Sustitucion de Liskov

SOLID – Principio de Sustitucion de Liskov

por | Jul 1, 2018

El principio de sustitucion de Liskov tiene dos formas de formularse: la enrevesada y la de andar por casa. Yo voy a anunciar la de andar por casa, pero aquí vamos a entender la formal, formulada por Barbara Liskov en 1988.

La definición más fácil de manejar es la siguiente: “los objetos a los que hace referencia un programa deberían ser sustituibles por sus subtipos sin alterar el buen funcionamiento del programa”.

Personalmente me considero un tiquismiquis de las definiciones formales y matemáticas, así que vamos a ver la que enunció Liskov. Estoy completamente seguro de que si existe alguna duda con la definicion informal quedará aclarada.

Si por cada objeto de tipo o1 de tipo S hay un objeto o2 de tipo T,  para todos los procedimientos P definidos en términos de T, si el comportamiento de P no varía cuando o1 es sustituido por o2, entonces S es un subtipo de T.

Lee atentamente la definición anterior. Si traducimos esto a  código, lo que nos dice es algo como “si un método usa como parámetro un objeto de tipo T y se puede cambiar por otro objeto de tipo S sin alterar el buen funcionamiento del método, entonces S es un subtipo de T”.

Donde mejor se puede ver esto es en un método que usa una interfaz como parámetro. Efectivamente podríamos cambiar la firma del método por un parámetro que sea de un tipo concreto que use la interfaz, aunque violaríamos otros principios.

En última instancia lo que nos quiere decir el principio de sustitucion de Liskov es lo mismo de siempre: programa sobre interfaces de forma que el cliente no sepa qué objeto concreto está usando. ¡Polimorfismo!

El problema Cuadrado-Rectangulo

Siguiendo con el ejemplo del libro Arquitectura Limpia de Robert C. Martin que se está siguiendo para ilustrar estos principios SOLID, veamos un caso en el que se vulnera el LSP.

Podríamos pensar que un rectángulo es la generalizacion de un cuadrado, pero hacer eso incumpliría el principio de Liskov, pues un cuadrado no tiene los mismos métodos que un rectángulo y no son sustituibles en el método de Main.

La solucion propuesta en el libro que mantenemos como guía es la creacion de una sentencia de control que nos permita saber si estamos ante un rectángulo o un cuadrado en tiempo de ejecución. A mi no me gusta la solucion. Sinceramente prefiero que ambas figuras sean concreciones de la familia de los paralelogramos y, mediante una factoría se construyan estas figuras pasando parámetros como el alto, ancho y el angulo menos que formen sus lados. A fin de cuentas, tendríamos el mismo problema con los rombos y romboides. De esta forma mantenemos la coherencia geométrica y cumplimos el principio de Liskov.

Ahora lee la definición informal del comienzo.