diff --git a/opensym2017/content/09-lessons.tex b/opensym2017/content/09-lessons.tex index 794fe63..9ad8a70 100644 --- a/opensym2017/content/09-lessons.tex +++ b/opensym2017/content/09-lessons.tex @@ -1,28 +1,17 @@ \section{Lessons Learned} \label{sec:lessons} -* 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. +The multidisciplinary composition of the development teams, mainly software engineers and designers, is necessary for the development of good software products, which naturally aim to meet the users needs. In the context of the SPB project, there were also stakeholders from different areas who composed the team of technicians and managers of the MP, as well as the administrative teams of UnB. This interaction with different professionals brought a great learning opportunity for the students, who had their first professional experience, even during their graduation course. On the other hand, the different perceptions of stakeholders generated high complexity of communications and expectations management, burdening too much the professors who were responsible for project management. - * arquitetura ficou mais complexa do que o necessário devido à exigência de utilização do colab (gamificação) -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. +The use of the Colab tool was a requirement required by the MP. They argueed that this tool presented functionalities that would allow MP managers to stimulate the participation of SPB service providers with gamefication practices. As we said, in order for Colab to perform the expected behavior in SPB its architecture had to be completely redefined and this caused in practice, i) the considerable increase in the architectural complexity of the SPB and ii) it was the subsystem that consumed the most effort and budget during development. - * 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 - 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. +Due to the computational complexity related to the SPB deployment, associated with MP's need for product support, we made an effort to provide complete automation of the entire deployment procedure, a result of DevOps activities. In this way, we encapsulate all this complexity and enable the deployment of new SPB releases through the execution of few commands, as registered in the project documentation. Although we have provided a high degree of automation, training workshops for the MP technical team, and a meticulous description of the procedures in the documentation, we observed that the MP technical staff invariably depended on our support to perform these procedures. - * 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. +From the point of view of management and development processes, we had to develop management strategies that would accommodate different organizational cultures. As reported, the MP has a functional hierarchical organizational culture, strongly supported by process management, typical of the traditional development paradigm. The UnB teams use a process based on agile manifest values ​​and FOSS and agile community practices. So we created a process of "translation" of work done to communicate with MP managers who manage their portfolio based on the PMBoK processes. On the one hand, in the intermediary and final project's phases we have matured this process, mainly due to the perception of the results by MP, on the other hand, in the initial phase we had a lot of intervention in our work style, which ended up focusing strategic discussions for operational discussions. Again there was an overload in professors, who were responsible for maintaining the strategic alignment of the MP with the day to day development of the UnB team. +Another importance factor for the students and maturing of the software engineering practices used in the project was the composition of the teams with the participation of experienced professionals from the FOSS communities. These professionals together with the professors promoted a work environment where the students could develop their skills in a didactic and practical way without being transferred the pressures for them. In addition, these experienced professionals were responsible for the most relevant technical decisions related to the SPB software product. + +% * 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. +The experience of the SPB project led UnB to develop a model of team composition and work style that proved to be appropriate to the cararteristics of an education environment, bringing the academy closer to the industry. The highest priority from the university's point of view is the students. Considering this, the activities of the project were never prioritized to the detriment of the classes and other didactic-pedagogical activities. In short we had students working at different times, part time, remotely or presential, always respecting their individual conditions, but doing the work in a collective, collaborative and open way. At the end of the project we realized that the skills developed by the students empowered them with the state in the practice of software engineering. The members of the teams got opportunities to work in public, private, national and international organizations, in addition to those students they preferred entrepreneurship, opening their own companies. -- libgit2 0.21.2