Aplicació d’una metodologia àgil al desenvolupament web

Aplicació d’una metodologia àgil al desenvolupament web Memòria Autor: Pau Vila Director: Enric Mayol Abril 2016 2 3 Índex de continguts 1 – Introducció i context....................................................................................... 8 1.1 – Localització.................................................................................................. 8 1.2 – Situació inicial.............................................................................................. 9 1.3 – Formulació del problema.............................................................................. 9 1.4 - Abast del projecte......................................................................................... 11 2 – Motivacions i objectius.................................................................................. 13 2.1 – Motivació per al treball............................................................................... 13 2.2 - Motivació per a resoldre el problema.......................................................... 14 2.3 - Objectius...................................................................................................... 14 2.4 - Competències tècniques............................................................................... 16 3 – Metodologíes àgils.......................................................................................... 18 3.1 – Metodología anterior.................................................................................... 18 3.2 - Metodologies àgils........................................................................................ 18 3.3 – Què és Kanban?............................................................................................ 20 3.3.1 – Elements de Kanban. ................................................................................ 21 3.3.2 – Com s'aplica Kanban? .............................................................................. 27 3.3.3 – Kanban i SCRUM..................................................................................... 28 4 – Implantació a l'empresa.................................................................................. 29 4.1 – Kanban a Interiorvista................................................................................. 29 4.1.1 – Actors implicats....................................................................................... 29 4.1.2 – Proposta................................................................................................... 30 4.1.3 - Nou disseny Kanban................................................................................. 31 4.1.4 - Nova manera d’aplicar Kanban................................................................ 36 4.1.5 - SCRUM a Interiorvista............................................................................. 37 4.2 - Desviacions de projecte............................................................................... 37 4.2.1 - Ampliació del projecte............................................................................. 37 4 4.3 - Obstacles inicials....................................................................................... 38 4.3.1 - Desviació dels obstacles......................................................................... 38 4.4 - Posada en marxa de Kanban ..................................................................... 39 4.4.1 - Formació................................................................................................. 39 4.4.2 - Resposta de la gent.................................................................................. 40 4.5 - Com està funcionant? ................................................................................ 40 5 – Planificacions............................................................................................... 42 5.1 - Planificació inicial...................................................................................... 42 5.1.1 - Descripció de les tasques i recursos........................................................ 42 5.1.2 - Diagrama de Gantt.................................................................................. 44 5.1.3 - Recursos humans.................................................................................... 45 5.1.4 - Valoració d’alternatives i pla d’acció..................................................... 45 6 – Desviacions ................................................................................................. 47 6.2 - Desviació sobre la planificació inicial....................................................... 47 6.2 - Desviació sobre el diagrama de Gantt........................................................ 47 6.3 - Accions sobre el pla d’accions................................................................... 47 7 - Gestió econòmica.......................................................................................... 49 7.1 - Identificació i estimació dels costos........................................................... 49 7.1.1 Recursos humans....................................................................................... 49 7.1.2 Software.................................................................................................... 50 7.1.3 Hardware................................................................................................... 51 7.1.4 Altres costos.............................................................................................. 51 7.1.5 Costos inesperats....................................................................................... 52 7.1.6 Cost total.................................................................................................... 52 7.2 Control de gestió........................................................................................... 52 7.3 Desviacions econòmiques............................................................................. 53 8 - Informe de sostenibilitat................................................................................ 55 8.1 - Dimensió econòmica.................................................................................. 55 8.2 - Dimensió social.......................................................................................... 55 5 8.3 - Dimensió ambiental.................................................................................... 56 9 – Valoració...................................................................................................... 57 9.1 - Resultats obtinguts..................................................................................... 57 10 – Conclusions................................................................................................ 59 10.1 - S’ha assolit l’objectiu principal? ............................................................. 59 10.2 – Visió personal......................................................................................... 59 10.3 - Objectius futurs....................................................................................... 60 11 - Bibliografía................................................................................................. 62 12 - Annèx.......................................................................................................... 64 Índex de taules Taula 1................................................................................................. 44 Taula 2................................................................................................. 46 Taula 3................................................................................................. 49 Taula 4................................................................................................. 50 Taula 5................................................................................................. 51 Taula 6................................................................................................. 51 Taula 7................................................................................................. 52 Taula 8................................................................................................. 52 Taula 9................................................................................................. 53 Taula 10............................................................................................... 53 Taula 11............................................................................................... 54 Taula 12............................................................................................... 55 Índex de figures Figura 1............................................................................................... 8 Figura 2............................................................................................... 19 Figura 3............................................................................................... 22 6 Figura 4............................................................................................... 24 Figura 5............................................................................................... 25 Figura 6............................................................................................... 26 Figura 7............................................................................................... 32 Figura 8............................................................................................... 35 Figura 9............................................................................................... 36 Índex de figures d’annèx Figura 1............................................................................................... 64 Figura 2............................................................................................... 64 Figura 3............................................................................................... 65 Figura 4............................................................................................... 65 Figura 5............................................................................................... 66 Figura 6............................................................................................... 67 Figura 7............................................................................................... 68 Figura 8............................................................................................... 69 7 8 1. Introducció i context 1.1 Localització El projecte es situa en l’empresa “Interiorvista Decoración digital S.L”, empresa de disseny d’interiors amb seu central a Igualada. A Interiorvista podem diferenciar tres departaments principals en quant a la producció (deixant a part l’administració), que són Software, Gestió de projectes i Producció 3D. L’estudi estarà però, enfocat als departaments de Gestió i Software. El primer departament on s’ha implantat l’estudi, és el de Software ampliant l’estudi cap al de gestió posteriorment per a una perfecta coordinació entre departaments. El departament de Software de la seu Igualadina, està format per quatre programadors, dos backend, dos frontend i un analista de dades, el qual es va incorporar a la meitat del projecte per una clara necessitat d’un nou membre per a poder abarcar totes les tasques amb una bona organització. El departament de Gestió compta amb un nombre fixe de 5 Project Managers 1més un nombre variable d’ells que actua com a suport en nous possibles projectes i/o ajuda a projectes més grans. 1 Gestors de projectes 2 S’anomena ambient a una escena dissenyada en 3D 3 Fa referència a Project manager, la figura del gestor de projectes Figura 1 9 1.2 Situació inicial Inicialment a Interiorvista no hi havia implantat cap tipus de metodologia per al desenvolupament. La comunicació i el control es feia de manera lliure, és a dir, l’únic registre per controlar les tasques són els mails interns de l’empresa. Es va intentar portar un programari de control i comunicació per les tasques anomenat JIRA. Aquest inclou varies eines per a facilitar l’implantació de metodologies àgils, tot i així, només es fa per registrar noves tasques i no pas per a portar el seu seguiment. Tot i tenir JIRA, el que es vol aconseguir és una fluïdesa de treball en el departament de programació, al ser un equip petit i proper, la comunicació virtual podría ser un coll d’ampolla per tant s’estudiarà l’implantació de la metodologia físicament. Per a recollir les analítiques només es disposava de l’API per defecte que Google Analytics posa a disposició del públic. Desde cada projecte enviavem events per cada interacció entre la persona i l’aplicació amb un seguit de funcions sense cap mena de Framework que ho gestionés, cosa que dificultava l’implantació ràpida i genèrcia d’estadístiques per a nous projectes. 1.3 Formulació del problema És conegut, que la desorganització en una empresa és un mal hàbit i pot esdevenir una de les causes que porti a aquesta a la fallida. En una empresa de software, la desorganització pot arribar a ser un “virus”. Ordenar el codi de varis desenvolupadors i organitzar-lo per a que sigui coherent i entenible en un mateix projecte pot ésser una tasca molt feixuga si no es fa de bon principi, i pot portar problemes greus en el codi tal i com poden ser el codi doblat, codi residual o inclús codi actual que fagi un mal ús del codi anterior i per tant, actuant com a codi maliciós. Un altre dels problemes que pot portar la desorganització en el desenvolupament a nivell empresarial podrien ser l’incompliment dels períodes d’entrega. En aquest cas, la falta d’organització és una clara culpable del problema. En el moment en què un projecte no porta un ordre, cada desenvolupador pot oblidar quines tasques està portant a terme el seu company i treballar en la mateixa tasca, perdent temps de desenvolupament de noves tasques com a conseqüencia directa. Això deriva directament en pèrdues econòmiques ja que el temps i diners invertits en aquella tasca doblada és inútil. 16 de pàgina, per tant, aquest sería un dels meus nous objectius junt amb l’altra part d’analytics que era la gestió dels comptes d’usuari dels nostres clients i els seus permisos. Finalment a arrel de noves tecnologíes implantades a l’empresa per el control de costos i de tasques, i quasi a part del treball, vaig decidir també com a objectiu personal, investigar i proposar alguna nova eina de treball relacionada amb la meva especialitat que aportes un grau de qualitat a la nostra feina. Finalment aquesta part va ésser la documentació i l’eina ha sigut “CONFLUENCE” de l’empresa Atlassian. Amb aquesta petita desviació, els meus objectius es van ampliar envers als inicials, donant més valor al treball en sí i a la meva figura en l’empresa. 2.4 Competències tècniques A continuació es descriuen les competències tècniques del treball i com s’han relacionat en la feina a l’empresa: • CSI1: Demostrar comprensió i aplicar els principis i les pràctiques de les organitzacions, de manera que puguin exercir d'enllaç entre les comunitats tècnica i de gestió d'una organització, i participar activament en la formació dels usuaris. o Envers aquesta competència, la principal, es basa l’estructura principal d’aquest estudi. L’implantació de Kanban a Interiorvista ha passat per fases d’aprenentatge en profunditat de la metodología i per una formació als altres usuaris per tal de poder portar a terme l’objectiu. En totes i cadascuna de les fases he estat present com a figura clau. • CSI2.1: Demostrar comprensió i aplicar els principis i les tècniques de gestió de qualitat i d'innovació tecnològica a les organitzacions. [Bastant] o En aquest apartat, ha estat cobert en gran part per la part de Google analytics ja que és la part més tecnològica que he portat a terme junt amb “CONFLUENCE”. Tot i així, l’ús i intent d’implantació de Kanban mitjançant JIRA també va ésser un pas per a assolir aquesta competència. 17 • CSI2.2: Concebre, desplegar, organitzar i gestionar sistemes i serveis informàtics, en contextos empresarials o institucionals, per a millorar-ne els processos de negoci; responsabilitzar-se'n i liderar-ne la posada en marxa i la millora contínua; valorar el seu impacte econòmic i social. [En profunditat] o De nou aquesta competència ha estat coberta per la branca principal de l’estudi ja que s’ha millorat l’organització de les tasques a l’empresa i la valoració de l’estudi ha estat satisfactori un cop implantat. • CSI2.7: Gestionar la presència de l'organització a Internet. [Una mica] o La part d’analytics cobreix aquesta part. • CSI3.1: Demostrar comprensió dels principis de l'avaluació de riscs i aplicar-los correctament en l'elaboració i l'execució de plans d'actuació. [Una mica] o Aquesta competència està coberta en tots els aspectes ja que totes les accions i decisions preses afectaven directa o indirectament a un risc. • CSI3.5: Proposar i coordinar canvis per a millorar l'explotació del sistema i de les aplicacions. [Una mica] o He sigut part de les reunions sobre aquests projectes per tant he participat activament en la decisió de canvis sobre els projectes. • CSI4.2: Participar activament en el disseny, la implementació i el manteniment dels sistemes d'informació i de comunicació. [Una mica] o CONFLUENCE, analytics i Kanban han estat part de la meva feina a Interiorvista i he participat activament en tots. 18 3. Metodologíes àgils 3.1 Metodología anterior A Interiorvista, es desenvolupa Software desde el primer dia de la seva creació, però a diferència d’avui, el departament de Software d’aquells dies estava format per una sola persona. La metodología de treball per aquells temps era doncs simplement la gestió del temps que distribuïa l’únic programador del equip. A mida que l’equip va créixer, les tasques i la feina va anar en augment però no va passar el mateix amb l’organització. Aquesta va continuar éssent caòtica fins al cap dels anys. Ara fa un any i mig, desde Interiorvista es va decidir organitzar les tasques a fer i es va decidir fer ús del sistema JIRA. Aquest sistema, gestiona les tasques assignant-les a un perfil i una fase del projecte. Aquestes tasques es poden descriure amb tot luxe de detall ja que l’eina disposa d’un editor de textos en format HTML amb possibilitat d’adjuntar imatges i fins i tot arxius en la tasca. Aquestes tasques però passaven únicament per els estats de “Fent-se” i “Revisant/Fetes”, cosa que deixava la part organitzativa del sistema quasi a zero. El sistema JIRA incorpora eines per a portar a terme metodologies àgils com Kanban amb facilitat i sense necessitat d’estructures físiques com pissarres o targetes i promou les diferents fases d’un projecte per a que s’assoleixi un mínim de qualitat. No ha sigut fins al present que a Interiorvista s’ha optat per seguir varies doctrines d’organització laboral per tal d’agilitzar les tasques i millorar la productivitat dels treballadors i un ambient de treball més distés, ja que les tensions per mala comunicació eren més que freqüents. 3.2 Metodologies àgils 19 Les metodologies àgils són un seguit de tècniques que ajuden a l’organització de les tasques en el desenvolupament del Software. Aquestes prioritzen l’efectivitat davant de la documentació exhaustiva. Les metodologies tradicionals a diferència de les àgils, prioritzen la generació de documentació davant la rapidesa i/o eficiència en la productivitat del projecte. Les metodologies àgils si que generen documentació a diferència de la creença general que s’ha generat al seu voltant, el que sí que passa és que les prioritats de producció molts cops deixen de banda una exhaustiva documentació del projecte cosa que porta a pensar que l’obvía. Tot i semblar una manera ràpida i “barata” d’accelerar la producció, les metodologies àgils no són sempre la millor opció. Cada projecte té unes preferències i unes dimensions que s’han d’estudiar amb atenció ja que podem caure en l’error de començar a produïr un projecte seguint una metodología erronea i podría donar-se el cas de ser massa tard per tornar enrere i generar mancances en el producte final amb la conseqüent pèrdua d’interès del client o pèrdua de qualitat. Les metodologies àgils estan caractreritzades per seguir un procés iteratiu. Entenem per procés iteratiu per aquell que dins d’un projecte va produint “iteracions”, on cada iteració pot ésser una tasca i repetir-la indefinidament fins que aquesta quedi resolta perfectament. Es poden portar varies tasques alhora i les iteracions poden repetir-se tan sols un cop per tasca. En algunes de les metodologies l’iteració passa per diferents fases com desenvolupament, revisió, pendent... Figura 2 20 Les metodologies àgils més populars són SCRUM, XP i Kanban entre moltes altres. No totes les metodologies són excloents, és a dir, que si es segueix una ja no es pot seguir alhora una altra, sinó, que algunes es complementen com per exemple SCRUM i Kanban es poden portar alhora perfectament fusionant els seus conceptes d’Sprints d’SCRUM i el control de fases de Kanban. 3.3 Què és Kanban? Kanban és una metodología àgil originalment utilitzada per Toyota en la seva cadena de muntatge on utilitzava targetes per informar de les necessitats de material. Com a curiositat, el seu nom és bastant explicatiu ja que KAN vol dir visual i BAN vol dir targeta, cosa que diu bastant de com funciona amb el seu mètode de targetes a simple vista. Els principis de Kanban són principalment els de les metodologies àgils. El fet és que ho separa en quatre grups gràcies a les ventatges que aporta aquesta metodología envers altres. Els quatre principis bàsics de Kanban són: 1 – Qualitat garantida: Un dels principis de Kanban és que les tasques han de sortir amb una qualitat excel·lent de bones a primeres per així reduïr el temps de producció, és a dir, podem trigar més en realitzar una tasca però no haurem de repetir-la varis cops. Això es pot assolir gràcies a la divisió d’una tasca principal en tasques de mida inferior més assolibles ràpidament i fàcils de validar. A part d’això, una o varies de les fases asseguren la qualitat de la tasca creada. 2 – Minimitzar la brossa: Al dividir les tasques a la mínima expressió, les tasques que no són estrictament necessàries per al projecte són eliminades ràpidament, evitant així la creació de codi innecessari i/o funcionalitats extra que podrien endarrerir el desenvolupament del projecte de manera notable. Aquesta neteja de tasques pot evitar també algunes funcionalitats que entressin en dissonància amb altres de necessaries. 3 – Millora contínua: Per a millora contínua entenem que les tasques van sorgint a mida que van sorgint noves necessitats, és a dir, si en qualsevol moment el client demanés una nova funcionalitat per a l’aplicació que s’està desenvolupant, el gestor del projecte analitzaria la possibilitat de portar a terme la tasca i a continuació es dividiria aquesta tasca més gran en varies d’inferior repercusió que no afectaríen de manera negativa al projecte principal, per tant, 21 en qualsevol moment podrem millorar la nostra aplicació sense cap mena d’impediment sobre les especificacions o sobre el planning ja que aquest es pot anar construint quasi sobre la marxa. 4 – Flexibilitat: La flexibilitat d’aquesta metodologia és molt alta ja que cadascú podrà aplicar Kanban a la seva manera. Si no necessitem o no disposem de diversos departaments que testegin per separat les aplicacions, la columna de testeig serà única, en canvi si primer testeja l’aplicació el programador i despres el PM, dividirem doncs la columna de Test review 4de tal manera que es subdivideixi en dos columnes, una per a cada departament. Aquest exemple es pot aplicar a totes i cada una de les columnes de la base. Podem també si es desitja, crear noves columnes per a acomodar millor les nostres necessitats envers el projecte. Cada aplicació de Kanban pot ser personalitzada tan per departament com per projecte o grup de treball. Aquesta eina proposa unes pautes que nosaltres podrem personalitzar al nostre gust i necessitats. 3.3.1 Elements de Kanban Per entendre com funciona Kanban, primer explicarem els elements que composen les bases del Kanban, ja que per aplicar-lo físicament, serà necessària una petita estructura de soport. Com a primer element tenim el que anomenarem base. La base com a tal, és una pissarra on aplicarem el Kanban i on tot el workflow d’un projecte es veurà reflectit. Aquesta pissarra l’anomenarem base ja que tota tasca, columna i anotacions de qualsevol tipus hauran de passar per ella. En la següent figura podem apreciar l’aspecte d’un expemle de pissarra “base”. 4 En revisió 22 A continuació aprofundirem el concepte de “base” definint els seus components: Columna: per a columna ens referim a tots i cada un dels estats per els que passa una tasca. Com bé s’ha explicat anteriorment, cada projecte pot tenir diferents necessitats. El nombre d’aquestes columnes per tant, podrà variar en cada un dels projectes. Totes les columnes tindran un títol per a descriure ràpidament en quina fase estan les tasques incloses i seran separades clarament de les altres columnes restants per tal de no aixecar confusions entre els usuaris del Kanban. Kanban ens proposa o s’ha estés la costum, de brindar-nos unes columnes claus per a un correcte funcionament de Kanban, deixant a part les necessitats personals de cada instància d’aquest. Cal remarcar que totes les columnes, tenen un nombre limitat de tasques possibles. Això és degut a que Kanban detecta ràpidament els colls d’ampolla gràcies a aquest mètode. El nombre d’elements que hi hagi en aquell moment dona una clara idea de com està anant la feina en general. En cas de que una de les columnes arribés al màxim nombre possible de tasques per ella, i les anteriors columnes es veguessin obligades a aturar la seva producció, s’hauría detectat en aquell precís instant, un clar coll d’ampolla, cosa que podría provocar una redistribució del personal per a poder donar abast a les tasques que generen aquesta aturada. 1. En primer lloc tenim la columna de “Backlog”. Les tasques situades en aquesta columna estan pendents d’aprobació, és a dir, es tracten com a futuribles, futures possibles Figura 3 23 tasques que es podríen portar a terme si finalment s’acceptessin com a possibles i viables. Quan una d’aquestes tasques passa pels “filtres”, s’accepta i es podría passar a la següent columna. 2. La segona columna és la “To do”. Aquesta columna ens mostra aquelles tasques que han estat acceptades i que estan llestes per a començar a ser desenvolupades. Com bé s’ha dit abans, tot i tenir infinites possibilitats, el nombre de tasques a fer serà finit per a evitar una sobrecàrrega de tasques i una possible confusió dels usuaris del Kanban i un possible desordre en el desenvolupament. 3. En tercera instància tenim la columna “Doing”. En aquesta columna es reuneixen totes les tasques que actualment s’estan desenvolupant. Hi ha grups que treballen amb aquesta columna dividida en dues columnes per separat. Aquesta gent utilitza les columnes d’anàlisis i de codi. En la columna d’anàlisi, posarem totes les tasques que s’estan analitzant, és a dir, cercar informació i/o tecnologíes per a desenvolupar-la de manera òptima. D’altra banda, la columna de codi, ens informa de totes aquelles tasques ja analitzades que s’estan portant a terme. Si es desitja, es pot fer servir la columna de “Doing” de manera única. Aquest mètode contempla aquesta columna com la unió de les dues explicades anteriorment. Les tasques situades aquí, seran analitzades i programades alhora per el programador a qui se l’hi assigni la tasca. 4. En la columna “Test review” o simplement “Testing”, es probarà i validarà el funcionament de les tasques programades per a l’aplicació. Aquesta columna és clau ja que Kanban defensa que les tasques programades han de prioritzar el funcionament, abans que el temps, és a dir, una tasca que podría ésser feta rápidament, s’haurà de fer amb més calma i a proba d’errors per a garantir la qualitat d’aquesta. Podríem pensar doncs que la columna de test no és necessària, pero no és així, ja que el programador pot haver obviat situacions reals on l’apliació pot veure’s afectada per afers externs i/o un mal ús del usuari i afectar a altres tasques. 5. Per acabar, la última columna és l’anomenada “Done”, en català, fet. En aquesta fase trobem aquelles tasques que estan acabades i validades. Tot i així el sentit d’aquesta columna no és més que el de pujar a producció, live o al servirdor la web o aplicació desenvolupada. Es separa en una columna ja que no podem pujar tota una aplicació sencera de cop a un entorn definitiu, sinó que les tasques s’aniran pujant a mida que es vagin desenvolupant. Aquestes tasques aniran desapareixent de la base a mida que es vagin pujant els canvis. 24 Aquesta columna pot ésser un coll d’ampolla perillós ja que les pujades a producció poden generar més problemes dels esperats per la simple pressió d’entregar unes tasques en un entorn definitiu. La següent figura ens mostra un exemple base d’una aplicació de Kanban “estàndard”. Figura 4 25 Targetes: El segon element clau de Kanban són les targetes. Les targetes, en aquesta metodología, respresenten una tasca i aquesta conté tota l’informació necessària per a poder seguir el seu desenvolupament. Fora el desenvolupament de Software, les targetes de Kanban tindríen un aspecte similar a la següent figura: La targeta conté tota l’informació necessària sobre la tasca en la que està. Aquí podem veure una breu descripció, el nombre d’unitats, a quí va dirigit i on, una identificació i altra informació adicional. En software però, les targetes són més austeres. Aquestes indicaran una breu introducció o títol de la tasca. Aquesta al ser tan breu haurà d’estar escrita en format i llenguatge molt clar i precís. A part d’això, les targetes hauran d’indicar quí està fent la tasca. Quí fa la tasca es podrà indicar tan si volem triar-ho abans i posar nom a la tasca desde la columna “To do” o podem assignar la tasca a l’hora de passar la targeta de “To do” a “Doing”. Figura 5 32 Per començar vam deixar espai per a una fila on describís quina fase representava aquella columna i a partir d’aquesta, començariem a crear tantes files com projectes s’estiguessin portant a terme. Aquesta però, era una decisió massa lliure ja que en qualsevol moment, doncs podríem tenir infinits projectes alhora, cosa que faría el Kanban una eina inútil alhora de produïr, per tant es va decidir limitar el nombre de projectes a 6 i aquests estaríen ordenats per grau d’importancia i/o urgència. Els projectes més importants i urgents doncs, queden en primer lloc i els projectes més suaus quedaríen relevats a les últimes posicions. A partir d’aquest moment ja haviem solucionat un dels grans problemes que era la gran quantitat de projectes a desenvolupar en un mateix moment, ara era el torn de passar a decidir les fases. Per a decidir les fases dels nostres projectes en desenvolupament, vam decidir optar per la vía quasi estàndard. Mantindríem les fases bàsiques simplement afegiríem algunes petites modificacions ja que el sistema base ens semblava bastant acurat. Les fases finals acabaríen éssent Backlog, To do, Doing, Test review i Done. Figura 7 La primera fase és aquella on resideixen possibles futures tasques que podríen cobrir noves funcionalitats no contemplades o encara per acceptar. Aquesta, inicialment comptava 33 amb un nombre finit de tasques però la necessitat de registrar cada una de elles feia que algunes d’aquestes caiguessin en l’oblit per tant es va decidir que la columna no disposés d’un nombre màxim de tasques acumulades. En la segona fase acumularem totes les tasques que estiguin acceptades i preparades per a desenvolupar. Què entenem per a tasca preparada? Aquella tasca preparada és la que s’ha parlat amb el client i es disposa de tot el contingut necessari per a ésser portada a terme, ja que en cas de no estar-ho, aquesta podría esdevindre un coll d’ampolla al quedar parada en una fase sense possibilitat d’avançar. Aquesta fase té un nombre finit de tasques acumulades en el mateix moment. No podem pretendre tindre massa tasques preparades i anant-se acumulant ja que significaría que no s’estan fent suficients tasques més endavant. El nombre límit de tasques en la columna To do alhora és de 5. És un nombre superior en una unitat al nombre de programadors que hi ha ja que alguns cops per desenvolupar una tasca, aquesta requereix de processos de llarga durada com carregues d’arxius i/o pujades al servidor, on en aquest lapse de temps podrem aprofitar per a començar a desenvolupar una altra tasca. Si més d’un desenvolupador queda atrapat en un d’aquests processos, aquest últim donarà suport en la tasca extra que desenvolupa el que ha quedat també aturat. En la tercera fase veiem un canvi respecte el Kanban original, i és que s’ha decidit dividir la columna en dues subcolumnes per a descriure millor la fase en la que estan. Aquestes dues columnes són anàlisis i codi. En la subfase d’anàlisis, posarem aquelles tasques i tan sols aquelles que necessitin d’una petita investigació. Un exemple d’investigació podría ésser l’ús d’una barra d’scroll amb gran poder de personalització. La tasca inicial de buscar una llibrería que s’adapti a totes les nostres necessitats ens farà situar la nostra targeta sota la columna anàlisis. Amb aquesta columna volem poder identificar si una d’aquestes investigacions ja s’havien fet. Cada programador pot veure què està situat sota anàlisis i per tant si en té coneixement, pot donar un cop de mà ràpidament al desenvolupador de la tasca per a una solució més ràpida. La segona subfase és la de codi, on les targetes que hi ha situades dins seu són aquelles tasques que ja estan éssent desenvolupades a codi. Aquesta és la fase de fent-se per excel·lencia ja que és la més representativa, descriptiva i visual de totes ja que podem veure un programador treballant en ella. 34 La quarta columna també es va decidir de dividir però per causes totalment diferents. A Interiorvista, els supervisors d’un projecte o PMs, han d’afrontar-se dia a dia amb els clients i aconseguir assolir els seus desitjos per mitjà de les aplicacions i això fa que cada una de les tasques tingui una gran repercussió sobre la seva feina. Aquesta és la causa de que haguem dividit aquesta columa en dos. La primera subfase serà aquella en la que el mateix desenvolupador proba el funcionament de la seva pròpia tasca desenvolupada. Aquest breu testeig normalment no es gestiona igual que si fossim usuaris, ja que per naturalesa, el programador buscarà fer bloquejar el programa i no fer-ne un mal ús. Aquesta segona manera de testejar és la que porta a terme el PM. El PM testejarà l’aplicació com a un usuari corrent per tant donarà un nou feedback d’errors si es donés el cas. En aquestes subfases es va decidir en un moment inicial de que el nombre màxim de tasques fós de 3 però al no dependre tan sols del nostre departament i no poder gestionar el temps dels altres treballadors de fora, es va decidir mantenir el nombre en 5. Per a la última fase també es va suprimir el nombre límit de tasques però a canvi es van prendre altres mesures. La útima fase és la de “fet”. En aquesta fase es situen totes les tasques ja desenvolupades i testejades sense límit, però, cada setmana es farà una buidada general on per cada una d’aquestes tasques s’haurà de confirmar la seva finalització. Les targetes de Kanban que farem servir a Interiorvista serán les usades normalment, és a dir, post-its. Aquests post-it, tindran en primer lloc i subratllat, el nom del projecte al que pertanyen. Això ens permetrà de repenjar la targeta a lloc correcte en cas de que aquesta es desenganxés. A continuació, es descriurà breu i clarament la tasca a desenvolupar. Només podrem escriura una tasca per targeta. Aquesta informació no hauría d’excedir la línia. 35 Per acabar, sobre el post-it, s’enganxarà un post-it petit de diferents colors depenent de a qui ha estat encomanada cada tasca. Cada un dels programadors tindrà un color assignat. En la següent figura podem veure un exemple de targeta usada en el Kanban d’Interiorvista. Figura 8 36 4.1.4 Nova manera d’aplicar Kanban A part d’un canvi de disseny, a Interiorvista també hem decidit donar una volta al funcionament de Kanban. Kanban de bon principi ens va semblar massa estricte en quant al reassignament de tasques per tant vam decidir obviar aquesta part del estàndard. Les tasques podríen ser reassignades a altres persones en qualsevol moment del procés. Aquesta decisió es va portar a terme en gran part per necessitat, ja que en la part de test review, haviem de comptar amb la figura d’un PM per a portar a terme un testeig més “humà” i per tant amb el funcionament estricte de Kanban, no es podría haver contemplat aquesta possibilitat. A part d’això, també s’ha relaxat l’avanç entre fases. Kanban obliga a començar una tasca i acabar-la fins a arribar al final, a Interiorvista però, hem volgut relaxar aquesta manera de fer ja que en alguns casos diversos clients han exigit un augment de la prioritat del seu projecte per diverses causes, cosa que ens obligava a deixar certes tasques a la meitat per tal de poder assolir els objectius necessaris per a aquell client. A continuació podem veure un exemple de tauler Kanban d’un projecte d’Interiovista: Figura 9 37 4.1.5 SCRUM a Interiorvista Al aplicar Kanban i portar a terme el seu ús, es va contemplar en el departament de Software d’igualada, el fet de fer reunions diàries per tal de portar un control més exhaustiu del estat en el que estava tots i cada un dels projectes i tasques d’aquests. Cada reunió hauría de demorar a un màxim de 15 minuts per a poder seguir fent la feina sense que el tall destirotés en excés el nostre dia. 4.2 - Desviacions de projecte 4.2.1 Ampliació del projecte Com bé s’ha resumit en apartats anteriors, la base d’aquest projecte és la d’implantar una metodología àgil en el desenvolupament de software en l’empresa Interiorvista. Tot i així s’em va presentar l’oportunitat d’ampliar els coneixements d’aquest, tot aplicant també en aquest nou projecte la metodología àgil estudiada. El nou projecte que s’em va proposar era el de gestionar les analítiques dels clients de l’empresa i controlar així les noves peticions dels clients i els informes mensuals. Aquest projecte m’animava ja que podría ampliar o si més no, complementar els meus coneixements sobre l’anàlisis de dades i si més no, unes breus pinzellades de màrqueting online. La sorpresa va ésser quan començant el projecte vaig conèixer més a fons aquesta eina i aquesta no gestionava per si sola les aplicacions de SPA (single page application). En aquestes, cada un dels events personalitzats que desitgessim hauríen d’ésser programats i enviats desde dins del propi codi. Aquests però no gaudíen d’una llibreria que els empaquetés tots per a facilitar la feina del desenvolupador ni afaboría la genericitat de les analítiques que brindem als clients per defecte. Aquest problema ens va portar a fer una petita llibrería on encapsularíem totes aquestes funcions per tal de aconseguir els nostres objectius. Per a desenvolupar-la vam desenvolupar a partir de l’API pública de Google Analytics, una llibrería on encapsularíem totes les crides genèriques comunes per tots els projectes i 38 posterirorment per a cada projecte, vam crear una plantilla on l’informació variaría per a cada projecte diferent per tal de conectar-se on hauría. Aquestes llibreríes es van penjar al servidor propi per tal de poder accedir a elles de manera similar a un CDN. Finalment es va desenvolupar una documentació per tal de que l’ús d’aquesta llibreria fós amè per a tothom i la formació necessària per a usar-la fós la mínima. 4.3 Obstacles inicials La dificultat d’aquest projecte és que al ser una empresa ja en rodatge des de fa temps, el fet de canviar la rutina de treball ja implantada no és una tasca fàcil i alhora, tampoc ho és d’assimilar per als treballadors. Tot i així, la seva desorganització també pot ser un al·licient per a adoptar alguna solució. Un altre obstacle pot ésser la negativa de l’ús de Google Analytics en els projectes. 4.3.1 Desviació dels obstacles Entre els obstacles inicials que es van descriure, un de clau va ésser el problema de canviar els hàbits de treball. Sobre aquest problema hem vist que gràcies a l’actitud predisposada i activa del departament de software, s’ha aconseguit evitar aquest obstacle de manera notable. Els primers dies va ésser difícil recordar que s’havia de fer targetes per a cada una de les feines assignades i s’havien de repartir entre els programadors i canviar de fase quan calgués, però a mida que va anar passant el temps, va passar a ser una actitud rutinaria més i així poder portar a terme Kanban sense problema. L’ús d’analytics no va ésser un problema ja que les analítiques antigues estaven molt desfassades i l’ús de un framework amb analytics va ésser una idea molt ben rebuda per tant no hi va haver obstacle tampoc en aquest aspecte. Un problema però, va ésser la distància. Les ganes de voler comunicar als equips de Barcelona l’ús de Kanban no van poder superar la barrera de la difícil comunicació amb Barcelona. Aquests equips a sobre treballen de manera molt hermètica i cadascú d’ells treballen segons la seva metodología cosa que impedeix les aportacions exteriors. 39 Finalment l’impossibilitat d’estar activament en tots els departaments també ens ha privat d’aplicar completament Kanban en tots els altres departaments de manera tan activa com en el nostre. 4.4 Posada en marxa de Kanban Després de la reunió inicial per implantar Kanban, es va procedir a la compra del material. Aquest estava compost per una base, retuladors, cinta aïllant i un munt de Post-its. Amb l’infraestructura ja muntada i l’esquema d’organització de la base aparaulat, es va procedir a fer l’inici de Kanban. Totes les tasques i projectes es van reflectir en menys d’una hora en una pissarra visual on ja vam poder treure les primeres conclusions, algú tenia massa feina i algú massa poca. Les primeres setmanes, sobretot la primera, van ésser un període de transició, entre la NO metodología i l’organització sobtada. Era molt comú en aquests dies el fet de reestructurar les tasques entre els companys i/o oblidar-se de passar de fase els post-it quan acabavem aquella fase de la tasca, això però, va anar millorant amb el temps. A causa d’aquests oblids, es va proposar implantar unes reunions mínimes diàries on s’analitzaría ràpidament l’estat de totes les tasques entre la segona i la quarta fase. Actualment s’han abolit les reunions ja que aquestes demoraven més de 10 minuts i aquestes on resolíen cap problema quan Kanban ja estava implantat. 4.4.1 Formació En el meu departament, tots els components havien treballat abans amb diferents tipus de metodologíes àgils així que la formació no va ésser un punt clau en la posada en marxa. El fet és que ells havien treballat la majoría amb SCRUM per tenien ben interioritzat el procés iteratiu però no havien usat Kanban, per tant, la formació es va reduïr a dues simples reunions de vora tres quarts d’hora cada una per un cop decidida ja l’estructura, parlar de com gestionariem la base i quin rol agafaría cadascú. 40 Sí que es va haver de fer, a diferència del departament de Software, una petita formació on s’explicava els principis de Kanban i el procés àgil, als components d’altres departaments involucrats amb les aplicacions desenvolupades en el nostre departament. Aquests van reunir-se en una reunió de formació liderada per el meu supervisor, on s’explicava com usar Kanban per mitjà de l’eina JIRA. D’aquesta manera, cap d’ells independentment d’on fóssin, podríen aplicar les tasques a la base sense problema i les fases podríen anar avançant. 4.4.2Resposta de la gent La resposta inicial va ésser molt càlida per part del nostre departament ja que posar ordre sempre ha sigut bona idea i vam acceptar la idea de molt bon grat ja que també sabíem quins resultats podríem obtenir-ne i quin sería l’esforç per a assolir-ho. Per altra banda, de cara a altres departaments, la resposta va ésser més freda i reàcia a l’ús de la metodología però finalment al cap del temps s’ha aconseguit que el seu ús es converteixi un estàndard per a la comunicació amb el departament de Soft d’Igualada. 4.5 Com està funcionant? Actualment l’estat de l’ús de Kanban varía segons els departaments així que aquesta secció es dividirà en dos apartats: Departament de Software: En el departament de Software, Kanban ha gaudit d’una molt bona rebuda desde el primer día i aquest s’està portant a terme amb naturalitat. Aquest mètode, ha provocat que siguem capaços d’estimar el nombre d’hores que trigarem o que hem trigat en cada un dels projectes o en petites parts d’aquest. Aquesta estimació d’hores esdevé en una aproximació del cost del projecte per tal de comptabilitzar amb més exactitud les despeses de cada projecte. També servirà així doncs per donar una mica més de criteri a l’imputació d’hores que hem de fer en l’OpenERP. La facilitat de canviar d’un projecte a un altre ha augmentat ja que no es perd el fil de què s’estava fent al separar tot en petites tasques. Sempre podrem acabar-ne una 41 d’un projecte per a seguir amb una altra d’un altre i tot i així no perdre informació sobre l’estat de cada aplicació. Departament de gestió: En aquest departament la rebuda va ésser més freda. Als inicis es va plantejar fer ús de la pissarra de forma conjunta, però per localització, la adaptació va ser nefasta. Cap dia es va poder actualitzar correctament cap de les tasques que portaven a terme altres companys de diferents departaments, per tant es va optar per fer ús de l’eina JIRA per a complementar el Kanban físic i fer-ne una rèplica virtual que anirà actualitzant la forma de la física per mitjà de nosaltres. Actualment es segueix fent ús del Kanban en aquesta eina per tal de mantenir la coherència i els companys del departament de gestió que estan involucrats amb nosaltres en fan un ús correcte i contínu. 48 Es va actuar ràpidament sobre aquest punt impartint una formació bàsica sobre l’equip de software d’Igualada. Va tindre una gravetat bastant baixa ja que al haver usat altres metodologies àgils prèviament en altres empreses van entendre l’importancia i conceptes fàcil i ràpidament. Per la meva part vaig aprofundir en la metodologia per tal de poder donar un bon suport en ella ja que hauría d’actuar com a “mentor” sobre aquesta. L’equip de gestió, va necessitar de més formació que el de Software ja que mai havien actuat sobre cap tipus de metodologia de treball fora de la comunicació per correu electrònic. En segon lloc, vam topar amb la poca predisposició inicial del equip de gestió de fer servir o seguir una metodologia de treball. En aquest cas es va decidir per informar del pla de treball als caps de departament per tal d’avaluar si era una bona opció. En aquest cas, els líders de departament van acceptar la proposta i es van impartir varies formacions per a donar els coneixements bàsics per a poder seguir la metodología. Com s’ha esmenat en apartats anteriors, la mala accessibilitat per part d’altres departaments d’actuar sobre la base física de Kanban, es va haver de pensar en una altra alternativa. Aquesta alternativa va ésser utilitzar l’eina virtual que presta JIRA com a substitut virtual de la base física. Aquest en segona instància va tindre més bona rebuda que el primer intent fallit sobre la base d’Igualada. 49 7 - Gestió econòmica 7.1 Identificació i estimació dels costos En aquesta secció s’estimaran els costos totals del projecte. Es definiran les estimacions de cada un dels recursos que s’han utilitzat per seccions com poden ésser Recursos humans, equips informàtics i/o programari. També inclourem totes i cada una de les despeses generals necessàries. 7.1.1 Recursos humans En aquest projecte s’han vist involucrades dos persones, han adoptat varis rols. La següent taula mostra el desglosament dels costos per recursos humans, especificant el preu per hora de cada perfil implicat en el projecte i les hores estimades. Persona Rol Preu per hora Hores estimades Total estimat Pau Vila Cap de projecte 7.5€/h 204h 1530€ Analista 7.5€/h 92h 690€ Dissenyador 7.5€/h 43h 322,5€ Programador 7.5€/h 117h 877,5€ Testing 7.5€/h 65h 487,5€ David Vilanova Analista 15€/h 32h 480€ Testing 15€/h 41h 615€ Total 594h 5002,5€ Taula 3: Costos derivats dels recursos humans Les hores estimades per a cada rol han estat calculades a partir del planning de la secció 2. Els preus per hora han estat calculats a partir del sou real actual de cada persona implicada, indiferentment del rol que aquest desenvolupés. 50 7.1.2 Software En aquesta secció es desglosaran tots els costos de tot el programari necessari per a desenvolupar el projecte. Al estar desenvolupat a l’empresa, tot i que el programari podría ser gratuït per les versions estudiants s’ha utilitzat el programari amb les llicències de l’empresa per tant no són gratuites. Programa Preu Vida útil Amortització total (6 mesos) Windows 7 Pro 135€ 5 anys 13.5€ PhpStorm 9.1 99€ 5 anys 9.9€ Google Chrome Gratuït - 0€ Mozilla Firefox Gratuït - 0€ Gantter Gratuït - 0€ JIRA Agile (60 usuaris) 450€/mes (60 usuaris) 6 mesos 45€ (1 usuari) Microsoft office 2013 119€ 3 anys 19.85€ SourceTree Gratuït - 0€ TOTAL 88.25€ Taula 4: Cost del programari La vida útil del programari de pagament s’ha estimat en base a la freqüencia en que treuen noves versions i el preu d’aquestes, també s’ha donat més vida útil per exemple al S.O en comptes de la suite d’ofimàtica ja que els canvis recents en l’últim, han estat molts, en canvi tot i que windows ha patit molts canvis, s’allarga la seva vida útil per la corva d’aprenentatge o la dificultat de compatibilitats. 51 7.1.3 Hardware Per a desenvolupar el projecte s’ha fet ús d’un ordinador. Per a ordinador entenem el conjunt de torre, teclat, ratolí i dues pantalles. Producte Cost Vida útil Amortització total (6 mesos) Ordinador 750€ 5 anys 75€ TOTAL 75€ Taula 5 : Cost del hardware necessari 7.1.4 Altres costos En aquesta secció es descriuen tots els costos derivats de la realització del projecte. L’energia elèctrica consumida, internet i transport estan inclosos en el desglosament. Cal també contar el material d’oficina per a poder portar a terme la metodologia Kanban. Producte Cost mensual Període Total Electricitat 0,15€/kWh*~0.15kW 600h 13.5€ Internet 35€ 6 mesos 210€ Transport 20€ 6 mesos 120€ Pissarra (base) 80€ - 80€ Post-it 5€ - 5€ Rotuladors 2€ - 2€ TOTAL 430.5€ Taula 6 : Costos varis 52 7.1.5 Costos inesperats Fins al moment no s’ha patit cap cost inesperat. Qualsevol desperfecte possible en algun dels elements implicaria l’immediata substitució per un de nou per a evitar cap aplaçament. En tot cas, l’empresa disposa d’equips de reserva per tant el cost directe sería nul, en tot cas el cost sería el de la reparació o substitució. En cap cas tindrem costos temporals. 7.1.6 Cost total Concepte Cost Costos directes 5002.5€ Costos indirectes 593,75€ Contingència (5%) 279,81€ Costos imprevistos - Total (IVA inclòs) 5.876,06€ Taula 7 : Cost total del projecte 7.2 Control de gestió Per tal de portar un control de les imputacions horaries, es crearà una taula on es descriuran les hores setmanals que s’han efectuat sobre cada un dels rols. Es crearà una d’aquestes taules per cada un dels integrants del equip. Hores Setmana Project Manager Analista Dissenyador Programador Testing 21/09/2015 11h - - 9h 3h Taula 8 : Control d’imputacions horaries per setmanes i rols També es crearà una taula amb els temps estimats i els reals. En aquesta segona taula podrem calcular els desviaments dels costos reals sobre els costos estimats i estudiar quina és la causa del desviament. 53 Rol Hores estimades Cost estimat Hores reals Cost real Project manager 204h 1530€ 230h 1725€ Analista 92h 690€ 101h 757,5€ Taula 9 : Control de desviacions 7.3 Desviacions econòmiques En el cas de l’economia, aquesta s’ha vist afectada a causa de la demora. Si intentessim acurar el màxim les hores dedicades al projecte en sí, el cost potser no variaría però ja que les tarifes mensuals no contemplen casos concrets ni hipotètics, he decidit que el cost total del projecte hauría d’ésser augmentat de pressupost a causa de l’aplaçament de la finalització d’aquest ja que s’ha necessitat internet i electre continuadament i no s’ha trencat el contracte amb ells en cap moment. En l’apartat de costos varis tenim la desviació següent: Producte Cost mensual Període Total Electricitat 0,15€/kWh*~0.15kW 800h 18 € Internet 35€ 8 mesos 280€ Transport 20€ 8 mesos 120€ Pissarra (base) 80€ - 80€ Post-it 5€ - 5€ Rotuladors 2€ - 2€ TOTAL 505€ Taula 10 54 Com bé podem apreciar, tenim una desviació de 74,5€ respecte del cost estimat inicial. Aquesta desviació no és molt notoria però s’ha de tenir en compte per a avaluar el cost del projecte respecte de la viabilitat estimada. A causa d’aquest augment de preu, tenim la següent taula de costos totals: Concepte Cost Costos directes 5002.5€ Costos indirectes 593,75€ Contingència (5%) 279,81€ Costos imprevistos 74,5€ Total (IVA inclòs) 5.950,56€ Taula 11 Posarem els costos de electre i internet extres en l’apartat de costos d’imprevistos ja que aquests costos no havien estat contemplats en la planificació inicial del projecte i van sorgir per imprevistos tal com són els projectes que van sortir entremig de l’estudi. 55 8 - Informe de sostenibilitat Per a identificar la sostenibilitat del projecte estudiarem el projecte en tres àmbits: econòmic, social i ambiental. Per avaluar la sostenibilitat del projecte s’ha creat una taula amb una puntuació sobre 30. A continuació estudiarem cada àmbit en detall. Econòmic Social Ambiental Planificació Viabilitat econòmica Millora en l’ambient de treball Anàlisis de recursos 23,5 7,5 8 8 Taula 12 : Sostenibilitat del PFG 8.1 - Dimensió econòmica Per a desenvolupar aquest projecte no s’ha tingut en compte costos administratius, reparacions i/o altres costos extra que puguin sorgir en un projecte a més llarg termini degut a la duració ajustada d’aquest. El cost total del projecte és molt ajustat ja que el sou d’un becari és baix i per tant els costos per recursos humans s’han pogut reduïr de manera notable. Sería possible reduïr el temps del projecte contractant un expert en metodologies àgils i un gestor de projectes de software, però el pressupost resultaría més elevat. La finalitat del projecte en termes econòmics té l’intenció de augmentar la productivitat dels treballadors per mitjà de l’organització de les seves tasques, això tindría una directa repercusió en una reducció d’hores de treball i per tant una reducció en costos per recursos humans i augment d’ingressos. 8.2 Dimensió social La desorganització en l’entorn de treball és una principal causa de situacions tenses en el treball la qual cosa provoca estrés en els treballadors que pot derivar en simptomes més greus desde malestar lleu a migranyes. 56 Kanban vol organitzar les tasques i millorar la comunicació entre departaments i treballadors per tal de reduïr situacions de descontrol i desconcert per tant millorar l’ambient de treball. 8.3 Dimensió ambiental El simple fet d’utilitzar un ordinador provoca un impacte a nivell ambiental per petit que sigui aquest. Durant tot el projecte farem ús de l’energia elèctrica i per conseqüent impacte ambiental. Es preveu un consum pròxim als 80kW de potència per al desenvolupament del projecte. A part de la part informàtica, s’utilitzen rotuladors per a pissarra blanca dels quals la seva tinta és contaminant. Tot i això, la quantitat utilitzada és tan petita que no es te en compte per al desenvolupament del projecte. 57 9 – Valoració 9.1 Resultats obtinguts En aquest apartat s’avaluarà l’impacte que ha tingut el projecte amb l’implantació d’una metodología àgil al departament de software de l’empresa Interiorvista a Igualada. Aquest apartat estarà dividit en dues parts. La primera part estarà formada per uns paràgrafs on trauré certs punts per tal d’argumentar la viabilitat que ha tingut aquest projecte i la necessitat del departament d’un mètode de treball. En la segona part, podrem veure la resposta avaluativa dels companys de departament per mitjà d’enquestes. Aquestes avaluacion com podem veure estan formades per opinions i no deixen de ser arguments subjectius, però aquest projecte en sí es basa més en la millora de l’ambient de treball i l’opinió dels treballadors ja que amb la seva millora de qualitat de vida a la feina podrem aconseguir i esperar uns millors resultats de la seva mà. Com a millora notable en l’ambient de treball, s’ha notat una relaxació en l’àmbit de la comunicació interdepartamental. Aquesta comunicació era tensa abans de començar Kanban. Les tasques es repartien i comunicaven mitjançant correus electrònics que sovint es perdíen o quedaven en l’oblit. Aquestes fractures en la comunicació causaven fregament entre les relacions de membres de diferents departaments. Gràcies a Kanban i el seu mètode, hem aconseguit alleujar aquests fregaments de manera notable ja que queden registrats en la base i no s’obliden. Cada dia, per altra banda, es fa un repàs de les feines actuals i així s’aconsegueix donar prioritat a tasques més importants, i no a les més recents. Podem veure també que el codi s’ha pogut optimitzar ja que al quedar les tasques registrades, podem revisar quines tasques s’estan fent i/o estan fetes per tant no les duplicarem. Gràcies també a Kanban podrem fer un repàs dels costos del projecte en el que treballem aplicant la metodología revisant les tasques i contabilitzant-les. 64 Annèx Figura annèx 1 Dates de cada fase i subfase del projecte Figura annèx 2 : Diagrama de Gantt del projecte 65 Figura annèx 3 Dates de cada fase i subfase del projecte amb desviacions Figura annèx 4: Dates de cada fase i subfase del projecte amb desviacions 66 Figura annèx 4 67 Figura annèx 5 68 Figura annèx 6 69 Figura annèx 7 70