Ver la versión completa : Otros Engines Utilidad del scrum
Holas,
No se si este post pinta aqui o seria mejor para el offtopic...
Anyways. Queria preguntar al resto que utilidad le veis al scrum porque tras 2 semanas solo me parece una perdida de tiempo total, y con tanto rollo de ser productivo y tanta parida no veo en que me ayuda a mi el scrum.
Tal vez lo hagamos mal donde trabajo pero aqui la cosa va asi:
-Cada mañana 15-20 minutos para que cada uno cuente que tarea esta haciendo, si le esta costando, etc, si esta completada la movemos al "done", (tenemos el trello abierto en un proyector) y si no pues nada sigue en el "doing"
Dado que donde trabajo somos 2 grafistas, 1 programador, 1 game designer y el jefe que se encarga de la historia y tal. Yo me pregunto, ¿que necesidad tengo de saber si fulanito esta dibujando los arboles cuando el tema me la pela muy mucho?, y lo mismo le pasará a el, no creo que le importe mucho saber si estoy haciendo un sistema de management u optimizando shaders...
No quiero parecer un despegado o un viva la vida, trato de analizar que me faltan horas al dia (para terminar el proyecto on time and budget) y no veo en que me ayuda a mi saber que hace el musico, o el grafista, o el guionista. Y no veo que perder 15-20 minutos al dia me ayuden a ser mas eficiente.
Si necesito una de sus tareas solo tengo que mirar el trello/basecamp/whatever, ver quien la hace y preguntarle para cuando la tendrá, sin tener que tragarme todos los dias el "que hace cada uno y como le va".
Efectivamente, ya que me trago el scrum no necesito preguntarle a nadie, ya se que hacen y cuando piensan terminar la tarea, asi que si necesito graficos ya se para cuando los tendré.
¿Soy muy rarito o perder el tiempo es el no va más en las empresas? xD
Una de las ventajas princiaples de Scrum es su metodológia Agil. Digamos, que es un framework que te da una serie de herramientas que vienen bien para proyectos que no son estáticos. Por estático me refiero a que pueden ir cambiando en el tiempo. Un video juego entra dentro de este campo.
Al final, lo que a mí me gusta más de este tipo de metodologías es que no te hacen pensar mucho más allá de 1 o 2 sprint y que ponen el foco muy claramente en el objetivo a corto plazo. A parte, te permiten llegado a ese objetivo tomar nuevas decisiones a un nuevo corto plazo para llegar al siguiente, etc...
De la forma que yo he usado Scrum no ha sido para saber que hacen mis compañeros, sino, como he dicho, para sincronizar a mi equipo en pos de llegar a un punto x. Así sabemos que cuando llegamos a ese punto vamos a tener una o varias funcionlidades hechas que nos va a permitir ver más claramente hacia donde nos tenemos que mover en el siguiente sprint.
El tema de las reuniones, etc... yo no lo he hecho, y si alguna vez lo hemos hecho ha sido 1 vez a la semana. Recordar que scrum es un framework y cada uno hace las cosas como le sale del popo.
El otro tema importante de scrum es que hay una serie de roles que entre otras cosas separan al equipo de producción de los politiqueos (Scrum Master) y además dan un punto de comunicación entre la empresa (Product manager) y el productor/inversor. El Scrum Master se dedica a que la atención de los hard-workes no se desvie del objetivo marcado y no haya distracciones. Por otro lado, el Product manager se encarga de extraer requerimientos, etc. del cliente, a parte de llevarlo al huerto :D, librando así al resto de equipo de estos quehaceres.
Un saludo.
Te digo lo mismo que le dije a un colega este finde. El scrum es una herramientas para los mánagers, no para los desarrolladores. Ellos tienen que tener sus métricas, sus horas, predicciones, planes a medio plazo, prioridades de los clientes, costes, gente a la que llevar, intentar limar asperezas en el proceso. Ninguna empresa te va a dejar suelto y sin medir (excepto startups de < 5 ingenieros), y el hacer waterfalls cada 2 semanas es la forma menos disruptiva que idearon en los 90.
Echa tus mitines, di las horas que te ha llevado la tarea, da estimaciones sabiendo que se van a revisar cada semana, y dedica el resto del día a hacer lo que mejor sabes sin que te molesten.
¿Soy muy rarito o perder el tiempo es el no va más en las empresas? xDNo te haces ni idea. Es el Heisenberg de la productividad: en cuanto intentas medirla, cae en picado. Pero no medirla no es una opción.
-----Actualizado-----
Maomeno lo que cuenta esta historia: http://mikehadlow.blogspot.cl/2014/06/heisenberg-developers.html
Estopero
11/02/2016, 08:23
En mi opinión, scrum es una herramienta para maximizar la productividad y que además funciona al menos a corto o medio plazo.
Sin embargo en mi opinión también, scrum es una metodología que solo debería usarse en equipos o departamentos donde se tienen fechas de entrega muy exigentes y principalmente donde existe mucha rotación y no se puede llegar a establecer una relación de confianza con los empleados.
En muchas ocasiones acaba siendo una excusa para managers autoritarios que quieren controlar y presionar diariamente a su equipo, lo que puede suponer al final una generación de stress que a la larga generará perjuicios y que precisamente incentivan esa rotación, entiéndase "rotación" como un eufemismo de "empleados que acaban hasta las narices"
Yo creo que con un buen sistema de gestión de tareas, llámese trello, redmine, jira, asana,.... Y una o dos reuniones semanales de seguimiento es suficiente para que un equipo conozca el estado del proyecto y se eviten atascos.
Eso sí, hay scrum masters que saben muy bien lo que hacen y son capaces de utilizar la herramienta correctamente y no generar demasiado stress añadido, pero en mi opinión no son muchos.
Echa tus mitines, di las horas que te ha llevado la tarea, da estimaciones sabiendo que se van a revisar cada semana, y dedica el resto del día a hacer lo que mejor sabes sin que te molesten.
No te haces ni idea. Es el Heisenberg de la productividad: en cuanto intentas medirla, cae en picado. Pero no medirla no es una opción.
Por no perder tiempo entiendase que yo le planteo a la empresa la cosa de "podia trabajar desde casa..." "uyyyyy no ni de blas, tienes que venir aqui porque se mejora la comunicacion, te hacemos perder el tiempo con reuniones que no valen para nada y la gente esta todo el dia hablando en la empresa y molestando", es un paquete que nadie puede rechazar xDDD
Pero ehhhh ven a la empresa que asi eres mas productivo.... pues entre el scrum y las tipicas "mierdas de empresa" no veo yo productividad ninguna xD .Obviamente como habeis comentado supongo que segun para qué o segun el punto del proyecto pueda ser interesante. De momento mi experiencia es que ni fu ni fa [Ahhh]
Las reuniones diarias no sirven para contar qué has hecho y qué vas a hacer, eso es un añadido útil sólo para equipos con roles muy similares. El objetivo de las reuniones es evitar bloqueos y mover las dependencias, eso es lo primero (y casi lo único) que se debe decir en una reunión diaria.
Si tu trabajo nada tiene que ver con el de un compañero, es decir, en tu equipo no existen roles rotativos (menos, quizás, scrum o PO) si no que 1 persona únicamente desempeña un rol, ni es ágil, ni es scrum y es un waterfall de libro. Los miembros de un equipo ágil, scrum, o lo que quieras, en mi opinión, deberían ser intercambiables. Así que efectivamente vuestras reuniones diarias son una pérdida de tiempo.
El resto de cosas de la metodología como refinamiento, planning y retro son elementos Scrum que pueden tener valor o no para un equipo, pero no siempre lo tienen, para mi la más importante es la planning, las otras ya es cosa vuestra; yo por ejemplo lo que mas valoro de Scrum y Kanban es la priorización clara de las historias.
Desde luego si una metodología se interpone en el mejor rendimiento de un equipo, entonces lo estáis haciendo mal y deberíais plantearos ir hacia lo que os dicte el sentido común.
Venía a decir lo mismo que amkam, si en tu equipo cada uno desempeña un trabajo que sólo puede hacer él, no acabo de ver claro que scrum os sirva de nada, más allá de saber si vais bien de tiempo o no, además como te comentan, las reuniones diarias no son para explicar tu vida y problemas, si no para decir si vas bien o mal.
A nosotros nos funciona muy bien porque todo el equipo podemos hacer prácticamente todas las faenas, incluso si hay algún problema que sabemos que va a afectar a algún compañero pues también lo comentamos. Pero la mejor parte para nosotros es el sprint planning, porque así todos tenemos una visión muy clara de lo que se tiene que hacer y como. También decir que nosotros lo aplicamos un poco a nuestra conveniencia ya que a veces nos piden cambios a medio desarrollo y eso en principio scrum no lo permite, pero en nuestro proyecto, por desgracia, es así...
^MiSaTo^
11/02/2016, 10:36
Yo quiero añadir que no se vosotros pero yo si tengo visión de "equipo" en el proyecto en el que estoy. A lo mejor estoy yo sola programando y hay un diseñador pero a mi SI me interesa saber qué hace el diseñador porque así se si está muy ocupado, o cuando va a tener las assets que necesito, etc.
Yo las reuniones de por la mañana las uso para tener una visión de cómo va la sprint para todo el equipo. Es más a veces voy a las del otro equipo por ver si necesitan ayuda o lo que sea y por saber qué están haciendo y tener una visión global del sprint (somos 2 equipos para entregar cosas en 1 sprint).
A mi no me la pela lo que hagan las otras disciplinas, al contrario. Es más lo mismo están atrancados con algo y por eso no tienen listo algo que les he pedido yo. Pues eso quiero saberlo y con las reuniones de por la mañana puedo ver también la progresión.
No se, yo llevo usando scrum durante 6 años ya y no es perfecto pero es la metodología que mejor me ha funcionado en proyectos gordos con clientes como bancos, supermercados, telecos tochas, etc (que no son fáciles precisamente tampoco).
Como dicen por ahí arriba muy bien si estás en un proyecto y toda la gente está en la misma oficina. En estudios, agencias, o consultoras por ejemplo, donde hay un par de equipos por cliente/producto. Yo no he tenido tanta suerte y en varias empresas he caído en grupos donde era el "chico Android" trabajando en tickets o productos distintos que los del resto de mi equipo, teniendo que localizar (yo o el PM) a diseñadores y gente de servidor de otros departamentos en distintas zonas horarias.
Por eso soy un poco escéptico de aplicar agile/waterfall/cualquier metodología a todos los proyectos. Y de hacer estimaciones a bocajarro ya ni hablamos xD
^MiSaTo^
11/02/2016, 13:19
Como dicen por ahí arriba muy bien si estás en un proyecto y toda la gente está en la misma oficina. En estudios, agencias, o consultoras por ejemplo, donde hay un par de equipos por cliente/producto. Yo no he tenido tanta suerte y en varias empresas he caído en grupos donde era el "chico Android" trabajando en tickets o productos distintos que los del resto de mi equipo, teniendo que localizar (yo o el PM) a diseñadores y gente de servidor de otros departamentos en distintas zonas horarias.
Por eso soy un poco escéptico de aplicar agile/waterfall/cualquier metodología a todos los proyectos. Y de hacer estimaciones a bocajarro ya ni hablamos xD
Si estás en una empresa carnicera sin ninguna organización vas a trabajar en como diga el cliente y ya.
Si no es el caso, entonces puedes usar metodologías agiles. Waterfal es lo que se suele usar por defecto (seguramente es lo que uses)
Si estás en una empresa carnicera sin ninguna organización vas a trabajar en como diga el cliente y ya.
Si no es el caso, entonces puedes usar metodologías agiles. Waterfal es lo que se suele usar por defecto (seguramente es lo que uses)
En los casos que estoy pensando no hay cliente, y creo que en eso nuestras experiencias difieren. La empresa no es carnicera, sólo tiene otra estructura porque el trabajo es distinto porque somos nuestro propio cliente.
En la empresa actual tenemos varias versiones del mismo producto en web, ios, y android, y >100 ingenieros repartidos en 25+ equipos cada uno con distintas tareas: librerías, automatización, nuevas features, scaling... Cada equipo tiene una feature o un par, pero en Android, como somos sólo 5 en toda la empresa, mis tareas requieren gente de servidor de otros equipos, y estoy ayudando a otros equipos cuando sus features tienen un problema/necesidad pero no tienen gente de Android.
En la otra empresa teníamos 4-5 mega productos, y los mismos de servidor trabajaban en una o dos a la vez que en la API que tu necesitas. Su tarea era tener un conjunto de APIs disponibles, y los de producto teníamos que ir a pedirles arreglos o novedades, pero ellos estaban en su propio scrum siendo nosotros su cliente.
En ambos casos hacer una medición de las tareas que voy a poder completar una semana, sin conocimiento del api o diseño detrás del tiquet, es complicado. Y medir mi productividad cuando voy cambiando de contexto de un día para otro lo hace aun más complicado. Me han dicho que me van a estabilizar en una feature, pero tampoco es que sea yo de asentar el culo y voy a seguir ayudando con tickets de infrastructura y demás.
^MiSaTo^
11/02/2016, 13:37
En los casos que estoy pensando no hay cliente, y creo que en eso nuestras experiencias difieren. La empresa no es carnicera, sólo tiene otra estructura porque el trabajo es distinto.
En la empresa actual tenemos varias versiones del mismo producto en web, ios, y android, y >100 ingenieros repartidos en 25+ equipos cada uno con distintas tareas: librerías, automatización, nuevas features, scaling... Cada equipo tiene una feature o un par, pero en Android como somos sólo 5 en toda la empresa mis tareas requieren gente de servidor de otros equipos, y estoy ayudando a otros equipos cuando sus features tienen un problema pero no tienen gente de Android en su equipo.
En la otra empresa teníamos 4-5 mega productos, y los mismos de servidor trabajaban en una o dos a la vez que en la API que tu necesitas. Su tarea era tener un conjunto de APIs disponibles, y los de producto teníamos que ir a pedirles arreglos o novedades, pero ellos estaban en su propio scrum siendo nosotros su cliente.
En ambos casos hacer una medición de las tareas que voy a poder completar una semana, sin conocimiento del api o diseño detrás del tiquet, es complicado. Y medir mi productividad cuando voy cambiando de contexto de un día para otro lo hace aun más complicado.
Tu caso es algo distinto sí pero en mi empresa salvo el proyecto en el que estoy ahora y otro tampoco tenemos cliente. Tenemos un producto propio tb en varias plataformas desde hace años ;)
Los equipos de features y demás nunca son más de 4-5 devs. Apostamos más por equipos pequeños pero siempre se usa scrum tanto en los dos proyectos que tienen cliente (que son MUY grandes y la rotacion de gente es alta porque acabas hasta la hueva de los clientes pijoteros) como en los de nuestro producto.
Aún así creo que es tb la mentalidad que se tenga en la empresa y demás. Yo curro muchas veces sentada con el diseñador para hacer una funcionalidad juntos, como si fuera pair programming pero con otra disciplina.
Pero we, creo que en las empresas que has estado tú tb son distintas
A escalas pequeñas se trabaja bien, si que he caído en un proyecto de esos y es la gloria, pero para mi han sido la excepción. Si me hubiera ido de cowboy developer o de agencias cuando estaba buscando las curro alomejor habría caído en otras estructuras. También llevo muchos años menos trabajados que tu, asi que aun queda para alcanzaros.
IronArthur
11/02/2016, 13:43
Yo solo veo beneficios a usar Scrum para un proyecto si:
Hay un cliente que vea los cambios y pueda dar feedback
El proyecto tiene un cierto tamaño, en uno pequeño es absurdo.
Salu2
^MiSaTo^
11/02/2016, 14:00
A escalas pequeñas se trabaja bien, si que he caído en un proyecto de esos y es la gloria, pero para mi han sido la excepción. Si me hubiera ido de cowboy developer o de agencias cuando estaba buscando las curro alomejor habría caído en otras estructuras. También llevo muchos años menos trabajados que tu, asi que aun queda para alcanzaros.
También sabes que en España no he currado así nunca xD Cuando tenía yo la empresa lo empezamos a usar como un año antes de venir aquí a Holanda y nos gustó la idea. Al venir aquí vi que todo dios lo usa y que yo no estaba aplicando scrum bien bien, sólo algunas cosas. No me gusta seguir normas a rajatabla pero tb he visto en estos 6 años que o se siguen o no funciona bien tampoco.
Yo solo veo beneficios a usar Scrum para un proyecto si:
Hay un cliente que vea los cambios y pueda dar feedback
El proyecto tiene un cierto tamaño, en uno pequeño es absurdo.
Salu2
Como he dicho en este tiempo he currado en los 2 casos opuestos que tú dices xD En un proyecto que no tiene cliente y en proyectos pequeños rollo una mini app de un festival que estaba hecha en mes y medio.
Lo que no se ahora, pero hace unos años no me parece que Scrum estuviera muy implantado en España. Lo que he visto por comentarios de compis programadores es que usan ciertas cosas de scrum pero no se siguen las normas y así os aseguro que tampoco funciona bien en todos los casos. Luego tb he visto en muchiiiisimos casos comentarios como los de Eskema y demás, que la gente no quiere usar esta metodología. Lo cual no es malo, me parece muy respetable, pero si tú ya no estás por la labor pues es obvio que no va a salir bien xD
Lo mejor es no usar nada de esto, llegas y te poner a escribir código, despues te preguntan que cuando esta listo y les preguntas el que, lo que estabas haciendo ayer o lo que estas haciendo ahora porque lo de ayer no vale porque alguien dice que no se hace así.
Os pagan por estar 8h escribiendo codigo sin parar, da igual si mañana lo tienes que borrar y empezar de cero, para eso os pagan.
XDXDXDXD
Ya molaría que pagaran por 8h picando código, pero nada más allá. Hay reuniones de producto, de arquitectura, revisiones de código, sesiones de testeo, mitines de planificación del sprint, colaboración con el diseño, dar y recibir cursillos...
En un buen día haces cinco horas. En uno malo, una o dos como mucho.
Y nos pagan por el lote completo.
Scrum en equipos de menos de 5 personas en la misma oficina === no ayuda mucho mas que para obtener metricas y tener conocimiento del proyecto.
Scrum en equipos de 5 o mas personas distribuidas === es imposible trabajar en equipo sin hacer un control de tareas, sin saber si estas bloqueado porque no sabes solucionar algo, o si tienes dependencias/pendientes de tus compañeros, clientes, patners o third parties.
De todas formas abrir el board en el daily me parece un scrum mal llevado, cada uno tiene que ser responsable de sus tareas, saber moverlas, saber hacer ping a su PM o lead para que le ayuden.
Las dailies deberian de ser solo para las cosas que se salen de lo normal, igual que los postmortem, las planificaciones, estimaciones, etc.
Saludos
Hay reuniones de producto
Ok, para hacerse pajas mentales de lo que se va a hacer.
de arquitectura
No
revisiones de código
:lol:
sesiones de testeo
No, el programador es el que prueba la aplicacion
mitines de planificación del sprint
¿planificacion? ¿sprint? WTF!?!?
colaboración con el diseño
No, lone coder aunque en la empresa sean varios.
dar y recibir cursillos...
Ok, hay que enseñar como va la aplicación a los posibles clientes, recibir cursillos NO.
Para saber si puedes aplicar Scrum bien en un equipo en cualquier empresa:
- Tienes un equipo multidisciplinar con personas que están dispuestas e interesadas en adoptar otros roles.
- Los miembros del equipo tienen tendencia a ser autoorganizados.
- No hay leader(ships), arquitectos, ni ***** mierdas de esas; hay gente que sabe más de unas cosas y otras de otras y todos están dispuestos a ayudarse mutuamente.
- Saben que un framework agile no sólo sirve para entregar producto, si no para mejorar la calidad laboral de todo el mundo.
- No hay multiplicidad de dueños de producto (PO). Sólo hay uno y es el que canaliza los requisitos de negocio.
- Si estáis empezando: Contáis con la ayuda de un facilitador (Scrum Master).
- El equipo comprende qué es un backlog y cómo puede ayudarles a realizar su trabajo.
- Todo el mundo se compromete a respetar el sprint, y no se altera hasta que termina. Salvo ciertas excepciones.
- Entienden que Scrum es un framework con un objetivo "oculto", generar métricas. Que no siempre va a mejorar el rendimiento del equipo.
Cuando una empresa no puede garantizar al menos todos menos uno de esos puntos, lo mejor es que sigan como están y que no probablemente acaben culpando a Scrum, sus herramientas o cualquier perogruyada de que les vaya mal un proyecto.
Al final scrum es como un puticlub... xD
Un saludo.
Yo quiero añadir que no se vosotros pero yo si tengo visión de "equipo" en el proyecto en el que estoy. A lo mejor estoy yo sola programando y hay un diseñador pero a mi SI me interesa saber qué hace el diseñador porque así se si está muy ocupado, o cuando va a tener las assets que necesito, etc.
A mi no me la pela lo que hagan las otras disciplinas, al contrario. Es más lo mismo están atrancados con algo y por eso no tienen listo algo que les he pedido yo. Pues eso quiero saberlo y con las reuniones de por la mañana puedo ver también la progresión.
Tu lo que pasa es que eres una cotilla, que es muy diferente!!! xDDDDD
Coñas aparte a mi dado que trabajo solo, no me importa que hace el grafista porque NO le puedo ayudar, no tengo ni zorra de graficos. Y lo mismo con el musico, no se de musica asi que no le puedo ayudar si se atasca.
Asi que si se atasca cualquiera lo logico es que se lo diga al jefe para que contrate alguien mas de apoyo, para que se cambien los plazos o lo que sea, pero a mi productivo no me lo parece el que yo sepa eso. Porque viendo en trello su tarea le puedo preguntar para cuando estima que estará lista y no que cada dia diga, "sigo dibujando los arboles" hasta que por fin "los termine anoche hoy voy a empezar la tarea X"
Como han dicho por ahi si fueramos todos que hacemos de todo pues estaria bien porque puedes tirarle una mano a quien sea.
Solo sirve para dar un boost en plan, "fijate teniamos 1000 tareas para hacer este juego y cada dia casi completamos alguna, estamos mas cerca de terminar", pues fueno pues fale....
Y ojo que yo no voy con la cosa de "no me gusta esto", me lo han presentado y me han dicho eso de "aqui gastamos scrum que es la caña". Yo acudo a mi reunion diaria, llevo 2 semanas y tras estas 2 semanas evaluo el sistema y en mi caso concreto le veo utilidad 0% para un equipo donde cada persona hace 1 cosa y somos 5 en total.
Leyendo lo que dicen otros veo que en determinados equipos y trabajos puede ser muy util :)
Ser la caña a estas alturas es usar kanban (https://www.atlassian.com/agile/kanban/) o "scrumban".
^MiSaTo^
11/02/2016, 19:21
Para saber si puedes aplicar Scrum bien en un equipo en cualquier empresa:
- Tienes un equipo multidisciplinar con personas que están dispuestas e interesadas en adoptar otros roles.
- Los miembros del equipo tienen tendencia a ser autoorganizados.
- No hay leader(ships), arquitectos, ni ***** mierdas de esas; hay gente que sabe más de unas cosas y otras de otras y todos están dispuestos a ayudarse mutuamente.
- Saben que un framework agile no sólo sirve para entregar producto, si no para mejorar la calidad laboral de todo el mundo.
- No hay multiplicidad de dueños de producto (PO). Sólo hay uno y es el que canaliza los requisitos de negocio.
- Si estáis empezando: Contáis con la ayuda de un facilitador (Scrum Master).
- El equipo comprende qué es un backlog y cómo puede ayudarles a realizar su trabajo.
- Todo el mundo se compromete a respetar el sprint, y no se altera hasta que termina. Salvo ciertas excepciones.
- Entienden que Scrum es un framework con un objetivo "oculto", generar métricas. Que no siempre va a mejorar el rendimiento del equipo.
Cuando una empresa no puede garantizar al menos todos menos uno de esos puntos, lo mejor es que sigan como están y que no probablemente acaben culpando a Scrum, sus herramientas o cualquier perogruyada de que les vaya mal un proyecto.
Madre mía que mal suenan todos los términos en español. Facilitador? XD
Por lo demás 100% de acuerdo. Es lo que me refería con que depende de la mentalidad que haya.
Yo haciendo cosas por mi cuenta he usado el kanban y me va bastante bien, no me veo haciendo sprints ni diciendo en una semana voy a hacer todo esto cuando me puedo encontrar con atascos inesperados.
Yo haciendo cosas por mi cuenta he usado el kanban y me va bastante bien, no me veo haciendo sprints ni diciendo en una semana voy a hacer todo esto cuando me puedo encontrar con atascos inesperados.
Es que kanban para esos casos va mucho mejor :D
mortimor
14/02/2016, 00:10
Scrum es adecuado para trabajos y equipos que cumplen las siguientes caracteristicas:
- Equipos maduros, con gente independiente y capacitada.
- Los componentes del equipo deben ser de un nivel de conocimientos mas o menos similar.
- No es valido para equipos grandes, mas de 8 personas.
- Proyectos que se han salido de madre o tienen plazos claramente insuficientes.
- Se debe contar con material visual para dar soporte a la metodologia.
- Las daily reviews no debieran exceder los 5 minutos (en eso influye el numero de integrantes del equipo y la labor del scrummaster)
Yo creo que es un metodología de trabajo muy buena si se dan las condiciones para desarrollarla correctamente. Lamentablemente muchas empresas confunden agil con: precipitado, horas extra, cambios continuos, ...
Yo voy a hablar desde mi experiencia, porque ya sabeis que de forma profesional, poco puedo aportar.
En tema de videojuegos, estoy con Misato, es importante que todos los miembros del equipo sepan, al menos, lo más básico de todas las disciplinas que intervienen en el videojuego (y si se ha desarrollado un juego completo sin apoyo de nadie, mejor). Yo soy programador, y no soy el Miguel Angel del ratón, pero al menos conozco herramientas de Photoshop, o diversos programas de diseño gráfico, y aunque no sé juntar tres notas seguidas, sí que conozco los formatos de sonido, las limitaciones y cosas así.
¿Por qué? pues porque en algún punto del desarrollo, alguien se atasca, y tu puedes ser el que le de la inspiración o la solución. Y no sólo eso, además puedes pedirle de forma correcta lo que quieres, y puedes complementar ambas disciplinas (por ejemplo, decirle al músico qué formato de audio usar y con qué canales y valores para poder modificarlos por código y darle riqueza al sonido en runtime).
Respecto a la forma de trabajar... gente más experimentada que yo me dicen que no hay una guía del desarrollo de videojuegos en grupo. Cada equipo es diferente, y su interacción es distinta.
El trabajo en remoto no es ágil, lo digo por experiencia. Si estás en grupo, y el grupo se centra y no pierde el tiempo (cosa difícil de lograr), es más rápido porque tienes contacto directo con el que te tiene que pasar algo o al que le quieres preguntar una duda que, de otra forma, tienes que escribir, enviar y esperar respuesta.
Las reuniones diarias tampoco, tendrían que estar fuera de las horas de trabajo, y sólo sirven cuando alguien dice "he acabado X". Es mejor tener reuniones semanales, y que todo el mundo tenga un seguimiento de lo que hacen los demás por dos razones:
- Estar al día de cuándo te va a llegar lo que necesitas de otra persona y conocer lo que los demás necesitan de ti.
- Hacer que todo el mundo trabaje.
Porque sí, en mi experiencia (y dicho por ellos mismos, incluso), los grafistas tienen tendencia a dejarse ir y no cumplir los plazos si no estás encima (aunque eso es aplicable a todo el equipo, y yo me incluyo en el saco).
Y aparte, reuniones puntuales por si hay que rediseñar algo o cambiar parte del proyecto.
En mi TFM eramos 6, con reuniones semanales, y el último mes, trabajando todos en la misma mesa hicimos más cosas que durante tres meses enteros. Y sólo gracias a las reuniones el proyecto fue avanzando.
En la oficina, teníamos reuniones cada dos semanas o cada mes, y sólo nos metían presión en las fechas de entrega. Sin embargo, yo tenía a mi jefa a dos metros, y me iba dando tareas a medida que las acababa y yo podía saber en todo momento cuánto quedaba por hacer y repartirme el tiempo (siempre intentando terminar antes de la fecha para ayudar en otras partes). E incluso tenía al cliente en la mesa de al lado, y aunque es poco ortodoxo, podía ver los fallos que tenía ella directamente en su máquina, arreglarlos en dos minutos, e incluso saber realmente qué es lo que necesitaba que hiciera realmente el programa, porque los informes de proyecto son la cosa más inexacta y abierta a reinterpretaciones que me he echado en cara.
No voy a decir que los sistemas usados en empresa no funcionen, seguramente sí si se cumplen sus condiciones, pero son estructuras de trabajo creadas para proyectos muy diferentes del desarrollo de videojuegos, normalmente mucho más compartimentados, y en un videojuego, si los gráficos van por un lado, la música por otro y el programador no entiende lo que le pasan, acaba saliendo algo que no satisface a nadie.
¿Mi método funciona? De momento, ha tenido relativo éxito (no voy a nombrar los juegos de Wiz otra vez), y son Caleb, FBustamante, Futublog y PrinceMegahit los que deberían dar su opinión al respecto :P
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.