Download as
Browse Code »

Commit ca5aac749c4999125fce2fdd31a5a715a941f6fd

Authored by Paulo Meireles
2 parents a14b1099 d2872190
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Merge branch 'revisao_hilmer'

Showing 5 changed files with 153 additions and 162 deletions   Show diff stats
cbsoft2017/content/01-introduction.tex
  Diff comments   View file @ca5aac7
... ... @@ -9,7 +9,7 @@ Público Brasileiro é considerado um bem público e o governo federal assume
9 9 algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios
10 10 de desenvolvimento de software livre, tal qual a tendência à descentralização
11 11 na tomada de decisões, o compartilhamento de informações e do desenvolvimento
12   -(código), e a interação contínua com seus usuários. Em 2007, o governo federal
  12 +(código-fonte), e a interação contínua com seus usuários. Em 2007, o governo federal
13 13 lançou o Portal SPB com o objetivo de compartilhar projetos de software livre
14 14 desenvolvidos pelo governo brasileiro. Adicionalmente, a Instrução Normativa
15 15 (IN 04/2012) determina que os agentes públicos devem priorizar as soluções
... ... @@ -17,7 +17,7 @@ disponíveis no Portal SPB. Em suma, a aquisição de uma solução proprietári
17 17 deve ser explicitamente justificada ao demonstrar que não há alternativa
18 18 adequada no Portal SPB.
19 19  
20   -Entretanto, desde 2009, o Portal SPB teve vários problemas técnicas. O código
  20 +Entretanto, desde 2009, o Portal SPB apresentou vários problemas técnicos. O código-fonte
21 21 original da plataforma não estava mais sendo desenvolvido, e havia uma grande
22 22 quantidade de dívidas técnicas para superar. Depois de alguns eventos e
23 23 encontros para coletar os requisitos via os agentes do governo federal e da
... ... @@ -29,7 +29,7 @@ para desenvolvimento de software colaborativo, e inclui funcionalidades para
29 29 redes sociais, listas de discussão, sistema de controle de versão e
30 30 monitoramento de qualidade de código-fonte. Para coordenar e desenvolver esse
31 31 projeto durante 30 meses, a UnB recebeu do Governo Federal Brasileiro um total
32   -de 2.619.965,00 reais.
  32 +de R\$ 2.619.965,00.
33 33  
34 34 O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de
35 35 mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo),
... ... @@ -45,7 +45,7 @@ Nosso processo foi baseado em práticas ágeis e nos mecanismos empíricos das
45 45 comunidades de software livre. Definimos ciclos de desenvolvimento e lançamos 5
46 46 versões do novo Portal SPB. A primeira versão (beta) foi disponibilizada em
47 47 setembro de 2014, apenas 9 meses desde o início do projeto. O antigo portal foi
48   -desligado em setembro de 2015. Por fim, a última versão foi entregue em junho
  48 +desativado em setembro de 2015. Por fim, a última versão foi entregue em junho
