Bienvenidos!

al curso teórico-práctico

Professional Scrum Developer

22 de febrero de 2019

Como facilitador

Necesito presentarme

Para que toda la clase me conozca 

Facilitador

Marvin López

Ingeniero de Sistemas Computacionales e Ingeniería de SW

+10 años de experiencia en Desarrollo de SW,

Calidad de SW, Gestión de Proyectos

y Gestión de equipos

Certificado por Scrum.org como:

- Professional Scrum Master

- Professional Scrum Developer

Certificado por ISTQB como

- Software Tester

Como miembro de la clase

Necesito presentarme

Para que el facilitador y el resto del grupo me conozcan y podamos trabajar de forma efectiva

Como miembro de la clase

Necesito anotar mis expectativas del curso

Para que el facilitador y el grupo puedan conocerlas y ayudarme a conseguirlas

Como clase

Necesito establecer reglas de convivencia del curso

Para que todos podamos aprovechar el tiempo y los recursos que tenemos disponibles de la mejor forma

Como clase

Necesito conocer los objetivos del curso

Para entender que voy a aprender en él

Objetivos

• Entender los principales aspectos de la Agilidad y cómo se relaciona con Scrum.
• Aprender los diferentes aspectos de un equipo Scrum y cómo trabajan en conjunto para entregar software de calidad y funcionando.
• Entender como las prácticas modernas de Ingeniería de Software y las herramientas de DevOps ayudan al equipo de desarrollo a mejorar la entrega de software de calidad.
• Obtener conocimientos para aprovechar las herramientas y prácticas modernas de desarrollo de software.

Como facilitador

Necesito introducir el contenido y herramientas del curso

Para que el grupo conozca como cumpliremos los objetivos

Herramientas del curso

Otras herramientas

• Google Classroom (Material de referencia)
• Socrative (quizzes, test exam) 
• Material impreso y útiles de oficina para desarrollar las prácticas

• Día 2 y 3

• Laptops por participante para realizar el taller práctico Desarrollo de Aplicación Móvil de películas tipo Netflix
• Uso de herramientas de desarrollo: Git, Visual Studio Code, Flutter
• Utilización de Azure DevOps como herramienta ALM & DevOps

Contenido - Día 1

Introducción a Ágil y Scrum

• Introducción a Ágil – Porque Ágil, Manifiesto Ágil, principios y valores agiles

  • Introducción a marcos de trabajo Ágil – XP, Kanban, Lean, DSDM

• Introducción a Scrum –Roles, Ceremonias y Artefactos

• Trabajando en Sprints

  • Burndowns, Burnups  y Cumulative Flow Charts

• Planificando Releases

• Estimación – Escribir historias de usuario y técnicas de estimación

• Crear un Backlog del Sprint

• Definición de Done (Hecho)

• Sprint Reviews

• Mejora Continua – Retrospectivas

Juego de las cartas

Dividir el salón en 2 equipos

1 Cliente (recibe las cartas al final, toma el tiempo completo), 1 Jefe (toma el tiempo por trabajador) y los trabajadores.

Iteraciones:

1. Cada participante debe voltear las cartas antes de pasarlas a su compañero de al lado.

2. Cada participante voltea sólo la mitad de cartas antes de pasarlas a su compañero de al lado.

3. Cada participante voltea sólo 1 carta por vez antes de pasarla a su compañero de al lado.

Fábrica de aviones

Criterios de aceptación Aviones

• Debe estar hecho de 1/4 de página
• Debe volar más de 5 metros.
• Tener escrito el número de serie en las alas.
• Tener escrito el nombre del equipo constructor en ambos lados.
• El avión debe tener 2 puertas en cada lado.
• El avión tiene que tener 3 ventanas en cada lado.

Fábrica de aviones

iteración

