06/02/2017 - Os Desafios do Famigerado MERGE - Histórico de revisão

Fábio Roseno em 20h49min de 6 de fevereiro de 2017

2017-02-06T20:49:03Z

Fábio Roseno em 20h48min de 6 de fevereiro de 2017

2017-02-06T20:48:41Z

Fábio Roseno em 20h47min de 6 de fevereiro de 2017

2017-02-06T20:47:12Z

Fábio Roseno em 20h46min de 6 de fevereiro de 2017

2017-02-06T20:46:01Z

Fábio Roseno em 20h45min de 6 de fevereiro de 2017

2017-02-06T20:45:20Z

Fábio Roseno em 20h43min de 6 de fevereiro de 2017

2017-02-06T20:43:29Z

Fábio Roseno: Criou página com '* Foi feito um resumo das duas últimas reuniões de desenvolvedores, para analisar o que se havia melhorado e se as ações estavam sendo tomadas. * Vimos que boa parte as a...'

2017-02-06T20:42:41Z

Criou página com '* Foi feito um resumo das duas últimas reuniões de desenvolvedores, para analisar o que se havia melhorado e se as ações estavam sendo tomadas. * Vimos que boa parte as a...'

Página nova

* Foi feito um resumo das duas últimas reuniões de desenvolvedores, para analisar o que se havia melhorado e se as ações estavam sendo tomadas.
* Vimos que boa parte as ações que competem aos Desenvolvedores, como Documentações pela WIKI, Revisões de Merges, Apresentações de Estruturas do Sistema, e etc já estão sendo feitas surtindo um pouco os efeitos das nossas Reuniões.
* Foi iniciada, por parte do Líder do Produto, uma apresentação macro, da Estrutura de algumas aplicações de Serviços e Micro-Serviços ativas no GS, como: CleanLog, GPS Coord, Claudus, dentre outros.
* Brotou-se a sugestão, de em formato de Capacitação e Testes, criássemos um branch, que recebesse os mesmos requests de merge do develop, para que nós do Desenvolvimento, tivéssemos autonomia nas revisões e merges. Que poderia ser controlado em formato de rodízio por todos, para que todos ganhassem esse skill de Revisor Aprovador de Merges, na tentativa de descentralizar essa tarefa.
* Surgiu-se também a grande ideia de se capacitar novos Revisores Aprovadores de Merges, por parte da Arquitetura, podendo ser feita no ato das aprovações de merges, chamando um desenvolvedor ou líder, pré-selecionado, para sentar-se ao lado do Arquiteto e que este obtivesse todas as informações possíveis e imagináveis para uma boa aprovação de merge. Bastando assim adequar as agendas do pré-selecionado com o Arquiteto para o momento dos respectivos merges, e dessa forma tentarmos dar fluidez nesse processo.
* Foi sugerido por Marcus, que se colocassem os códigos das Tarefas do RedMine na descrição da Requisição do Merge, para possibilitar aos os revisores e mescladores se a solução implementada está coerente com a demanda.

'''Ações a Serem Tomadas'''
----
* Publicação dos Produtos e Serviços que compõe o GeoSales na Documentação da Wiki.
* O líder do Produto Anderson Gomes, continuará a nos apresentar a estrutura de Aplicações e Serviços do GeoSales, 30 minutos antes da próxima reunião.
* Mediante consenso dos desenvolvedores, vimos que a criação de outro merge que receberia as atualizações do develop, seria mais despendioso e cansativo para os envolvidos na tarefa de controlar um branch a parte da linha de desenvolvimento.
* Solicitamos por parte da Gestão, que seja feita uma Preparação para um ou mais Desenvolvedor que seja capaz de receber no momento do merge, um by pass das melhores formas de mesclagem, para que tenhamos outros Revisores Mescladores de Merge(Trainee).

'''Participantes'''
----
Anderson Gomes, Anderson Couto, Bruno Araújo, Luan, Marcus Fábio, Mário, Raphael, Arielton e Rodrigo.

