Download as
Browse Code »

Commit d28721906484828eaf09f622a6edfa15348de725

Authored by Paulo Meireles
1 parent 00023793
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Minor adjustments

Showing 3 changed files with 106 additions and 80 deletions   Show diff stats
cbsoft2017/content/04-architecture.tex
  Diff comments   View file @d287219
1 1 \section{Visão geral do novo Portal SPB}
2 2 \label{sec:architecture}
3 3  
4   -Com base em uma extensa lista de requisitos funcionais definidos pelo MP, selecionamos alguns sistemas livres candidatos \'a compor a solução
5   -proposta para o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior sub-conjunto possível dos requisitos.
6   -
7   -Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
8   -plataforma:
  4 +Com base em uma extensa lista de requisitos funcionais definidos pelo MP,
  5 +selecionamos alguns sistemas livres candidatos à compor a solução proposta para
  6 +o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior
  7 +sub-conjunto possível dos requisitos. Do ponto de vista da arquitetura, dois
  8 +requisitos eram importantes para a nova plataforma:
9 9  
10 10 \begin{enumerate}
11 11 \item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais;
12   -\item \textit{Fornecer uma experi\^encia de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
  12 +\item \textit{Fornecer uma experiência de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
13 13 \end{enumerate}
14 14  
15 15 A adoção de sistemas livres existentes e a minimização de mudanças feitas
16 16 localmente tiveram como objetivo ser capazes de atualizar para versões mais
17   -recentes do software original, nos beneficiando pelas melhorias e manutenção feitas
18   -pelas comunidades de projetos existentes. Proporcionar uma experi\^encia de usuário
19   -consistente em cima dessas diferentes ferramentas era necessária para fazer a
20   -transição entre os diferentes sistemas sem a percepção do ponto de vista dos
21   -usuários, ou seja, sem confundí-lo através de interfaces gráficas completamente
22   -distintas ao interagir com o portal.
  17 +recentes do software original, nos beneficiando pelas melhorias e manutenção
  18 +feitas pelas comunidades de projetos existentes. Proporcionar uma experiência
  19 +de usuário consistente em cima dessas diferentes ferramentas era necessária
  20 +para fazer a transição entre os diferentes sistemas sem a percepção do ponto de
  21 +vista dos usuários, ou seja, sem confundí-lo através de interfaces gráficas
  22 +completamente distintas ao interagir com o portal.
23 23  
24 24 Para o primeiro requisito, identificamos quatro sistemas principais que exigiam
25 25 equipes especializadas para o trabalho no processo de integração. As equipes
... ...
cbsoft2017/content/07-process.tex
  Diff comments   View file @d287219
... ... @@ -2,23 +2,23 @@
2 2 \label{sec:process}
3 3  
4 4 A nossa equipe de desenvolvimento era composta por profissionais com diferentes
5   -níveis de experiência e habilidades, sendo a maioria deles estudantes de graduação de
6   -engenharia de software (a partir do 4º semestre de curso). Uma vez que os
7   -alunos não podiam dedicar muitas horas por semana ao projeto, eles sempre
8   -tiveram a flexibilidade para negociar seus horários de trabalho durante o
9   -semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diária
10   -no projeto incluiu programação, testes e tarefas de DevOps (contabilizando 16
11   -horas-semanais).
  5 +níveis de experiência e habilidades, sendo a maioria deles estudantes de
  6 +graduação de engenharia de software (a partir do 4º semestre de curso). Uma vez
  7 +que os alunos não podiam dedicar muitas horas por semana ao projeto, eles
  8 +sempre tiveram a flexibilidade para negociar seus horários de trabalho durante
  9 +o semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho
  10 +diária no projeto incluiu programação, testes e tarefas de DevOps
  11 +(contabilizando 16 horas-semanais).
12 12  
13 13 O desenvolvimento do projeto SPB exigiu experiência avançada, que os alunos de
14 14 graduação geralmente ainda não têm. Por essa razão, alguns desenvolvedores
15   -sênior se juntaram ao projeto para ajudar com as questões mais difíceis, além de
16   -transferir conhecimento aos alunos. Sua principal tarefa era fornecer soluções
17   -para problemas complexos. Como esses profissionais são muito hábeis e o projeto
18   -não poderia financiar um trabalho de tempo integral, eles trabalharam
  15 +sênior se juntaram ao projeto para ajudar com as questões mais difíceis, além
  16 +de transferir conhecimento aos alunos. Sua principal tarefa era fornecer
  17 +soluções para problemas complexos. Como esses profissionais são muito hábeis e
  18 +o projeto não poderia financiar um trabalho de tempo integral, eles trabalharam
19 19 parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados
20   -diferentes espalhados pelo Brasil, ou até em outros países, o que levou muito da
21   -comunicação a ser on-line.
  20 +diferentes espalhados pelo Brasil, ou até em outros países, o que levou muito
  21 +da comunicação a ser on-line.
22 22  
23 23 Em resumo, nosso processo de trabalho foi baseado em práticas de
24 24 desenvolvimento de software livre e colaborativo. O processo de desenvolvimento
... ... @@ -51,7 +51,8 @@ organização do projeto:
51 51 \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem
52 52 estar juntos fisicamente no laboratório (exceto, é claro, os membros da
53 53 equipe remota, mas que estarão on-line).
54   -\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil) trabalharia presencialmente ao lado dos alunos por uma semana.
  54 +\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil)
  55 +trabalharia presencialmente ao lado dos alunos por uma semana.
