Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Wei-Yu

fortnite > pubg

de calle

Fyn4r

Ahora sólo quedan bots, por que creeis que juego?

El fortnite estaría guapo si no hubiese que construir, skins de mierda, fumadas, trampolines, granadas de no se que, un gunplay aleatorio

Wei-Yu

la construcción es lo que hace guay al fortnite; pegarte con alguien y empezar a hacer castillos entre los dos era una pasada

B

.

Lecherito

Yo prefiero el Warcraft 3

1
Fyn4r

Yo prefiero el Star Fox 64

eondev

Yo prefiero leetcode al toquw

X-Crim

Yo soy mas de shenmue

1 respuesta
r2d2rigo

#18535 tu no seras furro?

Kaledros

#18548 Mira que eres seguero, cabrón.

desu

@Wei-Yu

https://stackoverflow.blog/2020/12/07/measuring-developer-productivity/

Tengo una dude a Agile/Scrum/Soplapolladas.

Como le llamáis a poner la dificultad de una tarea una vez completada?

Yo conozco la bobada de "estimar" la dificultad/complejidad y luego ir completando tareas y pintas la velocity.

Como se le llama a hacerlo del revés? Completamos tareas y luego decimos cuanto nos han costado (en team effort / team hours obviamente).

3 respuestas
Wei-Yu

#18551 si no es un concepto para nada novedoso lo que estabas hablando, yo el problema lo tengo con parametrizar estimaciones de las que no sabes el margen de error porque te es imposible, además del razonamiento del desgaste según van pasando las horas de trabajo (que a veces sí funciona así y otras no). De hecho al final del artículo trae algo que es parecido a lo que pienso:

So it follows that you should only measure what you really, truly want—whether or not it can be drawn as a line graph. For some, it can be frustrating to do or manage work that can’t be reduced to a number. But with work as nuanced and abstract as software development, the further we entrench ourselves in details, the more we defeat our own purposes. Useful software is our goal, and we shouldn’t settle for (or measure) anything less.

Un ejemplo fácil donde articular lo que digo es el tema del pomodoro; esa media hora/veinte minutos/loquesea es una abstracción humana que impones sobre tu fisiología. Quizás te funcione a veces pero en última instancia tus mecanismos internos no entienden de minutos.

1 respuesta
Kaledros
#18551desu:

Como se le llama a hacerlo del revés?

Retrospective.

desu

#18552 El pomodoro siempre es una aproximación, si acabas antes descansas antes, si te alargas 10 minutos te alargas 10 minutos... Todos los métodos son aproximaciones XD

Sobre la estimaciones, los paquetes de trabajos forman un grupo y los puedes ordenar por complejidad.

Después tienes que priorizar y se te forma un gantt.

Si divides tus tareas en varios grados de complejidad, i.e 1, 2 y 3.

Con el tiempo de proyecto las tareas y los gantt no deben ser dificil de autogenerarse aplicando regresiones lineales y haciendo scheduling.

Todo esto teniendo en cuenta que la capacidad de un equipo es el mismo.

Idealmente tu creas un TO-DO le asignas un a complejidad y toda la planificación se debería hacer de manera automática. el único trabajo manual es de crear las tareas y las relaciones y una vez terminadas realizar correcciones.

1 respuesta
JuAn4k4

#18551 Time tracking, ¿no?

Yo siempre he visto a gente decir: story points es complejidad, no tiempo, y pasarte una tabla de story points = tiempo, royo 1sp = 1d, 2sp = 3d, etc..

A mi me encanta cuando los equipos se miden sus story points y luego se valora por el número ese, algunos equipos valorando 1-5sp casi todos, y otros 25-50sp, y te venían, oye que hacéis solo 50-100 a la semana, este equipo me hace 200-300.

Y todas las semanas un burra por el equipo que hizo 500sp.

2 respuestas
eondev

tardais más tiempo con todas esas gilipolleces que en poneros a hacerlo
#18555 xdddddddddddddddddddd

5 2 respuestas
desu

