Appending lessons learned section in portuguese

Hilmer Rodrigues Neri
1 parent 461d434b
Showing 3 changed files with 22 additions and 6 deletions Show diff stats
opensym2017/content/01-introduction.tex
opensym2017/content/07-process.tex
opensym2017/content/09-lessons.tex
@@ -24,7 +24,7 @@ anymore, and the portal maintenance was becoming harder and harder.
 From January 2014 to June 2016, a new platform for the SPB Portal was
 designed and developed by the University of Brasília (UnB) and the
 University of São Paulo (USP) in a partnership with the Brazilian
-Ministry of Budget, Planning, and Management. This new Portal was
+Ministry of Budget, Planning, and Management(MP). This new Portal was
 designed as an integrated platform for collaborative software
 development. It includes functionality for social networking, mailing
 lists, version control system, and source code quality monitoring. In
@@ -17,7 +17,7 @@ synchronized.
 \subsection{Teams organizations}
-Approximately 70\% of the developmente team was composed of software engineering undergraduate students from University of Brasília and they
+Approximately 70\% of the development teams were composed of software engineering undergraduate students from UnB and they
 worked physically in the same laboratory in the opposite of the senior. Each
 student had their own scheduler based on their class, it made complicated to
 implement pair programming. Also, they had a different area of interests. To
 \section{Lessons Learned}
 \label{sec:lessons}
-- Dividir entre positivo e negativo (interação com profissionais de diferentes áreas)
+* Dividir entre positivo e negativo (interação com profissionais de diferentes áreas)
+A composição multidisciplinar dos times de desenvolvimento, principalmente engenheiros de software e designers, é necessária ao desenvolvimento de bons produtos de software, que tem naturalmente como objetivo atender as necessidades dos usuários. No contexto do projeto do SPB, haviam ainda stakeholders de diferentes áreas que compunham a equipe de técnicos e gestores do MP, além das equipes administrativas da UnB. Essa interação com diferentes profissionais trouxe uma grande oportunidade de aprendizado para a formação dos alunos, que tiveram sua primeira experiência profossional, ainda durante sua formação. Por outro lado, as diferentes percepções dos stakekholders geraram alta complexidade de gerenciamento das comunicações e expectativas, onerando demasiadamente os professores que eram responsáveis pela gestão do projeto.
+
  * arquitetura ficou mais complexa do que o necessário devido à exigência de utilização do colab (gamificação)
- * incapacidade do governo de continuar mantendo (mesmo com documentação e automação)
- * automação/DevOps
+O uso da ferramenta Colab foi um requisito exigido pelo Ministério do Planejamento. A justificativa era que esta ferramenta apresentava funcionalidades que permitiriam aos gestores do MP estimular a participação dos fornecedores de serviço ao SPB com práticas de gameficação. Como dissemos, para que o Colab desempenhasse o comportamento esperado no SPB sua arquitetura precisou ser completamente redefinida e isso representou na prática, i) o considerável aumento da complexidade arquitetural do SPB e ii) foi o subsistema que mais consumiu esforço e orçamento durante o desenvolvimento.
+ 
+* incapacidade do governo de continuar mantendo (mesmo com documentação e automação)
+* automação/DevOps
+Devido a complexidade computacional relacionada ao deployment do SPB, associada com a necessidade de sustentação do produto por parte do MP, fez com que envindássemos esforço para prover completa automação de todo o procedimento de deployment, resultado das atividades de DevOps. Com isso, encapsulamos toda essa complexidade e viabilizamos a implantação de novas versões do SPB por meio da execução de poucos comandos, conforme registrado na documentação do projeto. Embora tenhamos provido alto grau de automação, oficinas de treinamentos para a equipe técnica do MP, além de uma minusciosa descrição dos procedimentos na documentação, observamos que a equipe técnica do MP invariavelmente dependia do nosso suporte para executar esses procedimentos.
+
  * processo PMBok do Governo versus Ageis/SL do LAPPIS
+ Do ponto de vista dos processos de gestão e devenvolvimento, tivemos que desenvolver mecanismos de comunicação que acomodassem as diferentes culturas organizacionais. Como relatado, o MP possui uma cultura organizacional hierárquica funcional, fortemente apoiada na gestão por processos, típico do paradigma tradicional de desenvolvimento. Dado que utilizamos um processo apoiado nos valores do manifesto ágil e em práticas de comunidades ágeis e FOSS, criamos um processo de "tradução" do trabalho realizado para nos comunicarmos com os gestores do MP que que fazem a gestão de seu portfólio de projetos baseada nos processos do PMBoK. Se por um lado nas fases intermediáras e finais do projeto tenhamos amadurecido esse processo, principalmente pela percepção dos resultados por parte do MP, por outro, na fase inicial tivemos muita intervenção em nossa forma de trabalho, o que acabava tirando o foco de discussões estratégicas em prol de discussões operacionais. Novamente aqui houve uma sobrecarga na participação dos professores, que eram os responsáveis por manter o alinhamento estratégico do MP com o dia a dia do desenvolvimento da equipe da UnB.
+ 
+ 
  * Atores da comunidade SL no projeto
- * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M)
+ Outro fator de fundamental importância para a formação dos alunos e amadurecimento dos práticas de engenharia de software utilizadas no projeto foi a composição dos times com a participação de experientes profissionais oriundos de comunidades de FOSS. Esses profissionais juntamente com os professores promoveram uma ambiente de trabalho onde os alunos puderam desenvolver suas habilidades de uma forma didática e prática sem lhes serem transferidos as pressões do projeto. Outrossim, esses experientes profissionais foram responsáveis pelas decisões técnicas mais relevantes relacionadas ao produto de software SPB.
+ 
+% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa afirmação, embora eu e Paulo consigamos perceber isso.
+
  * Impacto nos alunos (pós projeto)
  * como trabalhar com alunos (tempo parcial etc)
+A experiência do projeto SPB fez com que a UnB desenvolvesse um modelo de composição de equipe e forma de trabalho que se mostrou adequado a cararterística de um ambiente de educação, aproximando a academia da indústria. A maior prioridade do ponto de vista da universidade é a formação dos alunos. Considerando isso, as atividades do projeto nunca foram priorizadas frente às aulas e demais atividades didático-pedagógicas. Na prática tínhamos alunos trabalhando em diferentes horários, em tempo parcial, de forma remota ou presencial, sempre respeitando suas condições individuais, mas fazendo com que o trabalho fosse realizado de forma coletiva, colaborativa e aberta. Ao final do projeto percebemos que as habilidades desenvolvidas pelos alunos os capacitaram com o estado na prática da engenharia de software. Os integrantes dos times, conseguiram oportunidades de trabalho em organizações públicas, privadas, nacionais e internacionais, além àqueles alunos que preferiam empreender, criando suas próprias empresas.
+
+
+
	@@ -24,7 +24,7 @@ anymore, and the portal maintenance was becoming harder and harder.		@@ -24,7 +24,7 @@ anymore, and the portal maintenance was becoming harder and harder.
24	From January 2014 to June 2016, a new platform for the SPB Portal was	24	From January 2014 to June 2016, a new platform for the SPB Portal was
25	designed and developed by the University of Brasília (UnB) and the	25	designed and developed by the University of Brasília (UnB) and the
26	University of São Paulo (USP) in a partnership with the Brazilian	26	University of São Paulo (USP) in a partnership with the Brazilian
27	-Ministry of Budget, Planning, and Management. This new Portal was	27	+Ministry of Budget, Planning, and Management(MP). This new Portal was
28	designed as an integrated platform for collaborative software	28	designed as an integrated platform for collaborative software
29	development. It includes functionality for social networking, mailing	29	development. It includes functionality for social networking, mailing
30	lists, version control system, and source code quality monitoring. In	30	lists, version control system, and source code quality monitoring. In
	@@ -17,7 +17,7 @@ synchronized.		@@ -17,7 +17,7 @@ synchronized.
17		17
18	\subsection{Teams organizations}	18	\subsection{Teams organizations}
19		19
20	-Approximately 70\% of the developmente team was composed of software engineering undergraduate students from University of Brasília and they	20	+Approximately 70\% of the development teams were composed of software engineering undergraduate students from UnB and they
21	worked physically in the same laboratory in the opposite of the senior. Each	21	worked physically in the same laboratory in the opposite of the senior. Each
22	student had their own scheduler based on their class, it made complicated to	22	student had their own scheduler based on their class, it made complicated to
23	implement pair programming. Also, they had a different area of interests. To	23	implement pair programming. Also, they had a different area of interests. To
1	\section{Lessons Learned}	1	\section{Lessons Learned}
2	\label{sec:lessons}	2	\label{sec:lessons}
3		3
4	-- Dividir entre positivo e negativo (interação com profissionais de diferentes áreas)	4	+* Dividir entre positivo e negativo (interação com profissionais de diferentes áreas)
		5	+A composição multidisciplinar dos times de desenvolvimento, principalmente engenheiros de software e designers, é necessária ao desenvolvimento de bons produtos de software, que tem naturalmente como objetivo atender as necessidades dos usuários. No contexto do projeto do SPB, haviam ainda stakeholders de diferentes áreas que compunham a equipe de técnicos e gestores do MP, além das equipes administrativas da UnB. Essa interação com diferentes profissionais trouxe uma grande oportunidade de aprendizado para a formação dos alunos, que tiveram sua primeira experiência profossional, ainda durante sua formação. Por outro lado, as diferentes percepções dos stakekholders geraram alta complexidade de gerenciamento das comunicações e expectativas, onerando demasiadamente os professores que eram responsáveis pela gestão do projeto.
		6	+