49 49 de 2016.
50 50  
51 51 Neste relato temos como agenda apresentarmos uma visão geral dessa nova geração
... ...
cbsoft2017/content/04-architecture.tex
  Diff comments   View file @ca5aac7
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 Governo
5   -Federal do Brasil, selecionamos alguns sistemas livres compor a solução
6   -proposta para o novo SPB. Avaliamos os sistemas que juntos poderiam fornecer o
7   -maior sub-conjunto possível dos requisitos. Nós também estávamos convencidos de
8   -que seria impossível fornecer todas as funcionalidade com uma única ferramenta.
9   -
10   -Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
11   -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:
12 9  
13 10 \begin{enumerate}
14 11 \item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais;
15   -\item \textit{Fornecer uma interface 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.
16 13 \end{enumerate}
17 14  
18 15 A adoção de sistemas livres existentes e a minimização de mudanças feitas
19 16 localmente tiveram como objetivo ser capazes de atualizar para versões mais
20   -recentes do software original, nos beneficiando pelas melhorias e manutenção feitas
21   -pelas comunidades de projetos existentes. Proporcionar uma interface de usuário
22   -consistente em cima dessas diferentes ferramentas era necessária para fazer a
23   -transição entre os diferentes sistemas sem a percepção do ponto de vista dos
24   -usuários, ou seja, sem confundí-lo através de interfaces completamente
25   -diferentes 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.
26 23  
27 24 Para o primeiro requisito, identificamos quatro sistemas principais que exigiam
28 25 equipes especializadas para o trabalho no processo de integração. As equipes
... ... @@ -58,12 +55,12 @@ desenvolvimento colaborativo em torno do repositório.
58 55  
59 56 \item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para
60 57 coletar métricas de código-fonte com o objetivo de monitorar a qualidade
61   -interna de projetos de software livre escrito em C, C ++, Java, Python, Ruby ou
  58 +interna de projetos de software livre escritos em C, C ++, Java, Python, Ruby ou
62 59 PHP.
63 60  
64 61 \end{itemize}
65 62  
66   -Do ponto de vista prático, a plataforma SPB foi implantada em 7 máquinas
  63 +Do ponto de vista da implantação, a plataforma SPB foi distribuída em 7 máquinas
67 64 virtuais com diferentes
68 65 funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}.
69 66  
... ...
cbsoft2017/content/07-process.tex
  Diff comments   View file @ca5aac7
... ... @@ -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 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 e tarefas de DevOps (contabilizando 16
11   -horas-semanais).
12   -
13   -O desenvolvimento do projeto SPB exigiu uma vasta experiência, que os alunos de
  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 +
  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 e
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é outros países, o que levou muita 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
... ... @@ -27,12 +27,11 @@ livre, destacando o alto grau de automação resultante das práticas de DevOps.
27 27 Assim, o processo de trabalho foi executado de forma cadenciada e contínua.
28 28  
29 29 Finalmente, o último grupo de participantes desse projeto foi composto por
30   -funcionários do Ministério
31   -do Planejamento, Desenvolvimento e Gestão (MP). Todas as decisões do projeto,
  30 +servidores públicos do MP. Todas as decisões do projeto,
32 31 validações e definições de escopo foram feitas com eles. Dessa forma,
33 32 desenvolvemos produtos de software de forma incremental, com lançamentos
34   -alinhados aos objetivos estratégicos do negócio. Como se pode ver, o projeto
35   -tinha muitos tipos diferentes de \textit{stakeholders} que tinham de ser
  33 +alinhados aos objetivos estratégicos do negócio. O projeto
  34 +tinha muitos perfis diferentes de \textit{stakeholders} que tinham de ser
