Desenvolvimento de software

Tamanho: px
Começar a partir da página:

Download "Desenvolvimento de software"

Transcrição

1

2

3

4 Desenvolvimento de software sempre foi uma atividade bastante dolorida. Já nos anos 70 se falou na primeira crise do software, onde pela primeira vez as dificuldades e armadilhas de se desenvolver sistemas complexos foram discutidas francamente. As causas dessa crise eram projetos estourando prazos e orçamentos, projetos que não atingiam os objetivos de negócio, com baixa qualidade, e que os tornava praticamente insustentáveis de se manter no médio / longo prazo. Nascia nesta época a engenharia de software, o modelo Waterfall, futuramente processos de desenvolvimento e gestão, o RUP então o SCRUM, agora o KANBAN. Por um lado, uma tentativa incessante de se melhorar as práticas de engenharia de software olhando por dentro a arquitetura, o código, a gerência de configuração, a integração contínua, as automações de build, teste e deploy, por outro, como conduzir, motivar e reter talentos. Tentamos fazer de tudo! Nos reinventamos a todo o momento para

5 nos livrar da tal crise do software que parece não ter nos largado até hoje. Do ponto de vista de negócio, os resultados da indústria de software são terríveis. Apenas um terço aproximadamente dos projetos de software no mundo são bem sucedidos, segundo o Standish Group, no seu estudo intitulado The Chaos Manifesto, que vem medindo ano a ano os resultados da indústria de software desde Os critérios para que os projetos sejam considerados bem sucedidos incluem serem concluídos dentro do prazo, do custo e com o escopo previsto. Imagina se somássemos a estes critérios o índice de felicidade das pessoas que trabalharam nestes projetos, da família destas pessoas e ainda dos usuários que utilizam os sistemas que desenvolvemos. Qual seria o resultado? Está na pauta de qualquer CIO hoje em dia tratar de ALM (gerenciamento do ciclo de vida da aplicação) e agilidade, sempre pensando em como mudar os resultados históricos obtidos. Uma visão recente sobre como mudar a forma tradicional de se produzir software e que vem ganhando força é o conceito de Continuous Delivery, que ganhou o mundo a partir de 2010 com a escrita do livro que leva o nome do conceito, por Jez Humble e David Farley. Falar de continuous delivery significa reduzir o tempo entre um código pronto e seu uso pleno pelos usuários reais, através de automação e melhoria dos processos de desenvolvimento e liberação de software. Técnicas como automação de testes, integração contínua e automação de build e deploy, permitem o desenvolvimento de software de alto padrão, de fácil empacotamento e distribuição. Isso habilita levar, com baixo risco e com um mínimo de intervenção humana, as melhorias e correções de bugs aos usuários, de forma rápida, confiável e repetível. Podemos falar de continuous delivery sob várias perspectivas, mais ou menos técnicas, focado na escrita de software, de ALM ou de negócios. Esta matéria aborda a discussão na perspectiva do ciclo de vida das aplicações. Ela vai contar a história de um time, os Aspiras, abreviação de Aspirantes, que partiu do zero e que foram evoluindo, melhorando suas práticas, processos e ferramentas até alcançar o estado de entregar software de valor continuamente. Uma coisa que precisa ficar claro neste tipo de leitura, que aborda a discussão sobre níveis de maturidade, é que a análise deve ser feita sempre no contexto de projetos, nunca das organizações. Normalmente, uma mesma organização possui vários projetos em diferentes níveis de maturidade. Outra coisa importante de ser dita é que nem todo projeto precisa praticar continuous delivery. Para alguns isso pode simplesmente não fazer sentido por uma série de fatores. Por isso, quando estiver lendo, tente imaginar um dos seus projeto onde pareça fazer sentido. Uma última questão a ser considerada é que os níveis descritos neste artigo não refletem nenhum padrão definido de mercado. Os níveis são baseados na observação de inúmeras organizações onde o autor do artigo teve a oportunidade de discutir sobre produção e entrega de software. O primeiro passo do time Aspiras foi escolher um conjunto de ferramentas para suportar o desenvolvimento do seu projeto. À disposição havia diversas ferramentas como Redmine, Jenkins, GIT, junit, jmeter, Selenium, Maven, Nexus, também ferramentas completas de ALM como o Team Foundation Server, que trata todo o ciclo de vida de aplicações em uma só suíte. Após escolherem a ferramenta, eles estruturaram os códigos-fonte no repositório para utilização do source control. Os desenvolvedores passaram então a trabalhar com códigos versionados, possibilitando voltá-los a um estado anterior, quando necessário. Não existia muita preocupação com metodologias e processos de desenvolvimento. O método utilizado por eles era o famoso EGH (Extreme Go Horse), onde ambos, stakeholders e times de desenvolvimento agiam de forma caótica em busca dos resultados esperados. Não havia nenhum nível de automação. Gerar o build da aplicação, por exemplo, significava dar um F5 na IDE de desenvolvimento. O processo de deployment era completamente manual. Na verdade, um evento especial, altamente orquestrado, com participação de diversas pessoas de diferentes áreas. O processo de qualidade também era completamente manual, estilo La Garantia Soy Yo. Não existiam testes unitários, funcionais, ou de qualquer outro tipo. Os testes, quando feitos, eram exploratórios. A cada nova versão, alguns testes eram feitos dependendo do tempo que se tinha. Se a versão estivesse planejada para ir para rua em três semanas, eles testavam por três semanas, se fosse há dois dias, testavam por dois dias. A Tabela 1 traz uma visão sintética dos marcos alcançada pelo time neste nível por disciplina. Depois de algum tempo, os Aspiras já estavam bem habituados em trabalhar com os repositórios de fontes. Nessa altura do campeonato, o controlador de versão já havia os salvado de algumas enrascadas. Eles perceberam o valor disso e passaram a enxergar o repositório como sua cesta de ovos e então quiseram protegê-la. Começaram então a definir políticas de check in para, através de análise estática de código, barrar códigos que não atendiam

