Métodos ágeis em FLOSS - CONSEGI 2011 - PT-BR
•Transferir como ODP, PDF•
1 gostou•667 visualizações
Apresentando os resultados da minha pesquisa de mestrado sobre as coisas que podem ser melhoradas buscando ideias na outra comunidade.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Métodos ágeis em FLOSS - CONSEGI 2011 - PT-BR
Semelhante a Métodos ágeis em FLOSS - CONSEGI 2011 - PT-BR (20)
Mais de Hugo Corbucci
Mais de Hugo Corbucci (12)
Métodos ágeis em FLOSS - CONSEGI 2011 - PT-BR
- 1. Métodos ágeis e software livre: um estudo da relação entre estas duas comunidades 2 01 1 Hugo Corbucci 2 01 0 2 009 corbucci@ime.usp.br 2 008 2 007 2 006
- 3. Software livre Liberdade para todos
- 4. Software livre Liberdade para todos de estudar e modificar
- 5. Software livre Liberdade para todos de estudar e modificar o funcionamento de projetos
- 8. Métodos ágeis Melhores formas de desenvolver software
- 9. Métodos ágeis Melhores formas de desenvolver software em equipe
- 10. Métodos ágeis Melhores formas de desenvolver software em equipe na indústria
- 11. ✓
- 12. ?
- 17. E ?
- 18. E OU
- 21. ?
- 22. ?
- 23. ?
- 24. ?
- 26. Indivíduos e interações sobre processos e ferramentas ✓
- 27. Software em funcionamento sobre documentação abrangente ✓
- 28. Colaboração com o cliente sobre negociação de contratos ?
- 29. Responder a mudanças sobre seguir um plano ✓
- 30. Será que eles enfrentam os mesmos problemas?
- 31. ? ?
- 33. Identificar o público participante
- 34. Avaliar seus conhecimentos em suas comunidades
- 35. Identificar principais problemas e soluções possíveis
- 37. Resultados
- 38. 180 respostas ok + 122 sem experiência 133 respostas ok + 28 sem experiência
- 39. 200 180 160 140 120 100 80 60 40 20 0 1971 1975 1979 1983 1987 1991 1995 1999 2003 2007 1969 1973 1977 1981 1985 1989 1993 1997 2001 2005 2009 O deslanche de FLOSS é menor mas mais antigo 140 120 100 80 60 40 20 0 1971 1975 1979 1983 1987 1991 1995 1999 2003 2007 1969 1973 1977 1981 1985 1989 1993 1997 2001 2005 2009
- 40. 100 90 80 0 70 70% menos 1a5 6 a 10 60 11 a 50 mais de 50 50 40 30 de 10 20 10 0 FLOSS tem algumas equipes maiores 70 60 50 80% menos 40 1a5 6 a 10 11 a 20 de 10 30 mais de 20 20 10 0
- 41. Equipes fragmentadas Mais distinções de papéis em FLOSS Membros multi- disciplinares
- 47. Princípios Princípios em FLOSS em ágeis
- 49. ?
- 51. Revisões Cruzadas
- 54. Retrospectivas
- 60. PDOC – Documentação do Produto (Product Documentation) Prover documentação de alta qualidade Criar uma documentação de desenvolvimento Criar uma documentação para usuário Criar uma documentação genérica Manter a documentação listada acima Melhorar a documentação do sistema Disponibilizar a doc. em várias línguas naturais e sua disponibilidade
- 61. PDOC – Documentação do Produto (Product Documentation) Prover documentação de alta qualidade Criar uma documentação de desenvolvimento Criar uma documentação para usuário Criar uma documentação genérica Manter a documentação listada acima Melhorar a documentação do sistema Disponibilizar a doc. em várias línguas naturais e sua disponibilidade
- 62. STD – Uso de Padrões Estabelecidos e Adotados (Use of Established and Widespread Standards) Desenvolver padrões abertos Usar padrões existentes e conhecidos e documentar seu uso Adotar padrões certificados por entidades que apoiam FLOSS Adotar processos de devolvimento que sejam padrões Desenvolver padrões abertos para seus processos e avaliá-los Garantir independência estratégica do projeto
- 63. STD – Uso de Padrões Estabelecidos e Adotados (Use of Established and Widespread Standards) Desenvolver padrões abertos Usar padrões existentes e conhecidos e documentar seu uso Adotar padrões certificados por entidades que apoiam FLOSS Adotar processos de devolvimento que sejam padrões Desenvolver padrões abertos para seus processos e avaliá-los Garantir independência estratégica do projeto
- 64. QTP – Qualidade do Plano de Testes (Quality of Test Plan) Prover um plano de testes de alta qualidade Garantir que o plano de testes cubra testes funcionais e não-funcionais Garantir que o plano de testes cubra vários tipos de testes Desenvolver e gerenciar o processo de testes Conduzir testes regularmente Garantir que recursos para testes e os resultados deles estão disponíveis Melhorar o processo de testes
- 65. QTP – Qualidade do Plano de Testes (Quality of Test Plan) Prover um plano de testes de alta qualidade Garantir que o plano de testes cubra testes funcionais e não-funcionais Garantir que o plano de testes cubra vários tipos de testes Desenvolver e gerenciar o processo de testes Conduzir testes regularmente Garantir que recursos para testes e os resultados deles estão disponíveis Melhorar o processo de testes
- 66. ENV – Ambiente Técnico (Technical Environment) Planejar para ter recursos e infra para o desenvolvimento Garantir disponibilidade do ambiente e das ferramentas de desenvolvimento Garantir disponibilidade das metodologias de desenvolvimento Manter continuamente o ambiente com base em feedback Medir o nível de satisfação do desenvolvedores com o ambiente Melhorar o uso de ferramentas livres
- 67. ENV – Ambiente Técnico (Technical Environment) Planejar para ter recursos e infra para o desenvolvimento Garantir disponibilidade do ambiente e das ferramentas de desenvolvimento Garantir disponibilidade das metodologias de desenvolvimento Manter continuamente o ambiente com base em feedback Medir o nível de satisfação do desenvolvedores com o ambiente Melhorar o uso de ferramentas livres
- 68. DFCT – Número de Commits e Relatórios de Defeitos (Number of Commits and Bug Reports) Prover um ambiente fácil para contribuir com relatórios de erros Gerir as contribuições, commits e relatórios de erros Melhorar o ambiente para contribuições Encorajar usuários a contribuir mais dando mais privilégios Medir o nível de satisfação dos usuários Melhorar o tempo de resposta da comunidade aos erros apontados
- 69. DFCT – Número de Commits e Relatórios de Defeitos (Number of Commits and Bug Reports) Prover um ambiente fácil para contribuir com relatórios de erros Gerir as contribuições, commits e relatórios de erros Melhorar o ambiente para contribuições Encorajar usuários a contribuir mais dando mais privilégios Medir o nível de satisfação dos usuários Melhorar o tempo de resposta da comunidade aos erros apontados
- 70. MST – Facilidade de Manutenção e Estabilidade (Maintainability and Stability) Planejar a qualidade do produto Garantir que o código e design são estáveis e de fácil manutenção Realizar testes de estabilidade em outros sistemas de software e hardware Planejar a qualidade do processo Medir os objetivos atingidos pelo projeto Gerir o processo de 'manutenabilidade' Avaliar a interoperabilidade e compatibilidade entre versões do produto
- 71. MST – Facilidade de Manutenção e Estabilidade (Maintainability and Stability) Planejar a qualidade do produto Garantir que o código e design são estáveis e de fácil manutenção Realizar testes de estabilidade em outros sistemas de software e hardware Planejar a qualidade do processo Medir os objetivos atingidos pelo projeto Gerir o processo de 'manutenabilidade' Avaliar a interoperabilidade e compatibilidade entre versões do produto
- 72. CM – Gestão de Configuração (Configuration Management) Estabelecer 'linhas-guias' Identificar itens de configuração Estebelecer um sistema de gestão de configuração Acompanhar e controlar mudanças Estabelecer integridade dos itens de configuração
- 73. CM – Gestão de Configuração (Configuration Management) Estabelecer 'linhas-guias' Identificar itens de configuração Estebelecer um sistema de gestão de configuração Acompanhar e controlar mudanças Estabelecer integridade dos itens de configuração
- 74. PP1 – Planejamento de Projeto Parte 1 (Project Planning Part 1) Esbelecer estimativas Estimar o escopo do projeto
- 75. PP1 – Planejamento de Projeto Parte 1 (Project Planning Part 1) Esbelecer estimativas Estimar o escopo do projeto
- 76. REQM – Gestão de Requisitos (Requirements Management) Gerir requisitos Obter um entendimento de requisitos Gerir mudanças nos requisitos
- 77. REQM – Gestão de Requisitos (Requirements Management) Gerir requisitos Obter um entendimento de requisitos Gerir mudanças nos requisitos
- 78. RDMP2 – Desenvolvimento de um Plano (Implementation of a Roadmap) Disponibilizar e manter um plano do produto Garantir que o plano mostra as funcionalidades dos 2 próximos lançamentos Atualizar o plano regularmente Atualizar o plano como planejado
- 79. RDMP2 – Desenvolvimento de um Plano (Implementation of a Roadmap) Disponibilizar e manter um plano do produto Garantir que o plano mostra as funcionalidades dos 2 próximos lançamentos Atualizar o plano regularmente Atualizar o plano como planejado
- 80. PP2 – Planejamento de Projeto Parte 2 (Project Planning Part 2) Obter comprometimento com o plano Estabelecer o plano do projeto
- 81. PP2 – Planejamento de Projeto Parte 2 (Project Planning Part 2) Obter comprometimento com o plano Estabelecer o plano do projeto
- 82. STK – Relações entre Interessados (Relationship between Stakeholders) Planejar o envolvimento das partes interessadas Categorizar mensagens na comunidade Medir os termos de muita discussão na comunidade
- 83. PMC – Monitoramento e Controle do Projeto (Project Monitoring and Control) Monitorar o projeto de acordo com o plano Implementar ações corretivas
- 84. PMC – Monitoramento e Controle do Projeto (Project Monitoring and Control) Monitorar o projeto de acordo com o plano Implementar ações corretivas
- 85. PPQA – Garantia de Qualidade no Processo e no Projeto (Process and Project Quality Assurance) Avaliar objetivamente os processos e produtos Fornecer uma visão objetiva
- 86. PPQA – Garantia de Qualidade no Processo e no Projeto (Process and Project Quality Assurance) Avaliar objetivamente os processos e produtos Fornecer uma visão objetiva
- 87. TST1 – Testes Parte 1 (Test Part 1) Preparar para verificação Selecionar os produtos para verificação Estabelecer o ambiente de verificação Realizar revisões externas Conduzir revisões externas Verificar os produtos Realizar a verificação
- 88. TST1 – Testes Parte 1 (Test Part 1) Preparar para verificação Selecionar os produtos para verificação Estabelecer o ambiente de verificação Realizar revisões externas Conduzir revisões externas Verificar os produtos Realizar a verificação
- 89. DSN1 – Projeto Parte 1 (Design Part 1) Desenvolver o projeto Montar o produto ou componentes a partir de um design alto nível
- 91. Conclusão
- 92. FLOSS == Agile
- 93. FLOSS == Agile
- 94. Problemas semelhantes ✓
- 97. Vamos criar tantas opções e dar a chance das pessoas melhorarem que alguma delas será excelente!
- 98. Vamos criar tantas opções e dar a chance das pessoas melhorarem que alguma delas será excelente! Vamos tirar todos os impedimentos, melhorar a qualidade técnica e parar assim que possível para ter sucesso!
- 99. Podem ser usados em conjunto ✓
- 101. FIM Perguntas? Críticas? Comentários? Inspiração:
Notas do Editor
- Boa tarde e obrigado por virem. Meu nome é Hugo Corbucci e estou aqui para apresentar meu trabalho de mestrado e, quem sabe, cumprir a desilusão de 2011. O tema é sobre métodos ágeis e software livre, mais especificamente, a relação entre essas duas comunidades. Para começar a falar disso, primeiro, vamos ver o que entendo por...
- Software livre. Representados essencialmente por algum projeto específico como o kernel do linux, o firefox, o openoffice e tantos outros. De acordo com a maioria dos defensores e apoiadores do software livre, o objetivo do movimento é de...
- Prover liberdade para todos, tanto desenvolvedores quanto donos quanto usuários. Essencialmente as famosas 4 liberdades que podem se resumir a...
- Estudar e modificar, isto é, ser capaz de ler, aprender, alterar e ver os efeitos das alterações em...
- Projetos e seus funcionamentos. Notem que isso está muito relacionado com software pelo nome, mas a ideia já passou dessas barreiras. Qualquer projeto pode ser 'livre' no sentido de permitir estudo e modificações. Estou pensando em arduino que é uma plataforma para desenvolvimento de componentes eletrônicos cuja especificação e instruções de desenvolvimento são livres.
- Já métodos ágeis, costumam ser representados pelas métodos específicos preferidos de cada um. Dentre eles, XP, Scrum, Crystal e FDD. O objetivo dos métodos ágeis é....
- Prover melhores formas de...
- Desenvolver software. Isto é, esteja na situação que você estiver, se quiser desenvolver software, métodos ágeis se propõem a indicar formas mais adequadas para atingir o sucesso...
- Desde que você esteja em equipe. Isso não quer dizer 1000 pessoas. Apenas mais do que uma. O motivo para pensar nisso é que o resultado de um software desenvolvido por uma única pessoa depende muito mais da sua própria capacidade, abilidade e ferramentas do que da sua metodologia. Além disso, métodos ágeis foram pensados para um ambiente...
- Industrial. Isto não quer dizer que não funciona fora da indústria. Apenas que trata de alguns assuntos e resolve alguns problemas que fazem sentido na indústria mas nem tanto em outros lugares. Notem que métodos ágeis são muito mais restritos do que a ideia de software livre. Notem também que o que representa software livre são projetos específicos enquanto métodos ágeis são representados por 'livros'. Enfim, o ponto é que métodos ágeis já conseguiram conquistar...
- O mundo acadêmico. Apesar de ser recente, já existem muitos estudos por aí sobre seus efeitos benefícos (ou questionáveis). A pergunta que eu queria levantar é:
- Será que métodos ágeis conseguem conquistar o software livre? Será que o software livre pode se aliar aos métodos ágeis? Bom, existem algumas coisas em comum que podem levar a essas perguntas. Ambos movimentos são, nos seus respectivos meios...
- Considerados pequenas revoluções que foram capazes de mudar, ainda que só um pouco (ou muito), o mundo de TI. Ambos os movimentos também tiveram motivações semelhantes como...
- A baixa qualidade dos projetos de software na década de 90...
- O péssimo ambiente de trabalho em que os profissionais de TI estavam naquela época. Muitas responsabilidades, pouco poder de decisão e uma taxa altíssima de fracasso. As soluções sugeridas pelos dois movimentos dão uma importância muito grande para...
- As pessoas envolvidas em todos os processos. Um esforço grande para acabar com a moda de chamar e tratar as pessoas como 'recursos' e dar o devido valor ao trabalho de cada indivíduo. Pensando muito em deixar as pessoas assumirem responsabilidade pelo que fazem e ganhar os créditos devidos pelas suas atividades. Com essas semelhança, vem uma dúvida...
- Será que o que realmente existe são duas origens separadas? Duas árvores, uma na qual os frutos são projetos livres e outra na qual os frutos são metodologias ágeis? Ou...
- Será que, na verdade, é um raiz comum, um tronco comum que dá ambos tipos de frutos? Ora um software livre, ora um método ágil? Será que existe um denominador comum para os dois movimentos? Bom, para tentar responder essa pergunta...
- Vamos tentar olhar para o que há de comum a...
- Todos os projetos livres. Entre todas essas iniciativas, para todos as plataformas, de todas as idades, o que norteia seus rumos? Existe algum resumo que explique o que cada projeto procura?
- Não realmente. Existem pontos de relação. As tais 4 liberdades... mas nem todos os projetos livres são radicais com todas as liberdades no mesmo grau. Existe a ideia colaborativa... mas a maioria dos projetos e começa e continua sendo projetos de 1 pessoa só ou que não conseguem atrair colaboradores. Como o ambiente é tão grande e tão variado, é difícil concluir qualquer coisa sobre todos os projetos...
- E para os métodos ágeis?
- Existe algo que norteie seus rumos? Existe alguma coisa comum a todos eles que nos permita achar um denominador comum?
- Com uma certa 'tolerância' existe o manifesto ágil. Apesar desse manifesto ter sido escrito alguns anos depois dos primeiros métodos ágeis, ele resume o que as pessoas envolvidas nesse movimento buscam...
- Esse curto texto mais uma lista de doze princípios resume o que o movimento tenta representar. São 4 valores principais enunciados e assinados originalmente por essas 17 pessoas e, em seguida, reassinados por milhares de outras pessoas. Com esses 4 valores, resume-se o objetivo dos métodos ágeis em geral. Vamos, então, procurar avaliar como reage a comunidade de software livre com relação a esses valores. Para começar...
- Indivíduos e interações sobre processos e ferramentas. Como eu disse antes, esse é um dos aspectos mais claros em que as comunidades concordam. Projetos livres existem, essencialmente, assim que um pessoa resolver contribuir para o mundo um trabalho que acha interessante. As interações do mundo com esse projetos são o que fazem o projeto crescer, viver e atingir o sucesso. São raros os casos em que os projetos crescem com um processo estabelecido desde o início. Também é frequente encontrar projetos em que as ferramentas mudam, muitas vezes, rápido até demais! De toda forma, a base da colaboração voluntária é dar importância aos indivíduos envolvidos e a forma com que interagem entre eles.
- Software em funcionamento sobre documentação abrangente. Esse é outro que é bem fácil de argumentar. Uma das principais reclamações (as vezes infundada) das empresas e dos usuários é que projetos livres não tem documentação ou ela é escassa. O ponto é que o projeto só ganha usuários se ele puder ser usado, testado e fornecer algum valor para seus usuários. Não conheço nenhum projeto de software livre em que a documentação é escrita antes das funcionalidades estarem em uso. Os projetos costumam, primeiro, desenvolver versões instáveis, betas, alfas para, em seguida, descrever os funcionamentos.
- Colaboração com o cliente sobre negociação de contrato. Esse ponto é um pouco mais complicado. Essencialmente porque a maioria dos projetos livres não tem um contrato envolvido. Isso não é uma verdade absoluta. Existem projetos com clientes e contratos mas a grande maioria deles não tem, sequer, a ideia de cliente no sentido de uma pessoa externa que sabe o que precisa ser feito. Raymond diz que projetos livres de sucesso “Scratch a developer's itch”, isto é, são soluções para os incômodos pessoais dos desenvolvedores. Nesse caso, os próprios desenvolvedores são os clientes e não faz muito sentido pensar nesse valor ágil nesse contexto.
- Por fim, responder a mudanças sobre seguir um plano. Esse é um dos princípios que não podemos realmente afirmar com relação a cada projeto. A abordagem livre nesse aspecto, é a da evolução darwiana, ou seja, aqueles que não evoluirem, que não se adaptarem, são abandonados, perdem terreno, morrem. Mas isso só acontece porque existem outros, mais adaptados, capazes de tomar o lugar. Sendo assim, software livre não abraça a ideia de que cada projeto responde a mudanças. Mas que, algum projeto, responderá a mudança (ou será criado por conta da mudança) e tomará as rédeas. O exemplo clássico disso, é a fundação Mozilla com o Firefox e Thunderbird nascidos da antiga glória perdida do Netscape e Netscape Mail. Portanto, de 4 valores, 3 “aceitos” e 1 ambíguo. Será...
- Que ambas comunidades encontram os mesmos problemas? Tendo esses valores comuns? Além disso, se forem problemas semelhantes, será...
- Que eles acham as mesmas soluções? Que as abordagens para lidar com incertezas são as mesmas? Para descobrir mais a respeito, elaboramos...
- Dois questionários. Um dirigido para a comunidade de software livre e outro para a comunidade de métodos ágeis. Nesses questionários...
- Procuramos identificar o público participante. Saber de onde eram, qual sua idade, quantos projetos já participaram e qual ano em que tiveram sua primeira participação. Dessa forma, poderíamos traçar o perfil geral do público e descobrir se atingimos o perfil desejado. Em seguida...
- Os questionários contavam com algumas perguntas para avaliar os conhecimentos do participante em suas comunidades. Isso permitiria que traçássemos alguma relação entre a experiência os tipos de problemas encontrados ou soluções sugeridas caso ouvesse algum viés nesse sentido. Por fim...
- Os questionários apontavam alguns possíveis problemas para os participantes selecionarem se consideravam estes problemas importantes. Os questionários também ofereciam algumas ferramentas e pedia para os participantes ordenarem elas da mais útil para a menos útil. O objetivo dessa ordenação era ver se algumas ferramentas de uma comunidade poderiam ajudar a outra e vice-versa. Com o questionário montado, partimos para...
- A divulgação. Tentando separar os públicos, divulgamos os questonários em época diferentes. Primeiro veio o questionário para a comunidade de software livre, com divulgações em blogs, twitter, listas de email da comunidade e boca-a-boca. Após algumas semanas, divulgamos o questionário para a comunidade ágil via twitter e listas de email.
- Foram 2 meses coletando resultados em ambas pesquisas e chegamos a...
- 302 respostas de contribuidores de software livre sendo que 40% deles não contribuiam ativamente mas se consideram da comunidade e 162 respostas de agilistas sendo que apenas 15% não tinham experiência real em projetos ágeis. Além disso, a divulgação na comunidade de software livre foi mais eficiente e conseguiu sair da comunidade sul-americana alcançando algumas proporções semelhantes às de outras pesquisas internacionais como FLOSS World. Na comunidade ágil, o impacto foi bem mais localizado. Provavelmente pela falta de apoio das entidades internacionais e empresas que foram contactadas. Sendo assim, pode-se dizer que as respostas da comunidade ágil são mais representativas da comunidade sul-americana.
- Com relação à experiência dos participantes de cada comunidade, percebe-se que o software livre é mais antigo e tradicional que os métodos ágeis. A adoção começou no início da década de 90 enquanto métodos ágeis só começa a dar sinais de vida no final da década. No entanto, a adoção de métodos ágeis foi mais rápida.
- Com relação aos tamanhos das equipes, há um forte viés para equipes pequenas (10 pessoas ou menos) com 60% das equipes de software livre nesse tamanho e 80% das equipes ágeis nesse intervalo sendo quase 50% entre 6 e 10 pessoas enquanto quase 50% das equipes livres tem entre 2 e 5 pessoas.
- Percebemos também que as equipes em software livre dividem papéis mais detalhados enquanto equipes ágeis identificam-se mais uniformemente. Isso é provavelmente consequência do incentivo dos principais métodos ágeis para ter membros multi-disciplinares.
- Por fim, com relação às ferramentas que foram consideradas mais interessantes, os resultados foram BEM parecidos. As cores e as ordens são as mesmas nos dois gráficos e mostram que as 3 primeiras ferramentas (não eram as 3 primeiras no questionário) são aquelas consideradas mais úteis. Sendo: Mensagens em caso de problema no build, estado dinâmico da versão atual a partir do andamento na ferramenta de planejamento e gerenciamento da ferramenta de planejamento pelo log das mensagens de commit . Com esses dados, confirma-se o seguinte cenário:
- Contextos diferentes entre as comunidades...
- Problemas semelhantes...
- E ferramentas semelhantes para resolver esses problemas.
- Mas, cuidado, com a pequena amostra de dados coletados, os dados não são extremamente conclusivos já que boa parte da comunidade ágil internacional não foi ouvida e os próprios questionários não tiveram o rigor que poderiam ter tido com relação às opções apresentadas e isolamento de outros fatores. De toda forma, esses resultados sugerem que...
- Essas comunidades compartilham alguns princípios comuns e formas de lidar com problemas mesmo se ainda cada comunidade tem princípios diferentes. Sendo assim, será...
- Que não podemos pegar as ideias e as soluções encontradas em cada contexto e...
- Aplicá-las no outro contexto? Será que essas aplicações seriam benéficas? Antes disso, que ideias podem migrar de contexto? Pensando do lado do software livre, uma ideia é a do...
- Papel do committer. Um committer é uma pessoa com direitos de escrita no ramo principal do repositório de controle de versões do projeto. Essencialmente, um committer é uma das pessoas que decide se determinado trecho de código deve ou não entrar na próxima versão do projeto. De acordo com Dirk Riehle, esse é um posto de 'glamuroso' do software livre. Ele é o terceiro nível de uma escada simples: usuário, colaborador e committer. O grande destaque do committer é que ele é uma promoção pública que enaltece a pessoa perante à comunidade existente pois a deixa num posto de confiança, de saber o que é bom pro projeto e como evitar alguns problemas. Em métodos ágeis, cumpriria um papel de revisor externo que, aliás, chama outra sugestão...
- De revisões cruzadas. Nessa ideia, quando determinada mudança é concluída, ela é entregue para alguém de fora da equipe, se possível um usuário da mudança, que pode realizar uma revisão técnica (e não-técnica) do que foi feito. Este olhar externo permite um tipo de revisão que não se atinge com programação em par, uma revisão de olhar não viciado. Um olhar mais semelhante ao de um usuário ou de um futuro desenvolvedor. Esse tipo de revisão permite verificar se o trabalho que foi feito atingiu realmente o objetivo desejado e é fácil de usar. Aliás, no mundo de software livre, essas revisões assim como código...
- Não são motivos de segredos e medos de revelações. Esses resultados e todos os outros são...
- Públicos. Isso não é bom apenas no ponto de vista do stress envolvido. Isso também permite que mais gente consiga ver, estudar, analisar e corrigir os trabalhos existentes. Dessa forma, não há apenas uma revisão técnica (pelo committer) e de usuário (de forma cruzada) mas revisões constantes e gerais. Note, aliás, que as três ideias estão relacionadas com revisões. Esse é um dos princípios mais fortes do software livre. Eric Raymond cita uma frase de Linus Torvalds para descrever esse princípio: “Given enough eyeballs, all bugs are shallow”. Isto é, com revisões suficiente, todos os problemas são encontrados e a solução evidente para alguém. Agora se pensarmos do lado de métodos ágeis...
- Retrospectiva é uma prática que poderia ajudar as equipes livres a se estruturarem melhor. A ideia de, regularmente, reunir-se para refletir sobre o ocorrido e como melhorar a situação atual poderia permitir uma maior regularidade nas melhoras dos projetos. Ajudaria as equipes a responder melhor às mudanças que sugirem. Por outro lado, a simples ideia de reuniões presenciais é sempre um problema no contexto de software livre. Isso porque, com equipes distribuídas, é sempre difícil acertar horários e reunir (mesmo que virtualmente a equipe). Por isso, seriam necessárias algumas adaptações e, provavelmente, ferramentas online para permitir a adoção. Situação que se repete para...
- Programação em pares. Essa prática, cujos benefícios já foram estudados pela Laurie Williams, requer duas pessoas trabalhando juntas para desenvolver um único código. Dentre os benefícios estão a melhor qualidade do código e maior velocidade para chegar na solução além de um efeito de manter o ânimo no projeto. Projetos livres poderiam usar essa ideia para atrair mais desenvolvedores e manter os desenvolvedores atuais mais interessados além de garantir uma certa periodicidade das atividades já que toda sessão precisa ser pré-programada com seu par. Novamente, essa prática precisaria de adaptações como na imagem de baixo onde uma pessoa aproveita de imagem e som além de compartilhamento de tela para permitir simular de forma virtual o pareamento.
- Por fim, testes automatizados. Apesar da adoção dessa prática em projetos livres ter crescido MUITO nos últimos anos, ainda são muitos projetos mais antigos com pouquíssimos (se algum) testes automatizados e mesmo quando tem, a qualidade desses testes é bem limitada. Uma abordagem de testes a priori e BDD/TDD poderiam ajudar a melhorar a quantidade de testes e a cobertura. A partir desse volume de testes, os projetos poderiam então passar a melhorar a qualidade de seus testes. Como outras práticas ágeis que poderiam agregar em software livre, também poderíamos citar as reuniões diárias e o uso de histórias mas o tempo já está curto. O ponto de aproveitar essas práticas e usar essas ideias é melhorar a qualidade dos projetos existentes e, dessa forma, a confiabilidade deles. O que nos leva ao...
- Projeto QualiPSo. O projeto QualiPSo é um projeto Chino-Brasilo-Europeu cujo objetivo é justamente esse: melhorar a confiabilidade dos projetos de software livre para aumentar sua adoção na indústria. O QualiPSo é dividido em 12 grandes áreas de pesquisa que incluem centros de competência em software livre, aspectos legais, resultados confiáveis e processos confiáveis. Nessa última área, de processos confiáveis, um dos trabalhos era elaborar uma forma de avaliar a qualidade de processos de desenvolvimento de software livre. Para isso, foi criado o OMM do QualiPSo, o Modelo de Maturidade Open Source. O OMM...
- Foi elaborado de forma semelhante ao modelo do Software Engineering Instutite da Carnegie Mellow, o famoso CMMi. Para montar o modelo, foram levantados os elementos que levam empresas a confiarem em um projeto livre, os chamados Trustworthy Elements. Cada um desses elementos foi separado em três níveis “aditivos”. Isto é, um nível superior inclui todos os elementos dos níveis inferiores. A ideia é...
- Tendo em mãos as práticas alteradas vindas do software livre e as práticas originais de XP, tentarmos satisfazer o nível básico e o nível intermediário do OMM. Para cada um dos elementos, o QualiPSo aponta algumas práticas recomendadas e outras obrigatórias para atingir o objetivo desejado. É com base nessas práticas que vamos estudar o uso de XP nesse contexto. Vou passar um pouco rápido nessa parte porque não vai dar tempo de fazer toda a argumentação.
- Na questão da documentação do produto, o projeto QualiPSo enuncia alguns objetivos e práticas associadas. Essencialmente, criar documentações, atualizar essas documentações e melhorá-las.
- Essencialmente, argumento que TDD e suas variações BDD e ATDD são responsáveis pela maioria desses aspectos em XP. A ideia é não gerar apenas uma documentação, mas uma documentação executável que deixe claro quando está desatualizada. Aliada com refatoração, essa documentação é melhorada do ponto de vista técnico mas, também, do ponto de vista do usuário. Isso graças a ferramentas existentes atualmente que permitem, a partir de testes, gerar relatórios de funcionamento descrevendo passo a passo o uso de determinada funcionalidade. O único aspecto não tratado é o da tradução. Apesar disso, é simples considerar que, no processo, para que uma funcionalidade esteja completa, sua documentação precisa estar traduzida.
- Com relação ao elemento de uso de padrões estabelecidos e adotados. O OMM se preocupa em garantir que os projetos não fiquem presos a soluções proprietárias que podem ser retiradas por terceiros tanto para ferramentas quanto processos. Com relação ao processo, é bem simples. XP é um processo livre no sentido que está descrito com um conjunto simples de práticas que pode ser avaliado. Já pra parte de ferramentas e soluções...
- XP vai garantir o uso, a difusão e a documentação dos padrões vai ser dar graças às práticas de código compartilhado, design simples e programação em pares (a versão modificada para ser usada em equipes distribuídas). A ideia é que o compartilhamento de código vai garantir que todos tenham a oportunidade de aprender e, se necessário, documentar o uso dos padrões pelo projeto (tanto pro próprio projeto quanto para seus resultados). O design simples vai evitar que projetos re-inventem a roda já que deveria procurar soluções existentes para simplificar o design. Por fim, a programação em pares serve de 'revisão' para diminuir as chances de não se implementar um padrão por falta de conhecimento.
- Com relação à qualidade do plano de testes, o OMM procura garantir que são vários tipos de testes, que eles são executados frequentemente e que seus resultados e recursos estão disponíveis. Por fim, que o processo de testes melhore com sugestões vindas de terceiros ou internamente. Em XP...
- Isso se dá com as práticas de código e teste, tdd e integração contínua. A prática de código e teste vai exigir que, para todo código que for incluído, aja um teste associado que verifica que ele faz o que deveria. A prática de TDD e suas variações BDD e ATDD vão ajudar a criar testes em vários níveis (de unidade, de integração e de aceitação). Já os testes não funcionais ficam por conta de código e testes quando aliadas a alguma história de requisito não funcional.
- Com relação ao ambiente técnico, o OMM se preocupa bastante em ter certeza que o ambiente é replicável e satisfatório para todos além de usar o número máximo de soluções livres possíveis. Em XP...
- A prática de integração contínua deveria fazer com que o ambiente seja fácil de replicar a partir de qualquer máquina já que tudo deveria estar no controle de versões e ter script para customização local. O repositório único de código e o código compartilhado devem garantir que os desenvolvedores estejam confortáveis para realizar as mudanças necessárias e, se estiverem insatisfeitos, alterar o ambiente (desde que o sistema de integração contínua continue funcionando).
- Para a parte de defeitos, o OMM se preocupa bastante em receber os relatórios e resolver os problemas. Alguns desses elementos (como medir nível de satisfação dos usuários e dar mais privilégios aos que mais relatam) estão fora do controle do processo de desenvolvimento mas não apresentam nenhum conflito com o próprio. Para o resto, XP...
- Faz uso ds práticas de TDD e repositório único de código para garantir que soluções para erros estejam sob controle de versões e que os erros não re-apareçam. Já a prática de histórias vai permitir priorizar esses relatórios com relação ao resto do projeto para melhorar o tempo de resposta.
- Passamos da metade! Sobre manutenção e estabilidade, o OMM se preocupa muito em manter um tracking da qualidade do projeto e a garantia de manutenção das funcionalidades. XP resolve isso...
- Com a interação de quase todas as técnicas. Essencialmente, esse é o objetivo principal de XP, fazer com que seja fácil manter o projeto sem introduzir problemas. TDD, código e testes vão apontar mudanças entre modificações no projeto. Programação em pares e código compartilhado vão evitar que o conhecimento fique preso em uma única pessoa. Repositório único de código e refatorações vão permitir manter um histórico e diminuir a dívida técnica do projeto. Por fim, análise de causa raíz vai identificar algum impedimento no objetivo do projeto.
- Para Gestão de Configuração, a preocupação é que as configurações necessárias para rodar corretamente o software estejam disponíveis e sejam atualizadas com as devidas versões correspondentes atribuídas.
- Novamente, a ideia da Integração contínua exige que todas essas configurações estejam descritas em scripts ou arquivos de configuração que estão sob controle de versão.
- Quase por fim, planejamento do projeto, para o OMM, em comunidades, é apenas estimar o escopo do projeto. Esse trabalho, em XP,
- É cumprido e revisado pelos ciclos semanais e de estação aliados com o jogo do planejamento.
- Por fim, a gestão de requisitos envolve, essencialmente, entender o que precisa ser feito e estar pronto para possíveis mudanças nesses requisitos. Novamente, o objetivo de XP é esse e é atingido
- Pelo ciclo de estações, jogo do planejamento e pelas histórias. Histórias representando requisitos, o ciclo de estações para mudanças de alto nível e análise de causa raíz para identificar os motivos da mudança. A integração contínua participa garantindo que o que já foi definido anteriormente continua funcionando. UFA! Com isso passamos por todo o nível básico do OMM com excessão do elemento de Licenças. Não falei dele porque ele é completamente ortogonal a XP. Em muitos casos não pode sequer ser realizado pelos desenvolvedores sem a devida consultoria jurídica.
- Em suma, XP aborda bem o nível básico do OMM com uso simples da programação em pares adaptada e da retrospectiva a distância. O nível intermediário, por sua vez, é bem mais complicado mas faz uso de algumas outras práticas e, mesmo assim, não cobre tudo. Nesse nível, a ideia de revisão cruzada e committers contribui para a questão Testes.
- Enfim, dito tudo isso. Vamos repassar de forma rápida por tudo que vimos:
- Apesar de terem algumas coisas em comum, software livre e métodos ágeis...
- NÃO são iguais. Sim...
- Eles enfrentam problemas semelhantes mas...
- Se aplicam em contextos diferentes. Não quer dizer que não dá pra aproveitar partes de cada um. Na verdade...
- Algumas ideias só fazem sentido no contexto original, outras podem ser aproveitadas, com ou sem adaptações no outro contexto. As abordagens de ambas comunidades são bem diferentes. Software livre pensa mais...
- Enquanto métodos ágeis tem uma abordagem mais local no estilo...
- O objetivo de um é vencer pela qualidade por eliminação na quantidade. O objetivo do outro é vencer pela qualidade individual. Sendo assim, faz sentido sim...
- Unir as ideias e aproveitar os contextos. Na verdade, mais do que sentido...
- Essa união pode mostrar processos e soluções de qualidade como o QualiPSo espera encontrar. E, era essencialmente isso...
- Que eu tinha para dizer.