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.
...	...	@@ -115,56 +115,50 @@ plataforma).
115	115	\subsection{Acompanhamento e gerenciamento de projeto de alto nível}
116	116
117	117	O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
118		-forma mais tradicional, diferentemente de nós com métodos ágeis e software
119		-livre. Essa dissonância nos causou um ruído de comunicação com o governo. Foi
	118	+forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e software
	119	+livre. Essa dissonância nos causou um ruído de comunicação com o MP. Foi
120	120	especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
121		-desenvolvimento ágil. Entretanto, depois de meses de trabalho e mostrando
122		-resultados, eles deixaram de resistir aos métodos empíricos.
123		-
124		-Definimos algum nível de granularidade de reunião para evitar gerar demasiada
125		-sobrecarga para os desenvolvedores. Tínhamos reuniões estratégica mensal e
126		-reuniões planejamento e revisão a cada 15 dias. Na reunião estratégica,
127		-geralmente, definimos as prioridades e as funcionalidades importantes para o
128		-governo. Normalmente, os professores, os \textit{coaches} de cada equipe, os
129		-\textit{meta-coaches} e alguns analistas do Ministério do Planejamento
	121	+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.
	122	+
	123	+Definimos níveis de granularidade das reuniões para evitar gerar demasiada
	124	+sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos reuniões de caráter estratégico, com periodicidade mensal, e
	125	+reuniões planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
	126	+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
	127	+\textit{meta-coaches} e alguns analistas do MP
130	128	participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
131		-desde nossa última reunião e definíamos as funcionalidades para a próxima
	129	+desde nossa última reunião e priorizámos as funcionalidades para a próxima
132	130	versão. Observe que apenas parte da equipe participava dessas reuniões
133	131	estratégicas, mas todos os estudantes interessados estavam convidados a
134		-participar (pois muitos estudantes quiseram essa experiência durante o
	132	+participar (pois muitos estudantes quiseram passar por essa experiência durante o
135	133	projeto).
136	134
137	135	Depois dos encontros estratégicos com os principais atores envolvidos do
138		-governo, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
139		-parte, cada equipe trabalhava junto para converter os requisitos em partes
140		-menores (histórias de usuário) que era representadas como ``Épicos'' da
141		-``release'' em desenvolvimento. Cada \textit{coach} era responsável pela
	136	+MP, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
	137	+parte, cada equipe trabalhava junto para converter a representação dos requisitos em ``Épicos'' da ``release'' em desenvolvimento, em requisitos
	138	+menores (histórias de usuário). Cada \textit{coach} era responsável pela
142	139	condução do planejamento, e depois a equipe toda a registrava na página wiki do
143	140	projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
144		-dias a equipe gerava um o planejamento da iteração/ciclo de desenvolvimento
145		-(com os pequenos passos dos problemas mapeados). Para manter o governo
146		-brasileiro sempre atualizado, convidávamos-os a trabalhar conosco para validar
	141	+dias a equipe gerava um o planejamento da sprint/ciclo de desenvolvimento
	142	+(com os pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado, convidávamos-os a trabalhar conosco para validar
147	143	as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
148	144	15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
149	145	plataforma do SPB, especialmente o Gitlab, tínhamos:
150	146
151	147	\begin{enumerate}
152	148
153		-\item Temos uma organização com muitos repositórios para cada ferramenta
	149	+\item uma organização com muitos repositórios para cada ferramenta
154	150	integrada e sub-sistema;
155	151
156		-\item Cada \textit{milestone} foi usado para registrar uma história de usuário;
	152	+\item cada \textit{milestone} foi usado para registrar uma história de usuário;
157	153
158		-\item Cada \textit{release} tem uma página no wiki com a compilação da reunião
159		-estratégica e o mapeamento sistemático das funcionalidades planejadas;
	154	+\item cada \textit{release} tevw uma página na wiki com a compilação da reunião
	155	+estratégica e o mapeamento das funcionalidades planejadas;
160	156
161		-\item Para cada \textit{milestone} (história de usuário) tem um conjunto de
	157	+\item para cada \textit{milestone} (história de usuário) tem um conjunto de
162	158	\textit{issues} (tarefas) específicas, que também são mapeadas na wiki da
163	159	\textit{release}, indicando qual dupla de desenvolvedores está trabalhando na
164	160	\textit{issue} em questão.
165	161
166	162	\end{enumerate}
167	163
168		-Em suma, esse fluxo de trabalho proporcionou a nós e aos participantes pelo
169		-governo brasileiro uma rastreabilidade completa e uma visão de alto nível de
170		-cada funcionalidade (requisito) até para o nível mais baixo (código).
	164	+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.
...	...