6 aos padrões de codificação estabelecidos pelo time ou códigos mal cheirosos (code smell) que eram caros de se manter. Também obrigaram os desenvolvedores a comentar seus check-ins, e a associa-los a requisitos, garantindo rastreabilidade entre código e demandas. Nesta etapa, eles descobriram que não dava mais para trabalhar sem definir uma estratégia de branches. Algumas vezes, quando hotfixes eram solicitados para produção, as correções tinham que ser feitas no estado atual do código e publicadas imediatamente para apagar o incêndio. O problema é que, quando isso acontecia, frequentemente mais bugs iam para o ar, uma vez que após as publicações, os times continuavam escrevendo novas funcionalidades e corrigindo bugs, e códigos que ainda não estavam prontos ou estáveis acabavam indo parar em produção. Em função das dificuldades enfrentadas na condução do projeto, eles começaram a praticar o SCRUM, que normalmente é por onde a agilidade começa a emergir dentro das organizações. Descobriram por eles mesmos o significado da famosa frase do Ken Schwaber de que SCRUM é um framework fácil de entender e muito difícil de praticar. Começaram a surgir indícios de automação, começando pela parte de Build. Eles haviam se cansado do trabalho árduo e manual de empacotar uma nova versão, com todas as suas dependências, e que só dava certo quando era gerada na máquina do João, já que somente lá todas as dependências estavam corretas. Um servidor de Build foi então implantado, e um build noturno agendado, gerando os binários da aplicação, com todas suas dependências, de forma suave, diariamente às 3h da manhã. O processo de deployment da aplicação continuava longo e manual. Eles começaram a descobrir as métricas de qualidade do código, como complexidade ciclomática, coesão e acoplamento de classes, profundidade de herança, número de linhas, etc., e que a soma de tudo isso, lhes dizia sobre o índice de manutenibilidade de um código, ou seja, quão caro ou barato era manter o código. Isso, então, acabou virando uma política de check in. Um novo código não podia mais ir para o repositório se o índice de manutenibilidade dele fosse menor que sete. Eles então perceberam que o nível de cobertura do código deles por testes automatizados era de 0% e isso os incomodou. Começaram então a escrever testes automatizados para cobrir qualquer novo bloco de código escrito. Em paralelo, por aonde iam passando para corrigir bugs ou refatorar, eles também escreviam testes unitários para cobrir aquelas áreas. Isso fez com que, aos poucos, o percentual de cobertura daquele projeto começasse a subir, momento no qual eles estabeleceram a meta de ter 30% do código coberto. Essa meta foi crescendo futuramente até chegar a 50%, 70% e 80%. Eles começaram nesta etapa também a criação de planos e casos de testes funcionais que cobriam os principais cenários de negócio da aplicação, de forma que, a cada nova versão, eles sabiam exatamente o que não podia deixar de ser testado em cada um dos módulos da aplicação. Assim, pelo menos os cenários mais críticos estavam cobertos e o índice de problemas em produção foi reduzido drasticamente, já que o time passou a pegar os problemas ainda dentro de casa. Veja na Tabela 2 as principais evoluções do time neste nível. Na parte de gestão de fontes / SCM, os Aspiras resolveram um grande problema que o time tinha: o do big bang integration, ou a dificuldade que eles tinham de integrar os códigos produzidos por diferentes pessoas do time para que uma versão pudesse ganhar a rua. Imagina sete pessoas escrevendo novas funcionalidades e fazendo manutenções evolutivas e corretivas durante três meses e, de repente, eles têm que integrar todo o código modificado, em um uma versão única para ser publicada. Era tanto trabalho, dava tanto problema na hora de fazer os merges, que os resultados quase sempre eram códigos perdidos, horas extras, pessoas estressadas, etc. Para resolver isso, eles implementaram um processo de integração contínua, que forçou que, a cada novo check in, o código do desenvolvedor fosse integrado com a versão oficial do repositório e que qualquer conflito tivesse que ser resolvido naquele momento. Ou seja, como a integração era feita continuamente, elas normalmente eram pequenas e fáceis de resolver. Começaram também a definir padrões modernos de arquitetura, criando projetos de exemplo para demonstrar o padrão que deveria ser seguido pelos desenvolvedores, a fim de resolver problemas conhecidos de componentização, regras de negócio e persistência de dados. Em termos de processos e metodologias, neste nível, os times já haviam atingido um bom nível de maturidade. Estavam rodando o SCRUM de forma fluida e sem grandes fricções.

