Scrum com Team Foundation Server 2010

Uma dica para os amantes do Scrum e do Dot Net é ler o slide abaixo, publicado por Aaron Bjork:

Scrum With Team Foundation Server 2010

View more presentations from Aaron Bjork.

As 10 melhores práticas para se construir software.

Estas são As 10 melhores práticas para se construir software, post escrito por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet:

1 - Desenvolva uma visão do produto.
2 - Trabalhe de modo iterativo e evolutivo.
3 - Envolva o cliente no processo.
4 - Gerencie requisitos.
5 - Acolha mudanças.
6 - Construa o design e a arquitetura incrementalmente.
7 - Diminua o tempo de feedback.
8 - Gerencie riscos.
9 - Aplique técnicas de engenharia.
10 - Confie na equipe.

Clique aqui e leia este e outros posts na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Como trabalham os desenvolvedores profissionais?

O post Como trabalham os desenvolvedores profissionais?, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, lista as características inerentes aos bons desenvolvedores da seguinte forma:

Estudam muito, sempre;
Gostam de compartilhar conhecimento;
Escrevem seus próprios testes;
Escrevem código para pessoas e não para máquinas;
Refatoram de forma disciplinada e habitualmente;
Evoluem com o design tendo o business em mente.

Clique aqui e leia este post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Verdades e Mitos sobre a Programação Orientada a Objetos

O post Verdades e Mitos sobre a Programação Orientada a Objetos, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, divide idéias sobre a programação orientada a objetos em:

Verdades:
O Desenvolvimento OO é mais lento;
Programadores mais antigos têm dificuldades com OO;
A programação OO favorece a reutilização.

Mitos:
Objetos são "abstrações" do mundo real;
Programar em Java ou C# gera automaticamente software OO;
Para aprender OO é preciso antes aprender UML;

Para saber o porquê destas verdades e mitos, clique aqui e leia o post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Scrum e as práticas de engenharia de software

O Scrum é uma metodologia adaptativa e voltada à gestão. Deixa lacunas em termos de riscos e engenharia. Por isso, o Scrum, de acordo com o contexto de cada projeto, deve ser combinado com outras práticas como, por exemplo, a gerência de riscos do PMI e práticas de engenharia de software. Neste post cito 2 práticas de engenharia do XP (Extreme Programming):

- Refactoring (refatoração): muito importante para que o código tenha um design cada vez mais limpo, elegante e flexível. Como o Scrum é um processo ágil, ocorrem vezes em que, devido ao prazo de entrega do release ao final do Sprint, um determinado código é entregue sem estar de acordo com o ideal. Isto gera um débito técnico (tech debt). Ou seja, quem entregou o código mentaliza que assim que houver a possibilidade, este código será melhorado, se tornará mais semântico, que aquele dado método que está muito grande será quebrado em métodos menores etc. E implementa estas melhorias! Para o usuário do software, o refactoring não muda nada, já que as mesmas funcionalidades serão mantidas. Porém, para o Time que desenvolveu o software, é um grande ganho de qualidade e, também, de tempo quando for necessário atender a requisitos de evolução relativos à manutenção, adaptação ou adição de novas funcionalidades.

- Pair Programming (programação em pares): visa a propriedade coletiva do código. Tem como meta a melhoria contínua do código e a idéia de que, em casos onde haja alguma dificuldade de imaginar a implementação de alguma estória, 2 cabeças pensem melhor que uma. Devido à questão da propriedade coletiva do código, a sugestão é que não se utilizem sempre os mesmos pares. O piloto deve trocar com o co-piloto e, também, as pessoas devem formar pares diferentes. Ao mesmo tempo, ninguém é obrigado a trabalhar em par o dia inteiro. Pode, por exemplo, trabalhar em par na parte da manhã e individualmente na parte da tarde. Ou vice versa! Pode trabalhar individualmente e, quando sentir a necessidade, devido a algum bloqueio de inspiração, programar em par. A programação em pares não deve ser imposta, mas uma atitude de convencimento através da conversa e da pontuação de seus benefícios.

Muitas empresas ainda não entendem a utilidade da programação em pares, com a mentalidade “pago o salário individualmente, não em par”. E muitos desenvolvedores dizem que é uma prática “furada”, sem nunca tê-la experimentado. Não se pode dizer que algo é ruim sem antes experimentar.

Scrum: por que fazer reuniões diárias?

O objetivo das reuniões diárias é que não somente o Scrum Master, mas todos os membros do Time, tenham um acompanhamento e feedback diário do Sprint. Nesta reunião, cada membro da equipe deve responder a 3 simples perguntas:

- O que fiz ontem?
- O que farei hoje?
- Houve algum impedimento?