• Se da 2 minutos al equipo para que comenten la cantidad de aviones que se comprometen a realizar en 5 minutos.
• Se da 5 minutos para que realicen los aviones comprometidos con el cliente.
• Al finalizar el tiempo, se revisa cuantos cumplen con la definición de hecho (Dependiendo el número de participantes puede variar de 5 a 15 Minutos). Aquí el facilitador verifica que los aviones cumplen todos los criterios de satisfacción.
• Se contabilizan y se escriben en el papel.
• Se da al equipo 2 minutos para que análisis sus resultados y que observen propuestas para mejorar el proceso.

Contenido - Día 2

• Recopilando Requerimientos

• Escribir historias de usuario y Criterios de Aceptación

• Crear Product Backlog - Proyecto Nextflix

  • Azure Devops Backlog

• Product Backlog refinement

  • Estimación Relativa (team) Planning Poker / T-Shirt Size

• Sprint Planning - Crear un Backlog del Sprint - Proyecto Nextflix

  • Sprint Goal y Definition of Done

• Sprint 1 - Proyecto Nextflix, Azure DevOps, Git

• Sprint Review - Proyecto Nextflix

• Sprint Retrospective - Proyecto Nextflix

• Arquitectura Emergente

Norte, Sur, Este y Oeste

Norte [N] = Mito

Sur [S] = Hecho/Realidad

Cuando se lea una de las tarjetas,

deberá moverse al Norte o al Sur

dependiendo de lo que crea que es la 

respuesta correcta.

Recopilando Requerimientos

El problema de la documentación

Porque la vida es

muy corta...

para escribir todo

Recopilando Requerimientos

No se maneja el cambio

Planning

La comunicación no llega correctamente.

Principio Ágil

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

Historias de Usuario

Descripciones cortas de funcionalidades que nuestro cliente quisiera ver algún día en el software.

{VALOR}

Historias de Usuario

• Deben tener sentido para el cliente
• No se escriben en lenguaje técnico
• Representan un End-2-End
• Independiente
• Negociable
• Se pueden probar
• Pequeña y estimable

Historias de Usuario

Título

Como <tipo de usuario/rol>

Quiero <objetivo/funcionalidad>

Para <razón/beneficio>

Para quién

Qué

Por qué

Las 3 C’s de la historia de usuario

Tarjeta(Card),

la Conversación (Conversation)

Confirmación (Confirmation). 

• El diseño de esta aplicación puede considerar algunos aspectos similares al de Netflix.
  Con respecto a su contenido de la aplicación debe ser sencilla y fácil de manejar.
• En la portada de presentación debe salir las siguientes listas de películas:
  • En cartelera, Tendencia, Por estrenar
• En la portada de presentación debe salir las siguientes listas de series de TV:
  • Populares, Tendencia, Más votadas,
• Cuando el cliente de click a una película, éste debe ser redirigido a otra pantalla donde se muestre la imagen de la película o de la serie de TV más un contenido de texto indicando de que trata la película y a que genero pertenece.
• En la portada de presentación se debe mostrar una opción que liste sólo películas y otra que liste sólo series de TV.
• La app debe cargar rápido

Vamos a crear Historias de Usuario

Criterios de Aceptación

Los criterios de aceptación definen cómo debe comportarse la aplicación al realizar una acción determinada, normalmente por parte de un usuario de la aplicación. Es lo que utiliza el Product Owner para aceptar o no una Historia de Usuario.

Escenario

Dado que <condición>

Cuando <acción>

Entonces <resultado>

Estimación

Estimación​

Necesitamos una forma de estimar qué:

- Nos permita planificar para el futuro

- Nos recuerde que nuestras estimaciones son solo supuestos

- Reconoce la complejidad inherente de crear Software

Estimación Relativa​

One Cookie = 10 sec
7 cookies = 10 sec x 7 = 70 Secs

14 cookies = 10 sec x 14 = Secs

Text

> x2 as big

Story Points​

Story Points​

