User Tag List

Página 2 de 2 PrimerPrimer 12
Resultados 16 al 28 de 28

Tema: Utilidad del scrum

  1. #16

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    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
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  2. #17

    Fecha de ingreso
    Jun 2004
    Ubicación
    Vivo en el pito foro...
    Mensajes
    20,686
    Mencionado
    70 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    230
    Agradecer Thanks Received 
    742
    Thanked in
    Agradecido 466 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    28
    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.
    Última edición por pakoito; 11/02/2016 a las 16:47

  3. #18

    Fecha de ingreso
    Oct 2003
    Mensajes
    17,905
    Mencionado
    42 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    214
    Agradecer Thanks Received 
    160
    Thanked in
    Agradecido 109 veces en [ARG:2 UNDEFINED] posts
    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

  4. #19

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por pakoito Ver mensaje
    Hay reuniones de producto
    Ok, para hacerse pajas mentales de lo que se va a hacer.
    Cita Iniciado por pakoito Ver mensaje
    de arquitectura
    No
    Cita Iniciado por pakoito Ver mensaje
    revisiones de código

    Cita Iniciado por pakoito Ver mensaje
    sesiones de testeo
    No, el programador es el que prueba la aplicacion
    Cita Iniciado por pakoito Ver mensaje
    mitines de planificación del sprint
    ¿planificacion? ¿sprint? WTF!?!?
    Cita Iniciado por pakoito Ver mensaje
    colaboración con el diseño
    No, lone coder aunque en la empresa sean varios.
    Cita Iniciado por pakoito Ver mensaje
    dar y recibir cursillos...
    Ok, hay que enseñar como va la aplicación a los posibles clientes, recibir cursillos NO.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  5. #20

    Fecha de ingreso
    Aug 2003
    Mensajes
    681
    Mencionado
    5 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    12
    Agradecer Thanks Received 
    92
    Thanked in
    Agradecido 55 veces en [ARG:2 UNDEFINED] posts
    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.

  6. El siguiente usuario agradece a amkam este mensaje:

    ^MiSaTo^ (11/02/2016)

  7. #21

    Fecha de ingreso
    Oct 2004
    Mensajes
    118
    Mencionado
    0 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    5
    Agradecer Thanks Received 
    9
    Thanked in
    Agradecido 6 veces en [ARG:2 UNDEFINED] posts
    Al final scrum es como un puticlub... xD

    Un saludo.

  8. #22

    Fecha de ingreso
    Jun 2004
    Ubicación
    Valencia
    Mensajes
    2,122
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    11
    Agradecer Thanks Received 
    102
    Thanked in
    Agradecido 57 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    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

  9. #23

    Fecha de ingreso
    Jun 2004
    Ubicación
    Vivo en el pito foro...
    Mensajes
    20,686
    Mencionado
    70 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    230
    Agradecer Thanks Received 
    742
    Thanked in
    Agradecido 466 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    28
    Ser la caña a estas alturas es usar kanban o "scrumban".
    Última edición por pakoito; 11/02/2016 a las 20:27

  10. #24

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por amkam Ver mensaje
    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.

  11. #25

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  12. #26

    Fecha de ingreso
    Oct 2003
    Mensajes
    17,905
    Mencionado
    42 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    214
    Agradecer Thanks Received 
    160
    Thanked in
    Agradecido 109 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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

  13. #27

    Fecha de ingreso
    Apr 2003
    Ubicación
    Salamanca
    Mensajes
    5,346
    Mencionado
    2 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    12
    Agradecer Thanks Received 
    32
    Thanked in
    Agradecido 27 veces en [ARG:2 UNDEFINED] posts
    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, ...

  14. Los siguientes 2 usuarios agradecen a mortimor este post:

    Nuria (16/02/2016), ^MiSaTo^ (14/02/2016)

  15. #28

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,202
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    675
    Agradecer Thanks Received 
    1,847
    Thanked in
    Agradecido 1,264 veces en [ARG:2 UNDEFINED] posts
    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
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

Página 2 de 2 PrimerPrimer 12

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •