Clasificación del software

Una posible clasificación del software es la que lo divide en tres grandes grupos:

  • Software de sistemas: el ciclo de ASIR se centre principalmente en este tipo de software.
  • Software de programación: nosotros nos centraremos principalmente en este software. Estamos hablando de editores de texto, compiladores, intérpretes, enlazadores, depuradores, programas de modelado de software, software de pruebas, gestores de versiones, etc. Y agrupando todo este compendio de utilidades, tenemos también los Entornos de Desarrollo Integrados (IDE).
  • Software de aplicación: es el software que utiliza el usuario final.

Actividad 1. Escribe en un documento de texto dos ejemplos de cada tipo de software según la clasificación presentada.

Entrega la actividad en un archivo de texto llamado Act1-introduccion.odt.

Introducción a los lenguajes de programación

En el siguiente enlace, podemos encontrar una clasificación de lenguajes de programación: Lenguajes de programación

Ejemplos de lenguajes de bajo nivel

Programa en código máquina (tftp) visualizado con el programa bless.

Programa en ensamblador para escribir "Hola mundo".

Ejemplo de lenguaje de medio nivel

Suele considerarse de medio nivel el lenguaje C y en ocasiones C++ por la forma de usar punteros y la gestión de memoria.

Programa en C manejando punteros y gestión de memoria

Ejemplo de lenguajes de alto nivel (Java)

Los lenguajes considerados de alto nivel son VB.NET, Ada, Java, Lisp, PHP, PL/SQL, Python, C#, Ruby, etc.

Ejemplo escrito en Java

Actividad 2. ¿Qué problemas presentan los lenguajes ensambladores? ¿Qué es un lenguaje de alto nivel? ¿Qué ventajas aportan los lenguajes de programación de alto nivel?

Entrega la actividad en un archivo de texto llamado Act2-introduccion.odt.

Historia de los lenguajes de programación

Historia de los lenguajes de programación

Lenguajes de programación según su ejecución

Interpretados

Lenguajes de programación interpretados

Hola mundo en PHP

  • Descargar e instalar Xampp
  • Crear un documento nuevo llamado phpinfo.php con el siguiente contenido:
  • <?php phpinfo(); ?>
  • Colocar el archivo en el directorio raíz de Apache (probablemente en C:\....)
  • Abrir la url siguiente: http://localhost/phpinfo.php

Hola mundo en Java

  • Instalar JDK. Debemos escoger una versión acorde a nuestro sistema operativo. En principio, asumiré que estamos empezando con Windows, así que yo descargaré jdk-8u60-windows-x64.exe. Durante la instalación se nos informará el lugar donde se instalará Java. En mi caso, esa carpeta es C:\Program Files\Java\jdk1.8.0_60.
  • Una vez instalado, agregamos la ruta a las herramientas de JDK a la variable de entorno %PATH%. En mi caso, la carpeta de interés es C:\Program Files\Java\jdk1.8.0_60\bin, ya que ahí es donde están las herramientas de desarrollo.
  • Abrimos un editor de texto, y escribimos lo siguiente:
  • class HolaMundo { public static void main(String[] args) { System.out.println("Hola Mundo"); } }
  • Guardamos el archivo en la carpeta C:\ED\ con el nombre holamundo.java.
  • A continuación compilamos el código fuente, para obtener el archivo bytecode, mediante el comando siguiente:
  • javac C:\ED\holamundo.java
  • Una vez compilado, podremos ver que hay un nuevo archivo holamundo.class en el directorio C:\ed. Para ejecutarlo utilizamos el comando java. A este comando tenemos que indicarle la ruta a los archivos .class mediante el parámetro -classpath ruta_a_archivos_class, así como el nombre de la clase a ejecutar. Así, para nosotros, el comando completo sería:

    java -classpath C:\ED holamundo

Compilados

Lenguajes de programación compilados

En el proceso de compilación un programa compilador (compiler) traduce el código fuente a código máquina en un proceso que consta de tres fases:

  1. análisis léxico
  2. análisis sintáctico
  3. análisis semántico