• Nos recuerda que nuestras estimaciones son supuestos.
• Se mide en base a tamaño o esfuerzo, no considera tiempo.
• Es rápido, fácil y simple.

Backlog Refinement

Sprint Planning

https://azure.microsoft.com/es-es/services/devops/

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. 

Sprint Review

Sprint Retrospective

Spaghetti Tower Marshmallow Challenge

• Tiempo: 18 minutos
• Instrucciones: Cada equipo debe construir una estructura que sostenga un malvavisco en la parte superior de la estructura,  cada equipo colocará los materiales como estime conveniente.
• Materiales: 20 espaguetis, 1 metro de cinta adhesiva, 1 metro de cuerda y 1 malvavisco.  

Gana el equipo que construya la estructura más alta en 18 minutos y se sostenga sola.

Contenido - Día 3

• Definition of Done

• Arquitectura Emergente

• Agile Testing

• Unit Testing - Test-Driven Development (TDD)

  • Refactoring

  • Test Smells
• Acceptance testing, ATDD
• Code Reviews

• Pair Programming / Swarming / Mob Programming-Testing

• Clean code – SOLID
• Code Metrics
• Integración Continua (CI)
• Continuous Delivery vs. Continuous Deployment

Definition of Done

"Done" significa que un PBI es un incremento que potencialmente se puede poner en producción.

Se representa como:

- Un checklist

- Visible para todos

- Documento vivo

Definition of Done

- El PBI es aceptado por el Product Owner

- Se completó el code review

- Se hizo push al Dev Branch

- El CI build ejecuta sin errores

- Pasan todas las pruebas de aceptación

- Pasan todas las pruebas de desarrollo

- Se hizo deploy en ambiente de pruebas

Arquitectura Emergente

Un equipo que practica SCRUM deja que la arquitectura emerja a medida que se construye el software.

Think Big, Act small, Fail fast and Learn Rapidly

Todas las decisiones de arquitecturas tienen que estar soportadas por código

Agile Testing

Agile Testing

Pirámide del Testing

El testing es responsabilidad de todos!

Unit Testing

Pruebas Unitarias

Pequeños test creados específicamente para cubrir todos los requisitos de unidades especificas del código y verificar sus resultados.

Ventajas:
1. Proporciona un trabajo ágil;
2. Calidad del código;
3. Detectar errores rápido;
4. Facilita los cambios y favorece la integración;
5. Proporciona información;
6. Proceso debugging;
7. El diseño;
8. Reduce el coste;

TDD - Test Driven Development

Ciclo de TDD

TDD - Test Driven Development

3 leyes de TDD:

1. No se permite escribir cualquier código de producción, a menos que sea para hacer pasar un test unitario fallido.
2. No se permite escribir más que un test unitario que sea lo suficiente para que éste falle; los errores de compilación se consideran fallos.
3. No se permite escribir cualquier código de producción mas que el que sea suficiente para hacer pasar un test unitario.

Refactoring

"Cambiar la estructura del código sin cambiar su comportamiento"

La refactorización también es:

• Una limpieza de código, básicamente
• La refactorización no arregla errores ni incorpora funcionalidades
• Si durante una refactorización se ha cambiado el comportamiento del software o web, es que has generado un error o bug

TDD - Test Driven Development

F.I.R.S.T.

– Fast: Tests should be fast.

– Independent: Tests should not depend on each other.

– Repeatable: Tests should be repeatable in any environment.

– Self-Validating: Tests should have a boolean output (pass or fail).

– Timely: Tests should be written before the production code.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

TDD - Test Driven Development

Crear un método que reciba como parámetro un boleano y retorne una cadena que contenga "Yes" cuando es verdadero y "No" cuando es falso.

Test Smells

• Las pruebas son difíciles de crear
• Lógica de contexto en el código de producción
• Hacen cosas extrañas para poder probar el código
• Las pruebas fallan intermitentemente

El resultado de las pruebas

cuenta la historia de

cómo en realidad está el

