diff --git a/cbsoft2017/content/07-process.tex b/cbsoft2017/content/07-process.tex index d0192fa..93ad1ec 100644 --- a/cbsoft2017/content/07-process.tex +++ b/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. -- libgit2 0.21.2