Introducci贸n

1

Lo que aprender谩s sobre DevOps con GitLab

2

驴Qu茅 es Devops?

3

El ciclo de vida del Devops

4

Introducci贸n a Gitlab

5

Gitlab vs Github

Administraci贸n

6

Autenticaci贸n

7

Grupos

8

Autorizaci贸n

9

Auditor铆a

10

Proyectos

Planificaci贸n

11

Tipos de desarrollo

12

Planificaci贸n en Gitlab-Issues

13

Planificaci贸n en Gitlab-Etiquetas

14

Planificaci贸n en Gitlab-Pesos

15

Planificaci贸n en Gitlab-Milestones

16

Planificaci贸n en Gitlab-Boards

17

Planificaci贸n en Gitlab-Service Desk

18

Planificaci贸n en Gitlab-Quick actions

Verificaci贸n

19

Inicializaci贸n del repositorio

20

Merge requests

21

Profundizando en Merge requests

22

Continuous Integration-CI

23

Gitlab CI

24

Automatizacion con GitLab Cl

25

Validacion de la configuracion con GitLab Cl

26

gitlab-ci.yml

27

Gitlab pages

28

Implementando Gitlab pages

29

驴Qu茅 es el Desarrollo 脕gil?

30

Gitlab autodevops

31

Implementando GitLab autodevops

32

Habilitando autodevops

Empaquetaci贸n

33

Gitlab container registry

34

Introducci贸n a contenedores

Seguridad

35

Introducci贸n a DevSecOps

36

Firmas de seguridad

37

Pruebas est谩ticas de seguridad

38

Escaneo de contenedores

39

Escaneo de dependencias

40

Pruebas din谩micas de seguridad

41

Gitlab security dashboard

Distribuci贸n

42

Continuous Delivery (CD)

43

Ambientes

44

Review apps

45

Estrategias de Distribuci贸n

46

Feature Flags

47

Rollback

Monitoreo

48

驴Por qu茅 monitorear?

49

M茅tricas de desempe帽o (performance metrics)

50

M茅tricas de salud (health metrics)

51

Metricas de equipo

52

Rastreo de errores

Conclusiones

53

驴Por qu茅 desarrollar con Gitlab?

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

0D
23H
33M
37S

Planificaci贸n en Gitlab-Pesos

14/53

Lectura

Uno de los puntos m谩s complejos del desarrollo de Software es la estimaci贸n. En esta clase me gustar铆a abordar qu茅 herramientas Gitlab nos ofrece para poder estimar la cantidad de trabajo que un issue requiere, qu茅 ventajas tiene agregar pesos a los issues y algunas de las buenas pr谩cticas relacionadas con este ejercicio.

...

Reg铆strate o inicia sesi贸n para leer el resto del contenido.

Aportes 31

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

En la empresa donde me encuentro actualmente, utilizamos mucho esta herramienta para la estimaci贸n de Scrum, sobretodo por que en muchos casos hay desarrolladores que no se encuentran fisicamente en la sala donde realizamos las reuniones, espero les sirva:
https://scrumpoker.online

No Confundir esfuerzo con tiempo.

El peso se refiere al esfuerzo requerido y de este modo podr铆a tambi茅n sugerir el tiempo que pueda requerirse, pero, el esfuerzo requerido tambi茅n depende de quien tenga a cargo el issue; un desarrollador junior podr铆a requerir m谩s tiempo que un desarrollador con m谩s experiencia. Como se podr铆a manejar este tipo de escenario?

Hay que aprender a planificar el esfuerzo.

Planning-poker

Super importante esta lectura, me qued贸 sonando lo de las tallas de las camisetas como sistema de estimaci贸n. Comparto esta otra lectura que tambi茅n me gust贸 https://eamodeorubio.wordpress.com/2011/05/16/estimacion-3-tecnicas-agiles/

En mi caso en varios equipos en los que he participado se realiza la definici贸n de un Pivote, una Historia de Usuario o Issue que todos conozcan muy bien y hayan solucionado. Se le asignan un peso y esta se utiliza como referencia para estimar el esfuerzo de los futuros Issues.

Yo les cuento que en unos procesos en los que aprend铆 algo de Scrum, nos mostraron apps como: 鈥淪crum Poker鈥 y 鈥淪crum Time鈥.
Muy interesantes por la posibilidad de definir las escalas o rangos a usar.

En mi experiencia, es una practica que va tomando sentido conforme se va desarrollando experiencia en varios proyectos.
De entre los cuales es posible obtener un factor comparador de scopes de acuerdo a la problem谩tica general a resolver, como saber que la integraci贸n con alg煤n servicio en particular suele ser una tarea compleja vs alguna otra como agregar una validaci贸n en un input.
En otras palabras, es posible acercarse a la realidad conforme se vaya recolectando patrones neuronales de resoluci贸n de issues. Lo cual har铆a que progresivamente seas mas eficiente en relacion a issues relacionados.