El resultado de este proceso es el código objeto del programa, es decir, uno o más archivos que contienen la traducción a código máquina del programa almacenado en el código fuente original. Si hay varios códigos objeto interdependientes, es preciso enlazarlos antes de tener un programa ejecutable.

Hola mundo en C#

  • Descargar e instalar Mono.
  • Agregar a la variable de entorno %PATH% la ruta hasta el compilador mcs. En mi caso, esa ruta es C:\Program Files (x86)\Mono\bin.
  • Descargar e instalar Microsoft .NET framework.
  • Crear un documento nuevo llamado holamundo.cs con el siguiente contenido:
  • using System; public class HolaMundo { static public void Main () { Console.WriteLine ("Hola mundo"); } }
  • Abrir una terminal, y dirigirse al lugar donde se ha guardado el archivo holamundo.cs
  • Compilar el programa con el comando siguiente:
  • mcs holamundo.cs
  • Ejecutar el archivo holamundo.exe generado

Actividad 3. Cuando se aborda el aprendizaje de un nuevo lenguaje de programación el primer programa que se suele escribir se denomina "Hola mundo". Busca la forma de ejecutar un programa "Hola mundo" en:

  • Javascript
  • C en GNU/Linux (necesitarás una máquina virtual)

Entrega la actividad en un archivo de texto llamado Act3-introduccion.odt. En dicho documento debe aparecer lo siguiente:

  • El código fuente del programa ejecutado
  • Una captura de pantalla donde se pueda apreciar la ejecución del programa.

Lenguajes de programación según su paradigma

