Comments for Contratos para desarrollo �gil at http://www.navegapolis.net , comment 1 to 5 out of 5 comments http://www.navegapolis.net Wed, 20 Aug 2008 08:17:14 +0100 FeedCreator 1.7.2 http://www.navegapolis.net/content/view/639/58/#comment-951 El tema de vender Scrum como un servicio a mi también me suena sensato, pero el drama siempre ha sido el escepticismo del cliente con una metodología ágil, hace poco leí la tesis de un informático, quien buscó parecidos entre scrum y el PMBOK (estandar internacional para la gestion de proyectos). y tomando como base el PMBOK hace una especie de conclusion de Scrum como una implementacion del PMBOK, o también se podía entender como una futura extension del PMBOK. - Nicolas Pérez Wed, 12 Sep 2007 21:07:30 +0100 http://www.navegapolis.net/content/view/639/58/#comment-861 Me identifico totalmente con las cuestiones que plantea Joserra (¿quizá porque yo también estaba en esa discusión a la que hace referencia :P ?) También me parece muy juicioso, y creo que está en mente de muchos, lo que apunta Miguel. Es como la pescadilla que se muerde la cola: para que un cliente confíe en ti de cara a aceptar un marco de trabajo en el que las especificaciones del software no estén más que esbozadas parece que debe ser un cliente satisfecho, con el que ya se ha trabajado durante mucho tiempo, lo que nos llevaría a la situación que plantea Miguel, ¿cómo "arrancar" un proyecto bajo una metodología ágil, desde el principio? ¿Quizá mostrando "casos de éxito" a la empresa contratante de proyectos desarrollados con una metodología similar? ¿Y cómo tener casos de éxito si no conseguimos nuestro primer proyecto desarrollado bajo metodología ágil? Un gustazo leer este blog, saludos :) - J. Babuglia Mon, 18 Jun 2007 21:25:43 +0100 http://www.navegapolis.net/content/view/639/58/#comment-860 Hola Joserra y Miguel Desde luego Joserra que es difícil dar forma a un contrato que deje espacio para trabajar de forma ágil, y si el mismo Ken Schwaber en un apéndice de su segundo libro de scrum dice no tener solución para estos contratos... Las dos líneas que apunto en el post no son porque haya visto contratos así, sino por compartir las dos líneas que considero en un proyecto para un sistema muy "incierto" que dirijo. Como primera forma, y por trabajar con un proveedor de software sin contrastar, basarme en un modelo de servicio, pero definiendo para cada release del producto su duración y las funcionalidades esperadas. Y Aun así está resultando algo rígido, porque planteamos releases de 2 ó 3 meses, y desde marketing surgen modificaciones para las que resultan demasiado largas; y si estuviéramos a lo estrictamente pactado, el proveedor (Innova en este caso) me diría que son cosas no contratadas. Desde mi punto de vista, con un equipo conocido y contrastado y con implicación del cliente en el proyecto lo mejor sería trabajar directamente integrado en el equipo con un contrato de servicio. Soy consciente de que como cliente soy una excepción, porque soy a la vez "cocinero" y "fraile", y desde esta experiencia dual es desde la que me parecen dos formas de las menos malas (por supuesto, la buena, buena yo no la conozco). Y a lo que comentas, Miguel son los menos, pero cuando el sistema es novedoso, sin ningún referente anterior puede ser una decisión del propietario del producto. Como sería mi caso ahora: un servicio en Internet, del que no hay ninguna referencia porque es nuevo y no se ha prestado antes, y con carácter global. Opción a) ante la responsabilidad de dar cuerpo a algo desconocido: requisitos sobre estudios de tendencia, tests y entrevistas con usuarios... algo que ya he experimentado y que fueron 6 meses de requisitos con consultores especializados en diseño de productos y un presupuesto que ni te cuento. El resultado fueron unas 800 páginas de documentación definiendo con nitidez como debía ser el sistema, e incluso vaticinando el uso que tendría. Hoy es un sistema de contabilidad ya desarrollado, que al ponerse en uso ha revelado cosas que no deberían ser así. Opción b) (la que tomo ahora que en realidad no es por saber, sino por seguir aprendiendo). La visión de producto es muy amplia. Si opto por desarrollar requisitos estables con garantías para los inversores de que no son las primeras ideas de una persona, necesitaré algunos meses y una inversión en investigación de mercado. Si opto por desarrollar las 3 funcionalidades básicas del producto, el 10% escaso de la visión inicial, y sobre eso empezar a armar en función de lo que puedo tocar y probar, y la respuesta que origina al ponerlo en el mercado en alfa, luego en beta, e ir creciendo de forma iterativa e incremental... Bueno, pues esta es la segunda opción. Este tipo de proyectos son minoritarios, pero los hay, y en cuanto "salga al ruedo" y no me lo impida el compromiso de confidencialidad con la firma que lo produce, por aquí lo veremos ( y espero que por muchos sitios de Internet ;-) Quizá más que como ejemplo de un tipo de proyecto que lo necesita, es mas una decisión de negocio de ahorrar el tiempo de una investigación, que por la novedad no va a resultar más eficaz, ni menos costosa que comenzar a desarrollar e ir definiendo sobre líneas trazadoras. Saludos - Juan Mon, 18 Jun 2007 20:45:37 +0100 http://www.navegapolis.net/content/view/639/58/#comment-859 ¿Me podéis poner un ejemplo de un Proyecto que parta desde cero donde los requerimientos sean tan volátiles que la mejor forma de atacar el problema sea mediante un desarrollo ágil? Ante proyectos que ya estén en producción y para los que se necesiten crear nuevos módulos, o tal vez añadir una serie de nuevas mejoras, o al intentar sacar a flote una aplicación que está colapsada por errores, veo el usar un desarrollo ágil una solución estupenda. Pero ante un desarrollo que parta totalmente desde cero, se me hace muy difícil el imaginar plantear todo de forma ágil, sin una base mínima de conocimiento. Una serie de casos de uso base que se tenga que cumplir y que deja a la aplicación en una fase mínima a partir de la cual el cliente pueda empezar a trabajar. Y luego, una vez puesta en producción, atacar las sucesivas mejoras de forma ágil. - Miguel Mon, 18 Jun 2007 16:27:51 +0100 http://www.navegapolis.net/content/view/639/58/#comment-858 Pues lo hemos comentado y discutido en la empresa hace poco todo este tema. El pricnipal escollo, es que es muy dificil vender por lo que tu supones en una frase: "suponiendo que sea conocedor de la diferencia entre previsión y agilidad, y que reconozca que a su producto le conviene un modelo de desarrollo ágil" ... ! ahí es nada ! Por otro lado, desde el lado más desarrollador que todos tenemos :) vemos que realmente en muchos proyectos es lo más útil para el cliente, y lo más ventajoso para el desarrollo. Pero que es muy dificil venderlo. Se puede llegar a plantear en proyectos con clientes de muchos años , experiencia y confianza, pero raramente como punto de entrada en un negocio. Sobre los dos formas de contrato que mencionas,... ¿alguna vez has visto uno así para desarrollos informáticos? ¿la plasmación real de una metodología ágil en un contrato entre dos partes? - Joserra Mon, 18 Jun 2007 14:03:24 +0100