Portada > Artículo > Comentarios

Scrum aplicado

13-03-2010 - César Martín

Resumen: Una de las mejores ideas del Drupal Camp 2010 fue el ver la exposición sobre Scrum (Scrum significa melé de rugby en inglés). El Scrum es una metodología de trabajo que quita algunas ideas viejas sobre como hacer funcionar una empresa. En César y Justina aplicamos esta metodología y te contamos como lo hacemos.

Leer artículo »

Comentarios

Hablar, escuchar, debatir... Alzado es un espacio de conversación abierto. Algunos consejos:

Procura que tus comentarios sean relevantes y relacionados con el artículo
Escuchar es una virtud. Lee los comentarios anteriores para no repetirte
Pon un título a tu mensaje aue permita identificar su contenido
Usa un tono respetuoso. Los comentarios inapropiados o en tono ofensivo podrán ser editados o eliminados.

#1 Como acercarse a la realidad Por Alex

Muy interesante artículo
Me quedo con esta frase.
"...se pide a todo el equipo que sea responsable del producto en su conjunto. No vale eso de "yo solo programo" o "yo solo diseño". Cada persona que se integra en el equipo ha de velar por el producto en su conjunto y es responsabilidad de todos que el producto salga bien."

De todas formas si pienso que esta metodolgía puede ser útil, pero para empresas pequeñas.

Luego está encontrar personas adecuadas para esa manera de trabajar, estoy seguro que hay gente que sería incapaz de trabajar de esa manera.

Enviado hace 5 mess, 3 semanas

#2 Correcto Por Tutoriales Photoshop - http://www.kaosconcept.net

Coincido con el artículo al 100%.

En una empresa hay que enfocar los esfuerzos en objetivos claros y, sobre todo, realistas.

La comunicación entre los trabajadores de la misma es fundamental y, como bien apunta el artículo, una estructura lo más horizontal posible facilita en gran medida este flujo.

Menos jefes, más indios, involucrarse y olvidar el puesto personal para crear una sinergia que amplíe la visión individual. Que todos sean uno.

No hace mucho vi un vídeo del estudio Naughty Dog (hacen juegos para Ps3). Y coincidía en todos los aspectos con lo expuesto. Grafistas hablaban con programadores o programadores con infógrafos, las relaciones eran de todos con todos. No había separadores o "cortafuegos" (jefecillos) que impidieran la fusión del grupo (aun siendo un equipo humano bastante amplio).

Es un punto que mejora la productividad y lo que es más importante, el resultado final. Si un buen diseñador sabe hasta donde puede llegar para aprovechar la habilidad de su compañero programador, es un salto cualitativo muy significativo en comparación a si cada uno va a su bola.

Enviado hace 5 mess, 3 semanas

#3 la documentacion si es necesaria Por mangod

pues yo no coincido con la parte de
"Por lo general no hay objetivos o público objetivo. Hay metas. Esas metas suelen ser entregas. Esas entregas son productos reales que se pueden utilizar. No papeles.

Esos productos reales deben responder a unos criterios mínimos, pero los máximos están por definir y son cambiantes. El producto se ha de modificar, adaptar y crecer para acometer nuevos requisitos. Es parte del ciclo de vida del diseño.

Eso exige que el producto esté sujeto a una constante evolución y mejora. No hay entrega final. No hay documentación. La aplicación tiene que ser fácil de utilizar, estandar y compatible."

la documentacion bien entendida es necesaria y util, no hay que ser inmovilista y ceñirse a un papel, ni detallar al milimetro que se hace o cambia.

Por ejemplo tener escrito los minimos de una entrega con una descripcion clara de cada objetivo es necesario.

hacer un check list con las partes que tienes que cambiar para cumplir un objetivo es necesario

tener un documento que explique que parametros de entrada genericos tiene un requisito es necesario, simplifica el desarrollo y ayuda a entender lo que se espera de entrada

