Artesanato de Software na Prática
•Transferir como PPTX, PDF•
1 gostou•278 visualizações
Principios de Artesanato de Software
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Artesanato de Software na Prática
Semelhante a Artesanato de Software na Prática (20)
Mais de Percival Lucena
Mais de Percival Lucena (12)
Artesanato de Software na Prática
- 1. Artesanato de Software na Prática Percival Lucena
- 2. Todo Mundo Faz Scrum
- 4. "O cliente está com pressa. Então entrega qualquer coisa, e logo!!!" Agora! Por que nos individamos tecnicamente?
- 5. Manifesto do Artesanato de Software software funcionando responder as mudanças indivíduos e interações colaboração com o cliente software de qualidade agregar valor constantemente comunidade de profissionais parcerias produtivas
- 6. Não apenas software funcionando, mas software de excelente qualidade ● TDD ● Programação em pares ● Revisão de Código
- 7. Não apenas software funcionando, mas software de excelente qualidade
- 8. Não apenas software funcionando, mas software de excelente qualidade Revisão de Código: ● Fácil de ler ● Fácil de mudar ● Fácil de evoluir
- 9. Não apenas software funcionando, mas software de excelente qualidade "Entregue o código sempre melhor do que encontrou"
- 10. Avi Alkalay Não apenas responder a mudanças, mas agregar valor constantemente
- 11. Avi Alkalay Não apenas responder a mudanças, mas agregar valor constantemente
- 12. Não apenas indivíduos e suas interações, mas uma comunidade de profissionais
- 13. Não apenas indivíduos e suas interações, mas uma comunidade de profissionais
- 14. Não apenas a colaboração do cliente, mas parcerias produtivas
- 15. E o processo como fica?
- 16. Conclusões
Notas do Editor
- Artesanato de Software na prática Buenas - Eu me chamo Percival Lucena Sou professor universitário e trabalho com desenvolvimento de software ha mais de 15 anos. Nesta tarde eu gostaria de conversar um pouco com vcs esta tarde sobre Artesanato de Software
- Hoje em dia, todo mundo faz Scrum. Até aquele projetinho maroto que é Waterfall acha que faz Scrum. Empresas pequenas, médias e grandes usam Scrum como processo de desenvolvimento de software. Quem aqui trabalha em uma empresa que usa Scrum? Levanta a mão. Joia. E quem usa outra metodologia? Kanban? Levanta a mao. (Go Horse não conta…) Mas usar Scrum não é bala de prata. Não garante que o projeto seja entregue em dia… Nem garante que o projeto seja entregue com qualidade… Quem aqui realmente se orgulha do trabalho que faz?
- Quando começamos um novo projeto quase não temos bugs. Isto por que tambem Não temos código. Os requisitos são novos. O time deslancha que é uma beleza! Mas com o passar do tempo vemos que a velocidade do time começa a cair em vez de subir? E ai a pressão aumenta! Por que o time não esta redendo! O PM, o SM não entende e resolve colocar mais gente no time, e a velocidade continua caindo. Um avião em queda livre. Porque na pressa de entregar, o time deixa a qualidade de lado e começa a entrar no cheque especial do Debito Tecnico. Começa assim: Vc faz uma caquinha. Depois o seu colega faz outra caquinha para corrigir a primeira caquinha. E quando vc vê: Holy Shit! O software é uma colcha de remendos cheia de bugs! É o que o Martin Flower em um artigo de 2009, chamada Flaccid Scrum. Um Scrum sem qualidade: sem codigo limpo, sem refactoring sem testes automatizados.
- A primeira coisa que pensamos quando se fala em débito tempo é que tivemos que agir assim porque não tinhamos tempo para implementar testes, ou fazer refactoring, ou melhorar a arquitetura. É fácil acreditar que nunca temos tempo. O cliente, o SM, o PM, todos defenderão um cronograma agressivo com entregas impossíveis. Mas este pode ser o papel deles não o nosso. Muitas vezes a equipe acredita, cai na historia de que o melhor que o time pode fazer é entregar o maior numero de features, o mais rápido possível Não podemos escrever software ruim, so porque temos pressa de entregar! Robert Martin (Tio Bob), um dos autores do Manifesto Ágil - keynote no Agile 2008 causou barulho. Ele colocou o dedo nesta ferida Para ele o problema era taao grave que valia a pena mudar o manifesto agil e adicionar um novo item - Artesanto ao invés de software ruim. Mas, O que sera que o tio Bob quis dizer com isto?
- Depois da palestra do Robert Martin em 2008, em Dezembro do mesmo ano, em Chicago (LibertyVille) ocorreu a primeira conferencia sobre Artesanato de Software. Os participantes desta conferência criaram um google group e durante a discussão Doug Bradbury, Scott Pfister juntaram varias das opinioes dos participantes e criaram o Maifesto do Artesanato de Software Mas por que o mundo precisa de mais um Manifesto? Vamos entnder o Contexto: Metodologias como Lean e XP (na moda) focavam mais em processos do que as práticas técnicas. Alguem precisava voltar a defender as práticas técnicas (como as praticas do Extreme Programming) para garantir a qualidade de software! Mas o artesanato não é apenas um XP-Light. Vamos analisar os valores do Manifesto do Artesanato de Software: A primerira vista o Manifesto de Artesanato é so uma manifeto Agile ++. Mas nao é assim. Vamos analisar cada um destes pontos individualmete
- Nao apenas software funcionando, mas software de excelente qualidade Pense numa aplicação de 5 anos, sem testes. O time que fez o app ja nao existe mais e Ninguem entende como a app funciona. O app é cheio de classes com centenas e as vezes milhares de linhas. Pense que seu time vai ter que dar manutenção nesta app. Sim Ela funciona, mas é o suficiente? Quando eu falo em Artesanato, muitas vezes a pessoa pensa que isto significa fazer as tarefas manualmente. Tipo fazer um colar de miçangas. Não não é isto que queremos dizer. Artesanato é usar as melhores praticas tecnicas. E muitas vezes as melhores praticas tecnicas, consistem em utilizar automacao. Algumas praticas que podem ser utilizadas em um time que busca melhor qualidade Automação de Testes - TDD. Escreve primeiro o teste depois o codigo Automação de Deploys com CI Programação em pares Revisão de código.
- Quanto custa ter um carro? Alguem aqui ja comprou um carro de um fabricante Xing Ling.? Aquele que para na oficina toda semana? E que não tem peça de manutenção? É um bom negocio? Um carro é bem mais do que o valor pago na promoção é uma serie de outros fatores que contribuem para o custo de propriedade: Impostos+Seguro+Estacionamento+Combustivel+Seguro+Manutenção+Depreciação Vc na hora de comprar faz estas contas ou compra o mais barato? Sera que o mesmo ocorre com Software? Vale a pena fazer software Xing Ling? Software custa caro. Escritório, equipamentos, salário do time. Os clientes que contratam software esperam fazer dinheiro, poupar dinheiro, ou proteger seus lucros. Adicionar valor ao software não é apenas adicionar novos features e corrigir bugs. Garantir a manutenibilidade é fundamental para diminuir o custo de manutenção do software. Devemos manter o código limpo, uma arquitetura extensível, testes automatizados e de fácil manutenção. A Qualidade Diminuiu o Custo Total do Software e maximiza os resultados financeiros obtidos
- Revisão de código - Meu projeto todo commit do git antes de passar do featire branch para a develop ou release branch passa pela revisão de pelo menos 2 outros membros do time. Ferramentas para isto O que procurar no code review. Bugs.? Bugs deveriam ser detectados pelos testes automatizados. Code review deveria avaliar a qualidade do codigo. Sei que nem sempre é viavel aplicar. Mas um bom comeco seria Aplicar principio do codigo limpo Facil Leitura e Facil Manutenção Principios basicos de design: Coesao, Acoplamento Padroes de codificacao
- Software de Excelente qualidade requer Codigo de Excelente Qualidade. Isto não quer dizer que é necessário ter uma arquitetura complexa, nem mesmo uma Arquiteto. A idéia da Arquitetuta evolutiva e Refactoring - Ajuste dos códigos existentes é uma prática importante Código Limpo: Nada de Repetições. Alta Coesão, Baixo Acoplamento - Principios de Design são importantes. Patterns Factories, proxies, DRY, OCP (open closed), DIP (dependency inversion), Dependency Injection -> agile software development principles patterns and practices Principio da Responsabilidade Unica Lei de Demeter,
- 2o Principio - Nao apenas responder a mudancas, mas agregar valor constantemente. Uma forma de entregar valor constantemente é não diminuir a velocidade. Outra forma é entregar o software para o cliente tão logo possível. Neste aspecto Devops e Continuous Integration são muito úteis. Essa figura é do Alvi Alkalay da IBM e eu coloquei ela aqui pra tentar ilustar o impacto que o Devops tem em entregar valor para o cliente Cascata trabalhava com fases monoliticas: Requisitos, Desenvolvimento, Teste, Implantação Agile: Focava em Desenvolvimento, testes e requisitos com ciclos curtos realmente melhora o feedback, e permite que o software seja desenvolvido na direção que o cliente quer. Mas Devops traz um ponto a mais que é a entrega constante de valor: É claro que para isto precisamos de um Pipeline 100% automatizado para deploy de apps.
- Quando eu falei sobre Devops no Caipira eu trabalhava numa empresa com um time que estava engatinhado no assunto. Hoje trabalho em outra empresa em que o fluxo é 100% automatizado. É muito bom poder deployar novo software de maneira automatica e sem medo. Não somente a compilação mas os testes e até a evolução do banco de dados é automatizada. A cada commit, executamos testes, analisamos qualidade do codigo (Sonar) e deployamos em um ambiente igual a produção. Podemos lançar novos releases em produção sem dor de cabeça uma ou mais vezes por dia se assim for preciso! É claro que ainda temos alguns problemas como a nossa cobertura de testes, mas trabalhamos a cada dia para melhorar nosso processo. Nosso Pipeline permite fazer deploy em produção sem janelas de instalação, sem tirar a produção do ar por um unico momento (Até agora). Pra quem tinha que negociar janelas de instalação e dependia do time de operações para instalar as apps este é um novo mundo maravilhoso.
- Aprendizado é um processo contínuo. Algumas empresas de software investem na capacitação dos funcionários oferecendo cursos, livros. Isto é legal, mas cabe ao profissional o dever de continuar aprendendo sempre. Fazer code reviews Participar de Dojos Escrever blogs Contribuir com projetos OSS Participar de encontros como este
- Comportamento profissional não é seguir as regras. Comportamento profissional é saber dizer não˜ Se um paciente pedisse para um médico não lavar as mãos e ir direto para cirurgia, o médico obedeceria? Claro que não. Muitas vezes a gente coloca a culpa no gerente, no cliente porque temos que fazer alguma grande bagunça para salvar o projeto. Mas se eu disser não eu vou ser mandado embora. Pode ser que vc trabalhe numa empresa que realmente seja assim. Mas se este for o caso este nao é o emprego que se vale a pena ter. Dizer nao é algo complicado. Vc nao precisa sair gritando (Eu fiz isto algumas vezes e me arrependo por isto) A formas e formas de discordar. DIscussões não publicas. Chega pega aquela pessoa de lado e conversa em particular.
- Puxa-Saco em Inglês é Yes-Man. Eu ja trabalhei em alguns projetos "Ágeis" na qual o SM ao invés de proteger o time, ou ajudar o cliente simplesmente dizia Sim para algum funcionário da empresa do cliente que contratou o projeto. Artesãos de software não são trabalhadores de Fábrica. Artesões de software entendem o négocio do cliente, questionam os requisitos, propõe melhorias e são parceiros do cliente. Um time de artesãos é composto por pessoas talentosas apaixonadas pelo que fazem e que atuam como parceiros de seus clientes. Um time de artesões não recebe uma lista de requisitos e sai correndo para codar o que o cliente quer. Um bom time ajuda o cliente ao questionar seus processsos, melhorar processos, mostrar outras opções. Questionar o valor de cada requisito! Ajudar o cliente a priorizar os requisitos. Assumir riscos juntos. Trabalhar juntos. Idealmente com o cliente em contato direto com a equipe. Uma coisa legal de alguns projetos da CI&T fora o fato do cliente constantemente nos visitar e falar com a gente é a TelePresença.
- É possível fazer Scrum, Kanban, sem ter um Scrum Master ou Gerente de Projetos. Ou sem um arquiteto? E sem testers? É possivel ter times multi-disciplinares auto-gerenciaveis? Precisamos olhar além do Scrum. Varios autores do manifesto ágil como Dave Thomas e Robert Martin (palestra na Noruega) já se pronunciaram contra a PMbokização do Scrum, onde o SM virou uma espécie de Gerente de Projetos. A idéia inicial do Scrum é que o SM fosse apenas responsável por defender o processo do Scrum. O papel seria transitório e passaria 1 semana ou sprint com cada membro do time até que todos conhecessem o Scrum e não precisassem mais de SMs. Um time multi-diciplinar, auto-gerenciavel não tem SMs, nem Arquitetos, nem Testers, nem DBAs, apenas um time de Desenvolvedores responsáveis por implementar e coordenar o projeto. E a liderança? Bom em termos legais ainda é necessário ter algum tipo de Gerente que seja responsável legal pelos contratos, pela equipe, mas não pela execução e planejamento dos projetos.
- Desenvolvimento de software não é somente um emprego É um oficio Pessoas apaixonadas pelo que fazem geram trabalhos de alta qualidade e valor agregado. Alguns projetos não valem a pena economicamente pois nao agregam valor suficiente ao cliente… … Agregar valr...