Processo de Desenvolvimento ´ Agil de Software

Relativamente `as metodologias ´ageis utilizadas nas empresas, constatou-se que a grande maioria (80% dos inquiridos) usa a metodologia SCRUM sem adaptac¸˜oes relevantes. Os restantes 20% dos inquiridos apontaram para utilizac¸˜ao de metodologias h´ıbridas com conceitos de SCRUM e Extreme Programming (XP) envolvidos no processo ´agil de de- senvolvimento de software (Figura 4.13).

Figura 4.13: Metodologias ´ageis adotadas em empresas portuguesas inquiridas.

Os inquiridos afirmaram que os membros da equipa trabalham no mesmo local f´ısico. A distribuic¸˜ao das pessoas foi feita segundo func¸˜oes desempenhadas no projeto.

Outra quest˜ao importante a colocar-se numa empresa de desenvolvimento de software est´a relacionado com o processo de divis˜ao de trabalho. Constatou-se que a maior parte dos inquiridos divide o trabalho em releases (Tabela 4.10).

Alternativas Frequˆencia Absoluta Frequˆencia Relativa Releases 3 60%

Projetos 2 40%

Outros 0 0%

Tabela 4.10: Divis˜ao de trabalho

´ageis. Constatou-se que os pap´eis de Product Owner, Membro de equipa e a de SCRUM Master s˜ao consideradas extremamente importantes no desenvolvimento de software e que s˜ao utilizadas como referˆencia em todas empresas inquiridas. Seguidamente, temos o papel dos stakeholders mencionado em 80% dos casos. Em terceiro lugar, com 40% temos o l´ıder de equipa e os especialistas. E, finalmente, ainda temos o papel do Domain expertmencionado em 20% da amostra neste estudo (Figura 4.14).

Figura 4.14: Percentagem de utilizac¸˜ao de pap´eis em equipas ´ageis.

Todas as empresas inquiridas neste estudo referiram que um elementi pode acumular pap´eis. Foram sugeridas diversas propostas, a sugest˜ao da empresa C consiste no ges- tor de projeto puder acumular Product Owner, Scrum Master e L´ıder de Equipa. J´a a empresa D, afirma que o Lider da equipa dever´a acumular apenas as func¸˜oes de Scrum Master. Para a empresa A pode-se formar 3 pares SCRUM Master/Product Owner, Pro- duct Owner/Developer, SCRUM Master/Developer em que o primeiro elemento do par acumula as func¸˜oes do segundo. As empresas B e E afirmam que o arquiteto pode acu- mular func¸˜oes do t´ecnico-chefe do projeto.

Os resultados demostram que todos os inquiridos neste estudo fazem ciclos iterativos durante o processo de desenvolvimento de software e que para a maioria dos inquiridos o per´ıodo m´edio das iterac¸˜oes ´e de duas semanas (Tabela 4.11).

Cap´ıtulo 4. Avaliac¸˜ao de Maturidade das Empresas Portuguesas 53

Empresas Per´ıodo M´edio de Iterac¸˜oes Empresa A 2 semanas

Empresa B 2-4 semanas Empresa C 2 semanas Empresa D 2 semanas Empresa E 4 semanas

Tabela 4.11: Per´ıodo M´edio de Iterac¸˜oes

No geral, todas as empresas inquiridas afirmam produzir dois tipos de documentac¸˜ao: documentac¸˜ao de gest˜ao que fica a cargo do gestor do projeto e outra documentac¸˜ao mais t´ecnica (incluindo manuais do utilizadores) que fica a cargo de toda a equipa SCRUM. De realc¸ar uma iniciativa da empresa D que consiste em colocar uma equipa paralela `a de desenvolvimento a criar conte´udo de treino. Estes conte´udos s˜ao normalmente v´ıdeos disponibilizados online, ficheiros de ajuda e notas t´ecnicas.

No que toca ao planeamento no in´ıcio de cada iterac¸˜ao, todos os inquiridos confirmam a existˆencia de planos no in´ıcio de cada iterac¸˜ao. Na empresa A, o SCRUM Master ga- rante que as reuni˜oes de planeamento do sprint acontecem no in´ıcio de cada sprint e que toda a equipa SCRUM est´a presente. Nas empresas B e E a responsabilidade da concec¸˜ao e atualizac¸˜ao do plano est´a atribu´ıda ao SCRUM master. Enquanto que na empresa C, a concec¸˜ao do plano ´e da responsabilidade do Gestor de projeto e a sua atualizac¸˜ao cabe `a equipa de desenvolvimento. Por ´ultimo, temos a empresa D que aponta o l´ıder da equipa como pec¸a fundamental no processo de planeamento do sprint.

Relativamente `a definic¸˜ao e priorizac¸˜ao das funcionalidades a concretizar por cada iterac¸˜ao ´e senso comum entre todos os inquiridos que estas dever˜ao ser efetuadas nas reuni˜oes de planeamento do sprint logo ao in´ıcio de cada iterac¸˜ao e que quem tem a pala- vra final sobre a priorizac¸˜ao ´e o Product Owner.