36 35 organizados e sincronizados.
37 36  
38 37 \subsection{Organização da equipe}
... ... @@ -52,49 +51,50 @@ organização do projeto:
52 51 \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem
53 52 estar juntos fisicamente no laboratório (exceto, é claro, os membros da
54 53 equipe remota, mas que estarão on-line).
55   -\item A cada 2 ou 3 meses, os desenvolvedores sêniors (residentes no Brasil)
56   - voaria e trabalharia 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.
57 56 \end{enumerate}
58 57  
59 58 Com as regras acima, dividimos todo o projeto em quatro equipes diferentes:
60 59 Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach})
61 60 responsável por reduzir o problema de comunicação com as outras equipes e
62   -ajudar os membros a se organizar da melhor maneira para todos (sempre
  61 +ajudar os membros a se organizarem da melhor maneira para todos (sempre
63 62 respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
64 63 que trabalhava como desenvolvedor na equipe com o dever extra de registar as
65 64 tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a
66   -responsabilidade de conversar com outras equipes. Uma coisa importante a
67   -observar é a mutabilidade da equipe e do \textit{coach}, pois durante o projeto
68   -muitos alunos mudaram de equipes para tentar ter diferentes experiências em
69   -diversas áreas.
  65 +responsabilidade de conversar com outras equipes. É importante salientar sobre
  66 +a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
  67 +muitos alunos mudaram de equipe para tentar ter diferentes experiências em
  68 +diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se
  69 +formando.
70 70  
71 71 Uma característica das equipes foi a presença de (pelo menos) um sênior por
72 72 equipe. Isso era essencial, porque as decisões difíceis e os problemas
73 73 complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica
74   -incentivamos aos demais alunos a terem o mesmo compartamento do \textit{coach}
75   -mesmo sem serem. Por fim, os desenvolvedores sêniors trabalharam diretamente
  74 +incentivou os demais alunos a terem o mesmo compartamento do \textit{coach}
  75 +mesmo sem serem. Por fim, os desenvolvedores sêniores trabalharam diretamente
76 76 com os alunos, e isso foi importante para dar ao graduando a oportunidade de
77   -interagir com profissionais experientes em sua área e manter o conhecimento
78   -fluindo no projeto.
  77 +interagir com profissionais experientes em sua área, além de manter o
  78 +conhecimento no projeto compartilhado entre as equipes.
79 79  
80 80 Por fim, tivemos ainda dois últimos elementos da organização da equipe que
81   -foram essenciais para a harmonia do projeto: o \textit{meta-coach} e
82   -professores. O primeiro era um engenheiro de software recentemente graduado
83   -(nossos ex-alunos) e que queria continuar trabalhando no projeto; estes últimos
84   -eram professores que orquestraram todas as interações entre todos os membros do
85   -projeto, inclusive do governo federal. O \textit{meta-coach} normalmente
86   -trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado
87   -atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam
88   -juntos para reduzir o problema de comunicação entre todas as equipes (o que
89   -tornava-se mais complexo conforme a evolução do volume de trabalho). Por
90   -último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o
91   -progresso do projeto para o Ministério, foi tratada pelos professores, mas com
92   -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.
93 93  
94 94 \subsection{Comunicação e gestão das tarefas}
95 95  
96 96 Nossa equipe tinha muitas pessoas trabalhando em conjunto, e a maioria dos
97   -sêniors trabalhavam remotamente. Além disso, tentamos manter nosso trabalho
  97 +sêniores trabalhavam remotamente. Além disso, tentamos manter nosso trabalho
98 98 completamente transparente para o governo brasileiro e os cidadãos interessados
99 99 em seguir o projeto. Para lidar com esses casos, usamos um conjunto de
100 100 ferramentas de comunicação e outras para gerenciar o projeto.
... ... @@ -106,11 +106,11 @@ editor, com ambos digitando e vendo a tela. Para perguntas e discussão rápida,
106 106 usamos o IRC. Para a notificação geral, usamos as listas de discussão.
107 107  
108 108 Para a gestão do projeto utilizávamos o próprio Portal SPB; Primeiro para
109   -validá-lo por nós mesmos, e também porque ele tem todas as ferramentas
  109 +validá-lo por nós mesmos, e também porque ele tinha as ferramentas
110 110 necessárias para o nosso projeto. Basicamente, criamos uma página Wiki, no
111 111 Gitlab integrado ao SPB, com um mapeamento entre as visões estratégica, tática
112 112 e operacional. Do ponto de vista prático, um ``milestone'' no GitLab era uma
113   -``História de Usuário" (funcionalidade) e um ou mais ``issues'' no GitLab era
  113 +``História de Usuário" (funcionalidade) e um ou mais ``issues'' no GitLab eram
114 114 as tarefas para o desenvolvimento da funcionalidade em questão. Com essa
115 115 abordagem, conseguimos dois objetivos importantes: manter toda a gestão o mais
116 116 próximo possível do código-fonte e acompanhar cada funcionalidade desenvolvida
... ... @@ -120,56 +120,59 @@ plataforma).
120 120 \subsection{Acompanhamento e gerenciamento de projeto de alto nível}
121 121  
122 122 O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
123   -forma mais tradicional, diferentemente de nós com métodos ágeis e software
124   -livre. Essa dissonância nos causou um ruído de comunicação com o governo. Foi
125   -especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
126   -desenvolvimento ágil. Entretanto, depois de meses de trabalho e mostrando
127   -resultados, eles deixaram de resistir aos métodos empíricos.
128   -
129   -Definimos algum nível de granularidade de reunião para evitar gerar demasiada
130   -sobrecarga para os desenvolvedores. Tínhamos reuniões estratégica mensal e
131   -reuniões planejamento e revisão a cada 15 dias. Na reunião estratégica,
132   -geralmente, definimos as prioridades e as funcionalidades importantes para o
133   -governo. Normalmente, os professores, os \textit{coaches} de cada equipe, os
134   -\textit{meta-coaches} e alguns analistas do Ministério do Planejamento
135   -participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
136   -desde nossa última reunião e definíamos as funcionalidades para a próxima
137   -versão. Observe que apenas parte da equipe participava dessas reuniões
138   -estratégicas, mas todos os estudantes interessados estavam convidados a
139   -participar (pois muitos estudantes quiseram essa experiência durante o
140   -projeto).
141   -
142   -Depois dos encontros estratégicos com os principais atores envolvidos do
143   -governo, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
144   -parte, cada equipe trabalhava junto para converter os requisitos em partes
145   -menores (histórias de usuário) que era representadas como ``Épicos'' da
146   -``release'' em desenvolvimento. Cada \textit{coach} era responsável pela
147   -condução do planejamento, e depois a equipe toda a registrava na página wiki do
148   -projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
149   -dias a equipe gerava um o planejamento da iteração/ciclo de desenvolvimento
150   -(com os pequenos passos dos problemas mapeados). Para manter o governo
151   -brasileiro sempre atualizado, convidávamos-os a trabalhar conosco para validar
152   -as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
153   -15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
154   -plataforma do SPB, especialmente o Gitlab, tínhamos:
  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.
  129 +
  130 +Definimos níveis de granularidade das reuniões para evitar gerar demasiada
  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:
155 157  
156 158 \begin{enumerate}
157 159  
158   -\item Temos uma organização com muitos repositórios para cada ferramenta
  160 +\item uma organização com muitos repositórios para cada ferramenta
159 161 integrada e sub-sistema;
160 162  
161   -\item Cada \textit{milestone} foi usado para registrar uma história de usuário;
  163 +\item cada \textit{milestone} foi usado para registrar uma história de usuário;
162 164  
163   -\item Cada \textit{release} tem uma página no wiki com a compilação da reunião
164   -estratégica e o mapeamento sistemático das funcionalidades planejadas;
  165 +\item cada \textit{release} teve uma página na wiki com a compilação da reunião
  166 +estratégica e o mapeamento das funcionalidades planejadas;
165 167  
166   -\item Para cada \textit{milestone} (história de usuário) tem um conjunto de
  168 +\item para cada \textit{milestone} (história de usuário) tem um conjunto de
167 169 \textit{issues} (tarefas) específicas, que também são mapeadas na wiki da
168 170 \textit{release}, indicando qual dupla de desenvolvedores está trabalhando na
169 171 \textit{issue} em questão.
170 172  
171 173 \end{enumerate}
172 174  
173   -Em suma, esse fluxo de trabalho proporcionou a nós e aos participantes pelo
174   -governo brasileiro uma rastreabilidade completa e uma visão de alto nível de
175   -cada funcionalidade (requisito) até para o nível mais baixo (código).
  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/09-lessons.tex
  Diff comments   View file @ca5aac7
... ... @@ -5,8 +5,7 @@
5 5 %
6 6 Nossa equipe foi composta principalmente de estudantes de graduação em
7 7 engenharia de software, que tiveram a oportunidade de interagir com
8   -desenvolvedores sênior e designers dentro da equipe, bem como com a equipe de
9   -técnicos e gerentes do governo brasileiro.
  8 +desenvolvedores e designers sêniores dentro da equipe, bem como com a equipe de técnicos e gerentes do governo brasileiro.
10 9 %
11 10 Eles interagiram com profissionais que possuíam diversos conhecimentos e foram
12 11 capazes de participar em todos os níveis do processo de desenvolvimento de
... ... @@ -37,19 +36,14 @@ maneira coletiva, colaborativa e aberta. E mesmo sob um ambiente potencialmente
37 36 adverso, o projeto entregou a solução desejada com sucesso.
38 37 %
39 38 Ao final do projeto, notamos que as habilidades desenvolvidas pelos alunos
40   -estavam no estado da arte da prática de engenharia de software. Depois que o
41   -projeto terminou, tivemos membros da equipe que abraçaram com sucesso
  39 +os capacitaram próximo ao estado da prática de engenharia de software. Após a conclus\~ao do
  40 +projeto, tivemos membros da equipe que abraçaram com sucesso
42 41 oportunidades em organizações públicas, privadas, nacionais e internacionais,
43   -além dos estudantes que entraram no empreendedorismo e abriram suas próprias
44   -empresas. No início do projeto, as partes interessadas do governo brasileiro
45   -tinham certas expectativas sobre o desenvolvimento de projetos que, digamos,
46   -não correspondiam exatamente ao nosso trabalho baseado em práticas ágeis e de
47   -software livre. Tivemos que desenvolver estratégias que apoiassem diferentes
48   -culturas organizacionais. Conforme relatado na seção\ref{sec:process}, o Ministério do Planejamento é
49   -organizado em uma estrutura organizacional hierárquica, tipicamente,
50   -um paradigma de desenvolvimento tradicional. Portanto, tivemos que criar um
51   -processo de ``tradução'' entre nossa equipe e os analistas do MP que gerenciaram o
52   -projeto do lado deles.
  42 +além dos estudantes que empreenderam e abriram suas próprias
  43 +empresas. Conforme relatado na seção\ref{sec:process}, o MP possui uma estrutura organizacional funcional, hierárquica, tipicamente presente no paradigma de desenvolvimento tradicional. Diante disso, tivemos que desenvolver estratégias e processos de trabalho que apoiassem a comunicação de diferentes culturas organizacionais.
  44 +
  45 +
  46 +
53 47  
54 48 \textbf{Gerenciar separadamente os objetivos de nível estratégico e de nível operacional.}
55 49 %
... ... @@ -62,43 +56,33 @@ sobrecarregando os professores, uma vez eles eram responsáveis por
62 56 manter o alinhamento estratégico do MP sincronizado com os planejamentos de
63 57 implementação da equipe de desenvolvimento, especialmente à luz do
64 58 desmembramento cultural acima mencionado. A mistura de ambas as preocupações
65   -nas mesmas discussões causava confusão em ambos os lados. Para o meio e fim do
  59 +nas mesmas discussões causava confusão em ambos os lados. Na metade final do
66 60 projeto, conseguimos manter essas preocupações separadas, o que facilitou o
67 61 trabalho de todos os envolvidos.
68 62  
69 63 \textbf{Não aceitar más decisões técnicas por questões políticas.}
70 64 %
71   -Nas fases iniciais do projeto, por motivação política e pessoal, os principais
72   -atores do governo brasileiro, envolvidos na época, impuseram o uso da Colab
73   -para orientar o desenvolvimento da nova plataforma SPB. Nossa equipe estava
74   -totalmente contra a essa ideia, porque já sabíamos que o Colab era um projeto
75   -muito experimental e sua adoção poderia aumentar dramaticamente a complexidade
76   -do projeto. Mesmo nós fornecendo as razões técnicas para não utilizar Colab, MP
77   -foi inflexível e tivemos de gerir este problema. Fizemos mudanças maciças e, ao
78   -final do projeto, reescrevemos completamente o Colab e o tornamos estável (o
79   -transformando em um Sistema de Sistema em camada de aplicação). É importante
80   -notar que o MP nos obrigou a aceitar uma questão técnica baseada apenas em
81   -interesses políticos, sem considerar todos os recursos que seriam gastos devido
82   -a essa decisão. Ao final do projeto, verificamos que a Colab de fato consumiu a
83   -maior quantidade do orçamento e aumentou a complexidade do projeto.
  65 +Nas fases iniciais do projeto, por motivação política, os principais
  66 +atores do MP, envolvidos à época, impuseram a restrição do uso do software Colab. Nossa equipe foi contra a essa ideia, porque sabíamos que o Colab era um projeto
  67 +muito experimental e sua adoção poderia aumentar a complexidade
  68 +do projeto. Mesmo com as justificativas técnicas para não adoção do Colab, o MP manteve a restrição e tivemos de gerir este problema. Para adequar o Colab às necessidades do SPB, ao
  69 +final do projeto, tivemos que reescrevê-lo e com isso, o tornamos estável (o
  70 +transformando em um Sistema de Sistema em camada de aplicação). Ao final do projeto, verificamos que o Colab, de fato, consumiu a
  71 +maior quantidade do orçamento e contribuiu sobremaneira para o aumento da complexidade do projeto.
84 72  
85 73 \textbf{Considerar a sustentabilidade desde o início.}
86 74 %
87 75 No processo de implantação da plataforma SPB na estrutura do MP, tivemos que
88   -interagir com os técnicos do MP. Fizemos vários workshops, treinamento e uma
  76 +interagir com os técnicos do MP. Realizamos workshops, treinamentos e uma
89 77 documentação meticulosa descrevendo todos os procedimentos necessários para
90   -atualizar a plataforma, no entanto, percebemos que os técnicos do MP
91   -constantemente evitavam essa responsabilidade. Depois de notar essa situação,
92   -nós organizamos uma equipe de DevOps específica que automatizou completamente
93   -todo o procedimento de implantação. Nós simplificamos toda a implantação da
94   -plataforma para algumas etapas: (1) configurações iniciais (apenas configuração
95   -SSH) e (2) a execução de comandos simples para atualizar completamente a
96   -plataforma. Ao final do projeto, observamos que os técnicos do MP sempre dependiam
  78 +atualizar a plataforma. Organizamos uma equipe específica de DevOps que automatizou completamente
  79 +todo o procedimento de implantação. Simplificamos a implantação da
  80 +plataforma em algumas etapas: (1) configurações iniciais (apenas configuração
  81 +SSH) e (2) a execução de comandos para atualizar completamente o ambiente. Ao final do projeto, observamos que os técnicos do MP sempre dependiam
97 82 do nosso apoio para atualizar a plataforma, mesmo com toda a automação
98   -fornecida por nós. Ficamos tristemente com um sentimento de incerteza sobre o
99   -futuro da plataforma após o término do projeto. Em retrospectiva, percebemos
  83 +fornecida por nós. Em retrospectiva, percebemos
100 84 que o MP dedicou analistas de sistemas e gerentes para o projeto, mas não
101   -técnicos de operações e desenvolvedores, que deveria ter sido envolvido com o
  85 +técnicos de operações e desenvolvedores, que deveriam ter sido envolvidos com o
102 86 processo para que pudessem, pelo menos, de forma confortável, fazer a manutenção
103 87 da infra-estrutura plataforma.
104 88  
... ... @@ -111,6 +95,6 @@ disponíveis no próprio Portal SPB. Também contribuímos com funcionalidades e
111 95 melhorias para as respectivas comunidades dos projetos integrados: que
112 96 beneficiam essas comunidades, assim como nós, pois podemos compartilhar o
113 97 desenvolvimento futuro e o esforço de manutenção com outras organizações que
114   -participam de seus projetos.
  98 +participam desses projetos.
115 99  
116 100  
... ...
cbsoft2017/content/10-finals.tex
  Diff comments   View file @ca5aac7
... ... @@ -19,23 +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 em 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 no Gerenciamento do Produto.
36   -Nessa área, tem colaborado com o desenvolvimento de softwares livres e também
37   -com dados abertos do governo. Entusiasta da área de Engenharia de Software, é
38   -fundador e membro do laboratório LAPPIS, que possui como foco a pesquisa e a
39   -produção de software, destacando a utilização de métodos ágeis aplicados às
40   -áreas de qualidade de produto, análise de dados, segurança e software livre.
  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 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.
... ...