ajustes na secao 2.3

Hilmer Rodrigues Neri
1 parent 36e7da91
Showing 1 changed file with 22 additions and 28 deletions Show diff stats
cbsoft2017/content/07-process.tex
@@ -115,56 +115,50 @@ 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 com métodos ágeis e software
-livre. Essa dissonância nos causou um ruído de comunicação com o governo. Foi
+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 mostrando
-resultados, eles deixaram de resistir aos métodos empíricos.
-
-Definimos algum nível de granularidade de reunião para evitar gerar demasiada
-sobrecarga para os desenvolvedores. Tínhamos reuniões estratégica mensal e
-reuniões planejamento e revisão a cada 15 dias. Na reunião estratégica,
-geralmente, definimos as prioridades e as funcionalidades importantes para o
-governo. Normalmente, os professores, os \textit{coaches} de cada equipe, os
-\textit{meta-coaches} e alguns analistas do Ministério do Planejamento
+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.
+
+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 definíamos as funcionalidades para a próxima
+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 essa experiência durante o
+participar (pois muitos estudantes quiseram passar por essa experiência durante o
 projeto).
 Depois dos encontros estratégicos com os principais atores envolvidos do
-governo, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
-parte, cada equipe trabalhava junto para converter os requisitos em partes
-menores (histórias de usuário) que era representadas como ``Épicos'' da
-``release'' em desenvolvimento. Cada \textit{coach} era responsável pela
+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 iteração/ciclo de desenvolvimento
-(com os pequenos passos dos problemas mapeados). Para manter o governo
-brasileiro sempre atualizado, convidávamos-os a trabalhar conosco para validar
+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:
 \begin{enumerate}
-\item Temos uma organização com muitos repositórios para cada ferramenta
+\item uma organização com muitos repositórios para cada ferramenta
 integrada e sub-sistema;
-\item Cada \textit{milestone} foi usado para registrar uma história de usuário;
+\item cada \textit{milestone} foi usado para registrar uma história de usuário;
-\item Cada \textit{release} tem uma página no wiki com a compilação da reunião
-estratégica e o mapeamento sistemático das funcionalidades planejadas;
+\item cada \textit{release} tevw 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
+\item para cada \textit{milestone} (história de usuário) tem um conjunto de
 \textit{issues} (tarefas) específicas, que também são mapeadas na  wiki da
 \textit{release}, indicando qual dupla de desenvolvedores está trabalhando na
 \textit{issue} em questão.
 \end{enumerate}
-Em suma, esse fluxo de trabalho proporcionou a nós e aos participantes pelo
-governo brasileiro uma rastreabilidade completa e uma visão de alto nível de
-cada funcionalidade (requisito) até para o nível mais baixo (código).
+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.