7 Nesse momento eles já haviam descoberto que ser ágil ia muito além do que diz o Scrum Guide. Começaram a entender que a mistura de stakeholders, artefatos, demandas, usuários, times, infraestrutura, etc., formava um sistema, um sistema complexo, complexo e adaptativo, e que nestes tipos de sistemas, nem sempre as coisas acontecem como esperado. Neste nível, os Aspiras levaram para o nível de consciência que desenvolver software é uma atividade complexa. Aceitaram, por exemplo, que não existe nenhuma ciência de estimativa, e que não é possível uma pessoa determinar em quanto tempo exatamente algo ficará pronto, já que ela é apenas um componente do sistema. Passaram a exercitar um pensamento muito mais estatístico e probabilístico do que determinístico. Na parte de automação, os Aspiras passaram a utilizar a integração contínua como gatilho para a automação de Build. Agora a cada novo check in, um novo build passou a ser enfileirado no servidor de Build. Falando de qualidade, eles permaneceram avaliando continuamente as métricas e os níveis de cobertura do código por testes automatizados. Os planos e casos de testes agora eram extensivos. Durante o último período, foi possível colecionar centenas de casos de testes, tornando impraticável executar manualmente cada um deles a cada nova versão liberada. Eles partiram então para um processo de automação destes testes, utilizando engines de testes de interface, que simulam o uso de uma pessoa na aplicação, clicando aqui e ali, fazendo os inputs de dados e validando de forma automática os resultados esperados. Assim ficou mais fácil garantir a entrega de software de alto padrão de qualidade. A Tabela 3 traz os novos desafios vividos pelo time neste nível. configuration management. A novidade aqui é que eles perceberam que, reduzindo a cadência de entrega, eles reduziam o tempo em que novas funcionalidades chegavam aos usuários, acelerando o processo de aprendizado e consequentemente de feedback e de novas demandas. Nesse ritmo era impossível pensar em big design up front. O time aqui entendeu que o melhor a ser feito era ficar bom em modificar a arquitetura da aplicação sob demanda, e que a arquitetura agora era emergente. O processo ágil deles estava a todo vapor, rodando de forma fluida, melhorando continuamente a cada Sprint executada. A consciência de que estavam inseridos em um sistema complexo aumentava e eles começaram a criar modelos de relações de causa e efeito. Um modelo onde ficam evidentes coisas do tipo: se mais isso, menos aquilo, se menos isso, mais aquilo. É como se eles começassem a descobrir o efeito que cada torção de parafuso tinha dentro do time. O que motivava o time, o que desmotivava, o que acelerava a entrega, o que desacelerava. Um exemplo: se paralelizassem as atividades do time a partir de um ponto, eles aumentavam o lead time, diminuindo o throughput, consequentemente diminuindo a previsibilidade de entrega do time. Esse tipo de modelo é fundamental para um time alcançar um alto desempenho. Normalmente, existe uma grande preocupação em gerir ocupação de pessoas, em garantir que os recursos estejam sempre 100% alocados. Isto é um pensamento 1.0, herança maldita No nível 400 pouco se discutia sobre fontes. O time já estava com alta proficiência na disciplina de SCM - source and

8 do modelo fabril que tomou conta da indústria de software durante quase um século. Agora existe muito mais uma preocupação em gerir o throughput e o lead time do time, do que em garantir que as pessoas estejam alocadas 100% do seu tempo. Entenda como throughput a quantidade de itens que o time coloca para fora da máquina em um determinado período de tempo, o quanto de itens prontos (production ready) é entregue. E lead time como o tempo que o item fica dentro da máquina, do sistema, desde o momento em que o item é aprovado para produção até o momento em que ele é entregue. O lead time serve para medir a eficiência do sistema como um todo, envolvendo todos seus componentes (desenvolvedores, tecnologia, demandas, stakeholders, impedimentos, etc.). Um erro comum é tentar utiliza-lo como medida de esforço. Mas não é o objetivo no momento. O fato é que, com um modelo causal estabelecido, e com o time trabalhando focado em throughput e lead time, foi possível chegar num ponto onde era possível afirmar com até 90% de certeza de que uma demanda aprovada, uma vez no sistema, entre quatro e seis dias, estaria disponível para produção. Nesse nível de entrega, os Aspiras já haviam deixado de trabalhar por iterações e estavam rodando em ciclos contínuos de entrega. Não eram mais baldes de coisas ficando prontas (sprints), era como se fosse uma torneira aberta, com fluxo contínuo de entrega. Com isso, eles descobriram a diferença entre sistemas puxados e sistemas empurrados. Vêm as demandas de negócio e elas são empurradas ao time, sem compasso, sem entender a capacidade de entrega dele (número de pessoas, número de projetos em desenvolvimento / sustentação, maturidade do time, habilidades técnicas, multidisciplinaridade, km rodados, disciplinas automatizadas por ferramentas, motivação, etc.). Isso faz com que o time tenha que trabalhar cada vez mais horas para dar conta de entregar as demandas de negócio dentro do tempo esperado. O efeito é o contrário do esperado: pessoas desmotivadas, cansadas, sem criatividade, com baixa produtividade, o que leva a um alto turnover, que abaixa ainda mais a entrega, e um novo ciclo de reforço negativo começa. Em sistemas puxados, o funcionamento é diferente. O time puxa trabalho para dentro do sistema de acordo com a capacidade de entrega que eles têm naquele momento. Fazem isso limitando o volume de trabalho em progresso (wip limit) para cada etapa de sua cadeia de valor, ou seja, para cada etapa de sua esteira de produção, o time passou a ter um limite de atividades que podiam ser executadas em paralelo. Outros tópicos mais avançados passaram a atuar no estado de consciência dos times como, por exemplo, entender qual a sua liquidez e qual efeito sistêmico que ela tem sobre os resultados (throughput e lead time). Entenda como liquidez, neste contexto, o casamento entre um determinado tipo de trabalho e a disponibilidade de mão de obra especializada dentro do time para executá-lo. Por exemplo, quando o time tem muitas atividades de arquitetura ou de gestão de configuração e poucas pessoas treinadas para executá-las, eles têm baixa liquidez. E pensando em sistemas complexos, baixa liquidez aumenta os gargalos, aumentando o lead time, reduzindo o throughput, a previsibilidade, além de aumentar a dependência de pessoas, criando heróis, desmotivando pessoas, etc. Um time multidisciplinar, onde todos são capazes de executar qualquer tipo de atividade é mais eficaz e eficiente. Os Aspiras passaram a trabalhar também com classes de serviço, que variavam de acordo com os SLAs de cada tipo de atividade. Classes de serviços estabelecem formas diferentes de o time atuar, dependendo do tipo de demanda que está em pauta. Se for um requisito planejado, ele simplesmente segue o fluxo planejado. Se for um bug em produção que está afetando o funcionamento da aplicação, ele pode entrar com prioridade maior dentro do sistema, furando restrições e limites de trabalho em progresso estabelecidos. Se for um bug crítico, que está impedindo a execução da aplicação em produção, ele pode fazer inclusive com que os membros do time parem o que estão fazendo naquele momento para resolver o problema, até que o ambiente de produção seja reestabelecido. Tudo depende de qual classe de serviço uma determinada demanda pertence. Outro ponto que caiu na atenção do time é a alta depreciação quando o assunto é sistema de informação. É muito comum fazermos diferentes estoques na nossa linha de produção. Estoques de arquitetura, estoques de requisitos, de artefatos (casos de uso, diagramas), de conversas e discussões, enfim... estoques. O que a gente não percebe é que o custo de criar e manter estes estoques são muito elevados e arriscados, já que a qualquer momento, uma nova informação, um novo aprendizado, uma nova ordem, pode mudar tudo de ponta a cabeça e você perder horas e mais horas de trabalho. Tente postergar ao máximo qualquer trabalho. Leve tudo até o último momento responsável (LRM Last Responsible Moment), onde a partir daquele momento, o custo de atraso é maior do que o benefício do atraso. Para entender a curva do custo de atraso, funciona mais ou menos assim: se um item não for feito até tal data, tudo bem, a partir de tal data, o negócio começa a azedar. Passando de outra data, ele começa azedar rapidamente, até chegar um momento em que não tem mais o que fazer, azedou de vez. Para finalizar estes tópicos avançados, outra coisa que ficou bastante evidente para os Aspiras foi o tempo médio de reparo (MTTR Main Time To Repair). Nessa altura do campeonato, eles adotaram políticas de só caminhar pra frente. Nada de rollback de versão. Como estavam em um estágio avançado de entrega contínua, vez ou outra alguma coisa mal cheirosa acabava parando em produção. Quando isso acontecia, o caminho era reproduzir o bug, então criar os testes unitários pra cobrir aquele bloco de código, criar novo caso de teste que cubra aquele cenário de negócio, então corrigir o erro e disponibilizar a versão em produção. O tempo entre o erro ter sido reportado e a correção publicada, é o que chamamos de tempo de reparo, e monitorar este indicador é fundamental quando falamos de entrega contínua de software. Eles descobriram recentemente o Management 3.0 e passaram a praticar suas seis visões dentro do time (como

9 energizar as pessoas, delegar responsabilidades, alinhar restrições, desenvolver competências, crescer o time e melhorar continuamente). Quando o assunto é automação, a novidade é que eles também automatizaram o processo de deployment e passaram a fazer deploy automático para o ambiente de homologação no contexto do check in, ou seja, quando um desenvolvedor fazia check in, um build era enfileirado e quando executado, os binários além de serem gerados, eram distribuídos para o ambiente de homologação para que o time de qualidade pudesse realizar seus testes, sempre em cima da última versão disponível, eliminando o gap de tempo, entre estar pronto na máquina do desenvolvedor e disponível para testes. Como o processo automático de deployment foi estabelecido, eles passaram a utilizar a mesma tecnologia para também efetuar deploy em produção, porém não de forma automática. Eles continuaram passando pelo processo de gestão de mudança estabelecido, mas no momento do deploy em si, ao invés de reunir todas aquelas pessoas, durante todo aquele tempo, simplesmente eles apertam um botão fazendo one-click deploy para produção. Uma coisa interessante que passou a ser necessário neste nível foi gerir, de forma dinâmica, os ambientes virtuais de testes. Já que eles estavam trabalhando com geração de build e deploy automático, isso significa que a cada check in, um build era enfileirado no servidor, compilando a aplicação, executando as centenas de testes unitários. Tudo dando certo, ele fazia o deploy automático da aplicação para um ambiente de teste, similar ao de produção, onde executava as centenas de casos de testes automatizados por testes de interface para garantir que todos os cenários críticos de negócio estavam funcionando e que não havia ocorrido nenhum problema de integração. Isso tudo a cada check in de cada desenvolvedor. Tudo dentro do contexto do build. A demanda de infraestrutura aqui era grande. Agora imaginem gerenciar todos esses ambientes de testes manualmente. Acho que não seria possível. Falando de qualidade, os times já estavam praticando desenvolvimento orientado a testes TDD. Nenhum novo bloco de código era escrito, sem que antes um teste unitário tivesse sido criado. Como já existia alta rastreabilidade entre código, requisito, testes, bugs, build, o time passou a utilizar análise de impacto para garantir que uma mudança no módulo um do sistema não estava quebrando o módulo seis, por exemplo. Eles agora praticavam code review, e um código só ia para o repositório depois de atender todas as políticas de check in e também de passar pela revisão de outro desenvolvedor do time. Dessa forma, se estabeleceu uma propriedade coletiva do código. Aquela coisa de que naquela classe só o João podia mexer ficou para trás.

10 Para que o time conseguisse realmente entregar valor, foi fundamental que eles reduzissem os ciclos de feedback. Afinal, eles não estavam otimizando todos seus processos para estarem sempre certos, e sim para detectar rapidamente quando estavam errados. É possível se ter feedback em segundos através dos testes unitários, em minutos através de code review com seus pares e em horas, quando estabelecemos um processo automatizado e leve de feedback dos stakeholders. Isso fez com que o time fosse mais assertivo em suas entregas, maximizando o valor e elevando o moral do time. A Tabela 4 deixa claro o quanto o time evoluiu do nível 300 para o nível 400. Neste momento, quando o time realmente atinge o estado de continuous delivery, grandes mudanças acontecem. Na parte de fontes, a principal delas tem a ver com a estratégia de branch do time. A estratégia agora passa a ser no branch. Isso mesmo. Por mais retrógrado que possa parecer, quando o time chega neste nível, o que eles fazem é ter apenas um branch, o main. Todo código produzido é comitado no main e deployado em produção. Isso mesmo, check in, produção, check in, produção. A segregação de código que nós estamos acostumados a fazer por ambientes (desenvolvimento, testes, homologação, pré-produção, produção, etc.) passa a ser feito agora por código. Os times passam a trabalhar com flags de configuração, para habilitar ou desabilitar funcionalidades ou comportamento do sistema, para públicos alvo específicos. Para tentar ilustrar, imagine que seu sistema possui uma funcionalidade de busca e que um novo sistema de busca está sendo produzido com muito mais recursos e filtros. Desde o primeiro check in da nova busca o código foi parar em produção, mesmo não estando pronto. No início, isso pode parecer que não faz muito sentido, mas pra desfazer este nó mental, precisamos compreender que disponibilizar um código em produção é diferente de lançar uma nova versão do sistema. O fato de colocar código em produção não significa que os usuários vão ter acesso a ele. É como se fossem dark releases, que estão seguros pelas flags de configuração colocadas no código. Imagina que você tem um parâmetro no seu arquivo de configuração chamado novabusca com valor off. Isso significa que ninguém, absolutamente ninguém terá acesso à nova funcionalidade de busca. Agora imagina que o valor deste parâmetro é DevTeam, BusinessTeam. Somente os usuários contidos nos grupos de desenvolvimento e de negócio terão acesso à nova busca quando acessarem o sistema. Outra opção de valor para este parâmetro poderia ser MárcioSete, JoaoPereira, MariaJoão. Neste caso somente estes três usuários teriam acesso à nova busca. Poderíamos também colocar como valor do parâmetro 30%. Neste caso, a funcionalidade já estaria pública, mas ainda com acesso limitado, já que poderíamos não saber como ela se comportaria com alto volume de acesso. Dessa forma, apenas 30% dos acessos seriam roteados para cair na nova busca, os outros 70% seriam direcionados para a busca velha. Assim, poderíamos monitorar o comportamento do sistema, aumentando gradativamente o volume de acesso para 50%, 75% e 100%, quando o valor do parâmetro passaria então a ser on, quando 100% do tráfego público do sistema seriam roteados para a nova busca. Para que esse ramp up de usuários aconteça, é fundamental que o time tenha feedback contínuo de operação. Normalmente através de um dashboard com diversos indicadores, que mostrem coisas básicas como características de hardware dos servidores de produção, thresholds das principais funcionalidades do sistema para identificar problemas de performance, número de transações realizadas, etc., até coisas menos óbvias como por exemplo, número de posts no fórum de bugs do sistema. Praticar continuous delivery sem estes tipos de feedbacks é como pilotar um avião sem instrumentos. Falando de qualidade, os requisitos passaram a ter também o definition of ready, além da definition of done, que indica quando os requisitos estão prontos para que alguém trabalhe neles. Os desenvolvedores só commitavam com testes unitários, funcionais, com code review, atingindo a definição de pronto do time e os critérios de aceitação do requisito. Em termos de metodologia, neste nível, os times já estavam praticando o desapego. Para eles, não interessava mais como se chamava a metodologia que estavam praticando. Neste nível de entrega, eles estavam praticando um mix de metodologias. Estavam utilizando várias práticas do SCRUM, do XP, do KANBAN e até mesmo do RUP, da mesma forma que estavam deixando de utilizar várias práticas destas mesmas metodologias. É como se eles tivessem alcançando o RI do ShuHaRi, um conceito das artes marciais japonesas, que medem os estágios de aprendizado até a maestria. O SHU significa aprendizado,