5	* arquitetura ficou mais complexa do que o necessário devido à exigência de utilização do colab (gamificação)	7	* arquitetura ficou mais complexa do que o necessário devido à exigência de utilização do colab (gamificação)
6	- * incapacidade do governo de continuar mantendo (mesmo com documentação e automação)
7	- * automação/DevOps	8	+O uso da ferramenta Colab foi um requisito exigido pelo Ministério do Planejamento. A justificativa era que esta ferramenta apresentava funcionalidades que permitiriam aos gestores do MP estimular a participação dos fornecedores de serviço ao SPB com práticas de gameficação. Como dissemos, para que o Colab desempenhasse o comportamento esperado no SPB sua arquitetura precisou ser completamente redefinida e isso representou na prática, i) o considerável aumento da complexidade arquitetural do SPB e ii) foi o subsistema que mais consumiu esforço e orçamento durante o desenvolvimento.
		9	+
		10	+* incapacidade do governo de continuar mantendo (mesmo com documentação e automação)
		11	+* automação/DevOps
		12	+Devido a complexidade computacional relacionada ao deployment do SPB, associada com a necessidade de sustentação do produto por parte do MP, fez com que envindássemos esforço para prover completa automação de todo o procedimento de deployment, resultado das atividades de DevOps. Com isso, encapsulamos toda essa complexidade e viabilizamos a implantação de novas versões do SPB por meio da execução de poucos comandos, conforme registrado na documentação do projeto. Embora tenhamos provido alto grau de automação, oficinas de treinamentos para a equipe técnica do MP, além de uma minusciosa descrição dos procedimentos na documentação, observamos que a equipe técnica do MP invariavelmente dependia do nosso suporte para executar esses procedimentos.
		13	+
8	* processo PMBok do Governo versus Ageis/SL do LAPPIS	14	* processo PMBok do Governo versus Ageis/SL do LAPPIS
		15	+ Do ponto de vista dos processos de gestão e devenvolvimento, tivemos que desenvolver mecanismos de comunicação que acomodassem as diferentes culturas organizacionais. Como relatado, o MP possui uma cultura organizacional hierárquica funcional, fortemente apoiada na gestão por processos, típico do paradigma tradicional de desenvolvimento. Dado que utilizamos um processo apoiado nos valores do manifesto ágil e em práticas de comunidades ágeis e FOSS, criamos um processo de "tradução" do trabalho realizado para nos comunicarmos com os gestores do MP que que fazem a gestão de seu portfólio de projetos baseada nos processos do PMBoK. Se por um lado nas fases intermediáras e finais do projeto tenhamos amadurecido esse processo, principalmente pela percepção dos resultados por parte do MP, por outro, na fase inicial tivemos muita intervenção em nossa forma de trabalho, o que acabava tirando o foco de discussões estratégicas em prol de discussões operacionais. Novamente aqui houve uma sobrecarga na participação dos professores, que eram os responsáveis por manter o alinhamento estratégico do MP com o dia a dia do desenvolvimento da equipe da UnB.
		16	+
		17	+
9	* Atores da comunidade SL no projeto	18	* Atores da comunidade SL no projeto
10	- * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M)	19	+ Outro fator de fundamental importância para a formação dos alunos e amadurecimento dos práticas de engenharia de software utilizadas no projeto foi a composição dos times com a participação de experientes profissionais oriundos de comunidades de FOSS. Esses profissionais juntamente com os professores promoveram uma ambiente de trabalho onde os alunos puderam desenvolver suas habilidades de uma forma didática e prática sem lhes serem transferidos as pressões do projeto. Outrossim, esses experientes profissionais foram responsáveis pelas decisões técnicas mais relevantes relacionadas ao produto de software SPB.
		20	+
		21	+% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa afirmação, embora eu e Paulo consigamos perceber isso.
		22	+
11	* Impacto nos alunos (pós projeto)	23	* Impacto nos alunos (pós projeto)
12	* como trabalhar com alunos (tempo parcial etc)	24	* como trabalhar com alunos (tempo parcial etc)
		25	+A experiência do projeto SPB fez com que a UnB desenvolvesse um modelo de composição de equipe e forma de trabalho que se mostrou adequado a cararterística de um ambiente de educação, aproximando a academia da indústria. A maior prioridade do ponto de vista da universidade é a formação dos alunos. Considerando isso, as atividades do projeto nunca foram priorizadas frente às aulas e demais atividades didático-pedagógicas. Na prática tínhamos alunos trabalhando em diferentes horários, em tempo parcial, de forma remota ou presencial, sempre respeitando suas condições individuais, mas fazendo com que o trabalho fosse realizado de forma coletiva, colaborativa e aberta. Ao final do projeto percebemos que as habilidades desenvolvidas pelos alunos os capacitaram com o estado na prática da engenharia de software. Os integrantes dos times, conseguiram oportunidades de trabalho em organizações públicas, privadas, nacionais e internacionais, além àqueles alunos que preferiam empreender, criando suas próprias empresas.
		26	+
		27	+
		28	+