O que NÃO fazer em A6PGP: Para quê sofrer?

Boa Tarde,

Há exatas 19 semanas eu, Suzana, assim como outros membros da equipe 101010 sentamos em um laboratório do IFSP e assistimos nossa primeira e única aula de A6PGP.  Única não porque desistimos logo na primeira aula - apesar do pensamento ter me assombrado conforme os professores Daniel e Ivan liam uma lista interminável de requisitos do projeto - mas porque depois desta quarta-feira em questão todas as outras foram dedicadas à produção do projeto e apresentações.

Se o leitor que acompanha este relato esta ingressando nesta jornada pela primeira vez, saiba que é justamente pensando em você que escrevemos esta última publicação

         

                            

Desde o seu primeiro dia de aula os professores vão te falar o que fazer, você provavelmente também vai buscar em trabalhos de outros semestres exemplos para seu próprio projeto. Já nós, da equipe 101010, estamos aqui para te dizer o que não fazer A6PGP para ter um semestre mais produtivo, com mais qualidade e mais tranquilo, afinal dizem que aprendemos mais com os nossos erros, então por que não ensinar com eles também?

No postagem anterior publicada no último dia de aula já havíamos pensando em alguns tópicos sobre o que não fazer em A6PGP. Consolidamos e completamos eles nos dez tópicos que podem ser conferidos abaixo: 

1. Não deixe de ler e reler a lista do site dicas Ivan desde a primeira semana

A primeira aula é inteirinha dedicada à lista porque ela é realmente muito importante. Você vai descobrir isso em algum momento, mas que não seja tarde demais, e por tarde demais me refiro à segunda aula! Se você e a equipe não relerem e revisar metodicamente as informações do site Dicas Ivan desde a primeira aula já vão começar fazendo as coisas erradas como publicações incorretas no blog, commits equivocados no SVN, vídeos não entregues no dia das apresentações.

2. Não pratique Go Horse

Talvez você nem saiba mas praticou Go Horse Process durante todos os outros semestres. Não faça isso em A6PGP! Leia sobre o Go Horse para saber exatamente o que não fazer. Planeje-se desde a primeira semana, não adianta sair fazendo mil coisas nos primeiros dias para se adiantar, porque segundo a regra três do Go Horse Process: quanto mais  Go Horse você fizer, mais vai precisar fazer, é um ciclo difícil de quebrar. 

Fluxograma Go Horse

Fonte: Go Horse Process

3. Não queira resolver todos os problemas possíveis e impossíveis com sua aplicação

Em outras palavras: seja realista. Não dá para fazer tudo. Se você tiver isto claro desde o princípio não vai se comprometer com requisitos que não vai conseguir cumprir. É melhor algo bom e funcional do que várias coisas incompletas que não fazem muito sentido no todo.

4. Não deixe os testes e revisões para a última hora

Parece óbvio, mas com a quantidade de coisas para fazer você pode acabar cometendo este erro. Faça testes e revisões sistematicamente, se você deixar tudo para o final não vai ter tempo para fazer correções. Pode ser que na sua equipe não tenha ninguém com experiência em teste de software considere isso no planejamento do projeto e defina uma metodologia de testes no início do desenvolvimento. Em relação aos documentos adote datas fixas de revisão e pessoas atribuídas para a tarefa. Se deixar para revisar toda a produção no fim, os erros vão passar, e os professores vão encontrar estes erros, pode ter certeza disso.

5. Não fique trocando as pessoas de função dentro da equipe

Quando não há planejamento e surge um "incêndio" no meio do projeto a resposta mais rápida é realocar uma pessoa para apagá-lo. Se o papeis não estão muito bem definidos desde o início, com responsável e suplente, a única coisa que você vai conseguir é perder tempo, e tempo é o recuro mais valioso em A6PGP. Não crie uma série de atividades e entregas sem ter bem definido quem irá executá-las e principalmente quem irá substituir o executor caso seja necessário. 

6. Não escolha caminhos que vão sobrecarregar integrantes da equipe

Este é um ponto difícil de identificar no começo do projeto, mas tome cuidado na escolha de ferramentas ou metodologias. A ferramenta, por exemplo pode ser maravilhosa, mas se apenas uma pessoa no grupo domina, mesmo esta sendo muito boa no uso dela, é preciso considerar o tempo que outras pessoas vão demorar para aprender, ainda havendo a possibilidade das outras pessoas nem ao menos aprenderem, e assim você vai ter um integrante sobrecarregado na sua equipe. 

Planejamento na distribuição de tarefas e definição de início e de fim de execução de cada uma delas também evita sobrecarga, ou você perde o controle de quem etá entregando o quê dentro do seu projeto.

7. Não negligencie o gerenciamento do projeto

Se você se voluntariou ou foi incumbido do  gerenciamento do projeto, saiba que é difícil. Pode ser que na sua equipe não tenha ninguém com experiência ou mesmo perfil de gerente, não é simples, mesmo no mercado sabemos que existem péssimos gerentes. Mas você pode superar esta questão adotando metodologias e boas ferramentas e quando digo isso não quer dizer que você tenha que adotar uma metodologia conhecida na área e tentar implementá-la completamente, entenda desde o princípio que o gerenciamento tem que ser algo para tornar a execução do projeto viável, organizado, transparente e com qualidade e que não pode ser negligenciado nem por um instante.

Se você não tiver ideia por onde começar reúna a equipe e definam isso primeiro, antes dos requisitos, antes das ferramentas de desenvolvimento, antes das responsabilidades, definam como vão controlar o projeto, como vão controlar entregas, planejem as reuniões, combinem o tempo de dedicação que cada um tem disponível  e a partir dessas definições podem ter mais clareza da metodologia em si.

8. Não deixe de consultar os professores todas as semanas

Tudo que for produzido na semana mostre aos professores, dúvidas que surgirem ao longo da semana anotem em algum local compartilhado e perguntem. Se a equipe não se forçar a semanalmente apresentar algo aos professores as chances de produzir muitas coisas em desacordo vão se tornando imensas. Não esqueça que os professores são os seus clientes, se você já trabalha com análise e desenvolvimento sabe que o seu cliente quer saber o tempo todo o que você está fazendo, e se está ficando do jeito que ele quer. Se o seu cliente não te procura e você não vai atrás dele é certo que quando entregar o projeto ele irá dizer: "Não era isso que eu queria".

Coloque a meta de levar toda semana uma entrega para eles revisarem, isto também evita semanas improdutivas.

9. Não permita falhas de comunicação

Não chegue a um ponto que você não sabe o que os seus companheiros estão fazendo. É uma equipe certo? Não um grupo (lembrem-se disso, ou o Ivan vai lembrá-los o tempo todo), para ser uma equipe todos precisam estar cientes do que está acontecendo, seja sincero quanto suas dificuldades, peça ajuda quando não conseguir resolver algo sozinho, mostre para os outros o que você está fazendo, peça opinião; precisa haver transparência! E não se esqueçam de compartilhar memes, claro.

10. Não deixe o caos dominar o projeto

Com isso queremos sintetizar todos os conselhos anteriores. Se planejem e se organizem, não deixem as coisas irem seguindo naturalmente, pois a probabilidade de elas seguirem para um caminho sombrio são grandes. 

Dezenove semanas parecem uma eternidade em alguns momentos mas a verdade é que passa muito rápido, então não corra o risco de chegar no meio do semestre e descobrir que você só tem 20% do projeto concluído, e pior ainda, não ter ideia de como recuperar o tempo perdido. 

Com isso desejamos a todos boa sorte, bom trabalho e bom semestre!

Abraços meus e da Equipe 101010.