Marvin López - Panamá
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
Certificaciones:
- Professional Scrum Master (Scrum.org)
- Professional Scrum Developer (Scrum.org)
- Professional Software Tester (istqb.org)
658675121
Computadora por participante para realizar el taller práctico Desarrollo de Aplicación Móvil de películas tipo Netflix
Introducción a Ágil y Scrum
Introducción a Ágil – Porque Ágil, Manifiesto Ágil, valores y principios ágiles
Mentalidad Ágil
Introducción a Scrum
Roles
Eventos
Backlog Refinement
Artefactos
Radiadores de información
Burndowns, Burnups y Cumulative Flow Charts
Impedimentos
Definición de Done (Hecho)
Escribe en un post-it y en una sola
oración, lo que piensas que es agilidad.
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 todas 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.
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Agile Mindset
Criterios de aceptación Aviones
iteración
Escribe en un post-it y en una sola
oración, lo que piensas que es Scrum.
Es un marco de trabajo (framework) a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor.
Es:
• Ligero
• Simple de entender
• Dificil de dominar
"NO es una metodología"
En equipos de 5 personas, cada equipo deberá crear su propio proceso de Scrum. Al final cada equipo deberá presentar al resto del grupo su resultado.
40 Min.
Inicio del Sprint
Fin del Sprint
Inicio del Sprint
Fin del Sprint
No es un evento o reunión “oficial” en Scrum… pero es muy típico usarla.
Radiadores
de
información
Burn-down chart
Cumulative flow diagram
Kanban o story board
Burn-up chart
Cualquier cosa que frene la velocidad del equipo Scrum e impida llegar al objetivo deseado del sprint.
Generalmente es algo que escapa del área de control del equipo, que requiere una búsqueda adicional de información, un análisis y una serie de acciones con otras personas fuera del equipo. Son una forma de desperdicio o “waste”.
"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
Cual seria el "Definition of Done" de tu equipo actualmente?
Definition of Done
- #######################
- #######################
- #######################
- #######################
- #######################
- #######################
- #######################
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
Pair Programming / Swarming / Mob Programming-Testing
El problema de la documentación
Porque la vida es
muy corta...
para escribir todo
No se maneja el cambio
La comunicación no llega correctamente.
Simplicity the art of maxmizing the amount of work not done is essential.
Business people and developers must work together daily during the project.
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.
Descripciones cortas de funcionalidades que nuestro cliente quisiera ver algún día en el software.
{VALOR}
Título
Descripción
(Qué se quiere lograr
y porqué)
Para quién
Qué
Por qué
Título
Como <tipo de usuario/rol>
Quiero <objetivo/funcionalidad>
Para <razón/beneficio>
Para quién
Qué
Por qué
Tarjeta(Card),
la Conversación (Conversation)
Confirmación (Confirmation).
Como usuario
Quiero que se muestre un carrusel
de imágenes que contenga las
imágenes de las Series de
TV POPULARES
Para poder navegar en toda
la lista fácilmente
Vamos a crear Historias de Usuario
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>
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
One Cookie = 10 sec
7 cookies = 10 sec x 7 = 70 Secs
14 cookies = 10 sec x 14 = Secs
Text
> x2 as big
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.
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:
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.
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
Gana el equipo que construya la estructura más alta en 18 minutos y se sostenga sola.
Arquitectura Emergente
Agile Testing
Refactoring
Como equipo seleccionemos:
Reglas:
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
Pirámide del Testing
El testing es
Pirámide del Testing
Cómo son las pruebas en tu proyecto? Explicar.
Qué está mal aquí?
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;
Ciclo de TDD
3 leyes de TDD:
"Cambiar la estructura del código sin cambiar su comportamiento"
La refactorización también es:
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.
https://www.codewars.com/kata/convert-boolean-values-to-strings-yes-or-no/train/dart
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.
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.
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.
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.
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
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:
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.
"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 ...
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”
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.
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.
“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
....
● 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
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!
Los distintos miembros de un equipo revisan de forma individual o en conjunto la implementación realizada por otro miembro.
Las reglas para revisar el código son establecidas por el equipo en conjunto.
Complejidad ciclomática
Profundidad de herencia
Acoplamiento de clases
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.
Objetivos
Pasos del
lopezm.marvin@gmail.com
https://www.linkedin.com/in/marvinlopez/
658675121
@marvlm
By Marvin López
Curso teórico-práctico basado en la certificación de Professional Scrum Developer de Scrum.org
