Category

Equipo

¡Feliz verano!

By | Equipo | No Comments

Aunque seguiremos trabajando sin descanso en las nuevas funcionalidades de la plataforma, no dejamos pasar la oportunidad de desearos un feliz verano, ¡nos vemos a la vuelta!

Tecnología, pedagogía y contenido (modelo TPACK)

By | Equipo | No Comments

El modelo TPACK, igual que el modelo SAMR del que hablamos hace poco, es un marco conceptual para la integración de las TIC en educación. Según los autores Punya Mishra y Matthew J. Koehler, una integración eficaz implica combinar tres aspectos fundamentales: la tecnología (TK), la pedagogía (PK) y el contenido (CK). Así, de la intersección de estos tres conocimientos, surge el acrónimo TPACK (Technological Pedagogical And Content Knowledge).

Es un modelo muy interesante pues reconoce la importancia que tiene tanto el contenido, como la pedagogía y la tecnología, así como las relaciones que se establecen entre estos tres componentes.

Fuente de la ilustración: tpack.org

Nuestras herramientas favoritas

By | Equipo | No Comments

En entradas anteriores, hemos hablado de lo útil que nos resultan Jira y Confluence para la gestión y documentación de nuestro proyecto, pero estas no son las únicas herramientas que utilizamos en nuestro día a día. A continuación os presentamos un pequeño recopilatorio de las que consideramos más interesantes y que son ampliamente conocidas:

  • Evernote: la reina de las anotaciones. La utilizamos para plasmar ideas de manera rápida, normalmente de nuevas características. Si la información que contiene la nota se convierte en un tema de relevancia, toma entidad en Confluence.
  • Google Drive: organizamos archivos y documentos editados por el equipo, generalmente burocráticos, y que deben ser fácilmente descargados (facturas, actas, estatutos…).
  • Dropbox: el repositorio de archivos. Almacenamos los documentos antiguos (como las distintas fases del diseño, por ejemplo, o nuestras ilustraciones) a modo de histórico del proyecto.
  • Flipboard: nuestra suscripción a las noticias que consideramos de interés. Leemos diariamente sobre tecnología, negocios, ciencia y educación. Compartimos las que más nos llaman la atención a través de Twitter.

En su día probamos Wunderlist y Trello, pero ambas han caído en el olvido con el uso de Jira.

Autoría de la imagen: Mike Kenneally (Unsplash)

Documentar el proyecto con Confluence

By | Equipo | No Comments

Confluence es, igual que JIRA, un producto de la empresa Atlassian, especializada en el diseño de herramientas para el desarrollo de software y la gestión de proyectos. Igual que os contábamos lo útil que nos resulta JIRA para el seguimiento de nuestras tareas, esta vez explicaremos las ventajas de documentar el proyecto con una herramienta como Confluence.

En realidad, Confluence funciona de manera muy parecida a una wiki (como la Wikipedia, por ejemplo). Se estructura en páginas y conjuntos de páginas, que denomina Espacios. Todos los miembros del equipo pueden editar las páginas a través de un sencillo editor de texto y suscribirse a las novedades, de forma que estén informados de los cambios. Es un buen sistema para centralizar toda la información y organizar el trabajo. Fomenta la participación y ayuda a que todo el equipo comparta su conocimiento sobre el proyecto. Además, es una herramienta muy flexible. Aporta una variedad de plantillas y las páginas adoptan todo tipo de formas y usos, como manuales, artículos de instrucciones, notas de reunión, listas de archivos o requisitos, por ejemplo.

Como principal desventaja, por citar alguna, es un sistema que exige mucha dedicación para que la información esté siempre actualizada, pero desde nuestro punto de vista, compensa con creces.

Autoría de la imagen: Eli Francis (Unsplash)

Gestión de las tareas con JIRA

By | Equipo | No Comments


JIRA es una herramienta que consideramos muy útil y que utilizamos diariamente para la gestión del proyecto, aunque en sus inicios se concibió como una herramienta para la resolución de incidencias.

La unidad mínima en JIRA son los asuntos (issues, en inglés), muchas veces traducidos como incidencias, como consecuencia de su uso original. Sin embargo, un asunto es mucho más que una incidencia y por tanto puede representar tanto incidencias como errores, características o mejoras.

Los asuntos se organizan en proyectos y estos a su vez se incluyen en categorías de proyectos. Además, los asuntos se pueden clasificar como épicas, historias de usuario, tareas, subtareas y errores (esta tipología se puede reservar para la gestión de las incidencias, por ejemplo). También se pueden etiquetar por versiones.