11 você segue os modelos estabelecidos. O HA significa quebrar com as tradições. Você já domina tanto aquilo que faz, que já é capaz de modificar a forma com que o faz. Sabe o efeito sistêmico de cada modificação que faz no processo. O RI significa que não há mais técnicas, todos os movimentos são naturais, é onde acontece a transcendência. Um time de alta performance como este é movido muito mais por autonomia, maestria e propósito, do que por recompensas e punições. A gestão e retenção de talentos aqui demanda alguém fora da caixa, que compreenda o valor individual de cada um, o valor do time como um todo, que tenha coerência, seja sensato, se comunique extremamente bem, se preocupe com o próximo, com o negócio, tenha poder de decisão e que, principalmente, esteja a fim de fazer algo diferente de tudo que vemos cotidianamente por ai. Os Aspiras passaram a praticar melhoria contínua, rodando Kaizens periodicamente. Dentre os principais indicadores do time está o Happiness KPI, afinal de contas, de que adianta fazer tudo isso se não estiverem todos felizes? A Tabela 5 mostra o momento onde o time realmente alcança o estado de entrega contínua de valor. Depois de tudo que você leu, se você fosse desafiado a aumentar a velocidade de entrega do seu time, de forma sustentável, o que você faria? Algumas pessoas neste momento, certamente estão com a cabeça girando a mil por hora, cheio de ideias e com uma energia incrível de mudança. Outras um pouco mais céticas devem estar pensando, isso não é pra mim ou para a minha organização. Uma coisa é certa, continuous delivery não é pra qualquer projeto, contudo viver a experiência de entregar continuamente software de valor ainda não é para qualquer um. Em 10 ou 15 anos, talvez este seja o modelo predominante de se desenvolver software no Brasil, enquanto isso, para viver uma experiência dessas, é preciso coragem para combater o status quo existente, liderança com autonomia e poder para questionar regras existentes, além de patrocinadores que enxergam valor em um ciclo de vida de aplicações moderno e que entendam que investir em ALM é caro e que não investir é mais caro ainda. Seja como for, um pontapé inicial é necessário para fazer as pessoas pensarem sobre como estão produzindo software hoje, e onde desejam chegar. Normalmente este pontapé é feito por um agente de mudança, que pode ser você. Crie situações para discutir sobre como estão trabalhando hoje. Consiga a presença dos principais influenciadores da sua organização, convide especialistas de fora para participar da conversa, participe dos principais eventos de agilidade e engenharia de software para oxigenar a mente e leia, leia bastante, assim como você está fazendo agora.

MPSP Projeto ALM/Scrum. Diretoria de Sistemas de Informação

MPSP Projeto ALM/Scrum. Diretoria de Sistemas de Informação MPSP Projeto ALM/Scrum Diretoria de Sistemas de Informação Agenda O que é ALM? Objetivo do Projeto Atividades Desenvolvidas Indicadores Dúvidas O que é ALM? ALM Application Lifecycle Management Gerenciamento

Leia mais

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br Workshop de Teste de Software Visão Geral Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br 1 AGENDA DO CURSO Conceitos Básicos Documentação Processo Plano de Teste Caso de Teste BIBLIOGRAFIA

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua

Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua Software Open Source e Integração Contínua no Instituto de Informática Ferramentas de Integração Contínua Janeiro 2015 Área de Desenvolvimento Departamento de Arquitetura e Desenvolvimento Agenda Processo

Leia mais

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D. Capítulo 25 Gerenciamento de Configuração slide 624 2011 Pearson Prentice Hall. Todos os direitos reservados. Tópicos abordados Gerenciamento de mudanças Gerenciamento de versões Construção de sistemas

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

Continuous Delivery. E seus princípios e práticas. Carlos Felippe Cardoso (CFC) cfc@k21.com.br @carlosfelippe slideshare.

Continuous Delivery. E seus princípios e práticas. Carlos Felippe Cardoso (CFC) cfc@k21.com.br @carlosfelippe slideshare. Continuous Delivery E seus princípios e práticas Carlos Felippe Cardoso (CFC) cfc@k21.com.br @carlosfelippe slideshare.net/cfelippe Agradecimento ao Flávio Costa pela ajuda! Quem sou eu? Sócio e Agile

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados

Tribunal de Justiça de Pernambuco. Diretoria de Informática. Guia de Utilização do Mantis Máquina de Estados Tribunal de Justiça de Pernambuco Diretoria de Informática Guia de Utilização do Mantis Máquina de Estados Guia de Utilização Mantis Histórico de Alterações Data Versão Descrição Autor Aprovado Por 02/09/2008

Leia mais

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Gerenciamento de Projetos de Software

Gerenciamento de Projetos de Software Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc. 2º Encontro Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr (VISTO) Aula 2:

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto O Guia Passo-a-Passo para IMPLANTAR Em seu próprio Projeto Aprenda como Agilizar seu Projeto! A grande parte dos profissionais que tomam a decisão de implantar o Scrum em seus projetos normalmente tem

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Objetivos do Módulo 3

Objetivos do Módulo 3 Objetivos do Módulo 3 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Conceitos do Scrum O que é um Sprint Decifrando um Product backlog Daily Scrum, Sprint Review, Retrospectiva

Leia mais

Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho

Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho UOL Produtos Rádio UOL Julho 2008 André Piza Certified Scrum Master Agenda Scrum como método

Leia mais

Gerenciamento de Mudanças. Treinamento OTRS ITSM

Gerenciamento de Mudanças. Treinamento OTRS ITSM Gerenciamento de Mudanças Treinamento OTRS ITSM Sumário Introdução...3 Associando a Mudança à Requisições...4 Papéis...5 Construindo uma Mudança...6 Informações Gerais da Mudança...6 Definindo os Papéis

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br Engenharia de Software II: SCRUM na prática Ricardo de Sousa Britto rbritto@ufpi.edu.br Construindo Product Backlog } O product backlog é o coração do Scrum. } É basicamente uma lista de requisitos, estórias,

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

Então resolvi listar e explicar os 10 principais erros mais comuns em projetos de CRM e como podemos evita-los.

Então resolvi listar e explicar os 10 principais erros mais comuns em projetos de CRM e como podemos evita-los. Ao longo de vários anos de trabalho com CRM e após a execução de dezenas de projetos, penso que conheci diversos tipos de empresas, culturas e apesar da grande maioria dos projetos darem certo, também

Leia mais

2 Medição e Acompanhamento

