From d28721906484828eaf09f622a6edfa15348de725 Mon Sep 17 00:00:00 2001 From: Paulo Meirelles Date: Mon, 10 Jul 2017 19:52:13 -0300 Subject: [PATCH] Minor adjustments --- cbsoft2017/content/04-architecture.tex | 24 ++++++++++++------------ cbsoft2017/content/07-process.tex | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------- cbsoft2017/content/10-finals.tex | 36 ++++++++++++++++++++++++------------ 3 files changed, 106 insertions(+), 80 deletions(-) diff --git a/cbsoft2017/content/04-architecture.tex b/cbsoft2017/content/04-architecture.tex index d28b041..8dd05eb 100644 --- a/cbsoft2017/content/04-architecture.tex +++ b/cbsoft2017/content/04-architecture.tex @@ -1,25 +1,25 @@ \section{Visão geral do novo Portal SPB} \label{sec:architecture} -Com base em uma extensa lista de requisitos funcionais definidos pelo MP, selecionamos alguns sistemas livres candidatos \'a compor a solução -proposta para o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior sub-conjunto possível dos requisitos. - -Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova -plataforma: +Com base em uma extensa lista de requisitos funcionais definidos pelo MP, +selecionamos alguns sistemas livres candidatos à compor a solução proposta para +o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior +sub-conjunto possível dos requisitos. Do ponto de vista da arquitetura, dois +requisitos eram importantes para a nova plataforma: \begin{enumerate} \item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais; -\item \textit{Fornecer uma experi\^encia de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada. +\item \textit{Fornecer uma experiência de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada. \end{enumerate} A adoção de sistemas livres existentes e a minimização de mudanças feitas localmente tiveram como objetivo ser capazes de atualizar para versões mais -recentes do software original, nos beneficiando pelas melhorias e manutenção feitas -pelas comunidades de projetos existentes. Proporcionar uma experi\^encia de usuário -consistente em cima dessas diferentes ferramentas era necessária para fazer a -transição entre os diferentes sistemas sem a percepção do ponto de vista dos -usuários, ou seja, sem confundí-lo através de interfaces gráficas completamente -distintas ao interagir com o portal. +recentes do software original, nos beneficiando pelas melhorias e manutenção +feitas pelas comunidades de projetos existentes. Proporcionar uma experiência +de usuário consistente em cima dessas diferentes ferramentas era necessária +para fazer a transição entre os diferentes sistemas sem a percepção do ponto de +vista dos usuários, ou seja, sem confundí-lo através de interfaces gráficas +completamente distintas ao interagir com o portal. Para o primeiro requisito, identificamos quatro sistemas principais que exigiam equipes especializadas para o trabalho no processo de integração. As equipes diff --git a/cbsoft2017/content/07-process.tex b/cbsoft2017/content/07-process.tex index 93ad1ec..3f69ca4 100644 --- a/cbsoft2017/content/07-process.tex +++ b/cbsoft2017/content/07-process.tex @@ -2,23 +2,23 @@ \label{sec:process} A nossa equipe de desenvolvimento era composta por profissionais com diferentes -níveis de experiência e habilidades, sendo a maioria deles estudantes de graduação de -engenharia de software (a partir do 4º semestre de curso). Uma vez que os -alunos não podiam dedicar muitas horas por semana ao projeto, eles sempre -tiveram a flexibilidade para negociar seus horários de trabalho durante o -semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diária -no projeto incluiu programação, testes e tarefas de DevOps (contabilizando 16 -horas-semanais). +níveis de experiência e habilidades, sendo a maioria deles estudantes de +graduação de engenharia de software (a partir do 4º semestre de curso). Uma vez +que os alunos não podiam dedicar muitas horas por semana ao projeto, eles +sempre tiveram a flexibilidade para negociar seus horários de trabalho durante +o semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho +diária no projeto incluiu programação, testes e tarefas de DevOps +(contabilizando 16 horas-semanais). O desenvolvimento do projeto SPB exigiu experiência avançada, que os alunos de graduação geralmente ainda não têm. Por essa razão, alguns desenvolvedores -sênior se juntaram ao projeto para ajudar com as questões mais difíceis, além de -transferir conhecimento aos alunos. Sua principal tarefa era fornecer soluções -para problemas complexos. Como esses profissionais são muito hábeis e o projeto -não poderia financiar um trabalho de tempo integral, eles trabalharam +sênior se juntaram ao projeto para ajudar com as questões mais difíceis, além +de transferir conhecimento aos alunos. Sua principal tarefa era fornecer +soluções para problemas complexos. Como esses profissionais são muito hábeis e +o projeto não poderia financiar um trabalho de tempo integral, eles trabalharam parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados -diferentes espalhados pelo Brasil, ou até em outros países, o que levou muito da -comunicação a ser on-line. +diferentes espalhados pelo Brasil, ou até em outros países, o que levou muito +da comunicação a ser on-line. Em resumo, nosso processo de trabalho foi baseado em práticas de desenvolvimento de software livre e colaborativo. O processo de desenvolvimento @@ -51,7 +51,8 @@ organização do projeto: \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem estar juntos fisicamente no laboratório (exceto, é claro, os membros da equipe remota, mas que estarão on-line). -\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil) trabalharia presencialmente ao lado dos alunos por uma semana. +\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil) +trabalharia presencialmente ao lado dos alunos por uma semana. \end{enumerate} 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 respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos que trabalhava como desenvolvedor na equipe com o dever extra de registar as tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a -responsabilidade de conversar com outras equipes. É importante salientar sobre a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto +responsabilidade de conversar com outras equipes. É importante salientar sobre +a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto muitos alunos mudaram de equipe para tentar ter diferentes experiências em -diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se formando. +diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se +formando. Uma característica das equipes foi a presença de (pelo menos) um sênior por 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 incentivou os demais alunos a terem o mesmo compartamento do \textit{coach} mesmo sem serem. Por fim, os desenvolvedores sêniores trabalharam diretamente com os alunos, e isso foi importante para dar ao graduando a oportunidade de -interagir com profissionais experientes em sua área, além de manter o conhecimento no projeto compartilhado entre as equipes. +interagir com profissionais experientes em sua área, além de manter o +conhecimento no projeto compartilhado entre as equipes. Por fim, tivemos ainda dois últimos elementos da organização da equipe que -foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os -professores. O primeiro era um engenheiro de software recentemente graduado, egresso, e que queria continuar trabalhando no projeto; esses últimos -eram professores que orquestraram todas as interações entre todos os membros do -projeto, inclusive do MP. O \textit{meta-coach} normalmente -trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado -atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam -juntos para reduzir o problema de comunicação entre todas as equipes (o que -tornou-se mais complexo conforme a evolução do volume de trabalho). Por -último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o -progresso do projeto para o Ministério, foi tratada pelos professores, mas com -o envolvimento de toda a equipe. +foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os +professores. O primeiro era um engenheiro de software recentemente graduado, +egresso, e que queria continuar trabalhando no projeto; esses últimos eram +professores que orquestraram todas as interações entre todos os membros do +projeto, inclusive do MP. O \textit{meta-coach} normalmente trabalhava em uma +equipe específica e tinha a tarefa extra de conhecer o estado atual de todas as +equipes. Os professores e \textit{meta-coach} trabalharam juntos para reduzir o +problema de comunicação entre todas as equipes (o que tornou-se mais complexo +conforme a evolução do volume de trabalho). Por último, todas as tarefas +burocráticas, como a elaboração de relatórios sobre o progresso do projeto para +o Ministério, foi tratada pelos professores, mas com o envolvimento de toda a +equipe. \subsection{Comunicação e gestão das tarefas} @@ -115,34 +120,40 @@ plataforma). \subsection{Acompanhamento e gerenciamento de projeto de alto nível} O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma -forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e software -livre. Essa dissonância nos causou um ruído de comunicação com o MP. Foi -especialmente difícil convencê-los a aceitar a ideia de escopo aberto e -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. +forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e +software livre. Essa dissonância nos causou um ruído de comunicação com o MP. +Foi especialmente difícil convencê-los a aceitar a ideia de escopo aberto e +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 \textit{releases}, a resistência foi gradualmente diminuindo. Definimos níveis de granularidade das reuniões para evitar gerar demasiada -sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos reuniões de caráter estratégico, com periodicidade mensal, e -reuniões planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica, -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 -\textit{meta-coaches} e alguns analistas do MP -participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu -desde nossa última reunião e priorizámos as funcionalidades para a próxima -versão. Observe que apenas parte da equipe participava dessas reuniões -estratégicas, mas todos os estudantes interessados estavam convidados a -participar (pois muitos estudantes quiseram passar por essa experiência durante o -projeto). - -Depois dos encontros estratégicos com os principais atores envolvidos do -MP, tínhamos um turno de planejamento com todas as equipes juntas. Nessa -parte, cada equipe trabalhava junto para converter a representação dos requisitos em ``Épicos'' da ``release'' em desenvolvimento, em requisitos -menores (histórias de usuário). Cada \textit{coach} era responsável pela -condução do planejamento, e depois a equipe toda a registrava na página wiki do -projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15 -dias a equipe gerava um o planejamento da sprint/ciclo de desenvolvimento -(com os pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado, convidávamos-os a trabalhar conosco para validar -as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada -15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria -plataforma do SPB, especialmente o Gitlab, tínhamos: +sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos +reuniões de caráter estratégico, com periodicidade mensal, e reuniões +planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica, +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 \textit{meta-coaches} e alguns analistas do MP participavam dessa reunião. +Em geral, discutíamos o que a equipe já produziu desde nossa última reunião e +priorizámos as funcionalidades para a próxima versão. Observe que apenas parte +da equipe participava dessas reuniões estratégicas, mas todos os estudantes +interessados estavam convidados a participar (pois muitos estudantes quiseram +passar por essa experiência durante o projeto). + +Depois dos encontros estratégicos com os principais atores envolvidos do MP, +tínhamos um turno de planejamento com todas as equipes juntas. Nessa parte, +cada equipe trabalhava junto para converter a representação dos requisitos em +``épicos da \textit{release}'' em desenvolvimento, em requisitos menores +(histórias de usuário). Cada \textit{coach} era responsável pela condução do +planejamento, e depois a equipe toda a registrava na página wiki do projeto +(wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15 dias a +equipe gerava um o planejamento da iteração/ciclo de desenvolvimento (com os +pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado, +convidávamos-os a trabalhar conosco para validar as funcionalidades em +desenvolvimento. Para isso, tínhamos uma reunião a cada 15 dia. E para manter +nosso fluxo de gestão de tarefas, usando a própria plataforma do SPB, +especialmente o Gitlab, tínhamos: \begin{enumerate} @@ -151,7 +162,7 @@ integrada e sub-sistema; \item cada \textit{milestone} foi usado para registrar uma história de usuário; -\item cada \textit{release} tevw uma página na wiki com a compilação da reunião +\item cada \textit{release} teve uma página na wiki com a compilação da reunião estratégica e o mapeamento das funcionalidades planejadas; \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; \end{enumerate} -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. +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/épico), a uma visão de grão +menor dos requisitos(história de usuário) até o código-fonte. diff --git a/cbsoft2017/content/10-finals.tex b/cbsoft2017/content/10-finals.tex index 29bf758..180d4c8 100644 --- a/cbsoft2017/content/10-finals.tex +++ b/cbsoft2017/content/10-finals.tex @@ -19,18 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi pesquisador visitante na Southern Illinois University Carbondale, Estados Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade software livre brasileira, entre outras, ministrando dezenas de palestras e -parcipando como painelista em vários eventos nacionais e internacionais nas últimas -duas décadas. Mais recentemente, coordenou a Evolução do Portal do Software -Público Brasileiro. Também, foi consultor do projeto Participa.Br, na Secretaria-Geral -da Presidência da República, para o desenvolvimento de uma plataforma de -participação social baseada em projetos de software livre. +parcipando como painelista em vários eventos nacionais e internacionais nas +últimas duas décadas. Mais recentemente, coordenou a Evolução do Portal do +Software Público Brasileiro. Também, foi consultor do projeto Participa.Br, na +Secretaria-Geral da Presidência da República, para o desenvolvimento de uma +plataforma de participação social baseada em projetos de software livre. \\ \\ {\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da -Universidade de Brasília. Está cursando o doutorado no programa de Engenharia de Sistemas e -Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em Ciência da -Computação pela Universidade Federal de Campina Grande. Acumula 20 anos de -experiência profissional na indústria de software, tendo atuado em empresas nas -esferas pública e privada. Nos últimos anos tem se dedicado a pesquisar e -praticar aspectos da Produção de Software com foco na Qualidade do Produto de Software. -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. +Universidade de Brasília. Está cursando o doutorado no programa de Engenharia +de Sistemas e Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em +Ciência da Computação pela Universidade Federal de Campina Grande. Acumula 20 +anos de experiência profissional na indústria de software, tendo atuado em +empresas nas esferas pública e privada. Nos últimos anos tem se dedicado a +pesquisar e praticar aspectos da Produção de Software com foco na Qualidade do +Produto de Software. 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. + +\section*{Agradecimentos} + +Agracemos à Melissa Wen, Rodrigo Siqueira, Antonio Terceiro e Lucas Kanashiro +pela co-autoria neste texto. Um agradecimento especial a todos os demais +professores, profissionais e alunos que participaram do projeto. Por fim, +agradecemos ao Prof. Leonardo Lazarte, do CDTC/UnB, e ao Prof. Fabio Kon, do +CCSL-IME-USP, pelas parcerias estratégicas e apoio constante. -- libgit2 0.21.2