hacer un documento con los casos de error que se pueden producir es muy importante, ya que se te pueden pasar cosas y ayuda ha hacer pruebas

hacer un boceto de como va a funcionar un requisito en plan ppt navegable permite que el cliente vea antes de escribir una sola linea de codigo como va a uncionar y sirve para ver muuuuchas cosas

no creo que sea bueno hacer un "libro" de 500 paginas para poner un boton, pero a mi escribir las cosas mientras las hago me ayuda a tener mas claro el esquema de cosas, a no saltarme pasos y a cometer menos errores, ya que lo haces y al escribirlo lo repasas.

humilde opinion de uno 8)

Enviado hace 5 mess, 3 semanas

#4 Y esto como se presupuesta? Por Javier González

Estoy de acuerdo que esto puede ser bastante práctico a la hora de desarrollar, pero no contamos con que un equipo tiene un coste y no tener funcionalidades predefinidas de foma concreta, puede suponer estar empantanado en poyaques todo el proyecto, mejorando y mejorando, que de cara al cliente perfecto, ya que va a tener un producto mejor que el esperado, y de cara a la empresa una imagen fantástica sobre la calidad de trabajo, pero....¿quién paga esto? pueden existir unas desviaciones terribles, a veces pequeñas funcionalidades pueden suponer muchas horas de desarrollo.

Pues eso, a ver si algún compañero me ayuda con mi duda ¿y esto como se presupuesta?

Saludos y gracias

Enviado hace 5 mess, 3 semanas

#5 De Acuerdo Por Shroud Of Turin

Como se comento anteriormente, se debe conocer a cabalidad y por completo las necesitades de la empresa, realizando un analisis de estrategia y analizar el comportamiento de la empresa para realizar un levantamiento para la empresa.

Enviado hace 5 mess, 3 semanas

#6 Termino medio Por Pha

Creo que es una forma de trabajo un tanto "extremista" en favor del cliente. Sí, "el cliente paga", pero la empresa en la que trabajas tiene que buscar la rentabilidad en sus proyectos.

Esta muy bien eso de dejarlo todo abierto a los cambios del cliente sin cerrar una buen porcentaje de los requisitos del trabajo a realizar, pero esto puede perjudicar a la empresa de diseño/desarrollo de forma directa. El cliente obviamente saldra beneficiado, pero la empresa puede salir perdiendo en un buen porcentaje de casos.

Y no digamos los empleados de la misma... Yo trabajo en una empresa cuya filosofia se parece, en parte, a la forma de trabajo que nos cuentan en este articulo. Este metodo, como se comenta, es muy bonito para el cliente, pero para el trabajador de a pie, al que no le pagan ni un duro mas por "hacer un esfuerzo" y realizar "para ayer" los ultimos de los ultimos cambios que ha pedido el tipico cliente pesado, pues no es precisamente bueno.

Con esto tambien tengo que decir que para un socio de la misma, o para un comercial, o para cualquiera que este en un puesto en el que se tenga un sueldo base + un sueldo variable por determinados objetivos, entonces la cosa no es tan mala, pero no todos estamos en ese barco.

En definitiva, hay que buscar el termino medio. No se puede dejar al cliente hacer lo que le de la gana con un proyecto porque puede incidir directamente en los beneficios de la empresa y puede incomodar en demasia al trabajador de a pie que no ve un duro mas por hacer trabajo extra.

Enviado hace 5 mess, 2 semanas

#7 presupuestar para scrum Por César

Está claro que es complicado presupuestar Scrum, pero la forma más fácil es definir un fijo mensual durante la vida del proyecto que te permita cubrir todos tus gastos y unos honorarios de la empresa. Es decir, un equipo dedicado al proyecto por mes cuesta X. Los honorarios de la empresa son Y. Creo que es bueno separar los honorarios del coste para que el cliente sepa cual es tu margen y cual es el coste del proyecto.

Enviado hace 5 mess, 2 semanas