código de producción.

Y si encuentro errores?

Un buen reporte de error debe contener:

- Un buen título

- Buena gramática en la descripción
- Un único error por reporte
- Pasos para reproducir el error, sin especificar supuestos
- Resultados esperados y resultados obtenidos
- Versión de la aplicación donde se encontró el error
- Imágenes videos que puedan describir el error
- No debe indicar ni asumir culpas dentro del equipo

Code Coverage

El Code Coverage o cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas.

De esta medida, podemos sacar varias conclusiones:

1. Podemos necesitar más pruebas unitarias.
2. Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

Code Coverage

ATDD

Acceptance Test Driven Development

El equipo discute en colaboración criterios de aceptación, con ejemplos, y luego los divide en un conjunto de pruebas de aceptación en concreto antes de que comience el desarrollo.

Code Reviews

Los distintos miembros de un equipo revisan de forma individual o en conjunto la implementación realizada por otro miembro.

Code Reviews

Las reglas para revisar el código son establecidas por el equipo en conjunto.

Pair Programming

Pair Programming

El pair programming, es una práctica de desarrollo donde dos programadores trabajan juntos compartiendo la máquina para la producción de software.

Roles:

• Driver, conduce la implementación del código hacia la meta o la consecución de la tarea.
• Navigator, encargado de revisar la conducción, proponer rutas, asegurar la calidad del viaje o aprender las habilidades de la conducción del piloto, ya que será él quien posteriormente asuma la labor de driver.

Pair Programming

Ventajas

• Calidad de código.
• Reviews de código.
• Mayor productividad.
• Mejor sistema de aprendizaje para los desarrolladores inexpertos.
• Validación de ideas.
• Distribución coherente de los conocimientos del proyecto.
• Mejora de la relación interna entre empleados.
• Compartir conocimientos.
• Desarrollo y entrega más rápido.

Desventajas?

Swarming

La idea es dedicar todos los esfuerzos del equipo a un único PBI (el de mayor prioridad), todo lo necesario para completarla se hace tan en paralelo como sea posible.

El Product Backlog debe estar priorizado.

Patrón Rey – Sirviente

Mob-Programming/Testing

El Mob Programming es una estrategia de desarrollo de software en la que todo el equipo trabaja en lo mismo, al mismo tiempo, en el mismo sitio y en la misma computadora. Igual que en Pair Programming existe un Driver, con la diferencia de que hay mas de 1 Navigator.

Cada cierto 15 o 20 min. se rota el responsable de escribir el código o ejecutar las pruebas.

Equipo no superior a 6 ó 7 

Qué nos permiten

Mob-Programming/Testing y Swarming

• Alineación. Todo el equipo toma parte en el desarrollo.
• Reglas de codificación. Todo el equipo define normas de codificación y reglas de calidad de software.
• Aprendizaje, traspaso de conocimientos. Los programadores más junior aprenden más y mejor de los programadores más senior.
• Durante el desarrollo de esta técnica de trabajo se evitan reuniones de alineamiento, puesto que ya se está trabajando y desarrollando sobre la funcionalidad.
• Se evitan problemas de comunicación.
• Se evitan problemas de toma de decisiones, las toma el equipo al completo.

Clean Code

"Un Código limpio (Clean Code) siempre parece que lo escribió alguién que le importa. No hay nada obvio que puedes hacer para mejorarlo."

- Michael Feathers, autor del libro Working Effectively with Legacy code

Elegante, Eficiente, Directo,

Claro, Bien Escrito, Simple,

Tiene significado,

Auto-documentado,

Bonito ...

Clean Code: Boy Scout Rule

Curiosa regla con altas dosis de moralidad y profesionalidad aplicable a muchísimas profesiones y, como no, el desarrollo de software no es una excepción.

“deja el campamento más limpio de como te lo encontraste”

Clean Code: Teoría de las ventanas rotas