2 Medição e Acompanhamento 2 Medição e Acompanhamento Para verificar a eficácia da aplicação da técnica de desenvolvimento dirigido por testes, foram usadas algumas métricas para determinar se houve melhoria ou degradação no processo

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Métodos Ágeis para Desenvolvimento de Software Livre

Métodos Ágeis para Desenvolvimento de Software Livre Métodos Ágeis para Desenvolvimento de Software Livre Dionatan Moura Jamile Alves Porto Alegre, 09 de julho de 2015 Quem somos? Dionatan Moura Jamile Alves Ágil e Software Livre? Métodos Ágeis Manifesto

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Resumo do mês de março Quer mais resumos? Todo mês em: http://www.thiagocompan.com.br

Resumo do mês de março Quer mais resumos? Todo mês em: http://www.thiagocompan.com.br Resumo do mês de março Quer mais resumos? Todo mês em: http://www.thiagocompan.com.br Jeff Sutherland criou um método para fazer mais em menos tempo com o máximo de qualidade! Usado por diversas empresas

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Expresso Livre Módulo de Projetos Ágeis

Expresso Livre Módulo de Projetos Ágeis Expresso Livre Módulo de Projetos Ágeis Desenvolvedor / Orientador Rafael Raymundo da Silva Guilherme Lacerda Out / 2010 1 Sumário 1.Conhecendo a ferramenta...3 2.Gerência de projetos ágeis...3 2.1Product

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas

Gerenciamento de configuração. Gerenciamento de Configuração. Gerenciamento de configuração. Gerenciamento de configuração. Famílias de sistemas Gerenciamento de Gerenciamento de Configuração Novas versões de sistemas de software são criadas quando eles: Mudam para máquinas/os diferentes; Oferecem funcionalidade diferente; São configurados para

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB

Testes de Software. Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB Testes de Software 1 AULA 01 INTRODUÇÃO A TESTES DE SOFTWARE Anne Caroline O. Rocha TesterCertified BSTQB NTI UFPB Conteúdo Programático do Curso Introdução a Testes de Software Técnicas de Testes de Software

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson QUALIDADE Simpósio Brasileiro de Qualidade de Software - SBQS Instituto Nokia de Tecnologia Unit Test Sucess Bug INdT Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua

Leia mais

Gerência de Configuração. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br

Gerência de Configuração. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br Gerência de Configuração Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br Introdução Mudanças durante o desenvolvimento de software são inevitáveis: os interesses

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

Um case de sucesso em equipe ágil, dedicada e remota com evolução adaptativa e gradativa do Scrum.

Um case de sucesso em equipe ágil, dedicada e remota com evolução adaptativa e gradativa do Scrum. Um case de sucesso em equipe ágil, dedicada e remota com evolução adaptativa e gradativa do Scrum. José Eduardo Ribeiro Gerente de Projetos (Scrum Master) jose.eduardo@s2it.com.br Bruno Darcolitto Analista

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO Um pouco de história... Década de 50: a gestão de projetos é reconhecida como disciplina,

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Você está fornecendo valor a seus clientes para ajudálos a superar a Paralisação virtual e acelerar a maturidade virtual?

Você está fornecendo valor a seus clientes para ajudálos a superar a Paralisação virtual e acelerar a maturidade virtual? RESUMO DO PARCEIRO: CA VIRTUAL FOUNDATION SUITE Você está fornecendo valor a seus clientes para ajudálos a superar a Paralisação virtual e acelerar a maturidade virtual? O CA Virtual Foundation Suite permite

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Software e Hardware Livres. Fábio Olivé (fabio.olive@gmail.com)

Software e Hardware Livres. Fábio Olivé (fabio.olive@gmail.com) Software e Hardware Livres Fábio Olivé (fabio.olive@gmail.com) Objetivos Ao final da apresentação, deverá estar claro que: Software Livre significa software com liberdade de uso, modificação e redistribuição,

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

Gerência e Planejamento de Projeto. SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002

Gerência e Planejamento de Projeto. SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 Gerência e Planejamento de Projeto SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 Conteúdo: Parte 1: Gerenciamento & Qualidade Plano de Projeto

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

ANEXO 04 PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP. Processo de Desenvolvimento de Sistemas

ANEXO 04 PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP. Processo de Desenvolvimento de Sistemas ANEXO 04 PROCESSO E METODOLOGIA DE DESENVOLVIMENTO PROCERGS MDP Processo de Desenvolvimento de Sistemas MDP - Metodologia de Desenvolvimento PROCERGS - é uma estrutura básica de definição de processos

Leia mais

Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/

Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/ Projeto gestão de demanda http://www.administradores.com.br/artigos/marketing/projeto-gestao-de-demanda/62517/ Muitas empresas se deparam com situações nas tarefas de previsões de vendas e tem como origem

Leia mais

IDC TECHNOLOGY SPOTLIGHT

IDC TECHNOLOGY SPOTLIGHT IDC TECHNOLOGY SPOTLIGHT A importância da inovação em fornecedores de sistemas, serviços e soluções para criar ofertas holísticas Julho de 2014 Adaptado de Suporte a ambientes de datacenter: aplicando

Leia mais

Programação extrema (XP)

Programação extrema (XP) Programação extrema (XP) Cursos de Verão 2010 - IME/USP Alfredo Goldman Departamento de Ciência da Computação www.agilcoop.org.br Agenda Primeira versão de XP Segunda versão de XP Perguntas durante a apresentação

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

SPEKX DATA SHEET. Visão Serviços. Release 4.5