#18556 Exacto. Bien visto. Por esto debería ser completamente automatizado y solo alimentarse de feedback al terminar las tareas.

Sobre las estimaciones porque se quedan cortas normalmente:

1
JuAn4k4

#18556 Totalmente, he visto groomings discutir soplapolleces máximas y pegarse 1-2h para una historia de 2h. Claro luego justificaban estar 1 semana con ella.

1
desu

Yo lo que tendria es un Gantt dinámico donde se alimenta del backlog.

Defines "epics" de casos de uso para empezar, si queréis para mantener un poco el vocabulario familiar.

Y dentro de las epics vas generando sub tareas que puedes etiquetar por complejidad.

Terminas una tarea, si hace falta cambias su complejidad o la divides en subtareas que has realizado, y añades los tiempos reales.

Siempre complejidad <=> Tiempo.

Y manteniendo un grupo ordenado/parcial ordenado.

De esta manera estas metiendo "puntos" para tu modelo predictivo.

Conforme crece el dataset las estimaciones serán más accurate.

Esto existe?


#18555 Aquí no se mantiene el orden entre equipos, es decir.

10sp equipo 1 > 50sp equipo 2.

Lo he explicado arriba.

La propiedad de orden NO se puede romper nunca.

1 respuesta
neil90

#18559 Eso lo hace Jira

1 respuesta
B

A vosotros tambien os pasa que para tener acceso al kibana de producción teneis que llamar por telefono al equipo IT para que os den las credenciales? Y que además expiran cada mes?

Me gustaría mandarlos a la mierda, compartiendoles algun artículo donde se exponga la terrible idea de hacer eso y que no tiene ningún sentido. Alguna sugerencia?

4 respuestas
neil90

#18561 https://www.elastic.co/guide/en/elasticsearch/reference/current/ldap-realm.html

Si es una instancia del servicio administrado de AWS, Cognito + SSO

1 1 respuesta
desu

#18560 Tal y como yo lo he contado? Con predicción, solo basado en complejidad y duración por complejidad?

A ver pásame link.

Sino es un side project que quizás hago.

Para github había extensiones del estilo pero no hacían esto. Para gitlab no me suena.

#18561 No me pasa con kibana pero si con muchas cosas de infraestrctura. Quejate a tu jefe razonandole la cantidad de HORAS que estas perdiendo. No puedes hacer mucho mas al ser otro equipo.

1 3 respuestas
eondev

#18563 #18561 pues a dormir la siesta o a pasear con el perro y a esperar a que os den acceso

B

#18561 Lo que dice Desu, el sueldo de un developer es alto, y no hay nada más que joda a tu jefe que las horas muertas

2 respuestas
B

#18562 para que te hagas una idea del pifostio que tienen montado, el acceso además solo funciona a través de una maquina virtual remota + vpn

#18563 #18565 ya lo he hecho pero los de IT es por parte del cliente, asi que no tenemos mucho poder tampoco... Lo que sí haré es imputar las horas que pierdo con ésta mierda

1 respuesta
Zoko
  • "Arrancamos" sprint el Lunes, los tickets a medio hacer pero era necesario arrancar porque si.
  • Hasta el Martes por la tarde no se acaban de definir los tickets y se cambia la feature 2/3 veces.
  • No se mueve la fecha de finalización del sprint ni se recorta en número de tickets para hacer.
  • Llega el Viernes y todavia faltan la mitad de tickets por empezar, ya no hablo siquiera de testear todo bien.
  • El PO no entiende que ha podido pasar.

Todavía se sorprenderán de por qué he decidido irme de la empresa JAJAJ

1 respuesta
desu
#18565vago_21:

el sueldo de un developer es alto

1 1 respuesta
eondev

#18567 tu estabas currando para una empresa de suiza no? o era otro zorro? xD

1 respuesta
B

#18568 No todos obviamente, pero mi jefe cobra mi hora a 70 euros, cada minuto que estoy parado flipas como se pone

EDIT: no a todos los clientes obviamente, pero nunca menos de 50

1 respuesta

Usuarios habituales