Atrav´es dos resultados, pode-se verificar que todas as empresas inquiridas fazem as reuni˜oes matinais e que nelas participam todos os elementos da equipa de desenvolvi- mento, inclusiv´e o SCRUM Master. Nestas reuni˜oes, cada elemento da equipa apresenta o que foi feito no dia anterior e os impedimentos sentidos e o que se pretende realizar no presente dia. Algumas empresas referiram a necessidade de realizar-se um follow up entre alguns elementos da equipa para se tomarem decis˜oes pertinentes sem atrasar os restantes elementos da equipa. Quanto ao uso de ferramentas usadas durante as reuni˜oes matinais, as respostas foram bastantes divergentes. A empresa B afirma n˜ao utilizar nenhum tipo de ferramenta enquanto que, a empresa A utiliza os instrumentos Team e Fundation Server

Web Access [53]. A empresa C usa as ferramentas do software JIRA [54] e o Confluence [55]. J´a a empresa D usa a ferramenta de gest˜ao de projetos Rally [56]. O instrumento mais simples e diferente ficou com a empresa E, que usa apenas uma bola que ´e passada de elemento a elemento na equipa com o objetivo de indicar que ´e a sua vez de falar.

Cerca de 60% dos inquiridos revelaram que n˜ao trabalham com os arquitetos da em- presa e gestores de portfolio (Tabela 4.12).

Alternativas Frequˆencia Absoluta Frequˆencia Relativa

N˜ao 3 60%

Sim 2 40%

Tabela 4.12: Trabalho em conjunto com arquitetos da empresa e gestores de portfolio

Relativamente a adoc¸˜ao das medidas das empresas, todos os inquiridos afirmam que as suas equipas de desenvolvimento ´agil seguem todas as orientac¸˜oes das empresas. E, cerca de 80% dos inquiridos afirmam que existe a cultura de partilha de lic¸˜oes aprendidas no seio da empresa (Figura 4.15).

Figura 4.15: Partilha de lic¸˜oes aprendidas na empresa.

Analisando as respostas do inqu´erito, pode-se constatar que todos os inquiridos tˆem como objetivo principal ajudar a equipa de desenvolvimento ´agil a crescer. No entanto, cerca de 40% consideram tamb´em importante ajudar no crescimento da organizac¸˜ao e apenas 20% referiu o crescimento pessoal, o que faz sentido tendo em conta a filosofia do SCRUM (Figura 4.16).

Relativamente `as restantes quest˜oes do inqu´erito, uma das empresas optou por n˜ao responder e sendo assim obtiveram-se apenas quatro respostas.

Cap´ıtulo 4. Avaliac¸˜ao de Maturidade das Empresas Portuguesas 55

Figura 4.16: Objetivos cont´ınuos dos elementos da equipa.

No que concerne `a gest˜ao do risco, a empresa A afirma que esta existe durante todo o processo de desenvolvimento. As empresas B e C tamb´em afirmam que este requesito ´e tratado continuamente e em espec´ıfico durante as reuni˜oes de planeamento e as de revis˜ao do sprint. J´a a empresa D admite que ´e feita mas n˜ao de uma forma regular e consistente. A empresa D afirma que faz Provas de Conceitos para alguns projetos para ajud´a-los na gest˜ao de expectativas em termos de resultados e prazos para um produto vi´avel (MVP- Minimum Viable Product).

Em relac¸˜ao ao uso de t´ecnicas Agile Data Modeling, Database Refactoring, Database Regression Testing, Test-driven Development (TDD) e Encapsulating Database Access, as empresas A e C referiram que n˜ao faz uso das mesmas. A empresa B refere o uso de testes autom´aticos, TDD, pair programming, Application Lifetime Management (ALM), integrac¸˜ao continua. No entanto n˜ao usa t´ecnicas orientadas especificamente para bases de dados (por exemplo, Database Refactoring). A empresa D por ser uma empresa de produto, d´a um enfoque muito grande em termos dos testes autom´aticos, de integrac¸˜ao e de regress˜ao como parte das iterac¸˜oes.

Sob o ponto de vista do acesso `as bases de dados, todas as empresas inquiridas afir- mam que a utilizac¸˜ao das Metodologias ´ageis n˜ao trouxe nada carater´ıstico.

Conseguiu-se identificar algumas ferramentas que est˜ao a ser usadas durante o pro- cesso de desenvolvimento ´agil de software, tais como: Per´ıodos de Testes alfa e beta, sprint demos, Issue trackers (por exemplo, Gemini), Gest˜ao de c´odigo (por exemplo, TFS), Maquetizac¸˜ao (por exemplo, Balsamiq Mockups), Testes de usabilidade e de carga (por exemplo, Visual Studio). Podemos realc¸ar aqui tamb´em o uso de regras na documentac¸˜ao com convenc¸˜oes de nomenclatura e ainda o uso da ferramenta StyleCop que garante o c´odigo, sintaticamente, segue um conjunto de regras. Ainda pode-se mencionar as Inspec¸˜oes e Revis˜oes de C´odigo de forma a garantir a qualidade e aprendizagem por parte das equipas ´ageis.

As melhorias para o processo de desenvolvimento de software apontadas pelos inqui- ridos centram-se nas necessidade de melhorias na formac¸˜ao dos elementos das equipas, na capacidade de estimar requisitos, e no processo de testes de software.