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:
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.
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.
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
Last updated
