Seguramente justo después de escribir la primera línea de código, ¿no? Votes: +0

Creo que al decidir que se cambia de la versión, por ejemplo, 0.5 a la 0.6 inicia el mantenimiento de la 0.5, pero solo aplica para algunos proyectos Votes: +0

No distinguir el desarrollo del mantenimiento es la aproximación al desarrollo de software que sigue Defect Driven Design....

http://memeagora.blogspot.com/2006/02/d-cubed_02.html

Es una aproximación muy interesante .... Votes: +0

Dependiendo del proyecto, el mantenimiento comenzará en un punto u otro. Lo genérico sería definir el inicio del mantenimiento una vez el proyecto esté en casa del usuario final. Votes: +0

Mantenimiento o Aumento del Valor?

Por lo que yo tengo entendido NUNCA hay mantenimiento en una gestión ágil.

Saludos.

Miguel. Votes: +0

¿Para qué?. Si estamos usando las prácticas de FDD, DSDM o Scrum... ¿por qué preocuparnos de aplicar procesos de mantenimiento, o las 7 fases del estándar IEEE?. Si lo hacemos ¿no nos complicaremos la vida queriendo hacer funcionar un extraño híbrido?.
Votes: +0

"En la gestión ágil de un producto de software, ¿cuándo acaba el desarrollo y empieza el mantenimiento?"

La verdad que conozco poco acerca de gestion agil de un producto de software, pero creo que el mantenimiento del código se debe realizar siempre. No es sólo para solucionar errores sino que para Refactorizar y asi en un futuro hacer mas simple el mantenimiento.
No se si esto aplicará para la gestion agil de un producto de software Votes: +0

El software como tal debe ser revisado día a día, pues esto sólo pasa cuando ese soft es usado por el cliente, lo cual es sinónimo del "éxito del software" ... por tanto, cuando más bugs tengamos, más éxito tiene nuestro software ... un poco liado, no?

Bueno, me parece que el mantenimiento (no definido como mantenimiento por contrato, o mantenimiento de releases) en la metodología Scrum (en agile imagino que también), no debería existir pues el software cambia a cada sprint de las necesidades (agilidad!), por tanto es mejora continua => cambio continuo => mantenimiento continuo

Por otro lado, la teoría dice que los productos entregados en al final de cada sprint deberían ser libres de errores => No mantenimiento de errores. Votes: +0

Yo prefiero el modelo similar a las herramientas de googlecomo gmail, o gogle reader, han notado cuanto tiempo llevan como Beta? es una beta perpetua que no cuenta con un lanzamiento oficial, tan solo las funcionalidades son agregadas y corregidas sobre el producto existente permitiendo el inmediato aprovechamiento por parte de los usuarios de las mismas

saludos gran pagina

Edson Votes: +0

Bueno para mi, el mantenimiento empieza cuando se empieza a modificar el plan de desarrollo inicial (sea en caso de corregir errores o añadir funcionalidades), por lo general esto es bastante dificil pues la gran mayoria de proyectos llevan varias revisiones de este plan antes de terminar, si empleamos una metodologia agil, la etapa de desarrollo podria ser la creacion de un metodo para solucionar una necesidad, en cambio el mantemiento nos llevaria a la modificacion de la solucion para esta necesidad(siempre se partira de algo, aun cuando desarrollemos modularmente, primero se deben establecer estos modulos correcta y concretamente, sino se estaria levantado un "castillo de naipes" o desarrollar al vuelo, lo cual nos generaria una etapa de mantenimiento muy grande) Votes: +0

Actualmente, con los cambios operativos que se producen en muchas empresas, que son de una cadencia alta, desde que se estan definiendo los requisitos se estan realizando modificaciones en los procesos que a su vez implican cambios en el desarrollo. Con esto quiero decir que el actualmente el desarrollo y mantenimiento de un producto, en la mayoria de las ocasiones, son indivisibles. Unicamente, en aquellos productos en los que en los procesos en los que se apoya dicho producto no cambian es donde es factible hacer un punto de corte entre la entrega del producto y mantenimiento. En este sentido, Scrum, desde mi punto de vista, contempla los desarrollos como algo continuo en cuanto a que te permite o no diferenciar esa separación dependiendo de las necesidades de cambio en los procesos operativos. Votes: +0