55 56 \end{enumerate}
56 57  
57 58 Com as regras acima, dividimos todo o projeto em quatro equipes diferentes:
... ... @@ -61,9 +62,11 @@ ajudar os membros a se organizarem da melhor maneira para todos (sempre
61 62 respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
62 63 que trabalhava como desenvolvedor na equipe com o dever extra de registar as
63 64 tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a
64   -responsabilidade de conversar com outras equipes. É importante salientar sobre a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
  65 +responsabilidade de conversar com outras equipes. É importante salientar sobre
  66 +a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
65 67 muitos alunos mudaram de equipe para tentar ter diferentes experiências em
66   -diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se formando.
  68 +diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se
  69 +formando.
67 70  
68 71 Uma característica das equipes foi a presença de (pelo menos) um sênior por
69 72 equipe. Isso era essencial, porque as decisões difíceis e os problemas
... ... @@ -71,20 +74,22 @@ complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica
71 74 incentivou os demais alunos a terem o mesmo compartamento do \textit{coach}
72 75 mesmo sem serem. Por fim, os desenvolvedores sêniores trabalharam diretamente
73 76 com os alunos, e isso foi importante para dar ao graduando a oportunidade de
74   -interagir com profissionais experientes em sua área, além de manter o conhecimento no projeto compartilhado entre as equipes.
  77 +interagir com profissionais experientes em sua área, além de manter o
  78 +conhecimento no projeto compartilhado entre as equipes.
75 79  
76 80 Por fim, tivemos ainda dois últimos elementos da organização da equipe que
77   -foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os
78   -professores. O primeiro era um engenheiro de software recentemente graduado, egresso, e que queria continuar trabalhando no projeto; esses últimos
79   -eram professores que orquestraram todas as interações entre todos os membros do
80   -projeto, inclusive do MP. O \textit{meta-coach} normalmente
81   -trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado
82   -atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam
83   -juntos para reduzir o problema de comunicação entre todas as equipes (o que
84   -tornou-se mais complexo conforme a evolução do volume de trabalho). Por
85   -último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o
86   -progresso do projeto para o Ministério, foi tratada pelos professores, mas com
87   -o envolvimento de toda a equipe.
  81 +foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os
  82 +professores. O primeiro era um engenheiro de software recentemente graduado,
  83 +egresso, e que queria continuar trabalhando no projeto; esses últimos eram
  84 +professores que orquestraram todas as interações entre todos os membros do
  85 +projeto, inclusive do MP. O \textit{meta-coach} normalmente trabalhava em uma
  86 +equipe específica e tinha a tarefa extra de conhecer o estado atual de todas as
  87 +equipes. Os professores e \textit{meta-coach} trabalharam juntos para reduzir o
  88 +problema de comunicação entre todas as equipes (o que tornou-se mais complexo
  89 +conforme a evolução do volume de trabalho). Por último, todas as tarefas
  90 +burocráticas, como a elaboração de relatórios sobre o progresso do projeto para
  91 +o Ministério, foi tratada pelos professores, mas com o envolvimento de toda a
  92 +equipe.
88 93  
89 94 \subsection{Comunicação e gestão das tarefas}
90 95  
... ... @@ -115,34 +120,40 @@ plataforma).
115 120 \subsection{Acompanhamento e gerenciamento de projeto de alto nível}
116 121  
117 122 O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
118   -forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e software
119   -livre. Essa dissonância nos causou um ruído de comunicação com o MP. Foi
120   -especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
121   -desenvolvimento ágil. Entretanto, depois de meses de trabalho e na medida em que os resultados foram se concretizando, em especial a entrega e implantação frequente de releases, a resistência foi gradualmente diminuindo.
  123 +forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e
  124 +software livre. Essa dissonância nos causou um ruído de comunicação com o MP.
  125 +Foi especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
  126 +desenvolvimento ágil. Entretanto, depois de meses de trabalho e na medida em
  127 +que os resultados foram se concretizando, em especial a entrega e implantação
  128 +frequente de \textit{releases}, a resistência foi gradualmente diminuindo.