Por otro lado, cada asunto pasa por una serie de estados: Por hacer, En proceso y Listo y está asignado a una persona del equipo. Otras personas del equipo interesadas en controlar el avance del asunto pueden incorporarse como observadores, de tal manera que reciban una notificación con cada actualización del asunto. Lo ideal es que todos los cambios estén registrados como comentarios, para conocer el histórico del proceso de una manera sencilla.

Si trabajas con Scrum, como es nuestro caso, es posible que crees las épicas y las historias de usuario y que utilices las versiones para gestionar cada entrega del proyecto (despliegue de nuevas características). Para controlar mejor el contenido de cada historia, puedes descomponerla en subtareas, de modo que también dependan visualmente de ella. Una vez incorporadas a JIRA las épicas, historias, tareas y subtareas, lo lógico es que inicies una nueva iteración e incluyas las tareas decididas en el sprint meeting al nuevo sprint.

En el apartado Trabajo pendiente de la pizarra de cada proyecto es posible arrastrar cada historia a la épica que le corresponde así como a la versión en la que se entregará.

En el ejemplo utilizado, el proyecto se denomina wibooki (con la abreviatura WIB), cae dentro de la categoría software y actualmente se divide en tres épicas. Una de las historias de usuario de la épica Perfil es la Creación de página de configuración. Dentro de esta historia encontramos tres subtareas, Cambio de imagen, Cambio de contraseña y Eliminación de cuenta. Todas estas características se desplegarán en producción en la versión 0.2. del proyecto.

Artículos relacionados:

Autoría de la imagen: Aaron Burden (Unsplash)

Mapa de historias de usuario

By | Equipo, La idea | No Comments

Los mapas de historias de usuario son herramientas muy útiles para organizar las tareas y guiar el desarrollo. Sirven para establecer, de manera visual, las interdependencias entre tareas. Como recordaréis por nuestra entrada sobre los conceptos básicos de Scrum, existen las historias de usuario (descripción de características a implementar) y las tareas de historia (cada uno de los asuntos en los que se divide una historia).

Un mapa de historias de usuario nos ayuda a englobar estas historias en dos elementos de orden superior, las épicas o actividades de usuario y las tareas de usuario. Las actividades de usuario son como una gran historia y constituyen la columna vertebral de la aplicación (backbone), mientras que las tareas de usuario establecen la secuencia temporal de uso de la aplicación (walking skeleton).

Así pues, si ordenáramos los elementos de más abstracto a más concreto, tendríamos las épicas o actividades de usuario, seguidas de las tareas de usuario, las historias de usuario y por último, las tareas de historia (que no suelen indicarse en el mapa).

El  mapa también nos ayuda a situar las historias de usuario en diferentes versiones (las diferentes entregas de la aplicación) así como ordenarlas en función de su prioridad.

A continuación os dejamos un mapa de historias de usuario real, de nuestro propio proyecto:

Mapa de historias de usuario

Autoría de la imagen: Dariusz Sankowski (Unsplash)

Un ejemplo práctico de Scrum

By | Equipo | No Comments

Hace poco comentábamos que habíamos dado nuestros primeros pasos con Scrum, un conjunto de buenas prácticas para el desarrollo ágil de software, que se basa en implementar nuevas características de manera iterativa e incremental. Esta filosofía de trabajo engloba una cantidad de nomenclatura que puede llegar a asustar la primera vez que te enfrentas a ella. Por eso pensamos que no hay nada como un buen ejemplo para asimilar sus conceptos básicos y más si es de un clásico cinematográfico como Pulp Fiction. Esta idea está sacada de una presentación sobre Scrum realizada por Toño Huerta (@tohuerta), fundador y CTO de Beroomers; y del artículo Scrum roles in Pulp Fiction.

Actores de Scrum

  • Product owner: la persona responsable del área de negocio, es el contacto directo con el cliente
  • Scrum master: el responsable del equipo técnico, actúa de intermediario con el área de negocio
  • Equipo de desarrollo técnico
  • Stakeholders: son los grupos de interés, como los clientes y los proveedores
  • Usuarios