'''Moderador:''' Fábio Roseno

@@ Linha 11: / Linha 11: @@
 * O líder do Produto Anderson Gomes, continuará a nos apresentar a estrutura de Aplicações e Serviços do GeoSales, 30 minutos antes da próxima reunião.
 * Mediante consenso dos desenvolvedores, vimos que a criação de outro merge que receberia as atualizações do develop, seria mais despendioso e cansativo para os envolvidos na tarefa de controlar um branch a parte da linha de desenvolvimento.
-* Solicitamos por parte da Gestão, que seja feita uma Preparação para um ou mais Desenvolvedor e/ou Líder que seja capaz de receber no momento do merge, ao lado dos Arquitetos, um by pass das melhores formas de mesclagem, para que tenhamos outros Revisores Mescladores de Merge(Trainee).
+* Solicitamos por parte da Gestão, que seja feita uma Preparação para um ou mais Desenvolvedor e/ou Líder que seja capaz de receber no momento do merge, ao lado dos Arquitetos, um 'by pass' das melhores formas de mesclagem, para que tenhamos outros Revisores Mescladores de Merge(Trainee).
 '''Participantes'''

@@ Linha 4: / Linha 4: @@
 * Brotou-se a sugestão, de em formato de Capacitação e Testes, criássemos um branch, que recebesse os mesmos requests de merge do develop, para que nós do Desenvolvimento, tivéssemos autonomia nas revisões e merges. Que poderia ser controlado em formato de rodízio por todos, para que todos ganhassem esse skill de Revisor Aprovador de Merges, na tentativa de descentralizar essa tarefa.
 * Surgiu-se também a grande ideia de se capacitar novos Revisores Aprovadores de Merges, por parte da Arquitetura, podendo ser feita no ato das aprovações de merges, chamando um desenvolvedor ou líder, pré-selecionado, para sentar-se ao lado do Arquiteto e que este obtivesse todas as informações possíveis e imagináveis para uma boa aprovação de merge. Bastando assim adequar as agendas do pré-selecionado com o Arquiteto para o momento dos respectivos merges, e dessa forma tentarmos dar fluidez nesse processo.
-* Foi sugerido por Marcus, que se colocassem os códigos das Tarefas do RedMine na descrição da Requisição do Merge, para possibilitar aos revisores e mescladores se a solução implementada está coerente com a demanda.
+* Foi sugerido por Marcus, que se colocassem os códigos das Tarefas do RedMine na descrição da Requisição do Merge, para possibilitar aos revisores e mescladores a verificação se a solução implementada está coerente com a demanda.
 '''Ações a Serem Tomadas'''

@@ Linha 1: / Linha 1: @@
 * Foi feito um resumo das duas últimas reuniões de desenvolvedores, para analisar o que se havia melhorado e se as ações estavam sendo tomadas.
-* Vimos que boa parte as ações que competem aos Desenvolvedores, como Documentações pela WIKI, Revisões de Merges, Apresentações de Estruturas do Sistema, e etc já estão sendo feitas surtindo um pouco os efeitos das nossas Reuniões.
+* Vimos que boa parte as ações que competem aos Desenvolvedores, como Documentações pela WIKI, Revisões de Merges, Apresentações de Estruturas do Sistema, e etc já estão sendo feitas surtindo um pouco aos efeitos das nossas Reuniões.
 * Foi iniciada, por parte do Líder do Produto, uma apresentação macro, da Estrutura de algumas aplicações de Serviços e Micro-Serviços ativas no GS, como: CleanLog, GPS Coord, Claudus, dentre outros.
 * Brotou-se a sugestão, de em formato de Capacitação e Testes, criássemos um branch, que recebesse os mesmos requests de merge do develop, para que nós do Desenvolvimento, tivéssemos autonomia nas revisões e merges. Que poderia ser controlado em formato de rodízio por todos, para que todos ganhassem esse skill de Revisor Aprovador de Merges, na tentativa de descentralizar essa tarefa.