/tech/ - Tech 2.0

Mode: Reply
Name
Subject
Message

Max message length: 4096

Opciones
Files
E-mail
Password

(used to delete files and postings)

Misc

Remember to follow the rules


Choroy 08/25/2024 (Sun) 08:21:57 80fe0c No. 14150
estoy estudiando materia relacionada al manejo de equipos en TI y aparecen estas (((metodologías))) que supuestamente es para mejorar la ruta de creación del producto pregunta para los choroyes 3 palos: que tan cierto es esto? recomiendan perder tiempo estudiando sobre esto o voy directo a aprender habilidades con las que pueda hacer cosas? siempre que he tenido la oportunidad de trabajar en equipo no seguimos ninguna metodologia con nombre anglófilo y solamente creamos una aplicación, vemos si funciona, corregimos errores, la subimos, seguimos corregiendo errores, etc, hasta que finalmente funciona y nunca mas la tocamos porque si no esta roto para que arreglarla
Deberías aprenderlas solo como conocimiento general. Tratar de llevar todas estas practicas a la realidad es poco factible. Somos personas, nos podemos sentir cansados, estresados, enojados, tristes, etc entonces no estaremos al 100% todos los días. Tiene cosas buenas, como lo de tener documentadas las tareas y saber en lo que está el equipo, sirve bastante para "tratar" de evitar el exceso de reuniones. Y poder levantar rápidamente los problemas, antes de se conviertan en bolas de nieve antes de la entrega. En resumen, es como todo en la vida, tiene cosas buena y malas. Debes adaptarlas a tus necesidades.
>>14150 Apenas se aplican al mundo laboral, pero decir que los vas a hacer le proyecto del cliente de forma ágil les da seguridad. Si sirve para saber como trabajar un proyecto y como ordenar tares, para cuando tú líderes un equipo puedas hacerlo mejor que los dinosaurios que programan y arreglan en la marcha usando lo que aprendiste de desarrollo ágil (existen más metodologías ágiles que Scrum, debes desbloquearlas).
644.30 KB, 855x855
>siempre que he tenido la oportunidad de trabajar en equipo no seguimos ninguna metodologia con nombre anglófilo y solamente creamos una aplicación, vemos si funciona, corregimos errores, la subimos, seguimos corregiendo errores, etc, hasta que finalmente funciona y nunca mas la tocamos porque si no esta roto para que arreglarla El flujo de trabajo es correcto, ahora lo que aprenderas con estas metodologias es pulir este flujo de trabajo. Lo interesante es que segun lo que cuentas ya tienen el objetivo fundamental: alcanzar Kaizen, la idea de mejora continua, pero ustedes simplemente deciden no ir mas alla porque no tienen la necesidad. Sin embargo, el ciclo de vida productivo industrial sigue en ese flujo entregando un producto cada vez mas refinado y en constante evolucion, cuyo desarrollo esta, en teoria, determinado por el mercado. Agile (y la metodologia mas usada de esa escuela de pensamiento, Scrum) plantea paso a paso como lograr de forma profesional eso mismo que estas logrando ahora, pero sin la necesidad de que estes trabajando con una cuadrilla conformada por tu equipo regular. Me explico, con Agile Scrum, podras obtener los mismos resultados con cualquier persona que se sume a tu equipo. Ese es el objetivo principal. Lograr profesionales altamente capacitados que pueden ser introducidos en cualquier proyecto y con la habilidad de lograr cualquier tarea (historia en el glosario Scrum) que el proyecto necesite. Piensalo en el sentido de que el desarrollo de software fue modelado de la misma forma que las lineas de produccion vehiculares de Ford (Assembly Line™) y Toyota (Production System™), por esa razon todas estas escuelas de pensamiento sobre como lograr la mayor productividad posible. Scrum es lo que se usa. La vieja escuela opera por metodologia de cascada (carta Gantt) y hay algunas personas en el IB que trabajan en estos equipos. Piensa que en lugar de seguir a la industria automotriz como referencia, ellos usan la metodologia de trabajo de las empresas inmobiliarias y proyectos de ingenieria dura. Se podria decir que Scrum es la forma recomendada de producir software, sin embargo, tambien debe respetarse la metodologia de los chilenos ancianos de bien, ya que la mayoria de los proyectos que operan en cascada son parte de Operadores de Importancia Vital y Proveedores de Servicios Esenciales. Consejo? Aprende las ceremonias scrum. La daily, la retro, el capacity planning y el grooming. De lo que si te daras cuenta es que muchos equipos llaman a estas ceremonias de distinta forma, por ejemplo, a la daily le dicen el Stand Up y ahi cuando recien entras te zamarrea un poco la nomenclatura, pero cosas como scrum poker son practicamente universales y no se prestan para mayor confusion.
>>14153 un compa trabajaba en una empresa donde todos los dias tenian que hacer "la deily" y se le rajaba el ano porque eran siempre las mismas preguntas, las reuniones se alargaban y se perdia tiempo que podia dedicarse a seguir programando la aplicacion. terminando odiando scrum con el alma
No sé, aun no gano 3 palos y me queda poco para salir, pero ya pasé ese ramo.
¿Es normal que hagan daily en la noche? Me quiero matar
>>14150 a los scrum masters les pagan bien por simplemente ir a reuniones y manejar grupos de gente. >>14153 >la vieja escuela opera por metodologia de cascada (carta Gantt) los agiles también las ocupan pero para presentarle al cliente las entregas. Lo que ocurre dentro de los sprints no lo detallamos en las planificaciones. >>14154 Ahi es porque el scrum master, el jefe de proyecto o quien sea que está a cargo no mantiene el ritmo de la reunión o se deja llevar por detalles. Ahí lo que hacemos es liberar al resto del equipo que está bien con sus avances y quedarte con quienes puedan estar en problemas.
408.83 KB, 952x1024
>Lean >Agile >Scrum >El culto religioso alrededor No gastes tiempo en eso. Revísalo bien superficialmente, porque es mayormente venta de humo. Yo mismo empleo técnicas similares de venta de humo y logro triunfar, porque mezclo mi conocimiento superficial en Scrum, Agile y Lean con palabras complejas (metaobservabilidad, postmonitoreo, supramétricas), que dejan contentos a los mandos altos. Lo que sí te recomiendo es: >Mejora tus habilidades para resolver problemas >Mejora tu vocabulario, particularmente con prefijos griegos (permite vender mucho humo) >Mejora tu entrega de productos, tanto en calidad como en tiempo Lean, Agile y Scrum sirven para hacer una bonita pantomima ante quienes se denominan sus practicantes y lo peor, es que los hueones te creen cuando les hablas huevadas que inventas en el acto. Si quieres una lectura buena sobre gestión de proyectos informáticos, opta por: >The Mythical Man-Month, de Fred Brooks >The Soul of a New Machine, de Tracy Kidder >The Practice of Programming, de Kernighan & Pike
>>14163 >porque es mayormente venta de humo. kek, mientras estaba estudiando scrum me daba cuenta de que era un set gigante de "lenguaje exitoso"
>>14164 Es que tenis que saber hacerla pos papito.
>>14163 Por experiencia, uno piensa que es venta de humo hasta que trabaja en un lugar donde no existe ninguna metodología, uno no ve lo que previene y estas metodologías previenen hartos dolores de cabeza igual las empresas no las aplican y venden humo, la guía Scrum se actualizó y es mucho menos permisiva, por eso, catalogando que si no aplican cosas como roles o historias de usuario no es Scrum ni ágil
>>14164 Piensa que eso es la interfaz del jefe de proyecto con el ingeco, que no entiende que cuando los autistas estan pegados tipeando estan trabajando, al contrlario de ellos que son puro blabla todo el dia.
>>14185 Lo que mencioné en >>14163 también lo digo por experiencia. Mayormente, porque si quitas toda la faramalla, te das cuenta que igual se está trabajando con waterfall, pero con ciclos más cortos y metas menos ambiciosas (respecto a que no entregas un producto completo, sino que vas iterando con él).

Delete
Report