domingo, 22 de fevereiro de 2015

Gerenciando projetos remotos com Github

É 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.

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 ...

Interação do Grupo

Testes
    
Entregas
   

sábado, 21 de fevereiro de 2015

TDD porque não usar

Acho muito estranho todos falarem sobre TDD hoje em dia. Mas pouco tem definido o que é e como utilizar no benefício do projeto. A mais ou menos uns 3 anos eu assisti uma palestra do Lucas Bastos, "Ágil como o MacGyver" e nela ele falava exatamente o mesmo. As pessoas se prendem em modelos prontos de solução e deixam de analisar o que realmente elas precisam.

Sendo assim resolvi comentar um pouco sobre minha experiência com TDD.

Para que fazer testes ?

Acho engraçado quando vejo algumas pessoas atribuindo os testes aos bugs. Fazer ou não fazer os testes não é solução para evitar bugs. Uma vez que mesmo seus testes podem conter bugs ou dificilmente eles vão ser tão geniais quanto os usuários de um sistema.

Os testes servem para garantir a continuidade do funcionamento do seu sistemas e não para remover erros. Em outras palavras, garantir qualidade.

Já vi programadores incríveis escreverem mais de 30 linhas de código e nem mesmo executar 1 vez se quer seu código parar verificar se ele realmente está funcionando ou não. Porém o código funcionou perfeitamente, porque o programador nesse caso, tinha o domínio total do problema e sabia exatamente onde e como resolver o problema. E da mesma forma já vi programadores mudarem apenas duas palavras e gerarem erros catastróficos em todo o sistema.

Aaaaaa, mas se eles tivessem executado os testes isso não teria acontecido

Sim, iria. O teste esperava um update, porém foi removido os filtros do update, alterando todos os resultados da base. Durante o teste isso não era verificado.

Ele deveria ter feitos mais testes para prever esses casos

É claro, programadores mais maduros conseguem prever alguns problemas, esses não são errados. Mas atirar no escuro, sem base nenhuma, sempre vai ser um problema.

Em um sistema pequeno ter testes desnecessários, quase não é perceptível, porém ter testes desnecessário significa: lentidão na de rodar sua suíte de testes e tempo desperdiçado.

Portanto o melhor a ser feito é focar seus testes naquilo que a história pede, e nos casos de bugs, acrescentar um novo teste para cada correção. Cobrindo os problemas e mantendo a integridade da história. 




segunda-feira, 17 de fevereiro de 2014

django-choices-flow 0.9.0

Finalmente nesse final de semana eu consegui terminar mais versão do django-choices-flow.
O problema só que o django-nose e o django-coverage não estão funcionando legal com o Django 1.6.2 e com o Django 1.7.x. Tive que remover eles do Travis CI.

Source Code:
https://github.com/valdergallo/django-choices-flow


Release:
https://github.com/valdergallo/django-choices-flow/blob/master/releases.md

Version: 0.9.0
  • Update default error message from Django settings
  • Add customer messagem on Choice using 'error_msg' as restrict word
  • add suport for django 1.6.x

Documentation:
https://django-choice-flow.readthedocs.org/en/latest/

sábado, 23 de novembro de 2013

django-choices-flow 0.8.5 (stable)

Motivação:

Precisava controlar a transação dos status de um Model do Django, evitando por exemplo que o usuário mudasse o status de um registro de cancelado para novo.


Documentação do projeto:



Repositório do projeto:

Release do data-importer 1.2.2

Mais de 187 downloads por dia :D

Configurações e deploy de Django na Digital Ocean

Eu distribuí os scripts de deploy do meu site, no Github para quem nunca publicou nada na Digital Oncean, o um serviço bem semelhante ao Linode, porém com HDs SSD.