quinta-feira, 13 de dezembro de 2018

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


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.


quarta-feira, 12 de dezembro de 2018

Lições aprendidas durante o semestre - Postagem de conclusão do semestre

Boa noite,

Durante o semestre recebemos a árdua tarefa de entregar uma aplicação documentada para cumprir os requisitos da disciplina de A6PGP. Nesse percurso, enfrentamos várias dificuldades como a própria adaptação à tecnologia usada no desenvolvimento e na aplicação e na documentação, problemas como a dificuldade individual no cumprimento de cada atividade.
Apesar de todas as barreiras apresentadas, superamos se não todas, pelo menos grande parte delas com o contato entre os membros da equipe e nossos orientadores que cooperaram bastante ajudando em nosso progresso da equipe.
Ficam como resultados claros nesse final, o desenvolvimento interpessoal de cada membro da equipe, todo o trabalho em equipe realizado e os momentos bons que cada um guardará durante o caminho desse gratificante projeto.
Algumas lições que aprendemos duramente e  gostaríamos de ensinar a outras pessoas são:

  • Sempre revisar cada atividade que está sendo executada para não ser surpreendido no final do projeto;
  • Revisar todas as semanas cada item do dicas do Ivan;
  • Não negligenciar o gerenciamento de tempo e de pessoas;
  • Não deixar ninguém sobrecarregado;
  • Definir o modelo de gerenciamento no começo do projeto e utilizá-lo.
  • Não deixar o caos dominar o projeto - parece óbvio, mas duas semanas são suficientes para instaurar o caos. 
  • Procure os professores todas as aulas, mostre os avanços, compartilhe os resultados.
 Este post é especialmente para pessoas que não são tão organizadas e metódicas: esses serão os maiores aprendizados.

Finalizamos por aqui esperando que apesar dos tropeços, nossa persistência e melhora tragam o resultado esperado!




domingo, 9 de dezembro de 2018

Resumo de Atividade - Semana 18

Boa noite,

nessa semana nossa equipe realizou a entrega da 2° versão do relatório do projeto Blood4Pets.
Após o recebimento do feedback dos professores, recebemos a missão de concluir as correções, as quais citamos abaixo e nomeamos os responsáveis:

O Arthur Soares e o Matheus Bolognesi ficaram responsáveis pela correção do documento;

O Douglas Peres se encarregou das correções referente ao  banco de dados

Vinicius Gomes na correção da aplicação, implementou a recuperação de senhas e outras correções no front-end;

A Suzana Sanches Cardoso ficou responsável pelos testes de funcionalidade;

O Vinicius Vieira pela revisão das métricas e por auxiliar em outras correções no documento.

domingo, 2 de dezembro de 2018

Resumo de Atividade - Semana 17

Boa noite,

nesta semana ocorreu o evento mais esperado do semestre: a apresentação final do projeto e o feedback dos professores. A apresentação ocorreu no sábado dia 24/11 e participaram da banca além dos professores Ivan e Daniel o professor Wagner. Os professores teceram diversas críticas aos resultados apresentados apontando erros que cometemos na documentação e na aplicação em si.

Logo após a apresentação nos reunimos para traçar a estratégia de trabalho para os últimos dias antes do fim derradeiro.

Na frente do desenvolvimento, o Douglas, que estava alocado para testes foi transferido para ajudar o Vinicius Gomes com as correções na aplicação e no banco de dados.

O Vinicius Gomes segue trabalhando na aplicação, mas decidimos que não trabalharíamos no desenvolvimento de novos requisitos, priorizando a correção de bugs e erros de segurança, ou conceituais, como a falta de aplicação de desenvolvimento orientado a objetos.

O Vinicius Vieira assumiu o lugar do Douglas na frente dos testes unitários.

O Matheus segue fazendo melhorias no documento com a criação de elementos pré e pós textuais e a correção de pontos destacados pelos professores.

O Arthur desenvolveu os vídeos das apresentação e está trabalhando na correção do diagrama de classes;

Por fim, eu, Suzana, também estou fazendo as correções destacadas no documento e criação da descrição dos casos de uso e vou ajudar o Vinicius Vieira com os testes.

Nesta reta final o desgaste emocional e cansaço pesam mais sobre os membros da equipe,  e algumas duras críticas que foram feitas pelos professores, para alguns servem como combustível e para outros como fator desanimador, mas de maneira geral acredito que a equipe está focada em realizar as correções possíveis e dar o máximo de si até a próxima quarta-feira, dia da entrega final corrigida e revisada.