Commit ca5aac749c4999125fce2fdd31a5a715a941f6fd
Exists in
master
and in
3 other branches
Merge branch 'revisao_hilmer'
Showing
5 changed files
with
153 additions
and
162 deletions
Show diff stats
cbsoft2017/content/01-introduction.tex
| @@ -9,7 +9,7 @@ Público Brasileiro é considerado um bem público e o governo federal assume | @@ -9,7 +9,7 @@ Público Brasileiro é considerado um bem público e o governo federal assume | ||
| 9 | algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios | 9 | algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios |
| 10 | de desenvolvimento de software livre, tal qual a tendência à descentralização | 10 | de desenvolvimento de software livre, tal qual a tendência à descentralização |
| 11 | na tomada de decisões, o compartilhamento de informações e do desenvolvimento | 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 | lançou o Portal SPB com o objetivo de compartilhar projetos de software livre | 13 | lançou o Portal SPB com o objetivo de compartilhar projetos de software livre |
| 14 | desenvolvidos pelo governo brasileiro. Adicionalmente, a Instrução Normativa | 14 | desenvolvidos pelo governo brasileiro. Adicionalmente, a Instrução Normativa |
| 15 | (IN 04/2012) determina que os agentes públicos devem priorizar as soluções | 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,7 +17,7 @@ disponíveis no Portal SPB. Em suma, a aquisição de uma solução proprietári | ||
| 17 | deve ser explicitamente justificada ao demonstrar que não há alternativa | 17 | deve ser explicitamente justificada ao demonstrar que não há alternativa |
| 18 | adequada no Portal SPB. | 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 | original da plataforma não estava mais sendo desenvolvido, e havia uma grande | 21 | original da plataforma não estava mais sendo desenvolvido, e havia uma grande |
| 22 | quantidade de dívidas técnicas para superar. Depois de alguns eventos e | 22 | quantidade de dívidas técnicas para superar. Depois de alguns eventos e |
| 23 | encontros para coletar os requisitos via os agentes do governo federal e da | 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,7 +29,7 @@ para desenvolvimento de software colaborativo, e inclui funcionalidades para | ||
| 29 | redes sociais, listas de discussão, sistema de controle de versão e | 29 | redes sociais, listas de discussão, sistema de controle de versão e |
| 30 | monitoramento de qualidade de código-fonte. Para coordenar e desenvolver esse | 30 | monitoramento de qualidade de código-fonte. Para coordenar e desenvolver esse |
| 31 | projeto durante 30 meses, a UnB recebeu do Governo Federal Brasileiro um total | 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 | O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de | 34 | O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de |
| 35 | mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo), | 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,7 +45,7 @@ Nosso processo foi baseado em práticas ágeis e nos mecanismos empíricos das | ||
| 45 | comunidades de software livre. Definimos ciclos de desenvolvimento e lançamos 5 | 45 | comunidades de software livre. Definimos ciclos de desenvolvimento e lançamos 5 |
| 46 | versões do novo Portal SPB. A primeira versão (beta) foi disponibilizada em | 46 | versões do novo Portal SPB. A primeira versão (beta) foi disponibilizada em |
| 47 | setembro de 2014, apenas 9 meses desde o início do projeto. O antigo portal foi | 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 | de 2016. | 49 | de 2016. |
| 50 | 50 | ||
| 51 | Neste relato temos como agenda apresentarmos uma visão geral dessa nova geração | 51 | Neste relato temos como agenda apresentarmos uma visão geral dessa nova geração |
cbsoft2017/content/04-architecture.tex
| 1 | \section{Visão geral do novo Portal SPB} | 1 | \section{Visão geral do novo Portal SPB} |
| 2 | \label{sec:architecture} | 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 | \begin{enumerate} | 10 | \begin{enumerate} |
| 14 | \item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais; | 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 | \end{enumerate} | 13 | \end{enumerate} |
| 17 | 14 | ||
| 18 | A adoção de sistemas livres existentes e a minimização de mudanças feitas | 15 | A adoção de sistemas livres existentes e a minimização de mudanças feitas |
| 19 | localmente tiveram como objetivo ser capazes de atualizar para versões mais | 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 | Para o primeiro requisito, identificamos quatro sistemas principais que exigiam | 24 | Para o primeiro requisito, identificamos quatro sistemas principais que exigiam |
| 28 | equipes especializadas para o trabalho no processo de integração. As equipes | 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,12 +55,12 @@ desenvolvimento colaborativo em torno do repositório. | ||
| 58 | 55 | ||
| 59 | \item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para | 56 | \item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para |
| 60 | coletar métricas de código-fonte com o objetivo de monitorar a qualidade | 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 | PHP. | 59 | PHP. |
| 63 | 60 | ||
| 64 | \end{itemize} | 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 | virtuais com diferentes | 64 | virtuais com diferentes |
| 68 | funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}. | 65 | funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}. |
| 69 | 66 |
cbsoft2017/content/07-process.tex
| @@ -2,23 +2,23 @@ | @@ -2,23 +2,23 @@ | ||
| 2 | \label{sec:process} | 2 | \label{sec:process} |
| 3 | 3 | ||
| 4 | A nossa equipe de desenvolvimento era composta por profissionais com diferentes | 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 | graduação geralmente ainda não têm. Por essa razão, alguns desenvolvedores | 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 | parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados | 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 | Em resumo, nosso processo de trabalho foi baseado em práticas de | 23 | Em resumo, nosso processo de trabalho foi baseado em práticas de |
| 24 | desenvolvimento de software livre e colaborativo. O processo de desenvolvimento | 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,12 +27,11 @@ livre, destacando o alto grau de automação resultante das práticas de DevOps. | ||
| 27 | Assim, o processo de trabalho foi executado de forma cadenciada e contínua. | 27 | Assim, o processo de trabalho foi executado de forma cadenciada e contínua. |
| 28 | 28 | ||
| 29 | Finalmente, o último grupo de participantes desse projeto foi composto por | 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 | validações e definições de escopo foram feitas com eles. Dessa forma, | 31 | validações e definições de escopo foram feitas com eles. Dessa forma, |
| 33 | desenvolvemos produtos de software de forma incremental, com lançamentos | 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 | organizados e sincronizados. | 35 | organizados e sincronizados. |
| 37 | 36 | ||
| 38 | \subsection{Organização da equipe} | 37 | \subsection{Organização da equipe} |
| @@ -52,49 +51,50 @@ organização do projeto: | @@ -52,49 +51,50 @@ organização do projeto: | ||
| 52 | \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem | 51 | \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem |
| 53 | estar juntos fisicamente no laboratório (exceto, é claro, os membros da | 52 | estar juntos fisicamente no laboratório (exceto, é claro, os membros da |
| 54 | equipe remota, mas que estarão on-line). | 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 | \end{enumerate} | 56 | \end{enumerate} |
| 58 | 57 | ||
| 59 | Com as regras acima, dividimos todo o projeto em quatro equipes diferentes: | 58 | Com as regras acima, dividimos todo o projeto em quatro equipes diferentes: |
| 60 | Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach}) | 59 | Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach}) |
| 61 | responsável por reduzir o problema de comunicação com as outras equipes e | 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 | respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos | 62 | respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos |
| 64 | que trabalhava como desenvolvedor na equipe com o dever extra de registar as | 63 | que trabalhava como desenvolvedor na equipe com o dever extra de registar as |
| 65 | tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a | 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 | Uma característica das equipes foi a presença de (pelo menos) um sênior por | 71 | Uma característica das equipes foi a presença de (pelo menos) um sênior por |
| 72 | equipe. Isso era essencial, porque as decisões difíceis e os problemas | 72 | equipe. Isso era essencial, porque as decisões difíceis e os problemas |
| 73 | complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica | 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 | com os alunos, e isso foi importante para dar ao graduando a oportunidade de | 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 | Por fim, tivemos ainda dois últimos elementos da organização da equipe que | 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 | \subsection{Comunicação e gestão das tarefas} | 94 | \subsection{Comunicação e gestão das tarefas} |
| 95 | 95 | ||
| 96 | Nossa equipe tinha muitas pessoas trabalhando em conjunto, e a maioria dos | 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 | completamente transparente para o governo brasileiro e os cidadãos interessados | 98 | completamente transparente para o governo brasileiro e os cidadãos interessados |
| 99 | em seguir o projeto. Para lidar com esses casos, usamos um conjunto de | 99 | em seguir o projeto. Para lidar com esses casos, usamos um conjunto de |
| 100 | ferramentas de comunicação e outras para gerenciar o projeto. | 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,11 +106,11 @@ editor, com ambos digitando e vendo a tela. Para perguntas e discussão rápida, | ||
| 106 | usamos o IRC. Para a notificação geral, usamos as listas de discussão. | 106 | usamos o IRC. Para a notificação geral, usamos as listas de discussão. |
| 107 | 107 | ||
| 108 | Para a gestão do projeto utilizávamos o próprio Portal SPB; Primeiro para | 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 | necessárias para o nosso projeto. Basicamente, criamos uma página Wiki, no | 110 | necessárias para o nosso projeto. Basicamente, criamos uma página Wiki, no |
| 111 | Gitlab integrado ao SPB, com um mapeamento entre as visões estratégica, tática | 111 | Gitlab integrado ao SPB, com um mapeamento entre as visões estratégica, tática |
| 112 | e operacional. Do ponto de vista prático, um ``milestone'' no GitLab era uma | 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 | as tarefas para o desenvolvimento da funcionalidade em questão. Com essa | 114 | as tarefas para o desenvolvimento da funcionalidade em questão. Com essa |
| 115 | abordagem, conseguimos dois objetivos importantes: manter toda a gestão o mais | 115 | abordagem, conseguimos dois objetivos importantes: manter toda a gestão o mais |
| 116 | próximo possível do código-fonte e acompanhar cada funcionalidade desenvolvida | 116 | próximo possível do código-fonte e acompanhar cada funcionalidade desenvolvida |
| @@ -120,56 +120,59 @@ plataforma). | @@ -120,56 +120,59 @@ plataforma). | ||
| 120 | \subsection{Acompanhamento e gerenciamento de projeto de alto nível} | 120 | \subsection{Acompanhamento e gerenciamento de projeto de alto nível} |
| 121 | 121 | ||
| 122 | O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma | 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 | \begin{enumerate} | 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 | integrada e sub-sistema; | 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 | \textit{issues} (tarefas) específicas, que também são mapeadas na wiki da | 169 | \textit{issues} (tarefas) específicas, que também são mapeadas na wiki da |
| 168 | \textit{release}, indicando qual dupla de desenvolvedores está trabalhando na | 170 | \textit{release}, indicando qual dupla de desenvolvedores está trabalhando na |
| 169 | \textit{issue} em questão. | 171 | \textit{issue} em questão. |
| 170 | 172 | ||
| 171 | \end{enumerate} | 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
| @@ -5,8 +5,7 @@ | @@ -5,8 +5,7 @@ | ||
| 5 | % | 5 | % |
| 6 | Nossa equipe foi composta principalmente de estudantes de graduação em | 6 | Nossa equipe foi composta principalmente de estudantes de graduação em |
| 7 | engenharia de software, que tiveram a oportunidade de interagir com | 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 | Eles interagiram com profissionais que possuíam diversos conhecimentos e foram | 10 | Eles interagiram com profissionais que possuíam diversos conhecimentos e foram |
| 12 | capazes de participar em todos os níveis do processo de desenvolvimento de | 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,19 +36,14 @@ maneira coletiva, colaborativa e aberta. E mesmo sob um ambiente potencialmente | ||
| 37 | adverso, o projeto entregou a solução desejada com sucesso. | 36 | adverso, o projeto entregou a solução desejada com sucesso. |
| 38 | % | 37 | % |
| 39 | Ao final do projeto, notamos que as habilidades desenvolvidas pelos alunos | 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 | oportunidades em organizações públicas, privadas, nacionais e internacionais, | 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 | \textbf{Gerenciar separadamente os objetivos de nível estratégico e de nível operacional.} | 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,43 +56,33 @@ sobrecarregando os professores, uma vez eles eram responsáveis por | ||
| 62 | manter o alinhamento estratégico do MP sincronizado com os planejamentos de | 56 | manter o alinhamento estratégico do MP sincronizado com os planejamentos de |
| 63 | implementação da equipe de desenvolvimento, especialmente à luz do | 57 | implementação da equipe de desenvolvimento, especialmente à luz do |
| 64 | desmembramento cultural acima mencionado. A mistura de ambas as preocupações | 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 | projeto, conseguimos manter essas preocupações separadas, o que facilitou o | 60 | projeto, conseguimos manter essas preocupações separadas, o que facilitou o |
| 67 | trabalho de todos os envolvidos. | 61 | trabalho de todos os envolvidos. |
| 68 | 62 | ||
| 69 | \textbf{Não aceitar más decisões técnicas por questões políticas.} | 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 | \textbf{Considerar a sustentabilidade desde o início.} | 73 | \textbf{Considerar a sustentabilidade desde o início.} |
| 86 | % | 74 | % |
| 87 | No processo de implantação da plataforma SPB na estrutura do MP, tivemos que | 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 | documentação meticulosa descrevendo todos os procedimentos necessários para | 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 | do nosso apoio para atualizar a plataforma, mesmo com toda a automação | 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 | que o MP dedicou analistas de sistemas e gerentes para o projeto, mas não | 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 | processo para que pudessem, pelo menos, de forma confortável, fazer a manutenção | 86 | processo para que pudessem, pelo menos, de forma confortável, fazer a manutenção |
| 103 | da infra-estrutura plataforma. | 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,6 +95,6 @@ disponíveis no próprio Portal SPB. Também contribuímos com funcionalidades e | ||
| 111 | melhorias para as respectivas comunidades dos projetos integrados: que | 95 | melhorias para as respectivas comunidades dos projetos integrados: que |
| 112 | beneficiam essas comunidades, assim como nós, pois podemos compartilhar o | 96 | beneficiam essas comunidades, assim como nós, pois podemos compartilhar o |
| 113 | desenvolvimento futuro e o esforço de manutenção com outras organizações que | 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
| @@ -19,23 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi | @@ -19,23 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi | ||
| 19 | pesquisador visitante na Southern Illinois University Carbondale, Estados | 19 | pesquisador visitante na Southern Illinois University Carbondale, Estados |
| 20 | Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade | 20 | Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade |
| 21 | software livre brasileira, entre outras, ministrando dezenas de palestras e | 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 | {\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da | 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. |