É estranho o número de pessoas que me perguntam como fazer para desenvolver em um grupo remoto. Resolvi colocar com base nas minhas experiências montar esse postagem.
O gerenciamento de tarefas é divido em duas partes. Milestones para quem trabalha com métodos ágeis isso seria chamado de Sprint, que como reza o Scrum não deve passar de 4 semanas. É claro que aqui também é possível descrever todo o projeto, deixando a vista todas Milestones planejados.
Cada Milestone contém um grupo de tarefas, que cada uma dessas tarefas podem ou não conter sub-tarefas, de acordo com o gerenciamento. Nesse caso é preciso que exista um Analista responsável para criar as histórias. É importante também entender que os Milestones são planejados pela equipe de desenvolvimento. O que é feito normalmente é uma reunião, onde é apresentado todo o backlog do projeto e o mesmo é quebrado em pedaços. Os prazos são definidos as vezes por toda a equipe, as vezes apenas pelo arquiteto. Essa parte fica definida pela empresa. Eu já tive os dois casos, na verdade eu gosto até mais quando é definido direto pelo Arquiteto, isso evita a perda de tempo com reuniões. Normalmente quando é definido pela equipe, notei que existe falhas de comunicação entre o Analista (PO) / Equipe de Desenvolvimento, isso gera erros de planejamento de prazos. Sem falar que existe o caso da equipe conter programadores em níveis diferentes, isso dificulta muito a média para o prazo. Uma vez que 1 tarefa para determinado desenvolvedor pode demorar 1% do que demoraria para outro. É importante entender que nesse caso não deve existir o direcionamento da tarefa para um programador específico. Uma equipe com tarefas direcionadas individualmente não é uma equipe. Se nesse caso um gerente o faz, ele deixa bem claro para toda a equipe que se você não está fazendo tal história é porque você não é bom o bastante para fazê-la. E assim, além dele atacar diretamente o ego também ajuda a promover a falta de conhecimento e evolução da equipe. Mantendo apenas aquele programador com o conhecimento necessário, criando assim o efeito refém. Já que se esse programador sair da equipe ninguém mais será capaz de fazer seu trabalho, ou mesmo de dar continuidade nele.
Não sei se você já fez tiro de guerra, ou prestou algum serviço militar, já reparou que durante a corrida que eles fazem durante o dia, todos da equipe andam na mesma velocidade ? O capitão fica na frente indicando o caminho e controlando a velocidade. Isso não quer dizer que entre esses soldados não tenha um que pode correr mais que os outros, mas garante o trabalho de equipe.
Uma equipe com nível muito diferente não consegue pontuar, sempre vai existir um programador com uma pontuação muitos disforme ao resto. Por mais incrível que pareça isso, mas os programadores com maior conhecimento e capacidade para desenvolver as histórias acabam se tornando o problema. Porque vai depender muito da humildade do mesmo para aceitar que história que ele faria em 1h pede levar 3 dias para sua equipe. Alguns livros de métodos Ágeis acredita que no caso da divergência os programadores devem conversar entre si para entender os prazos, e depois chegar em uma média. Mas na realidade o que acaba acontecendo é que o programador menos experiente não percebe que sua incapacidade é momentânea e ela tende a diminuir com o tempo. Nesse momento ele deve sim exigir seu espaço, de forma que se sinta confortável para progredir na equipe. E não se sujeitar a velocidade do programador mais experiente, o mesmo deve ser mais maduro e entender o problema da equipe e não se armar tanto durante as expectativas.
Lembrando também que nesses casos, deve existir um capitão, para controlar a velocidade e forçar a evolução da equipe. Se não existir ninguém para cobrar a melhora dos programadores menos experientes, nada garante a evolução dos mesmos. Já vi casos de programadores passarem 2 anos em uma equipe com uma evolução quase zero. É fundamental entender que deve existir um prazo para os novos se adaptarem a equipe e corresponderem conforme planejado. Manter na equipe programadores ruins também afeta os programadores mais experientes, uma vez que esses normalmente são extremamente cobrados, logo, precisam que essa carga seja divida.
Entende agora porque eu prefiro que o arquiteto planeje os prazos ? Com isso, fica mais fácil gerenciar os prazos. Caso exista algum erro de prazo, é feito um feedback para entender o que gerou o atraso e depois discutida uma melhoria. Em casos de programadores menos experientes, pode se dar cursos, cobrando sempre a melhora de velocidade. Fica mais fácil identificar os problemas da equipe ou mesmo solicitar uma substituição se necessário.
Testes
Planejamento
O planejamento do software é criado pela equipe de Análise, normalmente esse pessoal tem um contato maior com o Cliente, nesse caso existe reuniões constantes para manter em sintonia as espectativas. Quando se trabalha com métodos ágeis o Project Owner (PO), são eles que trazem os requisitos e demandas. Algumas empresas utilizam-se de vídeo conferencia, outras apenas reuniões presenciais, se me perguntar qual eu prefiro para esse caso, é uma reunião presencial. Caso não seja possível, pelo menos uma video conferencia. É extremamente importante que não exista falha de comunicação nessa parte para o sucesso do projeto.
Gerenciamento de Tarefas
O gerenciamento de tarefas é divido em duas partes. Milestones para quem trabalha com métodos ágeis isso seria chamado de Sprint, que como reza o Scrum não deve passar de 4 semanas. É claro que aqui também é possível descrever todo o projeto, deixando a vista todas Milestones planejados.
Cada Milestone contém um grupo de tarefas, que cada uma dessas tarefas podem ou não conter sub-tarefas, de acordo com o gerenciamento. Nesse caso é preciso que exista um Analista responsável para criar as histórias. É importante também entender que os Milestones são planejados pela equipe de desenvolvimento. O que é feito normalmente é uma reunião, onde é apresentado todo o backlog do projeto e o mesmo é quebrado em pedaços. Os prazos são definidos as vezes por toda a equipe, as vezes apenas pelo arquiteto. Essa parte fica definida pela empresa. Eu já tive os dois casos, na verdade eu gosto até mais quando é definido direto pelo Arquiteto, isso evita a perda de tempo com reuniões. Normalmente quando é definido pela equipe, notei que existe falhas de comunicação entre o Analista (PO) / Equipe de Desenvolvimento, isso gera erros de planejamento de prazos. Sem falar que existe o caso da equipe conter programadores em níveis diferentes, isso dificulta muito a média para o prazo. Uma vez que 1 tarefa para determinado desenvolvedor pode demorar 1% do que demoraria para outro. É importante entender que nesse caso não deve existir o direcionamento da tarefa para um programador específico. Uma equipe com tarefas direcionadas individualmente não é uma equipe. Se nesse caso um gerente o faz, ele deixa bem claro para toda a equipe que se você não está fazendo tal história é porque você não é bom o bastante para fazê-la. E assim, além dele atacar diretamente o ego também ajuda a promover a falta de conhecimento e evolução da equipe. Mantendo apenas aquele programador com o conhecimento necessário, criando assim o efeito refém. Já que se esse programador sair da equipe ninguém mais será capaz de fazer seu trabalho, ou mesmo de dar continuidade nele.
Não sei se você já fez tiro de guerra, ou prestou algum serviço militar, já reparou que durante a corrida que eles fazem durante o dia, todos da equipe andam na mesma velocidade ? O capitão fica na frente indicando o caminho e controlando a velocidade. Isso não quer dizer que entre esses soldados não tenha um que pode correr mais que os outros, mas garante o trabalho de equipe.
Uma equipe com nível muito diferente não consegue pontuar, sempre vai existir um programador com uma pontuação muitos disforme ao resto. Por mais incrível que pareça isso, mas os programadores com maior conhecimento e capacidade para desenvolver as histórias acabam se tornando o problema. Porque vai depender muito da humildade do mesmo para aceitar que história que ele faria em 1h pede levar 3 dias para sua equipe. Alguns livros de métodos Ágeis acredita que no caso da divergência os programadores devem conversar entre si para entender os prazos, e depois chegar em uma média. Mas na realidade o que acaba acontecendo é que o programador menos experiente não percebe que sua incapacidade é momentânea e ela tende a diminuir com o tempo. Nesse momento ele deve sim exigir seu espaço, de forma que se sinta confortável para progredir na equipe. E não se sujeitar a velocidade do programador mais experiente, o mesmo deve ser mais maduro e entender o problema da equipe e não se armar tanto durante as expectativas.
Lembrando também que nesses casos, deve existir um capitão, para controlar a velocidade e forçar a evolução da equipe. Se não existir ninguém para cobrar a melhora dos programadores menos experientes, nada garante a evolução dos mesmos. Já vi casos de programadores passarem 2 anos em uma equipe com uma evolução quase zero. É fundamental entender que deve existir um prazo para os novos se adaptarem a equipe e corresponderem conforme planejado. Manter na equipe programadores ruins também afeta os programadores mais experientes, uma vez que esses normalmente são extremamente cobrados, logo, precisam que essa carga seja divida.
Entende agora porque eu prefiro que o arquiteto planeje os prazos ? Com isso, fica mais fácil gerenciar os prazos. Caso exista algum erro de prazo, é feito um feedback para entender o que gerou o atraso e depois discutida uma melhoria. Em casos de programadores menos experientes, pode se dar cursos, cobrando sempre a melhora de velocidade. Fica mais fácil identificar os problemas da equipe ou mesmo solicitar uma substituição se necessário.
Legal você falou tudo isso, mas não explicou nada de como faço para cadastrar minhas tarefas no Github. Bom, segue o guia do Github que é muito melhor:
https://guides.github.com/features/issues/
Continua ...
https://guides.github.com/features/issues/
Continua ...
Interação do Grupo
Testes
Entregas
Comentários
Postar um comentário