Concurso público con modelo Agile Scrum
184 views
Skip to first unread message
Daniel, de la Cuesta Navarrete
Aug 11, 2010, 4:44:25 AM8/11/10
to agile...@googlegroups.com
Hola
Os paso enlace de este concurso público con modelo Agile Scrum que hemos sacado recientemente desde Fundación Iavante en Andalucía,
http://www.juntadeandalucia.es/contratacion/ContractNoticeDetail.action?code=2010-0000007311
Si le echais un vistazo al documento de prescripciones técnicas (http://www.juntadeandalucia.es/contratacion/document/download?refCode=2010-0000007311&refDoc=2010-0000007311-0), vereis muchos conceptos que os serán familiares como sprint, burn down, pila de producto, etc.
Básicamente se buscan ofertas por un punto de esfuerzo que se describe y la principal métrica del proyecto es la velocidad el equipo.
Nos gustaría recibir feeback por parte vuestra en cuanto al modelo (que queremos empezar a promocionar en nuestra contrataciones) y si alguna empresa que practique agile se anima pues adelante, el concurso termina el 27 de este mes.
Un saludo.
Un saludo.
Os paso enlace de este concurso público con modelo Agile Scrum que hemos sacado recientemente desde Fundación Iavante en Andalucía,
http://www.juntadeandalucia.es/contratacion/ContractNoticeDetail.action?code=2010-0000007311
Si le echais un vistazo al documento de prescripciones técnicas (http://www.juntadeandalucia.es/contratacion/document/download?refCode=2010-0000007311&refDoc=2010-0000007311-0), vereis muchos conceptos que os serán familiares como sprint, burn down, pila de producto, etc.
Básicamente se buscan ofertas por un punto de esfuerzo que se describe y la principal métrica del proyecto es la velocidad el equipo.
Nos gustaría recibir feeback por parte vuestra en cuanto al modelo (que queremos empezar a promocionar en nuestra contrataciones) y si alguna empresa que practique agile se anima pues adelante, el concurso termina el 27 de este mes.
Un saludo.
Un saludo.
Juan Carlos Quijano Abad
Aug 11, 2010, 6:10:19 AM8/11/10
to agile...@googlegroups.com
Buenas,
Fantástico!! Ya se lo he pasado a mi gerente para que nos presentemos. Con la descripción de la licitación y los requerimientos, y nuestra experiencia en proyectos scrum... el exito está casi asegurado.
Muchas gracias por mejorar e introducir Agile en el estado.
Fantástico!! Ya se lo he pasado a mi gerente para que nos presentemos. Con la descripción de la licitación y los requerimientos, y nuestra experiencia en proyectos scrum... el exito está casi asegurado.
Muchas gracias por mejorar e introducir Agile en el estado.
--
Un saludo
Juan Quijano
El 11 de agosto de 2010 10:44, Daniel, de la Cuesta Navarrete <cue...@gmail.com> escribió:
http://www.juntadeandalucia.es/contratacion/ContractNoticeDetail.action?code=2010-0000007311
Miquel A. Mora
Aug 12, 2010, 4:52:36 AM8/12/10
to agile-spain
Personalmente aplaudo la propuesta.
Me ha sorprendido mucho el modelo de contrato por punto de esfuerzo (y
valorando la velocidad). Es totalmente nuevo para mi.
Y mira que hay tipos de contrato para proyectos ágiles.
Contrato de Sprint
Precio Fijo / Alcance Fijo
Tiempo y Materiales
Tiempo y Materiales con Alcance Fijo y Techo de Costos
Tiempo y Materiales con Alcance Variable y Techo de Costos
Desarrollo por fases
Clausulas de Bonus y Penalidades
Ganancia Fija
"Dinero por Nada. Cambios Gratis"
Joint Venture
http://www.dosideas.com/noticias/actualidad/558-contratos-para-los-proyectos-agiles-parte-2.html
Hay contratos que gestionan la estimación errónea (el cliente paga
solo parte si se trabaja más de lo estimado, o paga menos si se
trabaja menos de lo estimado ), o que el cliente no paga si al final
de la iteración si el resultado no es aceptado por el cliente (con
criterios preestablecidos)
Me parece muy interesante este tipo de contrato o forma de valorar
para la licitación del proyecto, es una forma simple de utilizar unas
métricas para tomar una decisión.
Y me pregunto (y no es por desconfiar, sino por si te lo has
planteado) si esto no hará que las empresas que se presenten a la
licitación, puedan poner un precio por punto de esfuerzo bajo, pero
luego sobreestimar el esfuerzo necesario en el "planning poker".
Ademas, sobre la velocidad propuesta, algunos factores durante el
desarrollo pueden afectar la velocidad. No olvidemos que la estimación
de la velocidad, se obtiene del seguimiento de la velocidad del equipo
en otros proyectos, del numero de actividades por iteración, de la
facilidad de comunicación con el cliente,... y es posible que pueda
variar de un proyecto a otro, por lo que hay un nivel de incertidumbre
real.
Me gustaría que nos dieras el feedback de como funciona este tipo de
contrato, que creo que puede ser muy provechoso.
Y repito, felicidades por la iniciativa que estoy seguro que será un
referente a muchos niveles.
Me ha sorprendido mucho el modelo de contrato por punto de esfuerzo (y
valorando la velocidad). Es totalmente nuevo para mi.
Y mira que hay tipos de contrato para proyectos ágiles.
Contrato de Sprint
Precio Fijo / Alcance Fijo
Tiempo y Materiales
Tiempo y Materiales con Alcance Fijo y Techo de Costos
Tiempo y Materiales con Alcance Variable y Techo de Costos
Desarrollo por fases
Clausulas de Bonus y Penalidades
Ganancia Fija
"Dinero por Nada. Cambios Gratis"
Joint Venture
http://www.dosideas.com/noticias/actualidad/558-contratos-para-los-proyectos-agiles-parte-2.html
Hay contratos que gestionan la estimación errónea (el cliente paga
solo parte si se trabaja más de lo estimado, o paga menos si se
trabaja menos de lo estimado ), o que el cliente no paga si al final
de la iteración si el resultado no es aceptado por el cliente (con
criterios preestablecidos)
Me parece muy interesante este tipo de contrato o forma de valorar
para la licitación del proyecto, es una forma simple de utilizar unas
métricas para tomar una decisión.
Y me pregunto (y no es por desconfiar, sino por si te lo has
planteado) si esto no hará que las empresas que se presenten a la
licitación, puedan poner un precio por punto de esfuerzo bajo, pero
luego sobreestimar el esfuerzo necesario en el "planning poker".
Ademas, sobre la velocidad propuesta, algunos factores durante el
desarrollo pueden afectar la velocidad. No olvidemos que la estimación
de la velocidad, se obtiene del seguimiento de la velocidad del equipo
en otros proyectos, del numero de actividades por iteración, de la
facilidad de comunicación con el cliente,... y es posible que pueda
variar de un proyecto a otro, por lo que hay un nivel de incertidumbre
real.
Me gustaría que nos dieras el feedback de como funciona este tipo de
contrato, que creo que puede ser muy provechoso.
Y repito, felicidades por la iniciativa que estoy seguro que será un
referente a muchos niveles.
José Manuel Beas
Aug 12, 2010, 10:33:05 AM8/12/10
to agile...@googlegroups.com
Los puntos de esfuerzo, en general, no son comparables de un equipo a
otro ni de un proyecto a otro. Si lo que pretendéis es estandarizar
los puntos de esfuerzo desde el punto de vista del dueño de producto
(que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
nos contaréis cómo hacéis para tener historias de usuario y sus
correspondientes estimaciones.
otro ni de un proyecto a otro. Si lo que pretendéis es estandarizar
los puntos de esfuerzo desde el punto de vista del dueño de producto
(que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
nos contaréis cómo hacéis para tener historias de usuario y sus
correspondientes estimaciones.
Me pregunto si no sería más sencillo probar antes las fórmulas que ya
se han probado y entonces ir adaptando lo que no funcione. ¿Habéis
andado ya ese camino? ¿Qué razones os han llevado a tomar esta
decisión?
Un saludo,
JMB
--
Un saludo,
Jose Manuel Beas
David Esmerodes
Aug 12, 2010, 5:47:09 PM8/12/10
to agile...@googlegroups.com
Es una gran noticia para todos que la Administración comience a sacar concursos de este tipo.
Muy buena noticia.
Un saludo, David.
El 11 de agosto de 2010 10:44, Daniel, de la Cuesta Navarrete <cue...@gmail.com> escribió:
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
Juan Carlos Quijano Abad
Aug 13, 2010, 4:02:29 AM8/13/10
to agile...@googlegroups.com
Buenas,
JMB
¿A qué formulas te refieres?
¿Podrias dar los ejemplos de licitaciones que hayas escrito?
¿Podrías dar los ejemplos de pliegos concursales que hayas escrito?
Yo soy experto con más de 7 años de experiencia en licitaciones del estado y me muero de curiosidad por saber a qué autores te vas a referir.
Volviendo al tema, cosillas que salen de los ojos de un director cuando vé su primera licitación Agile.
Imaginaros que montamos el equipo de cinco personas y por cualquier motivo, que en función pública hay unos cuantos, el proyecto se paraliza en el sprint 3. ¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?
Más cosas interesantes de aplicar la REALIDAD (eso que tanto les molesta a los que no viven de esto) a este interesantísimo proyecto. ¿Se podría poner en papel la imposibilidad que se puedan cojer sprint sueltos? Es decir, que hagamos la iteración (y su correspondiente entrega) 1, 2 y 3. Que se paralice el proyecto por las dos siguientes iteraciones y que se vuelva a el en las iteraciones 7, 8 y 9. Es que en la redacción actual no hay no encuentro limitación u obligación de seguir una consecutividad. Y se podría caer en la confusión de entender a las iteraciones como unidades independientes. Como si fueran módulos intercambiables.
Más cosas que se vén con los ojos de una dirección ante un pliego Agile. Les ha extrañado el que se describa con tanto detalle SCRUM. En las licitaciones del estado indican cual es la métodología, y es tácito y sobreentendido que quien concurse sabe de qué se está hablando. En cambio en esta se hace una descripción detallada de la métodología.
Por ahora esas son las opiniones que me han comunicado. A ver si saco tiempo y le echo una ojeada larga y comparto mis opiniones.
Gracias!!
JMB
¿A qué formulas te refieres?
¿Podrias dar los ejemplos de licitaciones que hayas escrito?
¿Podrías dar los ejemplos de pliegos concursales que hayas escrito?
Yo soy experto con más de 7 años de experiencia en licitaciones del estado y me muero de curiosidad por saber a qué autores te vas a referir.
Volviendo al tema, cosillas que salen de los ojos de un director cuando vé su primera licitación Agile.
Imaginaros que montamos el equipo de cinco personas y por cualquier motivo, que en función pública hay unos cuantos, el proyecto se paraliza en el sprint 3. ¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?
Más cosas interesantes de aplicar la REALIDAD (eso que tanto les molesta a los que no viven de esto) a este interesantísimo proyecto. ¿Se podría poner en papel la imposibilidad que se puedan cojer sprint sueltos? Es decir, que hagamos la iteración (y su correspondiente entrega) 1, 2 y 3. Que se paralice el proyecto por las dos siguientes iteraciones y que se vuelva a el en las iteraciones 7, 8 y 9. Es que en la redacción actual no hay no encuentro limitación u obligación de seguir una consecutividad. Y se podría caer en la confusión de entender a las iteraciones como unidades independientes. Como si fueran módulos intercambiables.
Más cosas que se vén con los ojos de una dirección ante un pliego Agile. Les ha extrañado el que se describa con tanto detalle SCRUM. En las licitaciones del estado indican cual es la métodología, y es tácito y sobreentendido que quien concurse sabe de qué se está hablando. En cambio en esta se hace una descripción detallada de la métodología.
Por ahora esas son las opiniones que me han comunicado. A ver si saco tiempo y le echo una ojeada larga y comparto mis opiniones.
Gracias!!
--
Un saludo
Juan Quijano
2010/8/12 José Manuel Beas <jose....@gmail.com>
Daniel, de la Cuesta Navarrete
Aug 13, 2010, 4:46:33 AM8/13/10
to agile...@googlegroups.com
Hola,
Os respondo a las dudas y custiones que han ido surgiendo,
Miguel Angel Mora,
Con respecto a los tipos de contratos que comentas, si los conocemos y en realidad el que os he enviado podría encajar perfectamente en un contrato de tipo " Tiempo y Materiales con Alcance Variable y Techo de Costos" (si os fijais el importe total de la licitación pone 0 y el estimado 67000) y "Clausulas de Bonus y Penalidades".
Lo único que hemos hecho es poner la terminología de Scrum a nivel de contrato porque es la metodología que más éxito nos ha dado en los proyectos. Hasta ahora veníamos sacando concursos públicos del tipo tradicional (tiempo fijo, alcance fijo y dinero fijo) pero lo "scrumizábamos" dividiendolo en sprints y viendo hasta donde llegabamos y hasta donde no llegabamos conjuntamente con el proveedor basándonos en la velocidad por sprint, así que ¿porqué no poner esto por escrito?
>puedan poner un precio por punto de esfuerzo bajo, pero
>luego sobreestimar el esfuerzo necesario en el "planning poker"
Somos conscientes. Esto también nos ha ocurrido en los contratos tradicionales, las empresas piscineras que luego te lloran y dicen que no llegan, sin embargo de esta forma te das cuenta desde el primer sprint.
JMB
>Los puntos de esfuerzo, en general, no son comparables de un equipo a
>otro ni de un proyecto a otro
Totalmente de acuerdo, la idea es que el punto de esfuerzo sea una historia de usuario con valor 1 y que este punto de esfuerzo sea diferente para cada proyecto. Por ahora ya tenemos 4 o 5 puntos de esfuerzo descritos para cada una de las tecnologías y tipos de proyectos con los que trabajamos.
> Si lo que pretendéis es estandarizar
> los puntos de esfuerzo desde el punto de vista del dueño de producto
> (que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
> nos contaréis cómo hacéis para tener historias de usuario y sus
> correspondientes estimaciones
En el pliego solo se describe el punto de esfuerzo, no se le pone tiempo ni precio, son las empresas las que dan sus estimaciones de tiempo para ese punto de esfuerzo. Esperamos que ellas se reunan internamente con sus desarrolladores para dar esa estimación porque si no van a fallar mucho. A partir de ahi, una vez que hemos definido el punto de esfuerzo, se sacarán las historias de usuario en las reuniones de planificación en las que nosotros seremos dueños de producto y estaremos presentes.
>¿Habéis
>andado ya ese camino?
Podríamos ver este contrato como uno del tipo "Tiempo y materiales" pero con terminología scrum. Por otro lado llevamos aplicando scrum en proyectos internos desde hace ya bastante timpo. En cuanto a proyectos externos con proveedores también estamos aplicando scrum (pero bajo un contrato tradicional) desde hace 1 año con bastante buen resultado. Ya que nos ha permitido ver cuando nos íbamos a estrellar, cuando había que recortar funcionalidad porque no llegábamos, etc.
>¿Qué razones os han llevado a tomar esta
>decisión?
Porque Scrum es lo que mejor nos está funcionando y llevamos bastantes proyectos gestionados de la forma tradicional que casi siempre salen mal.
Juan Carlos Quijamo Abad.
>¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco >personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?
No está previsto, aunque siempre que el proveedor cumpla con la velocidad y la planificación de cada sprint será dificil que cortemos la relación. Además, este proyecto en concreto tiene un importe estimado de 67000 euros, este es el techo de costos. Además te puedo asegurar que a nosotros tampoco nos interesa parar el proyecto o cambiar de proveedor a mitad del proyecto. Riesgos compartidos :-)
>Les ha extrañado el que se describa con tanto detalle SCRUM.
Bueno la verdad es que queremos que nuestros proveedores utilicen Scrum y queríamos plasmar a nivel de contrato los conceptos de Scrum para que no se diluyan, además algunos de los proveedores con los que trabajamos normalmente no utilizan Scrum por lo que creiamos necesario describirla.
os mantendré informados sobre como discurre el proyecto.
Un saludo.
Os respondo a las dudas y custiones que han ido surgiendo,
Miguel Angel Mora,
Con respecto a los tipos de contratos que comentas, si los conocemos y en realidad el que os he enviado podría encajar perfectamente en un contrato de tipo " Tiempo y Materiales con Alcance Variable y Techo de Costos" (si os fijais el importe total de la licitación pone 0 y el estimado 67000) y "Clausulas de Bonus y Penalidades".
Lo único que hemos hecho es poner la terminología de Scrum a nivel de contrato porque es la metodología que más éxito nos ha dado en los proyectos. Hasta ahora veníamos sacando concursos públicos del tipo tradicional (tiempo fijo, alcance fijo y dinero fijo) pero lo "scrumizábamos" dividiendolo en sprints y viendo hasta donde llegabamos y hasta donde no llegabamos conjuntamente con el proveedor basándonos en la velocidad por sprint, así que ¿porqué no poner esto por escrito?
>puedan poner un precio por punto de esfuerzo bajo, pero
>luego sobreestimar el esfuerzo necesario en el "planning poker"
JMB
>Los puntos de esfuerzo, en general, no son comparables de un equipo a
>otro ni de un proyecto a otro
> Si lo que pretendéis es estandarizar
> los puntos de esfuerzo desde el punto de vista del dueño de producto
> (que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
> nos contaréis cómo hacéis para tener historias de usuario y sus
> correspondientes estimaciones
>¿Habéis
>andado ya ese camino?
>¿Qué razones os han llevado a tomar esta
>decisión?
Juan Carlos Quijamo Abad.
>¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco >personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?
>Les ha extrañado el que se describa con tanto detalle SCRUM.
os mantendré informados sobre como discurre el proyecto.
Un saludo.
Juan Carlos Quijano Abad
Aug 13, 2010, 5:21:04 AM8/13/10
to agile...@googlegroups.com
Buenas,
Un gustazo poder trabajar con vosotros. El tipo de cliente estatal con el que todos soñamos y que, menos mal, ahora mismo también estoy disfrutando en mi proyecto actual.
Sobre el montante mínimo.
Buenos los riesgos compartidos no son tan compartidos... es decir. Las causas por las que un proyecto se detiene en el estado son varias y variopintas. Simplemente el cambio de un subdirector o de un Jefe de area, son capaces de pasar al limbo cualquier proyecto (cosa que me ocurrió personalmente a mí el més de diciembre del pasado 2009). Pero en el caso de paralización los Pigs se van a la calle y los Chicken tendrán que esperar mejores tiempos. Unos ponen los huevos y otros el jamón. ;)
Por ello una clausula de "suelo" no estaría de más para que las empresas pequeñas (que son las que mejor scrum hacemos) podamos asumir el riesgo de contratar personal con garantías. La ausencia de ese suelo, hace preferentes a las empresas con capacidad de asumir personal sin proyecto asignado y quedan las grandes carnicerias, que ya han demostrado de lejos su valía. O las empresas medias que justamente tengan personal sin proyecto imputable en estos momentos y en el momento de la firma. Y se deja la puerta abierta a los abusos contractuales, que en la administración pública haberlos haylos (y alguno me ha tocado comerme) ya que no describe las causas objetivas de la cancelación prematura (antes de dicho suelo).
Un duda mia, propia. ¿Cómo se gestiona desde el punto de vista de la caja, el pago por iteración? ¿Se realiza una resolución de pago por cada una de las iteraciones, se ingresa todo el montante en una cuenta y se va liberando como si fuese un certificación de un Artepyme, otras formas? (Es que mi mujer es de presupuestos del CSIC y le ha causado curiosidad).
Muchas gracias por tus contestaciones,
Un gustazo poder trabajar con vosotros. El tipo de cliente estatal con el que todos soñamos y que, menos mal, ahora mismo también estoy disfrutando en mi proyecto actual.
Sobre el montante mínimo.
Buenos los riesgos compartidos no son tan compartidos... es decir. Las causas por las que un proyecto se detiene en el estado son varias y variopintas. Simplemente el cambio de un subdirector o de un Jefe de area, son capaces de pasar al limbo cualquier proyecto (cosa que me ocurrió personalmente a mí el més de diciembre del pasado 2009). Pero en el caso de paralización los Pigs se van a la calle y los Chicken tendrán que esperar mejores tiempos. Unos ponen los huevos y otros el jamón. ;)
Por ello una clausula de "suelo" no estaría de más para que las empresas pequeñas (que son las que mejor scrum hacemos) podamos asumir el riesgo de contratar personal con garantías. La ausencia de ese suelo, hace preferentes a las empresas con capacidad de asumir personal sin proyecto asignado y quedan las grandes carnicerias, que ya han demostrado de lejos su valía. O las empresas medias que justamente tengan personal sin proyecto imputable en estos momentos y en el momento de la firma. Y se deja la puerta abierta a los abusos contractuales, que en la administración pública haberlos haylos (y alguno me ha tocado comerme) ya que no describe las causas objetivas de la cancelación prematura (antes de dicho suelo).
Un duda mia, propia. ¿Cómo se gestiona desde el punto de vista de la caja, el pago por iteración? ¿Se realiza una resolución de pago por cada una de las iteraciones, se ingresa todo el montante en una cuenta y se va liberando como si fuese un certificación de un Artepyme, otras formas? (Es que mi mujer es de presupuestos del CSIC y le ha causado curiosidad).
Muchas gracias por tus contestaciones,
--
Un saludo
Juan Quijano
>¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco >personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?
martin
Aug 13, 2010, 5:53:33 AM8/13/10
to agile-spain
Hola Daniel,
La verdad es que enhorabuena por la propuesta y el trabajo realizado
en pensar el planteamiento y ponerlo en práctica, que seguro que ha
habido bastante. La verdad es que he disfrutado leyéndola y puede
sentar un precedente muy interesante.
Me gustaría saber un poco vuestra opinión y como planeáis evitar la
micro-estimación. Es decir, por lo que veo en el contrato todo se
centra en el punto de esfuerzo definido en una historia tipo que
habéis descrito. No entro ya en lo que acertádamente comenta Miguel
Ángel sobre la picaresca de ofrecer diréctamente un punto de esfuerzo
muy bajo, sino que voy más bien al caso de un proveedor que ve una
historia CRUD como la que ponéis y dice, "bah, esto está chupado" y
después resulta que en el resto de historias hay dos que no son
capaces, ya no por mala intención sino incluso por falta de contexto y
alcance general quizás. Quizás en este concurso no sea problema por el
tipo de aplicación, pero no sé hasta que punto esta micro-estimación
sería viable para otros concursos más complejos técnica y
funcionálmente. ¿Cómo os lo planteáis? ¿Poner una historia tipo
"media"? ¿Poner como historia tipo la más complicada para ver que
tiempo/esfuerzo os dan?
Y lo segundo es simplemente comentar que en algún momento quizás sí
que se entra en demasiado detalle. Por ejemplo, ¿por qué las
estimaciones tienen que ser con planning poker (por cierto hay una
errata, habéis puesto "pocker")? ¿Es para que el proveedor meta en el
coste la baraja? :-) Es broma, pero hay muchas varias formas de
estimar en agile y tampoco creo que sea demasiado relevante para el
contrato el usar una u otra.
Un saludo.
Martín
On 13 ago, 10:46, "Daniel, de la Cuesta Navarrete" <cue...@gmail.com>
wrote:
> juancarlosquij...@gmail.com> escribió:
> > Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> > Blog de opinión social <http://unmalnacido.blogspot.com/>
> > Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> > Blog de Tiro con Arco <http://litelllon.blogspot.com/>
>
> > 2010/8/12 José Manuel Beas <jose.m.b...@gmail.com>
La verdad es que enhorabuena por la propuesta y el trabajo realizado
en pensar el planteamiento y ponerlo en práctica, que seguro que ha
habido bastante. La verdad es que he disfrutado leyéndola y puede
sentar un precedente muy interesante.
Me gustaría saber un poco vuestra opinión y como planeáis evitar la
micro-estimación. Es decir, por lo que veo en el contrato todo se
centra en el punto de esfuerzo definido en una historia tipo que
habéis descrito. No entro ya en lo que acertádamente comenta Miguel
Ángel sobre la picaresca de ofrecer diréctamente un punto de esfuerzo
muy bajo, sino que voy más bien al caso de un proveedor que ve una
historia CRUD como la que ponéis y dice, "bah, esto está chupado" y
después resulta que en el resto de historias hay dos que no son
capaces, ya no por mala intención sino incluso por falta de contexto y
alcance general quizás. Quizás en este concurso no sea problema por el
tipo de aplicación, pero no sé hasta que punto esta micro-estimación
sería viable para otros concursos más complejos técnica y
funcionálmente. ¿Cómo os lo planteáis? ¿Poner una historia tipo
"media"? ¿Poner como historia tipo la más complicada para ver que
tiempo/esfuerzo os dan?
Y lo segundo es simplemente comentar que en algún momento quizás sí
que se entra en demasiado detalle. Por ejemplo, ¿por qué las
estimaciones tienen que ser con planning poker (por cierto hay una
errata, habéis puesto "pocker")? ¿Es para que el proveedor meta en el
coste la baraja? :-) Es broma, pero hay muchas varias formas de
estimar en agile y tampoco creo que sea demasiado relevante para el
contrato el usar una u otra.
Un saludo.
Martín
On 13 ago, 10:46, "Daniel, de la Cuesta Navarrete" <cue...@gmail.com>
wrote:
> > Blog de opinión social <http://unmalnacido.blogspot.com/>
> > Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> > Blog de Tiro con Arco <http://litelllon.blogspot.com/>
>
> > 2010/8/12 José Manuel Beas <jose.m.b...@gmail.com>
>
> > Los puntos de esfuerzo, en general, no son comparables de un equipo a
> >> otro ni de un proyecto a otro. Si lo que pretendéis es estandarizar
> >> los puntos de esfuerzo desde el punto de vista del dueño de producto
> >> (que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
> >> nos contaréis cómo hacéis para tener historias de usuario y sus
> >> correspondientes estimaciones.
>
> >> Me pregunto si no sería más sencillo probar antes las fórmulas que ya
> >> se han probado y entonces ir adaptando lo que no funcione. ¿Habéis
> >> andado ya ese camino? ¿Qué razones os han llevado a tomar esta
> >> decisión?
>
> >> Un saludo,
> >> JMB
>
> >> --
> >> Un saludo,
> >> Jose Manuel Beas
>
> >> --
> >> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> >> Grupos de Google.
> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> agile...@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a
> >> agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>
> > Los puntos de esfuerzo, en general, no son comparables de un equipo a
> >> otro ni de un proyecto a otro. Si lo que pretendéis es estandarizar
> >> los puntos de esfuerzo desde el punto de vista del dueño de producto
> >> (que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
> >> nos contaréis cómo hacéis para tener historias de usuario y sus
> >> correspondientes estimaciones.
>
> >> Me pregunto si no sería más sencillo probar antes las fórmulas que ya
> >> se han probado y entonces ir adaptando lo que no funcione. ¿Habéis
> >> andado ya ese camino? ¿Qué razones os han llevado a tomar esta
> >> decisión?
>
> >> Un saludo,
> >> JMB
>
> >> --
> >> Un saludo,
> >> Jose Manuel Beas
>
> >> --
> >> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> >> Grupos de Google.
> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> agile...@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a
> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/agile-spain?hl=es.
>
> > --
> > Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> > Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > agile...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>
> >>http://groups.google.com/group/agile-spain?hl=es.
>
> > --
> > Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> > Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > agile...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
Daniel, de la Cuesta Navarrete
Aug 13, 2010, 10:02:23 AM8/13/10
to agile...@googlegroups.com
Hola Juan Carlos,
Por ello una clausula de "suelo" no estaría de más para que las empresas pequeñas (que son las que mejor scrum hacemos) podamos asumir el riesgo de contratar personal con garantías. La ausencia de ese suelo, hace preferentes a las empresas con capacidad de asumir personal sin proyecto asignado y quedan las grandes carnicerias, que ya han demostrado de lejos su valía. O las empresas medias que justamente tengan personal sin proyecto imputable en estos momentos y en el momento de la firma. Y se deja la puerta abierta a los abusos contractuales, que en la administración pública haberlos haylos (y alguno me ha tocado comerme) ya que no describe las causas objetivas de la cancelación prematura (antes de dicho suelo).
Es cierto, puede ocurrir lo que dices. De todas formas es lo que te he comentado, nuestra idea es terminar el proyecto sin interrupciones y si la velocidad del equipo es constante no debería haber problemas
Un duda mia, propia. ¿Cómo se gestiona desde el punto de vista de la caja, el pago por iteración? ¿Se realiza una resolución de pago por cada una de las iteraciones, se ingresa todo el montante en una cuenta y se va liberando como si fuese un certificación de un Artepyme, otras formas? (Es que mi mujer es de presupuestos del CSIC y le ha causado curiosidad).
La facturación será por sprint. Una vez se valida el sprint, se hace el cálculo multiplicando los puntos de esfuerzo realizados por el precio por punto que ofertó la empresa.
Muchas gracias por tus contestaciones,
Un saludo.
--Un saludoJuan Quijano>¿Se podría negociar un montante mínimo del proyecto para que la empresa no se encuentre en un proyecto en perdidas y cinco >personas a un paso de la calle por causas ajenas a la empresa e, incluso, al licitador?No está previsto, aunque siempre que el proveedor cumpla con la velocidad y la planificación de cada sprint será dificil que cortemos la relación. Además, este proyecto en concreto tiene un importe estimado de 67000 euros, este es el techo de costos. Además te puedo asegurar que a nosotros tampoco nos interesa parar el proyecto o cambiar de proveedor a mitad del proyecto. Riesgos compartidos :-)
Daniel, de la Cuesta Navarrete
Aug 13, 2010, 10:10:56 AM8/13/10
to agile...@googlegroups.com
Hola martín,
El 13 de agosto de 2010 11:53, martin <mpe...@gmail.com> escribió:
Hola Daniel,
La verdad es que enhorabuena por la propuesta y el trabajo realizado
en pensar el planteamiento y ponerlo en práctica, que seguro que ha
habido bastante. La verdad es que he disfrutado leyéndola y puede
sentar un precedente muy interesante.
Gracias, a ver que tal sale, os seguiremos informando
Me gustaría saber un poco vuestra opinión y como planeáis evitar la
micro-estimación. Es decir, por lo que veo en el contrato todo se
centra en el punto de esfuerzo definido en una historia tipo que
habéis descrito. No entro ya en lo que acertádamente comenta Miguel
Ángel sobre la picaresca de ofrecer diréctamente un punto de esfuerzo
muy bajo, sino que voy más bien al caso de un proveedor que ve una
historia CRUD como la que ponéis y dice, "bah, esto está chupado" y
después resulta que en el resto de historias hay dos que no son
capaces, ya no por mala intención sino incluso por falta de contexto y
alcance general quizás. Quizás en este concurso no sea problema por el
tipo de aplicación, pero no sé hasta que punto esta micro-estimación
sería viable para otros concursos más complejos técnica y
funcionálmente. ¿Cómo os lo planteáis? ¿Poner una historia tipo
"media"? ¿Poner como historia tipo la más complicada para ver que
tiempo/esfuerzo os dan?
Tienes razón, esto lo hemos hablado y lo que estamos pensando hacer en el futuro (no ha dado tiempo para este pliego) es que nosotros vamos a adelantar la pila de producto no cerrada, con posibilidad de ampliar o reducir historias y vamos a hacer una estimación de las historias de forma no vinculante ni definitiva. La idea de avanzar la pila de producto y hacer esta estimación inicial es que las empresas puedan hacerse una idea de la complejidad global del proyecto pero siempre sin perder de vista que el alcance y el dinero no está cerrado.
Sobre el tema del adelanto de las estimaciones, siempre se podrán volver a reestimar en las reuniones de planificación de cada sprint. No queremos imponer nada porque entonces caeríamos en el modelo tradicional del que huimos.
Y lo segundo es simplemente comentar que en algún momento quizás sí
que se entra en demasiado detalle. Por ejemplo, ¿por qué las
estimaciones tienen que ser con planning poker (por cierto hay una
errata, habéis puesto "pocker")? ¿Es para que el proveedor meta en el
coste la baraja? :-) Es broma, pero hay muchas varias formas de
estimar en agile y tampoco creo que sea demasiado relevante para el
contrato el usar una u otra.
jeje, tienes razón, el tema de poner el "planning poker" es porque es la que utilizamos nosotros normalmente y nos gusta porque es un sistema en el que los desarrolladores pueden expresarse libremente sin estar condicionados. Nos ha dado buen resultado.
Un saludo.
José Manuel Beas
Aug 14, 2010, 11:30:36 AM8/14/10
to agile-spain
PERDÓN DE ANTEMANO POR EL LADRILLACO QUE SUELTO A CONTINUACIÓN
On 13 August 2010 10:46:33 UTC+2, Daniel, de la Cuesta Navarrete <cue...@gmail.com> wrote:
JMBTotalmente de acuerdo, la idea es que el punto de esfuerzo sea una historia de usuario con valor 1 y que este punto de esfuerzo sea diferente para cada proyecto. Por ahora ya tenemos 4 o 5 puntos de esfuerzo descritos para cada una de las tecnologías y tipos de proyectos con los que trabajamos.
>Los puntos de esfuerzo, en general, no son comparables de un equipo a
>otro ni de un proyecto a otro
Me refería concretamente a que lo que para el equipo "azul" de la empresa A, una historia de usuario de 1 punto puede ser (en mitad del proyecto, en las condiciones que explicáis en el pliego) un módulo completo, para el equipo "verde" de la empresa B eso puede ser una épica y decidir que es conveniente (para todos) partirla en varias historias y abordarla por partes. El hecho de que vosotros, como dueño del producto, digáis qué debe considerar el equipo como un punto, o dos, o cinco, o los que sean, es como si vosotros supiérais "cómo se va a hacer". Tener puntos de referencia sobre lo que es razonable para vosotros está bien, pero tengo la sensación de que no todos los ojos lo van a leer como eso. (Sigue leyendo porque abundo en esto más adelante).
En el pliego solo se describe el punto de esfuerzo, no se le pone tiempo ni precio, son las empresas las que dan sus estimaciones de tiempo para ese punto de esfuerzo. Esperamos que ellas se reunan internamente con sus desarrolladores para dar esa estimación porque si no van a fallar mucho. A partir de ahi, una vez que hemos definido el punto de esfuerzo, se sacarán las historias de usuario en las reuniones de planificación en las que nosotros seremos dueños de producto y estaremos presentes.
> Si lo que pretendéis es estandarizar
> los puntos de esfuerzo desde el punto de vista del dueño de producto
> (que sabe el qué) y sin contar con los equipos (que saben el cómo), ya
> nos contaréis cómo hacéis para tener historias de usuario y sus
> correspondientes estimaciones
No me refería a estandarizar en el sentido de poner precio sino en el sentido de que (unilateralmente) el dueño del producto está decidiendo cuánto esfuerzo representa para un equipo un tipo de historia de usuario. Conceptualmente es interesante porque nos lleva a la idea de "quien paga manda", que muchas veces se nos olvida, pero (en mi opinión) tal y como se ha articulado puede resultar perjudicial porque puede hacer que la parte comercial de las empresas (no la parte técnica, e.d. el equipo) hagan lo que se viene diciendo desde el principio de este hilo: que se ofrezcan "más puntos por euro" de lo que los equipos son, razonablemente, capaces de hacer a un ritmo sostenible.
En cualquier caso, supongamos que hay buena voluntad por ambas partes. ¿Qué impide en vuestro pliego una situación como la siguiente? Estamos en mitad del proyecto y al planificar una historia como la que habéis descrito en el pliego (un módulo de gestión para registrar "Productos" en el CMS). Supongamos que el proyecto no va tan bien como se esperaba y que en las retrospectivas se está detectando que sería interesante abordar historias de usuario como la anterior en dos partes: una primera en la que se desarrolla todo pero sin exposición pública, porque los despliegues no están siendo tan finos como debieran (fundamentalmente porque lo hace el departamento de sistemas, con sus propias herramientas y prioridades, y el feedback que se recibe es escaso y tardío). [¿Ese escenario se puede dar, verdad? Je, je] Y se deja la historia de usuario que expone los "Productos" para el siguiente sprint.
¿Cómo valoraríais esto? ¿La historia vale menos? (Tened en cuenta que hay aspectos ajenos al equipo que lo hacen ir más despacio, es decir, hacer los mismos puntos en más tiempo). ¿Cómo distinguís, en el pliego, esta circunstancia de una simple incompetencia del equipo? Incompetencia que podríamos ejemplificar como dice Martín o como sigue.
Un equipo se da cuenta a mitad de proyecto de que está acumulando mucha deuda técnica porque no habían tenido en cuenta ciertos detalles técnicos (o simplemente no tenían experiencia suficiente en la tecnología a usar). Su gerencia les impide refactorizar porque eso bajaría su velocidad (nominal) de desarrollo y, hasta el momento, nadie del cliente se está dando cuenta de que los defectos que están surgiendo son debidos a esta incompetencia del equipo. Así que siguen "como hasta ahora" con la esperanza (que todos sabemos vana) de que en algún momento la cosa mejore.
Lo que dices de avanzar la pila de producto ayudaría a reducir la incertidumbre pero tampoco me parece que vaya a resolver el problema de una manera definitiva porque, vuelvo a repetirme (lo siento), el dueño del producto no dice cómo se implementa una historia de usuario (salvo que desarrolle junto al resto del equipo), por lo que no puede decidir cuál será el esfuerzo a dedicar. Eso sí, el dueño del producto sí tiene la responsabilidad de no gastarse más dinero del razonable en una historia de usuario. ¿Cómo se traduce eso al castellano? Pues si miras el proyecto como una lista de historias de usuario, pues le pones un techo de coste a cada historia (tu estimación personal y la traducción de punto a euros) y vas una a una evitando que el equipo se columpie, o lo haces por "release", controlando los costes en cada una. (Te hablo de memoria, pero creo que Mike Cohn habla de esto en su libro "Agile Estimation and Planning")
Podríamos ver este contrato como uno del tipo "Tiempo y materiales" pero con terminología scrum. Por otro lado llevamos aplicando scrum en proyectos internos desde hace ya bastante timpo. En cuanto a proyectos externos con proveedores también estamos aplicando scrum (pero bajo un contrato tradicional) desde hace 1 año con bastante buen resultado. Ya que nos ha permitido ver cuando nos íbamos a estrellar, cuando había que recortar funcionalidad porque no llegábamos, etc.
>¿Habéis
>andado ya ese camino?
Me refería a si habíais desarrollado proyectos con proveedores que, haciendo Scrum, usárais las fórmulas a las que se refería Miquel. (Hay mucha documentación al respecto de casi todas estas fórmulas). Quizás un buen resumen de primera instancia sea http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts (que seguramente habréis leido ya porque sale de los primeros al buscar en google).
Mi pregunta se podría reescribir más bien como "¿habéis utilizado ya otras formas de licitar que han fracasado o no han funcionado lo bien que os gustaría? ¿cuáles han sido y por qué creéis que no han funcionado?". Si quieres no me contestes y en septiembre, a la vuelta de las vacaciones (yo estoy de vacaciones aún, je, je) quedamos y te entrevisto para un @podgramando ;-)
>¿Qué razones os han llevado a tomar estaPorque Scrum es lo que mejor nos está funcionando y llevamos bastantes proyectos gestionados de la forma tradicional que casi siempre salen mal.
>decisión?
Perdón por no ser suficientemente explícito, me refería a la decisión de pedir a los proveedores (empresas licitadoras) que ofertaran un precio por punto de esfuerzo. ¿Por qué no habéis pedido un precio por jornada? Que es lo típico.
Entiendo que, por lo que cuentas, como queréis que el proveedor elegido no sea sólo el más barato sino que os garantice que sabe lo que tiene entre manos, para llegar a ese número es necesario hacer un "release plan". Pero lo que no me termina de encajar es cómo esperáis que el "release plan" se pueda estimar sin que equipo y dueño de producto colaboren.
Tengo la sensación (es una sensación) de que, con el ánimo de ser muy puristas, habéis introducido el "punto de esfuerzo" en el pliego, obligando a ponerle precio (lo cuál no creo que sea inherentemente malo) pero donde el precio no lo pone la realidad de cómo ejecuta el equipo sino la negociación inicial (que es cuando más incertidumbre hay respecto al proyecto). Así, los puntos del principio del proyecto valen lo mismo que los del final del proyecto (cuando hay menos incertidumbre y lo que se está desarrollando, además, tiene menos valor para el dueño del producto).
¿No habría sido más fácil simplemente dar un tiempo y un presupuesto (techo de gasto), que cada licitador dijera qué es capaz de entregar y por cuánto (en base a unos criterios técnicos y unas conversaciones con el dueño del producto que expliquen/justifiquen su estimación) y establecer condiciones de win-win para ambas partes tanto en el caso de incompetencia (no son capaces de hacerlo) o de hipercompetencia (lo hacen todo y terminan antes de tiempo)? Ya sabes, si acabo antes me puedo ir a otro proyecto y empezar a darle valor (y a cobrarle) a otro cliente.
Entiendo que lo difícil para vosotros (como dueños del producto) sería decidir ese techo de gasto, pero ya lo estáis haciendo de todos modos, sólo que con la subasta de la licitación obligáis a los proveedores a recortar en lo recortable (y dado que el precio y el tiempo están fijados desde el principio del proyecto, el resto del camino ya lo conocemos, ¿verdad? ;-)
Quizás tenga mucho que ver con que vuestra "historia de usuario tipo" se mete mucho en el qué quereis pero sin explicar mucho el para qué. (Como <usuario> necesito <una funcionalidad> para <obtener un cierto beneficio>) Al obligarte a explicitar el beneficio obtenido, el dueño del producto se hace más consciente del "techo de coste" que puede esperar tener de una funcionalidad para que le sea rentable priorizarla más o menos arriba en la pila de producto y, por otro lado, el equipo es consciente de qué sinergias puede proponer en el corto, medio o largo plazo de la vida del proyecto.
No sé, Daniel, se me antoja más ágil trabajar enfocado en un plan de releases y en definir unos ámbitos funcionales para esas releases, que actuarían como hitos para decidir si el proyecto sigue adelante o si se debe corregir (adaptar) algo, incluida la cancelación del proyecto por alguna de las dos partes. (Insisto en que esta fórmula está ya explorada -ver la lista de Miquel- y hay experiencias (busca artículos sobre experiencias en "agile procurement") que la han puesto en práctica con éxito).
El plan de releases me parece fundamental como parte de la oferta. Yo, si fuera el que paga, preferiría tener cuanto antes software funcionando y EN PRODUCCIÓN. Me parece que estáis siendo poco "arriesgados" al no obligar al proveedor a sentirse parte de la generación de contenidos y excluir esto explícitamente de la oferta. No digo que estas tareas las deba asumir el proveedor, pero en estas condiciones os podéis encontrar con un portal teóricamente muy potente pero que, en el momento de empezar a introducir contenidos, sea un churro (no soporte picos de concurrencia, ciertos formatos en los que nadie pensó... etc) y el proyecto de desarrollo ya esté acabado. (Toda la ventaja de "lo ágil" la habrás perdido de un plumazo). Yo, si me permites "jugar a ser tú", habría decidido que la primera release del proyecto serán los contenidos de la categoría "A" -Información, Ayuda-Orientación, Educación-Formación, Opinión-Participación-). La que creáis más adecuada para tener un "bala trazadora" y que la mayor parte del proyecto se pueda poner en producción cuanto antes, aunque con carencias de contenido. Ya se irán añadiendo poco a poco. Para esto, lo normal será tener el rechazo de los políticos, que son muy amigos de las inauguraciones de obras faraónicas donde todo el mundo se queda con la boca abierta. Pero el agilismo no está hecho para eso. :-P
Respecto a las pruebas y la integración continua, creo que podríais haber incluido la expresión "pruebas automatizadas". También, tirando para mi huerto, me hubiera parecido genial que hubiérais hablado de "especificaciones ejecutables", "validación continua" y cosas por el estilo (pero bueno... "inspect-and-adapt") :-D
En resumen, que me sumo a la enhorabuena de todos por esta iniciativa y que, ojalá, funcione muy bien (aunque no sea a la primera, "inspect-and-adapt") y algún día podamos ser parte del mismo proyecto. [Esto último se puede considerar como peloteo diferido en el tiempo. Hablaré con David Bonilla para que lo implementen en próximas versiones de @Pelotator] :-)
Un abrazo,
Jose Manuel Beas
Daniel, de la Cuesta Navarrete
Aug 23, 2010, 7:32:22 AM8/23/10
to agile...@googlegroups.com
Hola de nuevo, he estado unos días de vacaciones y he conseguido no estar delante del ordenador :-)
JMB, nada de ladrillazo, me parecen interesantes tus aportaciones.
Sobre el tema que comentas de porqué no hemos pedido precio por jornada es porque confiamos en las métricas de scrum para evaluar el seguimiento y facturación de un proyecto y en ese sentido hemos puesto los conceptos de la metodología en el contrato. De la misma forma, pensamos que los puntos de esfuerzo son útiles para detectar qué proveedores nos ofrecen más valor, no más gente, o más horas trabajadas. Además queremos "educar" a nuestros proveedores para que trabajen de esa forma, te puedo asegurar que no hemos encontrado muchos hasta ahora.
Por todo lo demás me quedo con lo que comentas de "inspect and adapt".
Un saludo.
Muchos de los problemas que comentas, como el tema del plan de releases
2010/8/14 José Manuel Beas <jose....@gmail.com>
José Manuel Beas
Aug 23, 2010, 12:05:38 PM8/23/10
to agile...@googlegroups.com
On 23/08/2010, Daniel, de la Cuesta Navarrete <cue...@gmail.com> wrote:
>
> (...) pensamos que los puntos de
> esfuerzo son útiles para detectar qué proveedores nos ofrecen más valor, no
> más gente, o más horas trabajadas.
>
> (...) pensamos que los puntos de
> esfuerzo son útiles para detectar qué proveedores nos ofrecen más valor, no
> más gente, o más horas trabajadas.
Justamente lo que digo es que no termino de entender cómo vais a
comparar los puntos desfuerzo de un proveedor con los de otro. Cada
proyecto es diferente, cada equipo es diferente, cada historia de
usuario -aunque sea muy parecida- siempre es diferente -aunque sólo
sea porque se desarrolla en un momento diferente en el tiempo-, etc
así que no sé muy bien cómo de comparables van a ser. Quizás en el
largo plazo podáis clasificar a los proveedores por otras cualidades,
pero no termino de ver las cantidades (métricas intercambiables entre
equipos para compararlos).
¿Qué es lo que os interesa comparar exactamente entre dos proveedores
cualesquiera? Quizás es lo que no entiendo... :)
> Además queremos "educar" a nuestros
> proveedores para que trabajen de esa forma, te puedo asegurar que no hemos
> encontrado muchos hasta ahora.
>
[offtopic]
Mira que me creo una empresa "ahora mismo" y hago una oferta. ¡Uy!
Creo que según las últimas estadísticas se necesita más de un mes para
crear una empresa en España. :(
[/offtopic]
> Por todo lo demás me quedo con lo que comentas de "inspect and adapt".
>
En realidad es lo que define a un agilista: su disposición a estar en
un ciclo continuado de inspección de lo hecho y adaptación para
corregir/mejorar.
> Un saludo.
>
> Muchos de los problemas que comentas, como el tema del plan de releases
>
¿Algo en el tintero? ;-)
Un cordial saludo,
JMB
Daniel, de la Cuesta Navarrete
Aug 25, 2010, 2:31:09 AM8/25/10
to agile...@googlegroups.com
2010/8/23 José Manuel Beas <jose....@gmail.com>
On 23/08/2010, Daniel, de la Cuesta Navarrete <cue...@gmail.com> wrote:
>
> (...) pensamos que los puntos de
> esfuerzo son útiles para detectar qué proveedores nos ofrecen más valor, noJustamente lo que digo es que no termino de entender cómo vais a
> más gente, o más horas trabajadas.
comparar los puntos desfuerzo de un proveedor con los de otro. Cada
proyecto es diferente, cada equipo es diferente, cada historia de
usuario -aunque sea muy parecida- siempre es diferente -aunque sólo
sea porque se desarrolla en un momento diferente en el tiempo-, etc
así que no sé muy bien cómo de comparables van a ser. Quizás en el
largo plazo podáis clasificar a los proveedores por otras cualidades,
pero no termino de ver las cantidades (métricas intercambiables entre
equipos para compararlos).
¿Qué es lo que os interesa comparar exactamente entre dos proveedores
cualesquiera? Quizás es lo que no entiendo... :)
El punto de esfuerzo no será estandar para todos los proyectos, la idea es definir un punto de esfuerzo para cada proyecto. Entonces podremos comparar diferentes proveedores para un punto de esfuerzo dentro de un mismo proyecto.
Totalmente de acuerdo contigo en que incluso dentro de un mismo proyecto las historias valen diferente ya que no es lo mismo hacerlo al principio que al final, utilizar una tecnología u otra, un framework o hacerlo a mano.
Lo que queremos conseguir es definir (en la medida de lo posible) puntos de esfuerzo que no dependan de estos condicionantes, si vemos que no funciona nos plantearemos otros modelos.
Un saludo.
Un cordial saludo,
JMB
Dani
Aug 26, 2010, 3:36:21 PM8/26/10
to agile-spain
Primero daros la enhorabuena por el sacar el pliego de esta manera.
Nosotros estamos trabajando en Scrum con varias administraciones,
incluso expusimos nuestros ejemplos en la Conferencia Ágil 2010 de
Madrid, pero a diferencia de vuestra apuesta, fuimos entrando desde
abajo con pequeños proyectos, poco a poco han ido confiado en el
sistema de puntos, viendo sus resultados, hasta tal confianza que nos
han ido renovando los contratos sin problemas.
En cuanto al pliego me parece muy descriptivo y fácil de entender.
En nuestros primeros trabajos, lo que mas nos costaba era explicar la
medición en puntos de esfuerzo, mas de una reunión he tenido con
directores de proyectos para hacerle entender este concepto.
Espero que este sea un ejemplo a seguir por otras entidades.
--
Daniel Escribano
www.flowersinspace.com
www.scrum.es
Nosotros estamos trabajando en Scrum con varias administraciones,
incluso expusimos nuestros ejemplos en la Conferencia Ágil 2010 de
Madrid, pero a diferencia de vuestra apuesta, fuimos entrando desde
abajo con pequeños proyectos, poco a poco han ido confiado en el
sistema de puntos, viendo sus resultados, hasta tal confianza que nos
han ido renovando los contratos sin problemas.
En cuanto al pliego me parece muy descriptivo y fácil de entender.
En nuestros primeros trabajos, lo que mas nos costaba era explicar la
medición en puntos de esfuerzo, mas de una reunión he tenido con
directores de proyectos para hacerle entender este concepto.
Espero que este sea un ejemplo a seguir por otras entidades.
--
Daniel Escribano
www.flowersinspace.com
www.scrum.es
Juan Mari Huarte
Aug 30, 2010, 4:42:25 AM8/30/10
to agile-spain
Me ha encantado esta forma de plantear el proyecto. Pero quería hacer
una preguntas al aire desde mi poca experiencia.
Lo de puntos de esfuerzo, ¿No os resulta más interesante formularlo
como horas de esfuerzo y tarifa global por hora? A mi me resultaría
más fácil para comparar entre diferentes proyectos ¿no? Lo digo desde
el punto de vista vuestro, como parte que contrata.
Con lo de tarifa global, y para simplificar, y es algo que yo ya he he
hecho, es poner una tarifa general por hora por las horas globales
para todas las horas incurridas por el equipo. Así no tenemos que
andar haciedo cálculos con tarifas por perfiles profesionales. En esta
tarifa de hecho, suelo incluir dietas y desplazamientos.
Un saludo,
On 11 ago, 10:44, "Daniel, de la Cuesta Navarrete" <cue...@gmail.com>
wrote:
>
> Si le echais un vistazo al documento de prescripciones técnicas (http://www.juntadeandalucia.es/contratacion/document/download?refCode...),
una preguntas al aire desde mi poca experiencia.
Lo de puntos de esfuerzo, ¿No os resulta más interesante formularlo
como horas de esfuerzo y tarifa global por hora? A mi me resultaría
más fácil para comparar entre diferentes proyectos ¿no? Lo digo desde
el punto de vista vuestro, como parte que contrata.
Con lo de tarifa global, y para simplificar, y es algo que yo ya he he
hecho, es poner una tarifa general por hora por las horas globales
para todas las horas incurridas por el equipo. Así no tenemos que
andar haciedo cálculos con tarifas por perfiles profesionales. En esta
tarifa de hecho, suelo incluir dietas y desplazamientos.
Un saludo,
On 11 ago, 10:44, "Daniel, de la Cuesta Navarrete" <cue...@gmail.com>
wrote:
> Hola
>
> Os paso enlace de este concurso público con modelo Agile Scrum que hemos
> sacado recientemente desde Fundación Iavante en Andalucía,
>
> http://www.juntadeandalucia.es/contratacion/ContractNoticeDetail.acti...
>
> Os paso enlace de este concurso público con modelo Agile Scrum que hemos
> sacado recientemente desde Fundación Iavante en Andalucía,
>
>
> Si le echais un vistazo al documento de prescripciones técnicas (http://www.juntadeandalucia.es/contratacion/document/download?refCode...),
German DZ
Aug 30, 2010, 4:58:37 AM8/30/10
to agile...@googlegroups.com
Lo de la tarifa global, está muy bien, como costo hora del equipo. Pero falta un detalle para eso y es saber que puede hacer tu equipo con cierta cantidad de horas.
Por ejemplo:
Mi equipo ágil toma ritmo luego de 5 semanas de trabajo, osea que no te sirve contratarme digamos qeu menos de 9 semanas o algo así
Mi equipo funciona bien con iteraciones de 3 semanas, luego no puedes contratarme 7 días y 4 horas.
Mi equipo en esta tecnología en 2 días resuelve X puntos; pero otro equipo resuelve Y puntos. Incluso suponiendo que X e Y son iguales no sabes cuanto valor obtendrás porque se valoran en distinta cantidad de puntos las cosas y por lo tanto no puedes saber que equipo te entregará la mejor relación $/valor.
Por otra parte estamos suponiendo igual calidad.
Lamentablemente no aporto mucho con lo que digo, solamente establezco que no es tan simple comparar un proveedor con otro en base a tarifas.
Por ejemplo:
Mi equipo ágil toma ritmo luego de 5 semanas de trabajo, osea que no te sirve contratarme digamos qeu menos de 9 semanas o algo así
Mi equipo funciona bien con iteraciones de 3 semanas, luego no puedes contratarme 7 días y 4 horas.
Mi equipo en esta tecnología en 2 días resuelve X puntos; pero otro equipo resuelve Y puntos. Incluso suponiendo que X e Y son iguales no sabes cuanto valor obtendrás porque se valoran en distinta cantidad de puntos las cosas y por lo tanto no puedes saber que equipo te entregará la mejor relación $/valor.
Por otra parte estamos suponiendo igual calidad.
Lamentablemente no aporto mucho con lo que digo, solamente establezco que no es tan simple comparar un proveedor con otro en base a tarifas.
2010/8/30 Juan Mari Huarte <gusarm...@gmail.com>
Dani
Aug 30, 2010, 5:14:06 AM8/30/10
to agile-spain
En Scrum nunca se mide en horas, no tiene ningún sentido, precisamente
ese es un gran valor diferencial frente a otras métricas.
Si mides en horas normalmente no podrás aumentar la velocidad del
equipo ni conocer su velocidad máxima.
Otro problema es que la velocidad es del equipo en global, puede haber
personas que tarden mas tiempo en horas en hacer una cosa, pero que su
influencia y conocimientos aumente la producción de sus compañeros, es
por eso que esa persona no tiene por que tener la presión de horas/
persona/tarea, si no la de que el equipo mantenga una velocidad
constante.
En una empresa se dio el caso de prescindir de una persona que se
suponía que no cumplía con su producción, la velocidad del equipo
disminuyo un 20% en vez de mejorar. Esa persona aportaba otros
valores, no solo hora/rendimiento, que hacía que el equipo tuviera una
velocidad de producción óptimo.
ese es un gran valor diferencial frente a otras métricas.
Si mides en horas normalmente no podrás aumentar la velocidad del
equipo ni conocer su velocidad máxima.
Otro problema es que la velocidad es del equipo en global, puede haber
personas que tarden mas tiempo en horas en hacer una cosa, pero que su
influencia y conocimientos aumente la producción de sus compañeros, es
por eso que esa persona no tiene por que tener la presión de horas/
persona/tarea, si no la de que el equipo mantenga una velocidad
constante.
En una empresa se dio el caso de prescindir de una persona que se
suponía que no cumplía con su producción, la velocidad del equipo
disminuyo un 20% en vez de mejorar. Esa persona aportaba otros
valores, no solo hora/rendimiento, que hacía que el equipo tuviera una
velocidad de producción óptimo.
Dani
Aug 30, 2010, 5:20:31 AM8/30/10
to agile-spain
Creo que volvemos al mismo problema de horas/producción, algo que
Scrum precisamente intenta eliminar.
On 30 ago, 10:58, German DZ <g...@ndz.com.ar> wrote:
> Lo de la tarifa global, está muy bien, como costo hora del equipo. Pero
> falta un detalle para eso y es saber que puede hacer tu equipo con cierta
> cantidad de horas.
En Scrum se mira el número de puntos pos Sprint, suponagamos que un
equipo hace 40 puntos en un Sprint de 15 días, pues sabes que en una
semana hacen 20.
>
> Por ejemplo:
>
> Mi equipo ágil toma ritmo luego de 5 semanas de trabajo, osea que no te
> sirve contratarme digamos qeu menos de 9 semanas o algo así
>
> Mi equipo funciona bien con iteraciones de 3 semanas, luego no puedes
> contratarme 7 días y 4 horas.
>
Es que en Scrum no se contrata por días ni hora, si no por puntos de
esfuerzo, supongamos que en ese tiempo un equipo hace 20 puntos, pues
el cliente te contrata por 20 puntos, si el precio es por ejemplo de
500 $, pues el cliente te contrata por 10.000 $, si tu sprint es de
tres semanas, puedes priorizar para que todo el equipo produzca
primero en la pila del sprint las tareas del cliente que quiere la
entrega en una semana, y luego el Product Owner le hace una
presentación especial, mientras la pila de sprint sigue con otro
proyecto nuevo.
> Mi equipo en esta tecnología en 2 días resuelve X puntos; pero otro equipo
> resuelve Y puntos. Incluso suponiendo que X e Y son iguales no sabes cuanto
> valor obtendrás porque se valoran en distinta cantidad de puntos las cosas y
> por lo tanto no puedes saber que equipo te entregará la mejor relación
> $/valor.
En el concurso esta muy claro lo que es un punto, por lo que tomando
como referencia ese punto todas las demás tareas se deben poder
estimar. En caso de que un equipo diga 5 puntos a una tarea y otro 8,
evidentemente puedes elegir al proveedor que te cuesta menos,
suponiendo el mismo valor de calidad al punto. Un equipo con mucha
experiencia puede decir 5 y otro con poca 8, pero esa es la ventaja de
tener un equipo con mejores profesionales y mucha experiencia en hacer
una tarea.
>
> Por otra parte estamos suponiendo igual calidad.
>
> Lamentablemente no aporto mucho con lo que digo, solamente establezco que no
> es tan simple comparar un proveedor con otro en base a tarifas.
>
> 2010/8/30 Juan Mari Huarte <gusarmien...@gmail.com>
> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>
Scrum precisamente intenta eliminar.
On 30 ago, 10:58, German DZ <g...@ndz.com.ar> wrote:
> Lo de la tarifa global, está muy bien, como costo hora del equipo. Pero
> falta un detalle para eso y es saber que puede hacer tu equipo con cierta
> cantidad de horas.
equipo hace 40 puntos en un Sprint de 15 días, pues sabes que en una
semana hacen 20.
>
> Por ejemplo:
>
> Mi equipo ágil toma ritmo luego de 5 semanas de trabajo, osea que no te
> sirve contratarme digamos qeu menos de 9 semanas o algo así
>
> Mi equipo funciona bien con iteraciones de 3 semanas, luego no puedes
> contratarme 7 días y 4 horas.
>
esfuerzo, supongamos que en ese tiempo un equipo hace 20 puntos, pues
el cliente te contrata por 20 puntos, si el precio es por ejemplo de
500 $, pues el cliente te contrata por 10.000 $, si tu sprint es de
tres semanas, puedes priorizar para que todo el equipo produzca
primero en la pila del sprint las tareas del cliente que quiere la
entrega en una semana, y luego el Product Owner le hace una
presentación especial, mientras la pila de sprint sigue con otro
proyecto nuevo.
> Mi equipo en esta tecnología en 2 días resuelve X puntos; pero otro equipo
> resuelve Y puntos. Incluso suponiendo que X e Y son iguales no sabes cuanto
> valor obtendrás porque se valoran en distinta cantidad de puntos las cosas y
> por lo tanto no puedes saber que equipo te entregará la mejor relación
> $/valor.
como referencia ese punto todas las demás tareas se deben poder
estimar. En caso de que un equipo diga 5 puntos a una tarea y otro 8,
evidentemente puedes elegir al proveedor que te cuesta menos,
suponiendo el mismo valor de calidad al punto. Un equipo con mucha
experiencia puede decir 5 y otro con poca 8, pero esa es la ventaja de
tener un equipo con mejores profesionales y mucha experiencia en hacer
una tarea.
>
> Por otra parte estamos suponiendo igual calidad.
>
> Lamentablemente no aporto mucho con lo que digo, solamente establezco que no
> es tan simple comparar un proveedor con otro en base a tarifas.
>
Juan Mari Huarte
Aug 30, 2010, 5:25:28 AM8/30/10
to agile-spain
Ok. Estoy de acuerdo en que a mismas horas hay diferentes
productividades y apreciar esa productividad solo se conoce con
visibilidad del proceso y experiencia en proyectos similares.
Pues entonces solo queda definir bien claro que es un punto de
esfuerzo (el tema de siempre). Y será inevitable que las gerencias
hagan la traducción en coste y horas. De cajón de madera que se dice.
A ver si veo eso en algún taller y me pongo las pilas, que las
necesito ;-)
> > > Un saludo.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
productividades y apreciar esa productividad solo se conoce con
visibilidad del proceso y experiencia en proyectos similares.
Pues entonces solo queda definir bien claro que es un punto de
esfuerzo (el tema de siempre). Y será inevitable que las gerencias
hagan la traducción en coste y horas. De cajón de madera que se dice.
A ver si veo eso en algún taller y me pongo las pilas, que las
necesito ;-)
>
> - Mostrar texto de la cita -
German DZ
Aug 30, 2010, 5:27:17 AM8/30/10
to agile...@googlegroups.com
Exacto, el costo horario solo sirve para que el cliente sepa aproximadamente cuanto le costará continuar con el proyecto o modificar un poco la capacidad del equipo.
Por ejemplo, yo comercializo desarrollo de software bajo un contrato ágil con una base de €30/hora.... pero esto no te dirá mucho en forma aislada, lo que puedo decirte es: cada iteración de 3 semanas con un equipo de 2 devs + complementos te costará €9.000 pero no tienes muy claro que es lo que es capaz de producir este equipo y además para evaluar si mi oferta es válida o no deberás ver si el valor que obtienes por lo que te entregamos en cada iteración es superior a €9000.
Es decir que solo deberás preocuparte por elegir items del backlog que entren en 3 semanas y los mismos tengan un valor superior a 9000. Las horas, los problemas técnicos, el SVN, el bug de eclipse y todas esas cosas aburridas es problema de mi equipo. Si no te satisface lo que te entrega el equipo dices "no quiero más iteraciones" y ya está.
€30 la hora no significa nada. No es ni caro ni barato.
Por ejemplo, yo comercializo desarrollo de software bajo un contrato ágil con una base de €30/hora.... pero esto no te dirá mucho en forma aislada, lo que puedo decirte es: cada iteración de 3 semanas con un equipo de 2 devs + complementos te costará €9.000 pero no tienes muy claro que es lo que es capaz de producir este equipo y además para evaluar si mi oferta es válida o no deberás ver si el valor que obtienes por lo que te entregamos en cada iteración es superior a €9000.
Es decir que solo deberás preocuparte por elegir items del backlog que entren en 3 semanas y los mismos tengan un valor superior a 9000. Las horas, los problemas técnicos, el SVN, el bug de eclipse y todas esas cosas aburridas es problema de mi equipo. Si no te satisface lo que te entrega el equipo dices "no quiero más iteraciones" y ya está.
€30 la hora no significa nada. No es ni caro ni barato.
2010/8/30 Dani <da...@flowersinspace.com>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Ramon Gavira (SAGA)
Aug 30, 2010, 5:35:22 AM8/30/10
to agile-spain
Estoy deacuerdo con German, lo importante es lo que el equipo es capaz
de producir por iteración, al cliente le debe dar igual incluso si el
equipo está formado por 2 desarrolladores o 5.
Lo importante es que "cantidad de producto" puede el equipo
desarrollar por iteración.
On 30 ago, 11:27, German DZ <g...@ndz.com.ar> wrote:
> Exacto, el costo horario solo sirve para que el cliente sepa aproximadamente
> cuanto le costará continuar con el proyecto o modificar un poco la capacidad
> del equipo.
>
> Por ejemplo, yo comercializo desarrollo de software bajo un contrato ágil
> con una base de €30/hora.... pero esto no te dirá mucho en forma aislada, lo
> que puedo decirte es: cada iteración de 3 semanas con un equipo de 2 devs +
> complementos te costará €9.000 pero no tienes muy claro que es lo que es
> capaz de producir este equipo y además para evaluar si mi oferta es válida o
> no deberás ver si el valor que obtienes por lo que te entregamos en cada
> iteración es superior a €9000.
>
> Es decir que solo deberás preocuparte por elegir items del backlog que
> entren en 3 semanas y los mismos tengan un valor superior a 9000. Las horas,
> los problemas técnicos, el SVN, el bug de eclipse y todas esas cosas
> aburridas es problema de mi equipo. Si no te satisface lo que te entrega el
> equipo dices "no quiero más iteraciones" y ya está.
>
> €30 la hora no significa nada. No es ni caro ni barato.
>
> 2010/8/30 Dani <d...@flowersinspace.com>
> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegroups.com>
de producir por iteración, al cliente le debe dar igual incluso si el
equipo está formado por 2 desarrolladores o 5.
Lo importante es que "cantidad de producto" puede el equipo
desarrollar por iteración.
On 30 ago, 11:27, German DZ <g...@ndz.com.ar> wrote:
> Exacto, el costo horario solo sirve para que el cliente sepa aproximadamente
> cuanto le costará continuar con el proyecto o modificar un poco la capacidad
> del equipo.
>
> Por ejemplo, yo comercializo desarrollo de software bajo un contrato ágil
> con una base de €30/hora.... pero esto no te dirá mucho en forma aislada, lo
> que puedo decirte es: cada iteración de 3 semanas con un equipo de 2 devs +
> complementos te costará €9.000 pero no tienes muy claro que es lo que es
> capaz de producir este equipo y además para evaluar si mi oferta es válida o
> no deberás ver si el valor que obtienes por lo que te entregamos en cada
> iteración es superior a €9000.
>
> Es decir que solo deberás preocuparte por elegir items del backlog que
> entren en 3 semanas y los mismos tengan un valor superior a 9000. Las horas,
> los problemas técnicos, el SVN, el bug de eclipse y todas esas cosas
> aburridas es problema de mi equipo. Si no te satisface lo que te entrega el
> equipo dices "no quiero más iteraciones" y ya está.
>
> €30 la hora no significa nada. No es ni caro ni barato.
>
> > Para tener acceso a más opciones, visita el grupo en
> >http://groups.google.com/group/agile-spain?hl=es.- Ocultar texto de la cita -
Dani
Aug 30, 2010, 5:41:05 AM8/30/10
to agile-spain
Totalmente de acuerdo con vosotros.
Nosotros si un cliente no admite esto (presupuesto en puntos y
velocidad de ejecución de los mismos) no trabajamos con el,
sencillamente no cree en la metodologías ágiles, que busque otra
empresa que le cobre por horas, y que le meta horas de jefe de
proyectos, programador senior, junior, etc. Que luego se pierden horas
sin saber como.
On 30 ago, 11:35, "Ramon Gavira (SAGA)"
> > >http://groups.google.com/group/agile-spain?hl=es.-Ocultar texto de la cita -
Nosotros si un cliente no admite esto (presupuesto en puntos y
velocidad de ejecución de los mismos) no trabajamos con el,
sencillamente no cree en la metodologías ágiles, que busque otra
empresa que le cobre por horas, y que le meta horas de jefe de
proyectos, programador senior, junior, etc. Que luego se pierden horas
sin saber como.
On 30 ago, 11:35, "Ramon Gavira (SAGA)"
Juan Carlos Quijano Abad
Aug 30, 2010, 6:01:11 AM8/30/10
to agile...@googlegroups.com
Wow, ¿cómo se llama tu empresa? Y así le digo a mi director que tenemos un competidor menos :) (Obligar al cliente a una métodología de desarrollo...)) Por cierto, te equivocas creyendo que Agile es la única forma corrécta de establecer una relación contractual. Con Agile se puede, y mucho, engañar al cliente al mismo nivel que con cualquier otra filosofía empresarial. La Igualdad Agile = Bueno != Otras métologías, es una falacia.
Volviendo al tema,
Yo, que estoy ahora mismo con un equipo novel en scrum (y yo también), utilizo el término horas pero realmente las utilizo como puntos de esfuerzo. Así se puede ver en los Sprint Backlog un número de horas que supera a las humanamente posibles :)
A mi me encanta este tipo de contrato, pero mi empresa no se ha presentado al no querer tomar el riesgo de no tener garantizado un suelo. Montar un equipo cuesta mucho tiempo y dinero y creemos que es necesaria una garantia de que el proyecto no se va a cancelar en el primer o segundo sprint. Que, como en su momento comenté, las decisiones políticas y/o externas influyen, y mucho, en el desarrollo de los proyectos en la administración publica.
Volviendo al tema,
Yo, que estoy ahora mismo con un equipo novel en scrum (y yo también), utilizo el término horas pero realmente las utilizo como puntos de esfuerzo. Así se puede ver en los Sprint Backlog un número de horas que supera a las humanamente posibles :)
A mi me encanta este tipo de contrato, pero mi empresa no se ha presentado al no querer tomar el riesgo de no tener garantizado un suelo. Montar un equipo cuesta mucho tiempo y dinero y creemos que es necesaria una garantia de que el proyecto no se va a cancelar en el primer o segundo sprint. Que, como en su momento comenté, las decisiones políticas y/o externas influyen, y mucho, en el desarrollo de los proyectos en la administración publica.
Dani
Aug 30, 2010, 6:25:25 AM8/30/10
to agile-spain
On 30 ago, 12:01, Juan Carlos Quijano Abad
<juancarlosquij...@gmail.com> wrote:
> Wow, ¿cómo se llama tu empresa? Y así le digo a mi director que tenemos un
> competidor menos :) (Obligar al cliente a una métodología de desarrollo...))
> Por cierto, te equivocas creyendo que Agile es la única forma corrécta de
> establecer una relación contractual. Con Agile se puede, y mucho, engañar al
> cliente al mismo nivel que con cualquier otra filosofía empresarial. La
> Igualdad Agile = Bueno != Otras métologías, es una falacia.
Tienes toda la razón, a los clientes se les puede engañar con
> Wow, ¿cómo se llama tu empresa? Y así le digo a mi director que tenemos un
> competidor menos :) (Obligar al cliente a una métodología de desarrollo...))
> Por cierto, te equivocas creyendo que Agile es la única forma corrécta de
> establecer una relación contractual. Con Agile se puede, y mucho, engañar al
> cliente al mismo nivel que con cualquier otra filosofía empresarial. La
> Igualdad Agile = Bueno != Otras métologías, es una falacia.
cualquier cosa y cualquier planteamiento, y tampoco creemos que
Agilidad = Bueno, ni vendemos eso.
No es que nos equivoquemos, es que es en lo que nos hemos
especializado desde hace años, sabemos hacer una cosa y la hacemos
bien, por eso no encajamos en muchos tipos de clientes, no obligamos
al cliente a una tecnología, eso me parece absurdo, pero somos
especialistas en Scrum, si un cliente no encaja en esta manera de
trabajar pues no lo aceptamos y que se busque otro proveedor.
Gracias a especializarnos en una forma de trabajo, conseguimos buenos
resultados, pero que no quiere decir que un equipo en CMMI consiga
peores, pueden conseguir mejores resultados, todo depende de lo
preparado que este un equipo y como se entiendan, la metodología solo
es una forma de hacer la cosas, no tiene que por ser mejor ni peor,
cada uno se viste que como quiere :)
Lo bueno es que existen muchas maneras de hacer las cosas, si buscas
una empresa de desarrollo, lo mejor es encontrar la que se adapte a tu
manera de ser, y que no te impongan ni metodología ni tecnología.
>
> Volviendo al tema,
>
> Yo, que estoy ahora mismo con un equipo novel en scrum (y yo también),
> utilizo el término horas pero realmente las utilizo como puntos de esfuerzo.
> Así se puede ver en los Sprint Backlog un número de horas que supera a las
> humanamente posibles :)
>
> A mi me encanta este tipo de contrato, pero mi empresa no se ha presentado
> al no querer tomar el riesgo de no tener garantizado un suelo. Montar un
> equipo cuesta mucho tiempo y dinero y creemos que es necesaria una garantia
> de que el proyecto no se va a cancelar en el primer o segundo sprint. Que,
> como en su momento comenté, las decisiones políticas y/o externas influyen,
> y mucho, en el desarrollo de los proyectos en la administración publica.
>
> --
> Un saludo
> Juan Quijano
>
> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de Tiro con Arco <http://litelllon.blogspot.com/>
Juan Mari Huarte
Aug 30, 2010, 6:38:55 AM8/30/10
to agile-spain
¿Habéis hecho alguno la equivalencia, para vuestros cálculos, de 1 día
= 1 punto de esfuerzo?
Luego pasará lo de siempre, que un punto de esfuerzo es para unos un
día y para otros 2,...
Seguimos trabajando con puntos de esfuerzo... Al final he visto muchas
hojas para presupuestar que dicen que un pantalla de dificultad media
cuesta 2 días. La misma Excel te puede valer para dando puntos de
esfuerzo y todos contentos.
Igual ya habéis tratado este tema pero ¿Qué opináis?
> Blog de Tiro con Arco <http://litelllon.blogspot.com/>
= 1 punto de esfuerzo?
Luego pasará lo de siempre, que un punto de esfuerzo es para unos un
día y para otros 2,...
Seguimos trabajando con puntos de esfuerzo... Al final he visto muchas
hojas para presupuestar que dicen que un pantalla de dificultad media
cuesta 2 días. La misma Excel te puede valer para dando puntos de
esfuerzo y todos contentos.
Igual ya habéis tratado este tema pero ¿Qué opináis?
> Wow, ¿cómo se llama tu empresa? Y así le digo a mi director que tenemos un
> competidor menos :) (Obligar al cliente a una métodología de desarrollo...))
> Por cierto, te equivocas creyendo que Agile es la única forma corrécta de
> establecer una relación contractual. Con Agile se puede, y mucho, engañar al
> cliente al mismo nivel que con cualquier otra filosofía empresarial. La
> Igualdad Agile = Bueno != Otras métologías, es una falacia.
>
> Volviendo al tema,
>
> Yo, que estoy ahora mismo con un equipo novel en scrum (y yo también),
> utilizo el término horas pero realmente las utilizo como puntos de esfuerzo.
> Así se puede ver en los Sprint Backlog un número de horas que supera a las
> humanamente posibles :)
>
> A mi me encanta este tipo de contrato, pero mi empresa no se ha presentado
> al no querer tomar el riesgo de no tener garantizado un suelo. Montar un
> equipo cuesta mucho tiempo y dinero y creemos que es necesaria una garantia
> de que el proyecto no se va a cancelar en el primer o segundo sprint. Que,
> como en su momento comenté, las decisiones políticas y/o externas influyen,
> y mucho, en el desarrollo de los proyectos en la administración publica.
>
> --
> Un saludo
> Juan Quijano
>
> competidor menos :) (Obligar al cliente a una métodología de desarrollo...))
> Por cierto, te equivocas creyendo que Agile es la única forma corrécta de
> establecer una relación contractual. Con Agile se puede, y mucho, engañar al
> cliente al mismo nivel que con cualquier otra filosofía empresarial. La
> Igualdad Agile = Bueno != Otras métologías, es una falacia.
>
> Volviendo al tema,
>
> Yo, que estoy ahora mismo con un equipo novel en scrum (y yo también),
> utilizo el término horas pero realmente las utilizo como puntos de esfuerzo.
> Así se puede ver en los Sprint Backlog un número de horas que supera a las
> humanamente posibles :)
>
> A mi me encanta este tipo de contrato, pero mi empresa no se ha presentado
> al no querer tomar el riesgo de no tener garantizado un suelo. Montar un
> equipo cuesta mucho tiempo y dinero y creemos que es necesaria una garantia
> de que el proyecto no se va a cancelar en el primer o segundo sprint. Que,
> como en su momento comenté, las decisiones políticas y/o externas influyen,
> y mucho, en el desarrollo de los proyectos en la administración publica.
>
> --
> Un saludo
> Juan Quijano
>
> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de Tiro con Arco <http://litelllon.blogspot.com/>
>
> El 30 de agosto de 2010 11:41, Dani <d...@flowersinspace.com> escribió:
>
>
>
> > Totalmente de acuerdo con vosotros.
>
> > Nosotros si un cliente no admite esto (presupuesto en puntos y
> > velocidad de ejecución de los mismos) no trabajamos con el,
> > sencillamente no cree en la metodologías ágiles, que busque otra
> > empresa que le cobre por horas, y que le meta horas de jefe de
> > proyectos, programador senior, junior, etc. Que luego se pierden horas
> > sin saber como.- Ocultar texto de la cita -
> El 30 de agosto de 2010 11:41, Dani <d...@flowersinspace.com> escribió:
>
>
>
> > Totalmente de acuerdo con vosotros.
>
> > Nosotros si un cliente no admite esto (presupuesto en puntos y
> > velocidad de ejecución de los mismos) no trabajamos con el,
> > sencillamente no cree en la metodologías ágiles, que busque otra
> > empresa que le cobre por horas, y que le meta horas de jefe de
> > proyectos, programador senior, junior, etc. Que luego se pierden horas
Ramon Gavira (SAGA)
Aug 30, 2010, 6:59:39 AM8/30/10
to agile-spain
Nosotros usamos horas ideales para la estimacion de las historias de
usuario / Tareas (normalmente desglosamos las historias en Tareas).
Para el calculo de la velocidad, entendiendola como la capacidad del
equipo para terminar historias de usuario, calculamos la capacidad
ideal del equipo, la corregimos con un factor de foco (iniciamos con
un 0.75 lo corregimos segun la experiencia). si hay tareas que no se
corresponden directamente con la implementacion de historias, por
ejemplo crear paquetes, pasos a entornos de preproduccion,
documentacion etc... corregimos tambien esa dedicacion del tiempo
ideal.
Con lo anterior podemos calcular una velocidad inicial del equipo en
"unidades" de esfuerzo. Éste valor es el que nos sirve para calcular
el numero de historias de usuario que pueden entrar en un sprint en
concreto.
supongamos un equipo de 3 técnicos al 100%, una duracion de sprint de
2 semanas, una dedicación de 1 día para cerrar el sprint y un factor
de foco de 0.75
Velocidad = Miembros del equipo (3) x Dedicación (1) x [Duración
sprint (80) – Tiempo cierre(8)] x Factor Foco (0.75)
Velocidad = 3 x 1 x (80 – 8) x 0.75 = 162 Unidades de esfuerzo
Para una propuesta como la anterior, primero estimamos la historia de
usuario con en equipo de la forma en la que lo hacemos habitualmente y
posteriormente hacemos una equivalencia redondeando en unidades por
defecto ya que sólo deben entrar en el sprint historias completas.
Evidentemente, se oferta un equipo con una tecnología concreta y una
experiencia, esos tres parametros son los que nos sirven para poder
hacer la estimacion inicial de la historia de usuario segun nuestros
parametros y poder ofrecer al cliente una medida de velocidad que el
sea capaz de entender.
> > - Mostrar texto de la cita -- Ocultar texto de la cita -
usuario / Tareas (normalmente desglosamos las historias en Tareas).
Para el calculo de la velocidad, entendiendola como la capacidad del
equipo para terminar historias de usuario, calculamos la capacidad
ideal del equipo, la corregimos con un factor de foco (iniciamos con
un 0.75 lo corregimos segun la experiencia). si hay tareas que no se
corresponden directamente con la implementacion de historias, por
ejemplo crear paquetes, pasos a entornos de preproduccion,
documentacion etc... corregimos tambien esa dedicacion del tiempo
ideal.
Con lo anterior podemos calcular una velocidad inicial del equipo en
"unidades" de esfuerzo. Éste valor es el que nos sirve para calcular
el numero de historias de usuario que pueden entrar en un sprint en
concreto.
supongamos un equipo de 3 técnicos al 100%, una duracion de sprint de
2 semanas, una dedicación de 1 día para cerrar el sprint y un factor
de foco de 0.75
Velocidad = Miembros del equipo (3) x Dedicación (1) x [Duración
sprint (80) – Tiempo cierre(8)] x Factor Foco (0.75)
Velocidad = 3 x 1 x (80 – 8) x 0.75 = 162 Unidades de esfuerzo
Para una propuesta como la anterior, primero estimamos la historia de
usuario con en equipo de la forma en la que lo hacemos habitualmente y
posteriormente hacemos una equivalencia redondeando en unidades por
defecto ya que sólo deben entrar en el sprint historias completas.
Evidentemente, se oferta un equipo con una tecnología concreta y una
experiencia, esos tres parametros son los que nos sirven para poder
hacer la estimacion inicial de la historia de usuario segun nuestros
parametros y poder ofrecer al cliente una medida de velocidad que el
sea capaz de entender.
Dani
Aug 30, 2010, 7:00:40 AM8/30/10
to agile-spain
On 30 ago, 12:38, Juan Mari Huarte <gusarmien...@gmail.com> wrote:
> ¿Habéis hecho alguno la equivalencia, para vuestros cálculos, de 1 día
> = 1 punto de esfuerzo?
dado que vivimos nuestra vida en días y ciclos de 24 horas, es difícil
abstraerse de esta realidad, pero no es bueno hacer este cálculo por
dejamos de lado el Factor de Foco, que siempre corrige la producción,
Lo importante es la velocidad, es el dato relevante, velocidad por
sprint. Mentalmente haces cálculos de puntos por día, pero no debe ser
un dato a reflejar en ningún sitio, ni medible para tomar decisiones.
Juan Mari Huarte
Aug 30, 2010, 7:56:55 AM8/30/10
to agile-spain
Ok. Lo veo claro.
La última pregunta que me quedaría es si en la valoración de las
tareas / historias de usuario, manejáis horas ideales o bien tenéis
referencias para valorar, del tipo "una pantalla fácil cuesta x
unidades de esfuerzo" o bien las cartas la maneja cada uno a su
criterio.
Si tenía claro el concepto de que "hay que perseguir la velocidad".
Mil gracias por las respuestas dadas.
On 30 ago, 12:59, "Ramon Gavira (SAGA)"
La última pregunta que me quedaría es si en la valoración de las
tareas / historias de usuario, manejáis horas ideales o bien tenéis
referencias para valorar, del tipo "una pantalla fácil cuesta x
unidades de esfuerzo" o bien las cartas la maneja cada uno a su
criterio.
Si tenía claro el concepto de que "hay que perseguir la velocidad".
Mil gracias por las respuestas dadas.
On 30 ago, 12:59, "Ramon Gavira (SAGA)"
Dani
Aug 30, 2010, 8:50:01 AM8/30/10
to agile-spain
On 30 ago, 13:56, Juan Mari Huarte <gusarmien...@gmail.com> wrote:
> Ok. Lo veo claro.
>
> La última pregunta que me quedaría es si en la valoración de las
> tareas / historias de usuario, manejáis horas ideales o bien tenéis
> referencias para valorar, del tipo "una pantalla fácil cuesta x
> unidades de esfuerzo" o bien las cartas la maneja cada uno a su
> criterio.
gracioso, si tenemos que limpiar la casa, decimos: "Barrer una
habitación" vale un punto, pues otra historia es es Fregar el suelo,
¿vale lo mismo? ¿un punto? o ¿dos?, ya es el equipo el que estima si
vale o lo mismo o el doble o el triple.
Al final obtenemos las tareas valoradas respecto a la primera tarea.
Al terminar el primer sprint sabes que velocidad tiene el equipo.
Gustavo Cebrian Garcia
Aug 31, 2010, 5:28:41 PM8/31/10
to agile...@googlegroups.com
Hola, veo que habéis estado hablando de días ideales y puntos de historia. Bien, pongo aquí, según el libro de Mike Cohn ( Chapter 8 ), las consideraciones a favor de ambos métodos.
Considerations favoring Story Points
-Story points help drive cross-functional behavior. Es decir, se fomenta más trabajar en grupo, no la especialización. Mientras que estimar en días lleva a la especialización.
-Story points estimates do not decay. Dependiendo de la experiencia, los días ideales cambiarán en el futuro, lo que puede cambiar. Tamaña, sin embargo, es siempre tamaño.
-Story points are a pure measure of size. Con puntos de historia, siempre se estima por analogía. Con días ideales, siempre se va a la comparación con días reales.
-Estimating in Story points is typically faster.
-My ideal Days are not your ideal days. Hay diferencias entre los componentes de equipo a la hora de estimar en días ideales.
Considerations Favoring Ideal Days
-Ideal deays are easier to Explain Outside the Team
-Ideal days are easier to estimate at first
( Cierto que habla de estimar en días ideales, pero también tomando en cuenta el tamaño relativo )
Perdonadme por no explicar más cada punto. Si queréis, le podemos darle una vuelta.
( Por cierto, recomendación de Mike Cohn: story points )
Gustavo.
2010/8/30 Dani <da...@flowersinspace.com>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Juan Carlos Quijano Abad
Sep 1, 2010, 3:52:54 AM9/1/10
to agile...@googlegroups.com
Buenas,
A mi parecer es una discusión puramente semántica. Puntos de historia, puntos de esfuerzo, horas, dias ideales, etc. Hablamos de lo mismo: coger una tarea base, determinar una medida común del esfuerzo para realizarla y a partir de allí estimar el esfuerzo necesario para completar las tareas.
Me gusta mucho más la argumentación de Angel M. sobre porqué utilizar puntos de historia.
A mi parecer es una discusión puramente semántica. Puntos de historia, puntos de esfuerzo, horas, dias ideales, etc. Hablamos de lo mismo: coger una tarea base, determinar una medida común del esfuerzo para realizarla y a partir de allí estimar el esfuerzo necesario para completar las tareas.
Me gusta mucho más la argumentación de Angel M. sobre porqué utilizar puntos de historia.
Ricardo Borillo
Sep 1, 2010, 4:02:18 AM9/1/10
to agile...@googlegroups.com
Hola Juan Carlos,
¿Podrías enviar algún enlace a la argumentación que comentas?
Muchas gracias :)
---
Salut,
====================================
Ricardo Borillo Domenech
http://xml-utils.com / http://twitter.com/borillo
2010/9/1 Juan Carlos Quijano Abad <juancarl...@gmail.com>:
Ramon Gavira
Sep 1, 2010, 4:20:56 AM9/1/10
to agile...@googlegroups.com
Estoy completamente de acuerdo,
Entiendo que la idea es determinar una metrica que nos permita valorar los avances del equipo. A mi me gusta más usar dias/horas ideales precisamente por lo que comenta Angel M.: Es mas fácil estimar al principio y mas facil de entender desde fuera del equipo.
Desde mi punto de vista, con una simple conversión es posible pasar a puntos de historia.
En cualquier caso la estimación de la velocidad inicial del equipo, no deja de ser una estimación de la capacidad teórica, el día a día, la experiencia será la que indique la velocidad o ritmo del equipo. En los primeros sprint el factor de foco será siempre mayor, ya que el equipo debe ajustarse, y por tanto la velocidad menor. La pregunta es ¿Cuantos sprints deben pasar hasta que se estabilice la velocidad? ¿Cuantos consideramos como razonables? ¿Que es mejor una velocidad constante o un equipo que acelere en cada sprint?
----------------mensaje original-----------------
De: "Juan Carlos Quijano Abad" <juancarl...@gmail.com>
Para: agile...@googlegroups.com
Fecha: Wed, 1 Sep 2010 09:52:54 +0200
----------------------------------------------------------
Ramón Gavira Sáenz
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de SaGa Consulting. En el caso de haber recibido este correo electrónico por error, se ruega notifíquese inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of SaGa Consulting. If you have received this communication in error, please, notify the sender by reply e-mail.
P Wasting paper is harmful to the enviroment. Please consider that before printing this message.
Juan Carlos Quijano Abad
Sep 1, 2010, 4:22:09 AM9/1/10
to agile...@googlegroups.com
Buenas,
Me he pasado media hora buceando en mi buzón de gmail, leyendo cientos de mensajes de Angel pero no he encontrado en el que daba una clase magistral del porqué utilizar puntos de historia y planning poker para realizar las estimaciones.
Si lo encuentro hago un copy&paste.
Me he pasado media hora buceando en mi buzón de gmail, leyendo cientos de mensajes de Angel pero no he encontrado en el que daba una clase magistral del porqué utilizar puntos de historia y planning poker para realizar las estimaciones.
Si lo encuentro hago un copy&paste.
--
Un saludo
Juan Quijano
Vicenç Garcia
Sep 1, 2010, 4:27:42 AM9/1/10
to agile...@googlegroups.com
Buenas,
yo ahora mismo estoy estimando en dias ideales y no me acaba de gustar. Las razones són dos de las que dice Micke Cohn en su libro:
1.- Tus dias ideales no són mis dias ideales. Algo que a mi me parece que se hace en dos dias ideales a otro miembro del equipo le puede parecer que se hace en 5. Si cuentas con equipos no muy homogéneos, esto puede ser un problema.
2.- Hay cierta tendencia desde el exterior de juzgar estos días ideales. Es decir, si yo pongo que tardaré dos dias ideales, mi gestor inmediatamente traduce esto a dias normales y se putea si no está acabado a tiempo. O te pregunta pq si te ha dejado minimamente tranquilo, no hay manera que tus dias normales se acerquen a los ideales. No sé si me he explicado bien...
Otra de las razones por las que me gustan más los puntos de historia es que tienen significado de tamaño, no de duración.
Saludos.
PD: vamos a pasar a puntos de história en breve :P
2010/9/1 Ramon Gavira <ramon....@sagasoluciones.com>
Ramon Gavira
Sep 1, 2010, 4:46:19 AM9/1/10
to agile...@googlegroups.com
Me parece razonable lo que dices pero:
1.- Tus puntos de historia pueden tambien no ser los mios. Una historia de usuario de dos puntos para un miembro del equipo puede ser de cuatro para otro ¿no? En uno y otro caso tenemos el mismo problema.
2.- El problema es del gestor, que no entiende la metrica. En su defensa tengo que decir que los costes del equipo son proporcionales a los días reales de trabajo, la empresa no paga al equipo por puntos de nada, paga por meses, por tiempo... Esto debemos tenerlo en cuanta tambien.
Sigo pensando que da un poco igual usar puntos de historia o horas/dias ideales: Usamos una metrica para dimensionar el "tamaño" de las historias. Para calcular la Capacidad del equipo para resolver historias, tomamos la capacidad maxima y la corregimos con el factor de foco.
----------------mensaje original-----------------
De: "Vicenç Garcia" <vincen...@gmail.com>
Para: agile...@googlegroups.com
Fecha: Wed, 1 Sep 2010 10:27:42 +0200
----------------------------------------------------------
Jorge Uriarte Aretxaga
Sep 1, 2010, 4:51:56 AM9/1/10
to agile...@googlegroups.com
> 1.- Tus puntos de historia pueden tambien no ser los mios. Una historia de
> usuario de dos puntos para un miembro del equipo puede ser de cuatro para
> otro ¿no? En uno y otro caso tenemos el mismo problema.
>
> usuario de dos puntos para un miembro del equipo puede ser de cuatro para
> otro ¿no? En uno y otro caso tenemos el mismo problema.
>
en ambos casos, tiene que existir una definición clara punto/día -
equipo - proyecto. En ambos casos *no hay problema* ;)
Se ha explicado antes en este hilo que el punto base se asocia a la
complejidad de una historia de las mínimas y de estimación menos
refutable.
> 2.- El problema es del gestor, que no entiende la metrica.
No por eso el problema deja de existir, es importante poner las cosas
fáciles para todos.
>tomamos la
> capacidad maxima y la corregimos con el factor de foco.
>
de acuerdo, siempre que sigas midiendo y corrigiendo a lo largo de los
sprints, y no creas que lo que estimaste para aquel otro proyecto, o
unos números acordados al empezar el proyecto van a ser reales porque
los tenemos escritos ;)
Abrazos,
_
Jorge
Scrum Master
Sep 1, 2010, 2:49:26 PM9/1/10
to agile-spain
Bueno, he seguido con interés, si no pasión, el debate acerca de la
estimación del coste de desarrollo de un software siguiendo
metodología SCRUM, y hoy es un día importante en este debate, si nos
fijamos cómo nació, a raíz de una licitación pública con metodología
SCRUM, porque hoy ha sido la apertura pública de plicas, que creo que
no ha dejado indiferente a nadie.
Al hacerse públicas (bueno, parcialmente públicas...luego me explico)
los precios de las ofertas hemos encontrado licitaciones desde 67
euros el PdE (Punto de Esfuerzo) hasta 3.300 euros el PdE, con
cobertura lineal de todos los tramos (hay de 150, de 300, de 400, de
500, de 800, de 1500....). Por mucho que cambie la velocidad y el foco
de unas ofertas y otras, esta variabilidad no es algo normal, es algo
que nos debe hacer pensar a todos (a unos más que a otros). Creo que
hay que deducir que algo ha fallado (o ha funcionado?). El caballo de
batalla: ¿cómo estimar un desarrollo de software?, y otro caballo de
batalla: ¿cómo conseguir muchos puntos en una licitación pública?, en
este concurso parece que están los 2 al galope, y desbocados.
Parece que no queda muy claro qué es un PdE, qué es un SPRINT (de 2
semanas de duración...) o que es una historia, o seguramente lo que no
ha quedado claro es qué hay que hacer en un PdE, porque en este
negocio los costes de las empresas son similares y si sabemos lo que
hay que construir no puede existir tanta variabilidad entre las
ofertas, independientemente de la metodología a seguir y de las
velocidades y los focos.
Pero además parece que tenemos más problemas, y es que cuando la mesa
aplique la cláusula de baja temeraria va a ser un momento realmente
crítico, porque la corrección de velocidad y de foco no se incluye en
esta cláusula de baja temeraria, entonces, ¿cómo resolverá este Sudoku
la mesa?. Una posibilidad es que los pliegos están mal, que los
criterios de valoración no están bien planteados o alineados con los
requisitos del PPT. Otra posibilidad es que no hay baja temeraria y
otra que la hay, que también es defendible, pero a lo mejor el que más
puntos se lleva va a ir muy rápido en el SPRINT, rapidísimo, al
galope, de forma temeraria........y esto no es bueno para un proyecto
de SCRUM (ni de otra metodología), la velocidad también puede ser
temeraria en el desarrollo de software y en la carretera.
En definitiva, parece un fracaso de licitación, pero seguiremos
atentos al desenlace de la misma.
¿Qué pensáis?
On 1 sep, 10:51, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:
estimación del coste de desarrollo de un software siguiendo
metodología SCRUM, y hoy es un día importante en este debate, si nos
fijamos cómo nació, a raíz de una licitación pública con metodología
SCRUM, porque hoy ha sido la apertura pública de plicas, que creo que
no ha dejado indiferente a nadie.
Al hacerse públicas (bueno, parcialmente públicas...luego me explico)
los precios de las ofertas hemos encontrado licitaciones desde 67
euros el PdE (Punto de Esfuerzo) hasta 3.300 euros el PdE, con
cobertura lineal de todos los tramos (hay de 150, de 300, de 400, de
500, de 800, de 1500....). Por mucho que cambie la velocidad y el foco
de unas ofertas y otras, esta variabilidad no es algo normal, es algo
que nos debe hacer pensar a todos (a unos más que a otros). Creo que
hay que deducir que algo ha fallado (o ha funcionado?). El caballo de
batalla: ¿cómo estimar un desarrollo de software?, y otro caballo de
batalla: ¿cómo conseguir muchos puntos en una licitación pública?, en
este concurso parece que están los 2 al galope, y desbocados.
Parece que no queda muy claro qué es un PdE, qué es un SPRINT (de 2
semanas de duración...) o que es una historia, o seguramente lo que no
ha quedado claro es qué hay que hacer en un PdE, porque en este
negocio los costes de las empresas son similares y si sabemos lo que
hay que construir no puede existir tanta variabilidad entre las
ofertas, independientemente de la metodología a seguir y de las
velocidades y los focos.
Pero además parece que tenemos más problemas, y es que cuando la mesa
aplique la cláusula de baja temeraria va a ser un momento realmente
crítico, porque la corrección de velocidad y de foco no se incluye en
esta cláusula de baja temeraria, entonces, ¿cómo resolverá este Sudoku
la mesa?. Una posibilidad es que los pliegos están mal, que los
criterios de valoración no están bien planteados o alineados con los
requisitos del PPT. Otra posibilidad es que no hay baja temeraria y
otra que la hay, que también es defendible, pero a lo mejor el que más
puntos se lleva va a ir muy rápido en el SPRINT, rapidísimo, al
galope, de forma temeraria........y esto no es bueno para un proyecto
de SCRUM (ni de otra metodología), la velocidad también puede ser
temeraria en el desarrollo de software y en la carretera.
En definitiva, parece un fracaso de licitación, pero seguiremos
atentos al desenlace de la misma.
¿Qué pensáis?
On 1 sep, 10:51, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:
Gustavo Cebrian Garcia
Sep 1, 2010, 3:27:41 PM9/1/10
to agile...@googlegroups.com
Vincenc,
Siendo del Barca, tengo que decirte eso. Esto que dices ya lo he comentado yo! :-)
Pero tu lo has hecho mejor.
:-)
2010/9/1 Vicenç Garcia <vincen...@gmail.com>
Juan Carlos Quijano Abad
Sep 2, 2010, 3:33:05 AM9/2/10
to agile...@googlegroups.com
Buenas,
Ayer en la reunión de Agile-Madrid llegamos a conclusiones similares.
Ayer en la reunión de Agile-Madrid llegamos a conclusiones similares.
--
Un saludo
Juan Quijano
Ramon Gavira
Sep 2, 2010, 5:05:01 AM9/2/10
to agile...@googlegroups.com
Tambien he seguido apasionadamente este tema y pienso que si analizas las
ofertas, se pueden observar varias tendencias:
ofertas, se pueden observar varias tendencias:
1.- como decías, algunas no tienen muy claro que estaban ofertando. No
parece que quede claro que es un punto de esfuerzo y que un sprint.
2.- por otro lado la interpretación de la historia, sobre todo enmarcarla
en el contexto establecido (sprint intermedio, equipo estable, diseño y
maquetacion determinados etc), si que puede hacer que las velocidades
varíen. Ademas de esto cuando la funcionalidad es sencilla (evidentemente
segun la tecnologia que uses), puede llegar a ser muy atomica, de modo que
aunque las diferencias entre las ofertas parezcan muy grandes, basta una
variación de una unidad para que sea el doble una de la otra. Por ejemplo
si para calcular el Precio de la historia, una oferta estima 1 dia como
minimo una sobre estimacion nos dará 2 dias. Si calculas el coste de un
día de sprint y suponemos que las dos empresas obtienen el mismo valor
(como tu dices los costes son parecidos) la que estimó 1 ofertará la mitad
y la segunda ofertará el doble usando los mismos criterios de valoración.
Si te fijas quitando los "Outliers" los rangos de las ofertas van entre 200
y 600 basta con que alguien estime 1 dia (200), 2 (400) o 3 (600) para que
el rango parezca disparatado.
3.- ahora bien ¿porque unos estiman 1, 2 o 3? pues seguramente por que las
tecnologías son distintas o no se tiene experiencia, o la experiencia que
se tiene dicta eso. La licitación es para hacer un portal, ¿Que equipo vas
a poner al proyecto? Creo que con 3 desarrolladores/maquetadores que sepan
lo que hacen va sobrado. Si alguien ofertó 10 técnicos se le ha ido la
pinza. Estoy convencido de que precio alto será igual a velocidad lenta.
Por otro lado sería interesante saber como hace cada uno la estimación de
los costes (no el precio) ya que esto tambien afectará enormemente en el
precio: ¿Se tienen en cuenta costes de estructura, equipos,
inactividad,costes comerciales,...?
Con respecto a lo que quiere el cliente, creo que en este caso está claro,
tengo un presupuesto y quiero lo máximo que pueda hacer un buen equipo. El
principal problema es que en estos proyectos el alcance se va definiendo
según se va viendo el producto, ya que un portal web no es una aplicacion
con una funcionalidad concreta, sino que cambia segun las circunstancias o
estrategias que se quieran seguir en cada momento, las necesidades van
surgiendo. Por eso creo que la idea de esta licitación es bastante buena.
El que utilicemos scrum, simplemente nos marca una manera de hacer las cosas
y unas "metricas" sencillas para poder valorar el trabajo realizado, pero
sobre todo obliga a un seguimiento continuo que permite detectar
desviaciones pronto y poder actuar en consecencia.
Está claro que la única forma de que esto funcione es que Cliente /
Proveedor tengan la máxima confianza el uno del otro, el tema está en como
plasmar esto en una contrato y más aun en una licitación pública.
----------------mensaje original-----------------
De: "Scrum Master" scrumaste...@gmail.com
Para: "agile-spain" agile...@googlegroups.com
Fecha: Wed, 1 Sep 2010 11:49:26 -0700 (PDT)
-------------------------------------------------
> --
> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> agile...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> agile-spain...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/agile-spain?hl=es.
>
>
--
Ramón Gavira Sáenz
[www.sagasoluciones.com -> ../../../../../]
Scrum Master
Sep 2, 2010, 5:40:49 AM9/2/10
to agile-spain
Estoy de acuerdo contigo, entre 1 o 2 días no hay tanta diferencia,
pero para 3 ofertas de 200 400 y 600 la de 200 está en baja
temetaria !?. El establecer un criterio tan importante como el
económico en una unidad tan pequeña de medida, y tan poco relevante en
un proyecto global, creo que ha provocado este desastre.
> De: "Scrum Master" scrumaster.maste...@gmail.com
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
pero para 3 ofertas de 200 400 y 600 la de 200 está en baja
temetaria !?. El establecer un criterio tan importante como el
económico en una unidad tan pequeña de medida, y tan poco relevante en
un proyecto global, creo que ha provocado este desastre.
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario o destinatarios. Queda prohibida su divulgación, copia o
> distribución a terceros sin la previa autorización escrita de SaGa
> Consulting. En el caso de haber recibido este correo electrónico por error,
> se ruega notifíquese inmediatamente esta circunstancia mediante reenvío a
> la dirección electrónica del remitente.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario o destinatarios. Queda prohibida su divulgación, copia o
> distribución a terceros sin la previa autorización escrita de SaGa
> Consulting. En el caso de haber recibido este correo electrónico por error,
> se ruega notifíquese inmediatamente esta circunstancia mediante reenvío a
> la dirección electrónica del remitente.
Ramon Gavira
Sep 2, 2010, 5:57:23 AM9/2/10
to agile...@googlegroups.com
Estoy completamente deacuerdo contigo.
----------------mensaje original-----------------Fecha: Thu, 2 Sep 2010 02:40:49 -0700 (PDT)
-------------------------------------------------
----------------mensaje original-----------------Fecha: Thu, 2 Sep 2010 02:40:49 -0700 (PDT)
-------------------------------------------------
--
Ramón Gavira Sáenz
[www.sagasoluciones.com -> ../../../../../]
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario o destinatarios. Queda prohibida su divulgación, copia o
distribución a terceros sin la previa autorización escrita de SaGa
Consulting. En el caso de haber recibido este correo electrónico por error,
se ruega notifíquese inmediatamente esta circunstancia mediante reenvío a
la dirección electrónica del remitente.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Scrum Master
Sep 2, 2010, 6:05:35 AM9/2/10
to agile-spain
Ayer hice una reducción al absurdo sobre el pliego, imaginando que se
licitan zapatos pero puntua un 30% el precio de los cordones, y se
abren plicas sólo del precio de los cordones, y hay baja temeraria del
precio de los cordones....tendríamos un show parecido, lo importante
es el todo, el zapato, de ahí la pregunta, ?qué se está adquiriendo en
este pliego?, yo no lo tengo claro.
On 2 sep, 11:57, Ramon Gavira <ramon.gav...@sagasoluciones.com> wrote:
> Estoy completamente deacuerdo contigo.
>
> ----------------mensaje original-----------------
> ...
>
> leer más »
licitan zapatos pero puntua un 30% el precio de los cordones, y se
abren plicas sólo del precio de los cordones, y hay baja temeraria del
precio de los cordones....tendríamos un show parecido, lo importante
es el todo, el zapato, de ahí la pregunta, ?qué se está adquiriendo en
este pliego?, yo no lo tengo claro.
On 2 sep, 11:57, Ramon Gavira <ramon.gav...@sagasoluciones.com> wrote:
> Estoy completamente deacuerdo contigo.
>
> ----------------mensaje original-----------------
>
> leer más »
Reply all
Reply to author
Forward
0 new messages