# Requisitos comúns ### Title Requisitos comúns ### Patlet o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización. ### Problema O código común do repositorio compartido non satisfai as necesidades de tódolos proxectos que queren empregalo. ### Contexto * Moitos proxectos están tentando empregar un código común. Tódolos proxectos teñen acceso a un repositorio compartido. * Alguén (ou algún proxecto) escribe o código desde o principio e apórtao ao repositorio. * O código común é unha pequena porcentaxe da entrega global de calquera dos proxectos. * Cada proxecto ten o seu propio calendario de entrega, o seu propio conxunto de entregables e os/as seus/súas propios/as clientes/as. * Este modelo aplícase en calquera destas situacións: * Existe un/unha **propietario/a do código sólido**; de modo que tódolos cambios no repositorio compartido deben ser aprobados por el/ela. * A **propiedade do código é débil**, polo que ninguén é o/a propietario/a do código realmente. * Non hai **un/unha patrocinador/a benévolo/a**, polo que ningunha organización ou executivo/a proporciona recursos para organizar o código común á maneira InnerSource. ### Aspectos que mellorar O proxecto que fixo que o código estivera dispoñible ten certas necesidades, similares ás de parte da organización receptora, pero non exactamente as mesmas. Os requisitos do código han de derivarse das necesidades reais do/a cliente/a. As necesidades dos/as distintos/as clientes/as adoitan ser bastante similares; con todo, poden expresarse de maneira diferente ou ponderarse de distinto xeito entre uns/unhas clientes/as e outros/as. Un exemplo podería ser que algúns/algunhas clientes/as queren que un resultado se presente dunha maneira, mentres que outros/as queren que se presente na orde contraria. É sinxelo facer a tradución entre eles/as, pero require codificación adicional para un dos casos e, como resultado, o compoñente que computa o resultado non pode ser reempregado para ambos/as clientes/as. Moitos/as clientes/as queren que o/a provedor/a lles axude no que precisan. A empresa ten moitos/as enxeñeiros/as de sistemas que redactan os requisitos para os produtos. Suponse que estes requisitos foron extraídos das necesidades do/a cliente/a para guiar o desenvolvemento do produto. Reempregar o código é un obxectivo importante para aforrarlle tempo e diñeiro á empresa. ### Solución Hai dous aspectos que deben facerse en paralelo para resolver este problema: 1. Aliñar os requisitos dos proxectos para que o código que cumpra os requisitos dun proxecto tamén cumpra as necesidades dos demais proxectos. 2. Refactorizar o código en fragmentos máis pequenos para que os numerosos proxectos que o empregan poidan poñerse de acordo acerca dos requisitos. Ademais, aproveite que os/as clientes/as esperan que o/a provedor/a axude a dilucidar os requisitos. Consiga a aliñación dos requisitos durante as negociacións cos/coas clientes/as e inflúa nos requisitos do/a cliente/a na contra de cambiar o compoñente. No exemplo presentado anteriormente, o/a provedor/a axuda a ambos/as clientes/as a darse conta de que queren o mesmo e aforraralles esforzo (e diñeiro) a todos/as se se poñen de acordo á hora de elixir o resultado no mesmo formato. ![Requisitos comúns](/files/pX615HGTaaaFw6nIpTtS) ### Contexto resultante Para isto podería ser necesario negociar os cambios nos requisitos co/coa cliente/a. Os cambios tamén poden requirir a participación dos equipos de ventas e dos/as xefes/as de produtos para conseguir a aliñación cos requisitos. O/A cliente/a pode necesitar incentivos, como descontos, para aceptar os cambios. Un reto relacionado (e un posible modelo novo) é un exercicio circular de redacción de historias de usuario/a do que se informa nunha empresa que emprega InnerSource. En poucas palabras: * Os/As desenvolvedores/as escriben unha historia de usuario/a para resolver un problema dunha maneira. * Os/As directivos/as do programa reescriben a historia de usuario/a para expresar mellor as súas necesidades, mantendo a mesma esencia. No momento no que regresa ás mans dos/as desenvolvedores/as, estes/as non recoñecen o que querían facer nun primeiro lugar e, por tanto, resístense a poñelo en práctica. * A solución a este modelo é contar con máis asentos arredor da mesa de planificación para que as modificacións da historia de usuario/a se entendan en todo o proxecto, non só no grupo dos/as desenvolvedores/as ou directivos/as de programas. ### Exemplos coñecidos * Gran provedor/a de telecomunicacións ### Estado * Estruturado ### Autoría * Roberto Hanmer ### Recoñecementos * Manrique López * Daniel Izquierdo * Tim Yao * Sebastian Spier ### Tradución * Leticia Gómez Cadahía * María Lucía González Castro --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://patterns.innersourcecommons.org/gl/p/common-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.