lunes, 27 de agosto de 2018

Ingredientes de SCRUM


1 - Producto
Es el software que se construye durante el proyecto.

2 – Propietario de producto
Persona que se ocupa del producto. ¿Qué funcionalidades debe tener? ¿Cómo será más competitivo? ¿Qué mejoras se le pueden aplicar? Etc.

3 –Scrum master
Persona que se ocupa del proceso es decir, de que se utilice el método Scrum adecuadamente y que el trabajo de los equipos fluya evitando impedimentos.

4- Historias de usuario
Es la descripción de lo que el producto debe hacer.  Es decir, recopilan el conjunto de funcionalidades y otras características que se espera tenga el software que se va a construir.

5 – Puntos historia
Es una medida cuantitativa que asigna el equipo a cada historia. Los puntos historia miden la dificultad que se intuye que tendrá la historia para ser construida, comparada con el resto de las historias de la pila. Es decir no es una medida absoluta, es una medida de comparación.  Existe una técnica llamada “Planning poker” para medir puntos historia.

6 – Pila de producto
El propietario de producto es el responsable de la pila de producto. La pila de producto es una lista que contiene todas las historias que describen el producto. El propietario de producto prioriza las historias, al principio coloca las que se prevea que aportarán más valor para el negocio. Las historias del principio de la pila deben estar suficientemente detalladas para que el equipo de desarrollo tenga la información necesaria para poder construir el software, el resto de ellas pueden estar definidas más vagamente. Esto se debe a que en SCRUM el cambio es bienvenido, es decir, puede ocurrir que una historia que en principio se identificó como tal, después de varias iteraciones (sprints) se considere que ya no es importante y se elimine. También que aparezcan nuevas historias o cambien historias existentes. Por eso, no es útil que las historias de usuario del final de la pila, que todavía no se van a implementar o quizás no se implementen nunca, estén perfectamente detalladas.

7 – Sprint
Periodo de tiempo previamente fijado durante el cual el equipo desarrolla las funcionalidades y características descritas en las historias de usuario. Los sprints se suceden de forma iterativa en el tiempo, hasta que se haya terminado el producto. Los sprints se acaban cuando acaba el tiempo prefijado, si hay trabajo no terminado se reajustará en subsiguientes sprints. Se recomiendan sprints de 1 a 4 semanas y nunca de más de 6. Es importante que las historias de usuario que se acuerde llevar a cabo en un sprint, no se cambien durante el transcurso del sprint,  el objetivo es no alterar el trabajo del equipo.

8 – Reunión de planificación del sprint
El equipo de desarrollo se reúne con el propietario de producto y trabajan sobre la pila de producto. El equipo analiza las historias de usuario, debatiendo con el propietario de producto sobre su naturaleza. Se seleccionan tantas historias del principio de la pila de producto como el equipo considere que va a poder desarrollar durante el sprint, los puntos historia ayudan a saber cuántas historias seleccionar. Las historias seleccionadas pasan a la pila del sprint y se subdividen en tareas, de tal manera que el equipo desmenuza cada historia en las actividades necesarias para implementarla.
Se prepara el tablero SCRUM del sprint (“Por hacer”, “Haciendo”, “Hecho”) y se colocan las tareas de las historias seleccionadas en la columna “Por hacer”.

9 – Reunión SCRUM diario
Esta reunión se celebra cada día de cada sprint, normalmente al comienzo de la jornada de trabajo. Es una reunión breve, no más de 15 minutos. En esta reunión cada miembro del equipo dice como le fue con las tareas del día anterior y que tareas planifica hacer hoy.
  
10 – Reunión de revisión del sprint
Terminado el sprint el equipo hace una demo del software construido al propietario de producto y a los clientes/usuarios. El objetivo es mostrar el software construido y obtener retroalimentación sobre la perspectiva de clientes/usuarios y el propietario del producto. En caso de que se cumplan las expectativas de todos ellos seguir adelante, en caso de que no hacer los cambios necesarios para cumplirlas. 