122 129  
123 130 Definimos níveis de granularidade das reuniões para evitar gerar demasiada
124   -sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos reuniões de caráter estratégico, com periodicidade mensal, e
125   -reuniões planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
126   -geralmente, eram definidas as prioridades estratégicas do MP, e com isso o conjunto de funcionalidades importantes para atender àquelas prioridades estratégicas. Normalmente, os professores, os \textit{coaches} de cada equipe, os
127   -\textit{meta-coaches} e alguns analistas do MP
128   -participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
129   -desde nossa última reunião e priorizámos as funcionalidades para a próxima
130   -versão. Observe que apenas parte da equipe participava dessas reuniões
131   -estratégicas, mas todos os estudantes interessados estavam convidados a
132   -participar (pois muitos estudantes quiseram passar por essa experiência durante o
133   -projeto).
134   -
135   -Depois dos encontros estratégicos com os principais atores envolvidos do
136   -MP, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
137   -parte, cada equipe trabalhava junto para converter a representação dos requisitos em ``Épicos'' da ``release'' em desenvolvimento, em requisitos
138   -menores (histórias de usuário). Cada \textit{coach} era responsável pela
139   -condução do planejamento, e depois a equipe toda a registrava na página wiki do
140   -projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
141   -dias a equipe gerava um o planejamento da sprint/ciclo de desenvolvimento
142   -(com os pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado, convidávamos-os a trabalhar conosco para validar
143   -as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
144   -15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
145   -plataforma do SPB, especialmente o Gitlab, tínhamos:
  131 +sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos
  132 +reuniões de caráter estratégico, com periodicidade mensal, e reuniões
  133 +planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
  134 +geralmente, eram definidas as prioridades estratégicas do MP, e com isso o
  135 +conjunto de funcionalidades importantes para atender àquelas prioridades
  136 +estratégicas. Normalmente, os professores, os \textit{coaches} de cada equipe,
  137 +os \textit{meta-coaches} e alguns analistas do MP participavam dessa reunião.
  138 +Em geral, discutíamos o que a equipe já produziu desde nossa última reunião e
  139 +priorizámos as funcionalidades para a próxima versão. Observe que apenas parte
  140 +da equipe participava dessas reuniões estratégicas, mas todos os estudantes
  141 +interessados estavam convidados a participar (pois muitos estudantes quiseram
  142 +passar por essa experiência durante o projeto).
  143 +
  144 +Depois dos encontros estratégicos com os principais atores envolvidos do MP,
  145 +tínhamos um turno de planejamento com todas as equipes juntas. Nessa parte,
  146 +cada equipe trabalhava junto para converter a representação dos requisitos em
  147 +``épicos da \textit{release}'' em desenvolvimento, em requisitos menores
  148 +(histórias de usuário). Cada \textit{coach} era responsável pela condução do
  149 +planejamento, e depois a equipe toda a registrava na página wiki do projeto
  150 +(wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15 dias a
  151 +equipe gerava um o planejamento da iteração/ciclo de desenvolvimento (com os
  152 +pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado,
  153 +convidávamos-os a trabalhar conosco para validar as funcionalidades em
  154 +desenvolvimento. Para isso, tínhamos uma reunião a cada 15 dia. E para manter
  155 +nosso fluxo de gestão de tarefas, usando a própria plataforma do SPB,
  156 +especialmente o Gitlab, tínhamos:
146 157  
147 158 \begin{enumerate}
148 159  
... ... @@ -151,7 +162,7 @@ integrada e sub-sistema;
151 162  
152 163 \item cada \textit{milestone} foi usado para registrar uma história de usuário;
153 164  
154   -\item cada \textit{release} tevw uma página na wiki com a compilação da reunião
  165 +\item cada \textit{release} teve uma página na wiki com a compilação da reunião
155 166 estratégica e o mapeamento das funcionalidades planejadas;
156 167  
157 168 \item para cada \textit{milestone} (história de usuário) tem um conjunto de
... ... @@ -161,4 +172,7 @@ estratégica e o mapeamento das funcionalidades planejadas;
161 172  
162 173 \end{enumerate}
163 174  
164   -Em suma, esse fluxo de trabalho proporcionou a nós e aos envolvidos do MP uma rastreabilidade completa do alinhamento estratégico do negócio, a uma visão de alto nível de cada funcionalidade (requisito/\'epico), a uma visão de grão menor dos requisitos(história de usuário) até o código-fonte.
  175 +Em suma, esse fluxo de trabalho proporcionou a nós e aos envolvidos do MP uma
  176 +rastreabilidade completa do alinhamento estratégico do negócio, a uma visão de
  177 +alto nível de cada funcionalidade (requisito/épico), a uma visão de grão
  178 +menor dos requisitos(história de usuário) até o código-fonte.
... ...
cbsoft2017/content/10-finals.tex
  Diff comments   View file @d287219
... ... @@ -19,18 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi
19 19 pesquisador visitante na Southern Illinois University Carbondale, Estados
20 20 Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade
21 21 software livre brasileira, entre outras, ministrando dezenas de palestras e
22   -parcipando como painelista em vários eventos nacionais e internacionais nas últimas
23   -duas décadas. Mais recentemente, coordenou a Evolução do Portal do Software
24   -Público Brasileiro. Também, foi consultor do projeto Participa.Br, na Secretaria-Geral
25   -da Presidência da República, para o desenvolvimento de uma plataforma de
26   -participação social baseada em projetos de software livre.
  22 +parcipando como painelista em vários eventos nacionais e internacionais nas
  23 +últimas duas décadas. Mais recentemente, coordenou a Evolução do Portal do
  24 +Software Público Brasileiro. Também, foi consultor do projeto Participa.Br, na
  25 +Secretaria-Geral da Presidência da República, para o desenvolvimento de uma
  26 +plataforma de participação social baseada em projetos de software livre.
27 27 \\
28 28 \\
29 29 {\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da
30   -Universidade de Brasília. Está cursando o doutorado no programa de Engenharia de Sistemas e
31   -Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em Ciência da
32   -Computação pela Universidade Federal de Campina Grande. Acumula 20 anos de
33   -experiência profissional na indústria de software, tendo atuado em empresas nas
34   -esferas pública e privada. Nos últimos anos tem se dedicado a pesquisar e
35   -praticar aspectos da Produção de Software com foco na Qualidade do Produto de Software.
36   -Tem colaborado com o desenvolvimento de softwares livres e também com dados abertos do governo. Entusiasta da área de Engenharia de Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e a produção de software, destacando a utilização de métodos de desenvolvimento colaborativo e aberto. Áreas de interesse: métodos ágeis/lean; engenharia de software contínua; engenharia de produto; qualidade de produto de software; análise de dados; mineraç\~ao de repostórios de software; dados abertos do governo; software livre; inovação; empreendedorismo e experimentação aplicada \`a engenharia de software.
  30 +Universidade de Brasília. Está cursando o doutorado no programa de Engenharia
  31 +de Sistemas e Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em
  32 +Ciência da Computação pela Universidade Federal de Campina Grande. Acumula 20
  33 +anos de experiência profissional na indústria de software, tendo atuado em
  34 +empresas nas esferas pública e privada. Nos últimos anos tem se dedicado a
  35 +pesquisar e praticar aspectos da Produção de Software com foco na Qualidade do
  36 +Produto de Software. Tem colaborado com o desenvolvimento de softwares livres
  37 +e também com dados abertos do governo. Entusiasta da área de Engenharia de
  38 +Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e
  39 +a produção de software, destacando a utilização de métodos de desenvolvimento
  40 +colaborativo e aberto.
  41 +
  42 +\section*{Agradecimentos}
  43 +
  44 +Agracemos à Melissa Wen, Rodrigo Siqueira, Antonio Terceiro e Lucas Kanashiro
  45 +pela co-autoria neste texto. Um agradecimento especial a todos os demais
  46 +professores, profissionais e alunos que participaram do projeto. Por fim,
  47 +agradecemos ao Prof. Leonardo Lazarte, do CDTC/UnB, e ao Prof. Fabio Kon, do
  48 +CCSL-IME-USP, pelas parcerias estratégicas e apoio constante.
... ...