Un paradigma de programación representa un enfoque particular o filosofía para diseñar soluciones. Los paradigmas difieren unos de otros, en los conceptos y la forma de abstraer los elementos involucrados en un problema, así como en los pasos que integran su solución del problema. Existen diversas clasificaciones, aunque una buena opción es la siguiente:

  • Programación imperativa
  • Programación lógica
  • Programación orientada a objetos
  • Programación funcional
  • Actividad 4. La sentencia GOTO fue protagonista de cambios importantes en los lenguajes de programación ¿Para qué sirve la sentencia GOTO? ¿Qué problemas puede acarrear el uso de esta sentencia en la escritura de programas? ¿Cómo se denomina el estilo de programación que eliminó por primera vez el uso de GOTO en el código fuente de los programas? Explica dentro de que paradigma se encuentra.

    Entrega la actividad en un archivo llamado Act4-introduccion.odt

    Actividad 5. ¿Cuáles son las principales características de la programación estructurada?

    Entrega la actividad en un archivo llamado Act5-introduccion.odt

    Actividad 6. Observa el siguiente fragmento de código:

    Cuadrado c; int area; c.establecerDimensiones(100, 200); c.dibujarEnPantalla(); area = c.calcularArea(); cout << area;

    A qué paradigma dirías que corresponde. Explica por qué.

    Entrega la actividad en un archivo llamado Act6-introduccion.odt

    Listas de lenguajes más utilizados:

    • GitHub se encarga de mostrar estadísticas sobre los lenguajes más usados en los repositorios de github y estos son los datos que ofrece.
    • RedMonk se obtiene midiendo la popularidad en github y stackoverflow ofreciendo los siguientes resultados.
    • TIOBE se basa en el número de ingenieros cualificados, cursos y el posicionamiento en los motores de busqueda. Sobre todo, nos sirve para saber si nuestros conocimientos están obsoletos (hay pocos ingenieros/se ofrecen pocos cursos/se habla poco del lenguaje).

    Modelos de desarrollo de software

    En el siguiente documento, podemos ver un análisis de diferentes metodologías de desarrollo del software: Metodologías y ciclos de vida del software.

    Ingeniería del software

    • Proceso (marco de trabajo)
      • Da respuesta a...
      • ¿Quién se comunica con quién?
      • ¿Cómo se coordinan las actividades interdependientes?
      • ¿Quién es responsable de qué trabajo?
      • ¿Quién produce qué productos de trabajo, y cómo se evalúan?
      • Determina...
      • Todas las actividades y tareas de la ingeniería del software
      • Define el flujo de trabajo entre las actividades y tareas
      • Identifica los productos de trabajo que se producen
      • Especifica los puntos de control de calidad requeridos
      • Mecanismos para monitorizar y medir el avance del proyecto
    • Métodos (cómo llevar a cabo las actividades determinadas en un proceso)
      • Las actividades técnicas fundamentales son:
      • Análisis: el análisis es el fundamento de todos los trabajos de ingeniería que siguen. Durante el análisis, se crea el modelo de lo que es requerido por el software.
      • Diseño: las actividades de diseño siguen el análisis y traducen el modelo del análisis en cómo el producto proporciona estas funciones por medio del software.
      • Codificación: una vez que el diseño es completo, la codificación traduce el modelo de diseño en una forma ejecutable.
      • Pruebas: el proceso de pruebas ayuda a destapar errores en el código y el diseño subyacente.
    • Herramientas (automatización de las capas de Proceso y Métodos)
      • Herramientas de gestión de proyectos
      • Herramientas de control de cambios
      • Herramientas de análisis y diseño
      • Herramientas de generación de código
      • Herramientas de pruebas
      • Herramientas de reingeniería
      • Herramientas de documentación
      • Herramientas de prototipos
      • Etc...
    • Enfoque de calidad

    Ciclo de vida

    Un ciclo de vida o paradigma (o proceso de desarrollo) del software determina lo siguiente:

    • El orden de las fases (conjuntos de actividades) del proceso de software
    • Establece los criterios de transición para pasar de una fase a la siguiente
    • Define las entradas y salidas de cada fase
    • Describe los estados por los que pasa el producto
    • Describe las actividades a realizar para transformar el producto
    • Define un esquema que sirve como base para planificar, organizar, coordinar, desarrollar...
    • Define los entregables de cada fase (documentación o software)

    Modelo en cascada

    Modelo sashimi

    Modelo en V

    Modelo iterativo

    Modelo incremental

    Modelo en espiral

    Modelo de prototipado

    Actividad 7. Confecciona un documento con los modelos de ciclo de vida comentados en clase. Dicho documento debe tener la siguiente estructura:

    • Una descripción de cada modelo de ciclo de vida, donde se explique en qué consiste y se añada un gráfio explicativo.
    • Una tabla comparativa entre los diferentes ciclos de vida, donde se indiquen las ventajas e inconvenientes de cada uno.

    Entrega un documento llamado Act7-introduccion.odt.

    Scrum

    Dentro de las metodologías de desarrollo, cobran fuerza las metodologías ágiles. Pero qué es el agilismo (Ver. Cap.1 de Diseño Ágil con TDD).

    Una de las metodologías de desarrollo ágil es Scrum.

    Qué es Scrum

    Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos desde principios de los años 90. Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos.

    Qué contiene Scrum

    El marco de trabajo Scrum consiste en los siguientes componentes:

    • Equipos Scrum
    • Roles
    • Eventos
    • Artefactos
    • Reglas que relacionan los Roles, Eventos y Artefactos

    Empirismo

    Scrum se basa en la idea de que el conocimiento sobre un proyecto se va adquiriendo a partir de la experiencia previa en el mismo.

    Las decisiones se toman en iteraciones cortas, que permiten aumentar la predecibilidad.

    Para que el control de procesos empírico funcione, se deben dar tres condiciones: transparencia, inspección y adaptación.

    • Transparencia: Los responsables del resultado deben tener una idea común sobre los aspectos importantes del proceso. Por ejemplo:

      • Todos los participantes deben compartir un lenguaje común para referirse al proceso
      • Aquellos que desempeñan el trabajo y aquellos que aceptan el producto de dicho trabajo deben compartir una definición común de Terminado.
    • Inspección: Los usuarios implicados en Scrum deben inspeccionar regularmente los artefactos de Scrum y el progreso del proyecto, pero no como para interferir en su trabajo.
    • Adaptación: Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.

    Scrum prescribe cuatro eventos formales para la inspección y adaptación:

    • Reunión de Planificación del Sprint (Sprint Planning Meeting)
    • Scrum Diario (Daily Scrum)
    • Revisión del Sprint (Sprint Review)
    • Retrospectiva del Sprint (Sprint Retrospective)

    El equipo Scrum

    Los equipos Scrum están formados por personas que están directamente relacionadas con el producto. No deben haber terceras personas que lo dirija externamente.

    Son autoorganizados, es decir, deciden internamente la mejor forma de llevar a cabo su trabajo.

    El Equipo Scrum consiste en:

    • Dueño de Producto (Product Owner): Es el cliente. Sus responsabilidades son:
      • Ser el representante de todas las personas interesadas en los resultados del proyecto y actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones.
      • Definir los objetivos del producto o proyecto.
      • Crea y mantiene la lista priorizada con los requisitos o Product Backlog. Puesto que conoce el valor que aportará cada requisito, los prioriza en base al coste que el Equipo de Desarrollo.
      • Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas.
      • Antes de iniciar cada iteración replanifica el proyecto en función de los requisitos que aportan más valor en ese momento, de los requisitos completados en la iteración anterior y del contexto del proyecto en ese momento.
      • Participar en la reunión de planificación de iteración, proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.
      • Estar disponible durante el curso de la iteración para responder a las preguntas que puedan aparecer.
      • No cambiar los requisitos en medio de una iteración
    • Equipo de Desarrollo (Development Team): Es el equipo que desarrolla el producto.
      • Estimar la complejidad de cada requisito en el Product Backlog (lista priorizada de requisitos priorizada) del producto o proyecto.
      • Seleccionar los requisitos que se compromete a completar en una iteración, de forma que estén preparados para ser entregados al cliente.
      • En la reunión de planificación de la iteración subdivide los requisitos en tareas:
        • Identificar todas las tareas necesarias para completar cada requisito.
        • Estimar el esfuerzo necesario para realizar cada tarea.
        • Cada miembro del equipo se autoasigna a las tareas.
      • Cada especialista lidera el trabajo en su área y el resto colaboran si es necesario para poder completar un requisito.
      • Demostrar al cliente los requisitos completados al final de cada iteración.
      • Hacer una retrospectiva la final de cada iteración para mejorar de forma continua su manera de trabajar.
      • Todos los miembros del equipo trabajan en la misma localización física.
    • Scrum Master: Trabaja para que Scrum se aplique correctamente:
      • Asegurar que exista un Product Backlog (lista de requisitos priorizada) y que esté preparada antes de la siguiente iteración.
      • Tener claro lo que está pasando en cada momento.
      • Se coordina con el Product Owner para aportar activamente durante la priorización de requisitos, y detectar los riesgos asociados.
      • Interviene en las reuniones de Scrum (planificación de la iteración, reuniones diarias de sincronización del equipo, demostración, retrospectiva), haciendo propuestas que mejoren la productividad y consigan sus objetivos.
      • Actúa de "traductor" entre el Product Owner, que probablemente no tenga conocimientos sobre tecnología, y el Equipo de Desarrollo, que probablemente no tenga conocimientos sobre negocios.
      • Plantea las preguntas adecuadas durante la demostración del sprint y la restrospectiva, para conseguir respuestas cortas, honestas y valiosas, para aportar valor en la siguiente iteracion
      • Protege al equipo del Product Owner de cambios durante un sprint, renegociándolos para que afecten lo menos posible al sprint y no haya que cancelar el sprint completo.
      • Resuelve los problemas de cualquier tipo que puedan afectar al Equipo de Desarrollo.
      • Forma a los miembros que no conocen Scrum sobre su funcionamiento (actúa como un coach).
      • Se asegura de que la definición de Terminado se cumple. Por ejemplo, una definición de terminado podría incluir:
        • Cumplir con los criterios de aceptación definidos en la historia de usuario
        • Las pruebas unitarias, de integración y de aceptación deben haber sido terminadas
        • Deben existir cero defectos de severidad alta
        • La revisión de código por algún colega debe haberse completado.

    Eventos de Scrum

    En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Los eventos son:

    • El Sprint: El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto Terminado, utilizable y potencialmente desplegable.
      • Su duración es fija, no puede alargarse ni acortarse.
      • Su duración suele ser de 1 mes
      • Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.
      • No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal)
      • Dentro de un Sprint se producen otros eventos:
        • Reunión de Planificación del Sprint (Sprint Planning Meeting)
        • Scrums Diarios (Daily Scrums)
        • El trabajo de desarrollo
        • Revisión del Sprint (Sprint Review)
        • Retrospectiva del Sprint (Sprint Retrospective)
      • El alcance de cada sprint puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más sobre el proyecto.
      • Un sprint puede cancelarse bajo la responsabilidad del Producto Owner, porque:
        • La compañía cambia la dirección
        • Las condiciones del mercado o de la tecnología cambian
        • Si no tuviese sentido seguir con él dadas las circunstancias.
    • Reunión de Planificación del Sprint (Sprint Planning Meeting): Es la reunión en la que se planifica lo que se va a hacer durante el Sprint
      • Tiene una duración de 8 horas, dividas en dos partes de 4 horas cada una.
      • La primera parte de la reunión (de 4 horas) responde a ¿Qué puede ser terminado en este Sprint?.
        • El Product Owner presenta al equipo el Product Backlog, pone nombre a la meta del Sprint o Sprint Goal* (de manera que ayude a tomar decisiones durante su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.
        • El Equipo de Desarrollo examina la lista y hace lo siguiente:
          • Pregunta sobre el alcance de cada requisito. Por ejemplo, "¿Borrar 'Artículo' implica borrar todas las facturas relacionadas con ese artículo?"
          • Añade nuevas condiciones de satisfacción, del tipo "Dado aaa, cuando se produzca bbb, entonces ccc".
          Selecciona los requisitos del Product Backlog más prioritarios que se compromete a completar en el Sprint.
      • La segunda parte de la reunión (de 4 horas) responde a ¿Cómo se va a conseguir completar el trabajo?.
        • El Equipo de Desarrollo descompone los requisitos en tareas.
        • Realiza una estimación del coste necesario para realizar cada tarea.
          • Estimaciones a mano alzada que hacen los miembros del Equipo de Desarrollo.
          • Cálculos de velocidad teniendo en cuenta la velocidad en de los Sprint anteriores.
        • El Equipo de desarrollo decide qué requisitos (con todas sus tareas) se incluirán en el Sprint.
        • El Product Owner puede realizar cambios en los requisitos si desea que uno de ellos entre en el Sprint:
          • Puede subir la prioridad del requisito de interés para que suba en el Product Backlog y así entre en el Sprint actual
          • Puede bajar la prioridad de un requisito de modo que el requisito de interés se adelante en Product Backlog y entre en el Sprint actual
          • Puede reducir el alcance del requisito de interés para que así disminuya su coste y pueda entrar en el Sprint actual
          • Puede dividir el requisito de interés en requisitos más pequeños para que así uno de ellos (el de mayor interés) entre en el Sprint
      • Finalmente, cada miembro del Equipo de Desarrollo se hace cargo de ciertas tareas.

      Sprint Goal: El objetivo del Sprint debe poder resumir el objetivo del Sprint en una única frase. Por ejemplo, "Los usuarios deben poder hacer transferencias bancarias".

      Una vez que ha terminado el Spring Meeting, tenemos un Sprint Backlog, que es el conjunto de requisitos a cubrir durante el presente Sprint. Normalmente, tanto el el Product Backlog como el Sprint Backlog se almacenan en un documento/software que permite la compartición entre el Product Owner, el Scrum Master y el Equipo de Desarrollo. Esto puede hacerse mediante una hoja de cálculo compartida, o mediante programas específicos, como Planbox, Targetprocess, Yodiz, VersionOne, Axosoft, etc.

      Hay un elemento muy importante que se utiliza durante el Sprint Planning Meeting y durante todo el Sprint, llamado Task Board. El Task Board puede consistir en una simple pizarra, con una estructura como la siguiente:

      A partir del Product Backlog se van colocando los requisitos en la columna TO DO, y es donde se discute sobre qué requisitos y tareas se van a llevar a cabo en el Sprint.

      Cuando se van desglosando los requisitos en forma de tareas, se pueden utilizar postits de diferentes colores, como en el siguiente gráfico:

      • Daily Scrum: Es una reunión de 15 minutos donde cada miembro informa a los demás sobre ciertas cuestiones:
        • ¿Qué hice ayer desde la última reunión de sincronización? ¿Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
        • ¿Qué haré hoy?
        • ¿Qué problemas tengo para cumplir mis compromisos?
        • En esta reunión se informa únicamente, no se resuelven los problemas, para cumplir el TimeBox de 15 minutos. Después, el resto de miembros se puede ofrecer para ayudar, y en caso de no poder, se derivará al Scrum Master.

        • Todos los miembros escuchan al que está hablando sin interrumpir.
        • Mientras un miembro del Equipo de Desarrollo habla, va modificando el Task Board, moviendo tareas y/o requisitos, según los cambios que se hayan dado.
        • Se pueden hacer cambios de estimación de coste de las tareas y requisitos sobre la marcha, cuando el equipo así lo considere.
        • A veces pueden surgir nuevas tareas que no se habían planificado de cierta urgencia. Estas tareas se añaden a la sección No planificadas del Task Board
        • Al final del Daily Scrum, hay que actualizar el Burn-Down

      El Burn-Down Chart es un gráfico que permite hacer un seguimiento sobre los progresos del proyecto:

      • Sprint Review: Es una demostración de lo que se ha conseguido en el Sprint.
        • Tiene un TimeBox de 4 horas
        • El equipo, junto con el Producto Owner y el Scrum Master se reunen, y el Equipo hace una demostración de lo conseguido.
        • El Product Owner hace preguntas y/o comentarios sobre el resultado
        • Se plantean cambios sobre el producto para el próximo Sprint Planning Meeting.
        • Se habla informalmente sobre qué hacer a continuación, para incluirlo en el próximo Sprint Planning Meeting.
      • Sprint Retrospective: Reunión para hablar sobre la productividad y la calidad obtenida en el Sprint anterior.
        • Es una reunión a la que asisten solamente los miembros del Equipo de Desarrollo
        • Se hace siempre después del Sprint Review
        • Se cubren los siguientes aspectos:
          • Qué cosas han funcionado bien.
          • Cuales hay que mejorar.
          • Qué cosas se quieren probar hacer en el siguiente Sprint.
          • Qué se ha aprendido.
          • Cuales son los problemas que podrían impedir progresar adecuadamente. El Scrum Master se encargará de ir eliminando los obstáculos identificados que el propio equipo no pueda resolver por sí mismo.
      • Release Planning Meeting: El propósito es acordar las entregas. Una entrega puede incluir los productos desarrollados en uno o más Sprints.
        • Se necesitan los siguientes elementos para fijar las entregas:
          • Un Product Backlog donde cada Historia de Usuario tenga asignada Valor y Coste
          • Una estimación de la velocidad del Equipo de Desarrollo, obtenida a partir de los Sprints anteriores.
      • Las Entregas son imprecisas, ya que se basan en estimaciones de coste y velocidad aproximados.
      • Se pueden refinar durante el Sprint Planning Meeting, o bien crear una reunión específica.
      • No debe alargarse demasiado, puesto que siempre se basa en información imcompleta, y no merece la pena gastar demasiado tiempo en una información que podría cambiar.

      Artefactos de Scrum

      Scrum utiliza una serie de conceptos y herramientas útiles para conseguir lo que Scrum busca: Transparencia para que todos los que participan en el proyecto tengan la misma idea sobre el mismo, y sobre lo que se está haciendo.

      • Definición de Trabajo Terminado (Definition of Done o DoD: Es la idea acordada entre el Equipo de Desarrollo y el Product Owner sobre lo que significa que un requisito ha sido completado.
        • Terminado debe ser entregable, para que el Product Owner pueda tomar decisiones en el Sprint Review, como por ejemplo, cambiar las condiciones de satisfacción en función de la velocidad del proyecto, reforzar ciertas condiciones, etc.
        • Debe incluir condiciones de satisfacción claras y concisas, como por ejemplo:
          • Código fuente escrito
          • Código fuente probado con pruebas unitarias/de integración
          • Código fuente documentado
          • Código fuente refactorizado para conseguir calidad interna/mantenibilidad
          • etc.
        • Las condiciones de satisfacción deben ser utilizadas para identificar las tareas a realizar durante el Sprint
      • Pila de Producto (Product Backlog): El Product Backlog es una lista ordenada de todo lo que podría ser necesario en el producto
        • Es propiedad del Product Owner, es decir, es su responsable en cuanto a su contenido, su disponibilidad y su orden
        • Es la única fuente de requisitos para cualquier cambio a realizarse en el producto.
        • La lista no es necesario que sea completa ni que el detalle sea muy alto en todos los requisitos.
        • Es mejor que el nivel de detalle vaya aumentando y el orden vaya cambiando (refinamiento) conforme el proyecto avanza. Así, los requisitos más importantes se tratarán primero, y los menos importantes se dejarán para Sprints posteriores.

      • Historias de usuario/Requisitos (User Stories): Son las partes que componen un Product Backlog, y que se utilizarán durante todo el proceso.
        • Una historia es un requisito de negocios visto desde el punto de vista de un usuario.
        • Un ejemplo: Como cliente del banco, quiero pedir un préstamo para poder comprar una casa
        • Cuando se trabaja sobre una historia de usuario, hay que definir varios aspectos
          • La historia en sí
          • Valor (numérico) que aporta la historia desde el punto de vista del Product Owner.
          • Coste (numérico) que supone la historia desde el punto de vista del Equipo de Desarrollo.
          • Riesgo que supone el desarrollo de la historia, en función de las dependencias, estado de la tecnología, nivel de experiencia, etc.
          • Condiciones de satisfacción de la historia.
        • Las historias de usuario se suelen plasmar en tarjetas al colocarlas en el Task Board

      A continuación, algunos ejemplos de Historias de Usuario.

      • Pila de Spring (Sprint Backlog): Es la lista de tareas que el equipo elabora en el Sprint Planning Meeting como plan para completar los objetivos/requisitos seleccionados para el Sprint.
        • Cada objetivo/requisito está asociado a:
          • Tareas asociadas
          • Coste por cada tarea
          • Asignación que han hecho los miembros del equipo.
        • Debe poder verse la evolución de las tareas según su estado. Posibles ejemplos de estado pueden ser:
          • Por hacer
          • En desarrollo
          • En pruebas
          • Completado
        • Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.
        • El Sprint Backlog suele representarse en una Task Board, o Kanban Board.

      Existen diveras maneras de reflejar el Sprint Backlog. A continuación podemos ver algunos ejemplos:

      Sprint Backlog hecho con Target Process

      Sprint Backlog hecho mediante una pizarra y postits

      • Gráficos de Trabajo Pendiente (Burndown Chart): Es un gráfico de trabajo pendiente en el Sprint.
        • Muestra la velocidad a la que se está completando los objetivos/requisitos.
        • Permite estimar si el Equipo podrá completar el trabajo en el tiempo estimado.
        • La tabla tiene dos ejes:
          • Vertical: Coste del Sprint
          • Horizontal: Días del Spring
        • La evolución ideal del Sprint, viene dada por una línea que une dos puntos de la tabla:
          • Punto inicial: (Día_0 , Coste_total_Sprint)
          • Punto final: (Día_30 , Coste_0)
        • Conforme se van completando tareas, se van añadiendo puntos a la gráfica

        Actividad 8. Busca información sobre Planning Poker. Después prepara el tuyo propio sobre la marcha, y trata de asignar un coste a las siguientes tareas, poniéndote de acuerdo con otros 3 compañeros, sobre las siguientes tareas:

        • Realizar una compra en Internet en Amazon.
        • Realizar una compra en Internet mediante transferencia bancaria, con comprobante.
        • Instalar el CMS Wordpress desde cero.
        • Crear una página web para publicitar nuestro currículum.
        • Instalar CentOS 7 una máquina virtual.

        Para cada pregunta, anota los valores obtenidos en las diferentes rondas hasta alcanzar un consenso. Describe también qué argumentos han hecho cambiar de opinión a los miembros del equipo.

        Entrega un documento con lo que se pide, llamado Act8-introduccion.odt. El archivo debe contener los nombres de los componentes del equipo.

        Scrum en la práctica

        Un análisis muy interesante sobre lo que es Scrum en la práctica, viene explicado en el Scrum y XP desde las trincheras.

        Actividad 9. Escoge uno de los siguientes apartados del libro Scrum y XP desde las trincheras:

        • COMO HACEMOS PILAS DE PRODUCTO....(página 17 - 20)
        • COMO NOS PREPARAMOS PARA LA PLANIFICACIÓN DE SPRINT y COMO HACEMOS LA PLANIFICACIÓN DE SPRINT.... (páginas 20 - 27)
        • Definiendo la meta del Sprint, Decidiendo qué historias incluir en el Sprint, ¿Cómo puede el Dueño de Producto alterar las historias que se incluyen en el Sprint?, ¿Cómo decide el equipo qué historias incluir en el Sprint? (páginas 27 - 35)
        • Por qué usamos tarjetas, Definición de terminado y Clarificando historias (páginas 35 - 42)
        • Dividiendo historias en historias más pequeñas, Dividiendo las historias en tareas, Definiendo el sitio y la hora para el Scrum diario, Dónde trazar la línea, Historias técnicas, Sistema de seguimiento de errores vs. Pila de Producto, ¡Por fin acabó la reunión de planificación de Sprint! (páginas 42 a 47)
        • COMO COMUNICAMOS LOS SPRINTS, COMO HACEMOS PILAS DE SPRINT, Formato de la Pila de Sprint, Cómo funciona el tablón de tareas, Ejemplo 1 - tras el primer Scrum diario y Ejemplo 2 - tras unos cuantos días (páginas 42 a 53)
        • Como funciona el diagrama burn-down, Señales de alarma en el burn-down, Hey, ¿Qué pasa con la trazabilidad?, Estimando en días vs horas (páginas 53 a 57)
        • COMO DISTRIBUIMOS LA SALA DEL EQUIPO, la esquina de diseño, ¡Sienta al equipo junto!, Mantén al Dueño de Producto a mano, Mantén a los gerentes y coachs a mano (páginas 57 a 63)
        • CÓMO HACEMOS SCRUM DIARIOS, Cómo actualizamos el tablón, Tratando con tardones, Tratando con no se qué hacer hoy, CÓMO HACEMOS LA DEMO DE SPRINT, Por qué insistimos en que todos los Sprints acaben con una demo, Lista de comprobación para demos de Sprint y Tratando con historias indemostrables (páginas 63 a 69)
        • CÓMO HACEMOS RETROSPECTIVAS DE SPRINT, Por qué insistimos en que todos los equipos hagan retrospectivas, Cómo organizamos las retrospectivas, Difundiendo las lecciones entre los equipos, Cambiar o no cambiar, Ejemplo de cosas que pueden surgir en las retrospectivas (página 69 a 74)
        • DESCANSOS ENTRE SPRINTS, Define tus umbrales de aceptación, Estimación de los elementos más importantes, Estimar la velocidad, Uniéndolo todo en un plan de entregas (release plan), Adaptando el plan de entregas (página 74 a 80)

        Lee el apartado escogido y prepara una exposición oral donde expliques lo que has aprendido sobre lo que has leído.

        El profesor pedirá a algunos alumnos elegidos al azar que expongan sus conclusiones.

        Actividad 10. Esta práctica pretende simular un proyecto de Scrum, pero en lugar de contruir un programa, construiremos una maqueta de papel. Las instrucciones están los siguientes documentos:

        La documentación entregable se puede consultar en los documentos PDF adjuntos.

        Si no dispones de un Product Backlog, pudes utilizar esta sugerencia, importándolo desde Google Docs.