11 – Reunión de refinamiento de pila de producto
Se reúne el propietario de producto con el equipo de desarrollo, para revisar las historias que se prevé abordar en el próximo sprint. En base al software construido y a posibles cambios producidos en el transcurso del tiempo, se refinan las historias de usuario: re-priorizar, eliminar, modificar y/o  crear nuevas historias. La idea de refinamiento es doble, por un lado se trata de aportar más detalles sobre las historias del próximo sprint y por otro lado reajustar la priorización de las historias para adaptarse al momento (gestión de los cambios).
En Scrum desde el primer sprint el usuario dispone de software construido.  Esto permite que el desarrollo del producto se realice siguiendo unas especificaciones que se basan en la realidad de un software funcionando en vez de hipótesis sobre lo que debería de hacer o no el producto.

12 – Reunión de retrospectiva
Al final de cada  sprint se celebra una reunión de retrospectiva. La retrospectiva vigila el proceso, no el producto. La retrospectiva, lo que persigue es que el equipo: desarrolladores, propietario de producto y clientes/usuarios, pongan de relieve aquellas cosas que creen que pueden hacer mejor para el próximo sprint. Por ejemplo: los SCRUM diarios se han alargado cada día durante más de 2 horas y el equipo ha perdido mucho tiempo. Aquí una mejora es proponerse mantener el scrum diario en los 15 minutos estipulados para los próximos sprints.

viernes, 17 de agosto de 2018

Aprender Angular gratis: Donde acudir.


Angular es un framework para el desarrollo de aplicaciones web y apps para móviles. Al igual que otros framewoks el objetivo de Angular es simplificar el desarrollo y mantenimiento de aplicaciones.
Esta plataforma fue desarrollada por Google que la lanzó inicialmente en 2010 con el nombre de AngularJS.  En 2016, lanzó una evolución llamada Angular o Angular 2.  AngularJS y Angular no son compatibles, son frameworks distintos. Sin embargo ambos frameworks  tienen el mismo objetivo, de hecho Angular se diseño aprovechado las ventajas que supuso AngularJS y mejorando sus desventajas.
En conclusión Angular es la evolución de AngularJS y incorpora mejoras de todo tipo: mejor rendimiento, mejores mecanismos para la modularización,  tiene en cuenta las plataformas móviles y hay otras muchas mejoras en la arquitectura suministrada.
Angular no es un framework al uso. Angular ofrece mayor soporte que otros,  resolviendo asuntos sobre los que el desarrollador no tiene que decidir, solamente tiene que usar los elementos que pone Angular a su disposición. Las aplicaciones Angular tienen todas el mismo patrón arquitectónico y son fácilmente abordables para los conocedores del framework.
Los desarrolladores de Angular proporcionan una plataforma donde descargar y aprender a utilizar Angular desde sus fundamentos hasta llegar a un conocimiento completo y profundo del framework.
Para iniciar el aprendizaje de Angular acceder a https://angular.io/guide/quickstart. En esta guía se describen los pasos para crear un entorno de desarrollo local y poder crear una aplicación básica. A través de cuatro simples pasos se instala el Angular y el software necesario para trabajar con él, se crea una aplicación Angular, se arranca el servidor que soporta la aplicación y se edita y modifica un componente para iniciar al navegante en el desarrollo en Angular.
Después se puede profundizar en el aprendizaje en https://angular.io/tutorial. Durante este tutorial se crea una aplicación web, que ilustra los elementos principales que existen en el framework: directivas para mostrar información en pantalla, componentes, plantillas, enlace de datos one-way y two-way, enlace de métodos a eventos del usuario, creación de servicios y uso de enrutamiento para navegar entre vistas y componentes.
En https://angular.io/guide/architecture se puede echar un vistazo a la arquitectura  del framework a grandes rasgos. La arquitectura viene representada con la siguiente imagen:


Esta imagen representa una aplicación Angular que a modo resumen tiene los siguientes componentes:

  • Modules: Los módulos son unidades funcionales. Agrupan componentes que hacen algo común, es decir funcionalmente trabajan juntos. Una aplicación Angular al menos tiene siempre un módulo raíz. 
  • Component: Cada componente define una clase que tiene datos y lógica de aplicación. Todo ello asociado con una vista (template) que es lo que ve el usuario en la pantalla. Una aplicación Angular tiene al menos un componente.
  • Template: Las vistas son páginas HTML con directivas y marcado de enlace de datos para asignar datos de la aplicación a los elementos de la página HTML. 
  • Directive: Las directivas proporcionan soporte de lógica de programación y enlace de datos que conectan los datos de tu aplicación y el DOM de la página HTML.
  • Property Binding: asigna valores a las propiedades de la página HTML.
  • Event Binding: toma control de las acciones de usuario sobre la página HTML.
  • Injector: Asocia dinámicamente servicios a componentes, de manera que el uso de servicios en los componentes es más versátil.
  • Service: Los servicios proporcionan funcionalidades a los componentes. Estos se crean para lógica y datos que están asociados con más de una vista. Su fundamento es la reutilización.

Esto es todo. Espero facilitar el aprendizaje de Angular con este Post. Se agradecen los cometarios y preguntas.

sábado, 11 de agosto de 2018

Contribuir al software libre: Cómo empezar.


A mí siempre me ha gustado desarrollar software. La parte en la que más me gusta participar en el equipo de desarrollo es la elaboración del código fuente, es decir en la programación. Actualmente no me dedico a la programación de forma profesional. Entonces, con el objetivo de poder participar en desarrollos de software pensé en participar en la elaboración de código para algún proyecto de los que actualmente se elaboran por comunidades o grupos sin ánimo de lucro. Actualmente hay muchos productos software que se pueden descargar de forma gratuita y estos productos están desarrollados por estas comunidades. Me planteé formar parte de alguno de los grupos que desarrollan estos productos. Recurrí a internet para ver donde podía colaborar. Buscando encontré este enlace:


En este enlace proponen varias plataformas a las que acudir cuando quieres colaborar en el desarrollo software de algún producto. Las plataformas propuestas ahí son:

·         Google Summer of Code y sus organizaciones.
·         Awesome First PR Opportunities
·         Lista de proyectos de Mozilla.
·         GitHub Explore

Yo elegí GitHub Explore y buceé a ver qué proyectos estaban en marcha. Lo primero que hice fue registrarme en la plataforma, paso obligatorio para poder colaborar.
Después elegí el proyecto en el que colaborar. Cuando se accede a GitHub Explore, hay una página que en diferentes categorías muestra los proyectos en los que se puede colaborar. También existe una búsqueda avanzada en la que se pueden seleccionar preferencias: lenguajes de programación, número de colaboradores, número de cambios en los últimos meses, etc.
Tras una larga y minuciosa búsqueda, seleccioné el proyecto TheAlgorithms/java ( https://github.com/TheAlgorithms/Java ). Para buscar el proyecto, me centré en algo que fuese sencillo para empezar. Descargué el código y lo cargué en mi IDE preferido Eclipse y empecé a trastear, leyendo código y ejecutando algoritmos. Encontré uno que fallaba referente a la obtención del Máximo Común Divisor. Entonces creé un incidente “issue” para informar del fallo. Alguien recogió la incidencia y arregló el problema. En este proceso recibí un correo de la persona que había arreglado el problema. Aproveché este correo para preguntarle si necesitaba ayuda con algún código y me dijo que sería útil refactorizar  el código de este repositorio de acuerdo con las  normas de codificación de Java.
Elegí un algoritmo y me puse manos a la obra. Estudié el código y comprobé cómo funcionaba. Después ayudada por los plugins “Sonarlint” de Sonarqube  y de Checkstyle para Eclipse, puse el código de acuerdo a las normas de codificación de Java.  Para terminar comprobé a través de pruebas manuales que el código seguía funcionando correctamente.
Para enviar las modificaciones a GitHub, tuve que crear un fork. En este fork almacené el nuevo código. Desde el fork abrí una nueva branch y desde esta branch creé una petición de cambio del fichero mediante un pull request.
Ahora estoy esperando a que alguien acepte mi pull request y que el fichero modificado se cargue en la rama principal (master) del proyecto. Y así estoy, a la espera.
Voy a indagar en otras plataformas, ya os contaré.