En criminología, la teoría de las ventanas rotas sostiene que mantener los entornos urbanos en buenas condiciones puede provocar una disminución del vandalismo y la reducción de las tasas de criminalidad.

Cómo aplica esto en desarrollo de Software?

El código incorrecto

es el principio del desastre.

Clean Code: Cómo medirlo?

Clean Code: Nombres

“Dar nombres a las cosas es una de las cosas mas dificiles de la profesión”.

Utilizar nombres que:

- Tengan sentido​​

- Sean claros y concretos de la responsabilidad que tiene

- Eviten la desinformación

- No contengas prefijos

- Se puedan pronunciar

- Se puedan buscar

- No estén codificados

.... 

Clean Code: Nombres

Clean Code: Funciones

● Pequeñas!

● Hacen una sola cosa!

● Se leen de arriba hacia abajo, como un libro

● Mínima cantidad de argumentos

● No tienen efectos alternos

– “checkPassword” no debería crear una sesión

● Capturar Excepciones sobre códigos de Error

● DRY

Clean Code: Funciones

Clean Code: Comentarios

1. Siempre explicar en el código.
2. No ser redundantes.
3. No agregar ruido.
4. No comentar el código sin uso. Mejor quitarlo.
5. Utilizar como explicación de la intención.
6. Utilizar como aclaración de código.
7. Utilizar como advertencia de consecuencias.

Clean Code: Formatting

1. Separate concepts vertically.
2. Related code should appear vertically dense.
3. Declare variables close to their usage.
4. Dependent functions should be close.
5. Similar functions should be close.
6. Place functions in the downward direction.
7. Keep lines short.
8. Don't use horizontal alignment.
9. Use white space to associate related things and disassociate weakly related.
10. Don't break indentation.

Clean Code: Deuda Técnica

El código se rompe en la presencia de cambio.

La deuda técnica = Defectos, complejidad, falta de testing, duplicidad... NO HAY QUE DEJARLA CRECER!

Clean Code: S.O.L.I.D.

Single Responsibility Principle (SRP)

Open-Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversión Principle (DIP)

Son cinco principios fundamentales, uno por cada letra, que hablan del diseño orientado a objetos en términos de la gestión de dependencias. Las dependencias entre unas clases y otras son las que hacen al código más frágil o más robusto y reutilizable.

https://uniwebsidad.com/libros/tdd/capitulo-7/principios-solid?from=librosweb ​

Code Metrics

• Complejidad ciclomática -mide la complejidad del código estructural. Se crea, calculando el número de rutas de acceso de código diferente en el flujo del programa.Un programa que tiene el flujo de control complejo requerirá más pruebas para lograr una buena cobertura de código y será más difícil de mantener.

• Profundidad de herencia -indica el número de definiciones de clase que se extienden a la raíz de la jerarquía de clases. La profundidad la jerarquía más difícil comprender donde se definen los campos y métodos determinados podría ser o / y ha vuelto a definir.

Code Metrics

• Acoplamiento de clases -mide el acoplamiento a las clases únicas a través de parámetros, variables locales, tipos de valor devuelto, llamadas a métodos, las creaciones de instancias genérica o de plantilla, clases base, implementaciones de interfaz, los campos definidos en los tipos externos, y decoración de atributo. Buen diseño de software dicta que deben tener alta cohesión y acoplamiento bajo los tipos y métodos. El significativo acoplamiento indica un diseño que es difícil reutilizar y mantener debido a sus interdependencias en otros tipos.

Code Metrics

• Líneas de código -indica el número aproximado de líneas del código.  Un número muy alto podría indicar que un tipo o método está intentando hacer demasiado trabajo y debe dividirse. También podría indicar que el tipo o método podría ser difícil de mantener.

Integración Continua

CI - Continuous Integration

La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas.

Continuous Delivery & Continuous Deployment

Herramientas

Libros

lopezm.marvin@gmail.com

https://www.linkedin.com/in/marvinlopez/