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.

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

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

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

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

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

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

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

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

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

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

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

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

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

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

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

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

Freelapro. Título: Como o Freelancer pode transformar a sua especialidade em um produto digital ganhando assim escala e ganhando mais tempo

Freelapro. Título: Como o Freelancer pode transformar a sua especialidade em um produto digital ganhando assim escala e ganhando mais tempo Palestrante: Pedro Quintanilha Freelapro Título: Como o Freelancer pode transformar a sua especialidade em um produto digital ganhando assim escala e ganhando mais tempo Quem sou eu? Eu me tornei um freelancer

Leia mais

ERP. Enterprise Resource Planning. Planejamento de recursos empresariais

ERP. Enterprise Resource Planning. Planejamento de recursos empresariais ERP Enterprise Resource Planning Planejamento de recursos empresariais O que é ERP Os ERPs em termos gerais, são uma plataforma de software desenvolvida para integrar os diversos departamentos de uma empresa,

Leia mais

Transforme. Transforme a TI. a empresa. Três imperativos da TI para a transformação da empresa realizada pelo CIO em um mundo dinâmico.

Transforme. Transforme a TI. a empresa. Três imperativos da TI para a transformação da empresa realizada pelo CIO em um mundo dinâmico. TECH DOSSIER Transforme a TI Transforme a empresa Três imperativos da TI para a transformação da empresa realizada pelo CIO em um mundo dinâmico. Consolidar para conduzir a visibilidade da empresa e a

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

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

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

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

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

A Evolução de XP segundo Kent Beck Parte 2

A Evolução de XP segundo Kent Beck Parte 2 A Evolução de XP segundo Kent Beck Parte 2 O que mudou nesses 5 anos? Danilo Toshiaki Sato dtsato@ime.usp.br Agenda PARTE 1 1. Introdução 2. O que é XP? 3. O que mudou em XP? Valores, Princípios e Práticas

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

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

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

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

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

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

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

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

Tópicos. Engenharia de Software: Uma Visão Geral

Tópicos. Engenharia de Software: Uma Visão Geral Tópicos 2 3 Engenharia de Software: Uma Visão Geral SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 A importância do Software Software Aplicações

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Integrando Lean com os sistemas de tecnologia de informação

Integrando Lean com os sistemas de tecnologia de informação Integrando Lean com os sistemas de tecnologia de informação Jean Cunningham Quando eu era CFO (Chief Financial Officer) da Lantech (Louisville, KY), ajudei a adaptar o sistema de tecnologia de informação

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

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

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

Minha lista de sonhos

Minha lista de sonhos Licença No: # 122314/LS Fone: +55-11 5539-4719 E mail: vagner@programavirandoojogo.com.br Web: www.programavirandoojogo.com.br 2015 Minha lista de sonhos Com visão 2025 PREPARADO POR VAGNER MOLINA Rua

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

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

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

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

TUTORIAL PRÁTICO SOBRE Git. Versão 1.1

TUTORIAL PRÁTICO SOBRE Git. Versão 1.1 TUTORIAL PRÁTICO SOBRE Git por Djalma Oliveira Versão 1.1 "Git é um sistema de controle de revisão distribuida, rápido e escalável" (tradução rápida do manual). Basicamente é

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

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

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

Especialização em Arquitetura e Engenharia de Software

Especialização em Arquitetura e Engenharia de Software Especialização em Arquitetura e Engenharia de Software O curso vai propiciar que você seja um especialista para atua atuar na área de Arquitetura de Software em diferentes organizações, estando apto a:

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

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit)

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) Agenda A palestra Angola Cliente O projeto Usando o PMBOK Usando o Cobit Lições Aprendidas Conclusão

Leia mais

Governança de T.I. Professor: Ernesto Junior E-mail: egpjunior@gmail.com

Governança de T.I. Professor: Ernesto Junior E-mail: egpjunior@gmail.com Governança de T.I Professor: Ernesto Junior E-mail: egpjunior@gmail.com Information Technology Infrastructure Library ITIL ITIL é um acrônimo de Information Technology Infraestruture Library. Criado em

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

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br PROCESSOS PODEROSOS DE NEGÓCIO ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br POR QUE ESCREVEMOS ESTE E-BOOK? Nosso objetivo com este e-book é mostrar como a Gestão de Processos

Leia mais

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br

Modernização e Evolução do Acervo de Software. Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Modernização e Evolução do Acervo de Software Gustavo Robichez de Carvalho guga@les.inf.puc-rio.br Tópicos 1. Estudo Amplo sobre Modernização 2. Visão IBM Enterprise Modernization 3. Discussão - Aplicação

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Gestão de Projetos com Métodos Ágeis - Avançado

Gestão de Projetos com Métodos Ágeis - Avançado Gestão de Projetos com Métodos Ágeis - Avançado Caxias do Sul, 16 de Agosto 2013 Gustavo Casarotto Agenda O Scrum Planejamento da Sprint 1 Execução da Sprint 1 Revisão da Sprint 1 Retrospectiva da Sprint

Leia mais

PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ MANUAL DE UTILIZAÇÃO DO CVS NO ECLIPSE

PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ MANUAL DE UTILIZAÇÃO DO CVS NO ECLIPSE PLATAFORMA DE DESENVOLVIMENTO PINHÃO PARANÁ MANUAL DE UTILIZAÇÃO DO CVS NO ECLIPSE Agosto 2007 Sumário de Informações do Documento Tipo do Documento: Manual Título do Documento: MANUAL DE UTILIZAÇÃO DO

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

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

TRANSIÇÃO DE SERVIÇO ITIL FOUNDATION V3 Conteúdo deste resumo deve ser contemplado com a leitura do livro ITIL Service Transition

TRANSIÇÃO DE SERVIÇO ITIL FOUNDATION V3 Conteúdo deste resumo deve ser contemplado com a leitura do livro ITIL Service Transition TRANSIÇÃO DE SERVIÇO ITIL FOUNDATION V3 Conteúdo deste resumo deve ser contemplado com a leitura do livro ITIL Service Transition Conjunto de processos e atividades para a transição de serviços Engloba

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

ESCOLHA UM TESTE PARA EXECUTAR

ESCOLHA UM TESTE PARA EXECUTAR ESCOLHA UM TESTE PARA EXECUTAR Acompanhe o ritmo de aceleração dos ciclos de lançamento. Descubra a automatização com um toque humano EXECUTE UM TESTE 26032015 Com a Borland, tanto analistas de negócios

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

Quais são as características de um projeto?

Quais são as características de um projeto? Metodologias ágeis Flávio Steffens de Castro Projetos? Quais são as características de um projeto? Temporário (início e fim) Objetivo (produto, serviço e resultado) Único Recursos limitados Planejados,

Leia mais

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software Análise e Projeto de Sistemas Análise e Projeto de Sistemas Contextualização ENGENHARIA DE SOFTWARE ANÁLISE E PROJETO DE SISTEMAS ENGENHARIA DA INFORMAÇÃO Perspectiva Histórica Engenharia de Software 1940:

Leia mais