É uma reunião rápida, realizada em pé e com um timebox de no máximo 15 minutos. Caso o(s) membro(s) reporte(m) impedimentos, o Scrum Master é responsável por, somente após a reunião, tratá-los e removê-los. Exemplos de impedimentos: solicitações referentes a outras atividades que não digam respeito ao projeto, problemas no servidor de teste, dificuldades com a tecnologia, entre outras.

O melhor horário para realizar esta reunião é na parte da manhã, quando todos os integrantes do Time tiverem chegado. Caso não seja possível, pode-se realizá-la em outro horário na parte da manhã ou da tarde. Mas é importante que sempre seja realizada em um horário fixo.

Esta reunião não é para expor um membro da equipe caso esteja com alguma dificuldade. É exatamente para que haja um feedback precoce e quaisquer dificuldades sejam sanadas. Assim, o Time se manterá sempre produtivo. Por outro lado, esta reunião também faz com que o Scrum Master detecte facilmente o “morcegão”, aquele integrante que "não quer nada com nada". Este tipo de profissional detesta Scrum.

Um bom teste para verificar se os membros do Time entenderam o significado da Daily Scrum é o Scrum Master deixar de aparecer na reunião um dado dia. Se o Time se reunir e realizar a reunião, isto significa que entendeu o seu significado.

Assim como todas as práticas sugeridas pelo Scrum, a reunião diária não deve ser imposta no estilo: “vocês vão fazer esta reunião diária porque eu sou o chefe e quero assim”. Deve-se, através da comunicação e negociação contínua, fazer com que as pessoas entendam o seu significado, passem a aderir e, conseqüentemente, apoiar sua utilidade e reconhecer seu grande valor no processo.

Scrum (Parte 4): Reuniões

Scrum – Reuniões (Cerimônias):

Sprint Planning (Planejamento do Sprint): o que vamos construir no Sprint e como iremos construir. O Product Owner (PO) explica o escopo (o que é mais importante para a dada iteração). Ele escreve as tarefas de cada história em alto nível (funcionalidades a serem construídas). Depois, o time estima a complexidade. O time escolhe o sprint backlog e escreve as tarefas para cada estória. O Time Boxed máximo para esta reunião é de 4 horas.

Daily Scrum (Reunião Diária): reunião diária para levantar como está ocorrendo o sprint. A sugestão é fazer a reunião todo dia pela manhã, se possível no começo do dia, se todos chegam no mesmo horário. O que fiz desde a última reunião? O que farei até a próxima reunião? Algum impedimento? Esta reunião é feita em pé para que seja rápida. O Scrum Master anota os impedimentos, se houverem, para depois da reunião tratá-los. Não é uma reunião de discussão. A reunião não é para o chefe, mas para o time. Um bom teste para o chefe é faltar uma vez ou outra para verificar se a equipe faz a reunião. Se não fizer, então a equipe não entendeu o propósito das reuniões diárias. Nesta reunião ninguém pode ficar exposto por não estar conseguindo realizar certas tarefas. A função do Scrum Master neste caso é escutar, depois "chamar para um café", detectar as dificuldades e pensar numa solução para esta pessoa (ex.: treinamento, ou colocar algum profissional mais experiente para auxiliá-lo). Esta reunião dá visibilidade a um processo que é empírico por natureza. As reuniões diárias visam também uma melhora constante da comunicação entre as pessoas e isso faz com que muito do que teria que ter sido escrito possa ser resolvido na base da conversa. E se uma pessoa sai da empresa, em uma equipe de 5? As outras 4 pessoas conhecem muito bem o projeto e dividirão as estórias que a pessoa que saiu deixar. Nada substitui uma boa conversa. A reunião diária leva ao feedback constante do projeto. É ESSENCIAL que pelo menos o Scrum Master e o time inteiro estejam presentes. Já o Product Owner deve estar disponível para ser consultado pelo Time diversas vezes ao longo do dia, para o caso de dúvidas em relação aos requisitos ilustrados nas estórias. Time boxed máximo: 15 minutos.

Sprint Review (Revisão do Sprint): onde o Tiime mostra o resultado do sprint (Team demo). É informal, sem slides. Todos podem participar, mas somente 'pigs' (Time, Product Owner e Scrum Master) podem falar. O Product Owner dará a nota para o Sprint, podendo aceitá-lo ou rejeitá-lo. O time boxed máximo é 2 horas.

Sprint Retrospective: lições (o que foi bom? O que precisa melhorar? O que o time pode resolver? O que a empresa precisa resolver?). Participam Product Owner, Scrum Master e Time). O time boxed máximo é de entre 2 horas.