SPEKX DATA SHEET. Visão Serviços. Release 4.5 SPEKX DATA SHEET Visão Serviços Release 4.5 Versão 2.0 ÍNDICE ANALÍTICO 1. Introdução 3 1.1. Solução Única 3 2. Visão Resumida 4 2.1 Diagrama de Etapas de Projetos / Serviços 4 2.2. Resumo Descritivo Etapas

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO

UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO UMA ABORDAGEM SOBRE TESTES AUTOMATIZADO DE SOFTWARES EM AMBIENTES DE DESENVOLVIMENTO Robson L. Nascimento 1, Késsia R. C. Marchi¹ 1 Universidade Paranaense (UNIPAR) Paranavaí-PR-Brasil robsonluisn@yahoo.com.br,

Leia mais

Gerência de Configuração de Software Funções

Gerência de Configuração de Software Funções Universidade Estadual de Maringá Departamento de Informática Ciência da Computação Processo de Engenharia de Software II Gerência de Configuração de Software Funções Rafael Leonardo Vivian {rlvivian.uem

Leia mais

Introdução a Métodos Ágeis de Desenvolvimento de Software

Introdução a Métodos Ágeis de Desenvolvimento de Software Introdução a Métodos Ágeis de Desenvolvimento de Software Curso de Verão Centro de Competência em Software Livre Departamento de Ciência da Computação - IME / USP Realização: AgilCoop Verão Ágil 2010 Copyleft

Leia mais

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Tiago Domenici Griffo 1, Gothardo Francisco de Magalhães Santos 1, Rodrigo Becke Cabral 1 1

Leia mais

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação ScRUM na prática Scrum no dia-a-dia V Semana de Tecnologia da Informação Agenda Manifesto Ágil; O Scrum; Os papéis do Scrum; Quem usa Scrum; O Scrum na Tray; Cerimônias; Artefatos. Qualidade. era uma vez

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

Leia mais

User. Stories. Por que e como escrever requisitos de forma ágil? RAFAEL HELM e DANIEL WILDT. Wildtech start wild, keep wild

User. Stories. Por que e como escrever requisitos de forma ágil? RAFAEL HELM e DANIEL WILDT. Wildtech start wild, keep wild User Stories Por que e como escrever requisitos de forma ágil? RAFAEL HELM e DANIEL WILDT Wildtech start wild, keep wild Qualidade de software começa na especificação. Rafael Helm. 2 Sobre os autores Rafael

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

Tópicos abordados. Testes de Software (Capítulo 8 Sommerville) 2/2/2015. Testes de desenvolvimento. Desenvolvimento dirigido a testes

Tópicos abordados. Testes de Software (Capítulo 8 Sommerville) 2/2/2015. Testes de desenvolvimento. Desenvolvimento dirigido a testes Testes de Software (Capítulo 8 Sommerville) slide 569 2011 Pearson Prentice Hall. Todos os direitos reservados. Tópicos abordados Testes de desenvolvimento Desenvolvimento dirigido a testes Testes de release

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Maior Previsibilidade com o Visual Studio Team System 2008

Maior Previsibilidade com o Visual Studio Team System 2008 Maior Previsibilidade com o Visual Studio Team System 2008 White Paper Maio de 2008 Para obter as últimas informações, visite o site www.microsoft.com/teamsystem As informações contidas neste documento

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

Leia mais

Como entendemos a Gestão por Processos?

Como entendemos a Gestão por Processos? RIO DE JANEIRO SÃO PAULO BRASÍLIA BELO HORIZONTE Como entendemos a Gestão por Processos? Mobilizando pessoas para promover melhorias e inovações a partir de processos André Macieira & Leandro Jesus Alguns

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Corporation. Gerenciamento de Projetos Iterativos e Metodologias Ágeis

Corporation. Gerenciamento de Projetos Iterativos e Metodologias Ágeis Gerenciamento de Projetos Iterativos e Metodologias Ágeis Marcio Tierno Outubro 2006 Page 2 O que NÃO esperar Exposição sobre Gerenciamento de Projetos PMBOK, etc Técnicas detalhadas sobre Gerenciamento

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

Implementando Integração Contínua

Implementando Integração Contínua Modelo Zend para Entrega Contínua Implementando com Jenkins e server porslaveykaradzhov Introdução Entrega contínua é uma metodologia, uma mudança de mentalidade e uma prática de liderança que foca em

Leia mais

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS TM RELATÓRIO EXECUTIVO DE NEGÓCIOS A visão da computação em nuvem por Aad van Schetsen, vicepresidente da Compuware Uniface, que mostra por que

Leia mais

Reuse in a Distributed Environment

Reuse in a Distributed Environment Reuse in a Distributed Environment É possível aplicar APF em um Ambiente Ágil? Alcione Ramos, MSc, CFPS, PMP, CSD Cejana Maciel, MSc, Scrum Master, ITIL, COBIT Ponto de função é coisa dos anos 70. É uma

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Tecnologias Atuais de. Desenvolvimento de Software

Tecnologias Atuais de. Desenvolvimento de Software Tecnologias Atuais de Desenvolvimento de Software volução dos Processos de Desenvolvimento de Software Prof. Luiz Antônio lpereira@uninet.com.br Agenda onceitos volução dos Processos de Software Modelos

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

Transformando a TI de uma agência governamental em ágil

Transformando a TI de uma agência governamental em ágil Transformando a TI de uma agência governamental em ágil Gavin Martin O governo é composto de programas independentes que, por causa de sua organização, inibem cadeias de valor eficientes. Por minha experiência,

Leia mais