Elementos de Scrum

  • Historias de usuario: descripción de las características a implementar (se acompañan de los criterios de aceptación)
  • Tareas de historia: cada una de las partes que componen las historias de usuario
  • Puntos de historia: valoración del coste asociado a cada tarea (puntos de complejidad)
  • Product backlog: conjunto de tareas pendientes de realizar
  • Sprint: cada una de las iteraciones (suelen durar entre dos y cuatro semanas)
  • Sprint backlog: conjunto de tareas para realizar dentro de la iteración
  • Burndown: gráfico de trabajo pendiente que se elabora a lo largo de la iteración

Reuniones

  • Sprint meeting: es la reunión de planificación de cada ciclo, en la que se definen las historias de usuario, se descomponen en tareas, se valoran y se incorporan al sprint.
  • Daily Scrum: reunión diaria, generalmente de pie, en la que se expone el trabajo realizado, el que se va a realizar y los conflictos encontrados.
  • Sprint review: al completar el ciclo, se revisa qué se ha desarrollado y qué no y se hace una demostración al resto del equipo.
  • Sprint retrospective: sirve para aprender de los errores cometidos y mejorar el proceso de desarrollo.

Utilizaremos la escena de Pulp Fiction en la que Vincent dispara accidentalmente en el coche a Marvin y acude junto a Jules a casa de Jimmy a recibir el consejo de Sr. Lobo para ejemplificar algunos de estos conceptos.

¿Quién es quién en esta ficción? Sr. Lobo es el Scrum Master, pues es quien conoce el estado del proyecto, el que organiza al equipo y el que facilita las soluciones a los problemas, así como el nexo de unión con el Product owner. Jimmy es a su vez el Product owner, quien aporta la visión del cliente (su mujer llegará a casa a las 9:30 y es imprescindible que no los encuentre allí), prioriza las necesidades y trabaja junto al equipo de desarrollo, que en este ejemplo, son nada más y nada menos que Vincent y Jules. En su caso, Vincent y Jules son los encargados de ejecutar las tareas decididas en esta reunión de planificación (sprint meeting).

En la reunión se mencionan tres historias de usuario: sacar el coche del valle, limpiar el coche y deshacerse del coche. La historia de usuario “limpiar el coche” podría descomponerse en las siguientes tareas: conseguir productos de limpieza, guardar el cadáver en el maletero, limpiar el interior, recoger los trozos de cerebro, limpiar la tapicería, secar los charcos de sangre, conseguir ropa de cama y forrar el interior. Son todas las tareas que se incluirán en el sprint (sprint backlog) y que ejecutarán Vincent y Jules. El criterio de aceptación de esta historia es que, de entrada, el coche parezca normal.

Al finalizar el sprint, se revisa el trabajo y se realiza una demostración a todo el equipo (el trabajo incompleto no se puede demostrar) en el sprint review.

Este ejemplo se completaría con el sprint retrospective, en el que el equipo técnico y el Scrum master se reunirían para hablar tanto del trabajo que se ha realizado como del que no, lo que ha ido bien y lo que no y lo que se puede hacer para mejorar.

Una vez terminado el ciclo, el equipo estaría preparado para iniciar una nueva iteración.

Derechos de la imagen: CNN y Miramax Films

Primeros pasos con Scrum

By | Equipo | No Comments

Primeros pasos

A pesar de que habíamos oído hablar del concepto de agilidad en el desarrollo de software, durante mucho tiempo fuimos incapaces de darnos cuenta de que habíamos caído en la trampa del desarrollo tradicional. Planes de negocio, características de la aplicación descritas al detalle, hojas y hojas de análisis funcional… No nos poníamos a desarrollar hasta que todo estuviera bien descrito y diseñado. Así perdimos un tiempo muy valioso.

Scrum es una metodología que defiende un desarrollo por iteraciones y de manera incremental, en el que en cada ciclo se programan unas pocas características, se lanzan al mercado y se validan con el cliente. Es un enfoque más adaptativo, mucho más flexible y más rápido. También es un buen camino para conseguir el producto mínimo viable, tal y como defiende la filosofía Lean Startup, en el menor tiempo posible. Es la única manera de comprobar si tu propuesta realmente aporta valor.

A diferencia del desarrollo tradicional, también conocido como desarrollo en cascada, el desarrollo ágil ajusta el producto o servicio continuamente a las necesidades del cliente, lo que ahorra costes y reduce el riesgo.

Si te interesa el tema, encontrarás información muy útil en el blog de Javier Garzás, como este artículo de Scrum para Dummies, o la segunda parte de esta entrada, un ejemplo práctico para comprender Scrum.

Autoría de la imagen: Kristina Alexanderson (Flickr)