analisi-disegno.com

Homepage  | Blog | Per essere avvisati in caso di nuovi documenti | In English

Responsabilità per sviluppo e manutenzione

La separazione di responsabilità tra sviluppo e manutenzione è diffusa, soprattutto in ottica di outsourcing.

Uno dei vantaggi della separazione, e del potenziale outsourcing della manutenzione, viene considerato il liberare per nuovi progetti di sviluppo (considerati come fonte di innovazione) risorse che altrimenti sarebbero assegnate ad attività di manutenzione (considerate come carico negativo che frena l'innovazione).

Ma la separazione ha pro e contro. Seguono alcune opinioni.

Robert Glass: Software Maintenance is a solution, not a problem

James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 pp.250-251:

"Some of the most powerful design insights come late in the design cycle, particularly during the phase we affectionately call maintenance. But traditional staffing profiles deploy the most skilled designers at the front of the life cycle, leaving the later phases to maintenance engineers.

Valuable architectural insight tends to emerge late in the life cycle as a result of having addressed requirements from concrete, successive problems drawn from a given domain. It is at this late stage that a system can be refactored to consolidate design insight and to polish reusable artifacts. Such insight can be best harvested if people are deployed along the grain of the domain and if a given individual has responsibilityfor a well-defined part of it.[...]

Deploy people along the grain of the domain. That is to say, give them dedicated, long term responsibility for a manageable piece of the system, thereby enabling them to exploit opportunities to consolidate and improve the reusability of their parts of the system as experience accrues."

Pete McBreen: Software Craftsmanship, Addison-Wesley 2002, pp.167-168:

"Maintenance is the most important part of the life of any application.

Software engineering labeled the activities that take place after the initial release as 'maintenance', but this terminology is really just a hangover from the mechanical metaphor. What is really going on here is a whole series of smaller software development projects - some fixing mistakes - but the bulk is either changing the application to meet changing business needs or making major functional enhancements to the application. This work should not be performed by a separate maintenance team. It is wasteful to train a new team of developers when you already have a team perfectly capable of doing this work.

Maintenance needs to be made a high-status activity."

Mary and Tom Poppendieck: Implementing Lean Software Development, Addison-Wesley 2006, p.79

"Any code that is deployed will need maintenance, and sometimes separate maintenance teams are formed so that developers can focus on development and not have to task-switch with maintenance tasks. However, we generally recommend against this, because we believe that it is best for a team to remain with its product over the product's lifecycle. Otherwise people may begin to believe that there is such a thing as "finishing" the code, which is usually a myth. Code is a living thing that will (and should!) constantly change."

Pagina principale Project Management