Issue #18
Seções de Introdução e Trabalho Relacionados
Como o paper do OpenSym foi aceito, o que vamos submeter ao ICSE precisa ser um trabalho de continuidade/seguimento a esta publicação. Com isso, não precisamos focar muito em apresentação detalhada do que é o portal SPB - Arquitetura e Features, mas sim nas organização das equipes, na cultura de desenvolvimento e nas interações com o MPOG.
Também podemos já nos direcionar a discutir como o governo funciona e como a equipe de desenvolvedores funcionava. Começar a marcar os pontos de colisão/divergência nos processos de comunicação/reunião/levantamento de requisitos/homologação... etc
No OpenSym, duas das questões de pesquisa consideramos que pode ser o gancho para o trabalho do ICSE:
- How to introduce the FOSS collaborative and agile practices to governmental development process?
- How to involve undergraduate students in real-world projects, interacting with real customers from a Government?
Talvez mais a 1 do que a 2. No OpenSym, respondemos esta pergunta com uma análise mais empírica do processo (de uma maneira bem geral). Então no ICSE a ideia é termos uma avaliação mais quantitativa, além das validações (via survey).
Responsáveis:
- Diego
- Manzo
-
Terminei de ler o artigo do OpenSym hoje e tive algumas preocupações/considerações:
- Na seção de processos tem bastante coisa que possivelmente vai estar duplicada no artigo do ICSE
- Como ela fala de como a organização e processos ficaram no final (não diz que é no final em nenhum momento, mas foi a impressão que deu), será crucial focarmos na evolução.
- Na seção de lições também tem algumas coisas que podem acabar sendo duplicadas
A minha maior preocupação é a conclusão. Acredito que é possível escrever o artigo abordando essa evolução da organização e adaptação de culturas de forma diferente do que foi escrito no artigo do OpenSym. Porém, não sei como a conclusão do artigo do ICSE seria diferente, já que teria intersecção com as lições aprendidas no artigo do OpenSym. Será que conseguimos escrever algo complementar?
- Na seção de processos tem bastante coisa que possivelmente vai estar duplicada no artigo do ICSE
-
Acredito que a nossa ideia é encontrar evidências quantitativas. Analisar as respostas das surveys dos diferentes grupos (alunos/seniors/mpog) em relação a satisfação de trabalho/entregas, questões de comunicação (se há evidências de desgaste ou se os integrantes estavam confortáveis) e o quanto cada grupo sentia/tinha percepção desta diferença de culturas e pontos de conflitos na gestão desses ambientes de desenvolvimento distintos.
Se tivermos perna, penso que podemos varrer algumas issues de features que tiveram mais debates com o mpog para homologação (já pensando nas que tivemos que fazer uma reunião presencial para explicar ou acordar), ou avaliarmos as features das releases (nosso log) e o que constava nos relatórios do Gepnet (o log deles), por exemplo.
Acho que esse trabalho todo já tem uma cara bem diferente do OpenSym.
O que você acha?
-
Concordo.
Minha preocupação é como escrevermos (em particular a conclusão/lições aprendidas) para que não fique muito parecido com o que temos no OpenSym. Aqui eu estou assumindo que os resultados das surveys vão bater com o que já reportamos no OpenSym.
-
Milestone changed to Sprint 2
-
Status changed to closed