Pero no hay que confundir el esfuerzo con el tiempo

En la compa帽铆a donde estoy se usan esta metodolog铆a y es bastante eficiente. Existen algunos casos (muy pocos), en donde algunos desarrolladores lo que hacen es que se aprovechan de esto para a una tarea relativamente sencilla darle una complejidad alta, pero en general es muy buena pr谩ctica.

Lo del poker ayuda mucho cuando se integra personas con distintos niveles de conocimiento, en algunos casos ayuda a redefinir los equipos de trabajo.

Una de las cuestiones importantes a la hora de estimar y que por lo menos he visto poco en los equipos en los que estuve es que el SCRUM master no hace que el PO este presente en la planning. Para mi es importante ya que puede aclarar muchas dudas al momento de estimar o dudas de alguna feacture en particular.

Es muy 煤til la estimaci贸n. En donde trabajo lo usamos hace unos a帽os y ayuda much铆simo a ser m谩s objetivos y a no pensar por sobre el compa帽ero de trabajo subestimando o sobrestimando su capacidad de trabajo.

Las estimaciones, siempre son 煤tiles a la hora de entregar resultados, son las que te indican la velocidad de tu equipo

Al estimar usando poker planning, y asignar puntos historia, esto tambi茅n puede usarse para medir el progreso real del equipo en t茅rminos de trabajo realizado.

Ahora si se viene lo chido!

Es preciso tener buena base de comunicacion en el equipo para trasladar un sistema de estimaciones

Jajaj la idea del poker esta genial!

Venga que Agile anda en todo 馃槙 , pero que mas darle que si no duele no sirve

Gracias, no sabia que era el 鈥淓stimation poker鈥

No me queda claro el uso del peso, basados en este 驴vamos a definir el orden de ejecuci贸n de las tareas?, o 驴cual es su objeto?

驴Por qu茅 no se usa la estimaci贸n en horas de trabajo? o 驴este peso puede ser lo que uno quiera que sea en cada proyecto?

Siento que este tema merece un v铆deo y algunos ejemplos reales de uso.

Gracias

Con respecto a las estimaciones, hay varios puntos que puente generar grandes desviaciones para los puntos estimativos.

  1. La experiencia de los devs es importante. Un junior tardar铆a m谩s en resolver un problema que un semi-senior y a su vez que un senior.
  2. La cantidad de desarrolladores que intervienen en el proceso podr铆a complicar la repartici贸n de las tareas y la interacci贸n entre estos mismos.
  3. El tama帽o de desarrollo y construcci贸n de la tarea asignada. A veces se crea un Sprint que resulta muy cargado de procesos que engloban una tarea y conviene antes de crear un issue fraccionar en partes y luego reunir los procesos para dicho sprint.
  4. Los problemas que pueden surgir durante el desarrollo y la construcci贸n del software, que pueden crear bloqueos importantes en el progreso de los procesos y peor a煤n, si estos procesos son contiguos y correlativos los unos de los otros.

Mi cr铆tica:
Supongo que deben haber m谩s puntos. Una cosa que critico en茅rgicamente de Agile y Scrum, es que no poseen c谩lculos o determinaciones para obtener el 鈥渃amino cr铆tico鈥 durante un sprint. Tan solo los proyectos basados en Peart lo poseen mientras que Gann y otros no. El camino cr铆tico es ideal para corregir potenciales desviaciones en los progresos de los procesos de desarrollo. Es algo que veo que los ingenieros no resuelven o no pueden resolverlo con estos m茅todos.

Vi algo como esto en donde trabajo, pon铆an a los desarrolladores involucrados en una sala, las reglas eran evaluar del 1 al 10 la dificultad y considerar el estimado de tiempo que llevar铆a completar alg煤n modulo especifico o la integraci贸n de alg煤n servicio tercero, posterior a esto nos preguntaban porque elegimos el valor para ver nuestros puntos de vistas, en lo particular me dio gusto ya que hubo muy pocas discrepancias en el valor que eleg铆as vs el de tu colega, y en los casos donde hab铆a discrepancia muy notoria, nos deten铆amos, mostr谩bamos nuestra postura y volv铆amos a retomar esta pregunta para encontrar un equilibrio en el peso de la estimaci贸n del punto a desarrollar, me gusto ya que ves la perspectiva de la otra persona, te hace tener un panorama amplio y una proyecci贸n de lo que estar谩s desarrollando

Tener un Hist贸rico de esas estimaciones puede ser fuente para un control para siguientes issues

aprendiendo!

Este paso es de suma importancia. El equipo debe tener claro cu谩ntas horas / ingeniero equivale 1 peso o 鈥減unto de historia鈥.

lo de la estimaci贸n poker es muy utilizado en las metodologias agiles (scrum) y muy recomendable gracias por el aporte.

Gracias por el aporte. Son muy buenos tus consejos

La estimaci贸n de poker, es una buena forma en la que el equipo pueda realizar la estimaci贸n de los pesos de los issues.