al curso teórico-práctico
Professional Scrum Developer
22 de febrero de 2019
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
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
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.
Criterios de aceptación Aviones
iteración
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 [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.
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.
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
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).
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.
Gana el equipo que construya la estructura más alta en 18 minutos y se sostenga sola.
Definition of Done
Agile Testing
Refactoring
Pair Programming / Swarming / Mob Programming-Testing
"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
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
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.
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.
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.
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
"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.
“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!
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
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.
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.
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.
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.
By Marvin López
Curso teórico-práctico basado en la certificación de Professional Scrum Developer de Scrum.org
