Democratização da tecnologia (2000-2008)

Ao início do século XXI viu a emergência de novas metodologias ágeis, como Scrum, Kanban, Lean, e Extreme Programming, que revolucionaram a forma como os projetos de software eram geridos. Essas metodologias colocam ênfase na colaboração contínua, na adaptação às mudanças e na entrega rápida de funcionalidades, em contraste com as abordagens mais rígidas e sequenciais que prevaleciam anteriormente. Além disso, a crescente ubiquidade dos dispositivos móveis e a ascensão da computação em nuvem abriram novas fronteiras para o desenvolvimento de software, permitindo a criação de aplicações mais dinâmicas, escaláveis e acessíveis.

Ao longo das décadas, a história dos projetos de software tem sido uma história de adaptação e inovação constante. Cada avanço tecnológico trouxe consigo novos desafios e oportunidades, impulsionando a evolução contínua das práticas e ferramentas utilizadas no desenvolvimento de software. Hoje, os projetos de software são parte integrante de quase todos os aspectos da vida moderna, desde a comunicação e o comércio até a educação e o entretenimento, refletindo a importância crescente do software em nosso mundo interconectado.

2000: Kanban¶

Origem: O método Kanban foi adaptado do gerenciamento de produção industrial (Toyota), e começou a ser utilizado em desenvolvimento de software na década de 2000. Características: Foco na visualização do fluxo de trabalho, limitando o número de tarefas em progresso e otimizando a entrega contínua. Limitações: Pode ser difícil de adotar sem uma cultura de melhoria contínua e foco em fluxo de trabalho eficiente.

• 2000: Google Sheets (início como parte de Writely) – A versão inicial das planilhas baseadas na web começou a surgir, mais tarde evoluindo para Google Sheets como parte do Google Docs em 2006.
• 2000: Basecamp – Um dos primeiros softwares de gerenciamento de projetos baseado na web.
• 2000: A SoftBank do Japão apresenta o primeiro telefone com câmera, o J-Phone J-SH04; um telefone digital fabricado pela Sharp com câmera integrada.
• O PlayStation 2 (PS2) representa uma mudança significativa no conceito de consoles de jogos.
• Pen Drive - Os drives USB Flash são introduzidos
• Bug do Milênio: O problema estava enraizado no fato de que os carimbos de data na maioria dos softwares escritos anteriormente usavam apenas dois dígitos para representar as informações do ano.
• O conceito de Test Driven Development (TDD) foi popularizado por Kent Beck no início dos anos 2000. Ele formalizou a prática no livro "Test-Driven Development: By Example", publicado em 2002;

2001: Agile (Manifesto Ágil)¶

O Manifesto Ágil surgiu da necessidade de uma abordagem mais eficiente e centrada no valor do que as metodologias tradicionais de desenvolvimento de software.

Representantes de várias disciplinas de desenvolvimento de software se reuniram em 2001 para criar uma alternativa à documentação intensiva e processos focados.

O objetivo era desenvolver software que entregasse valor, atendesse às expectativas dos clientes e proporcionasse um ambiente de trabalho motivador.

Os Quatro Valores do Manifesto Ágil¶

• Indivíduos e interações acima de processos e ferramentas: O foco deve ser nas pessoas e em sua capacidade de colaborar, em vez de seguir processos rígidos ou depender de ferramentas.
• Software funcional acima de documentação abrangente: O progresso é medido pela entrega de software que funciona e agrega valor ao cliente, não pela produção de documentos extensos.
• Colaboração com o cliente acima de negociação de contratos: O relacionamento com o cliente deve ser baseado na confiança e colaboração, em vez de contratos formais e rígidos.
• Resposta à mudança acima de seguir um plano: O desenvolvimento de software deve ser flexível e capaz de se adaptar a mudanças nos requisitos, em vez de seguir um plano fixo.

Princípios de Suporte ao Manifesto Ágil¶

• Satisfação do cliente: Priorizar a entrega contínua de software valioso para satisfazer o cliente.
• Bem-vindos à mudança: Acolher mudanças nos requisitos, mesmo tardiamente, para garantir uma vantagem competitiva para o cliente.
• Entregar software funcional com frequência: Entregar software funcional em intervalos curtos, com preferência por prazos mais curtos.
• Colaboração diária: Desenvolvedores e pessoas de negócios devem trabalhar juntos diariamente.
• Indivíduos motivados: Construir projetos em torno de indivíduos motivados, fornecendo o ambiente e suporte necessários.
• Conversa face a face: A comunicação face a face é o método mais eficiente para troca de informações.
• Software funcional como medida de progresso: O software funcional é a principal medida de progresso, não outras métricas como tempo gasto ou orçamento.
• Ritmo constante: Promover um desenvolvimento sustentável, mantendo um ritmo constante indefinidamente.
• Excelência técnica: Buscar constantemente a excelência técnica e bom design, pois isso aumenta a agilidade.
• Simplicidade: Maximizar a quantidade de trabalho não feito. Implementar apenas o mínimo necessário.
• Equipes auto-organizadas: As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizadas.
• Refletir e ajustar: A equipe deve refletir sobre como se tornar mais eficaz e ajustar seu comportamento.

Valores Ágeis¶

Os valores ágeis como verdade, transparência, confiança, respeito e compromisso devem ser aplicados tanto no desenvolvimento de software quanto na vida cotidiana.

Importância da Entrega Contínua e Ritmo Constante¶

A entrega contínua de software com valor é essencial para a satisfação do cliente e para responder às mudanças. É preciso um ritmo constante de trabalho, o que significa manter a equipe trabalhando de forma consistente. Variabilidade no ritmo leva a incerteza e dificuldade em planejar.

Fatores que Impedem a Adoção do Agile:¶

• Resistência à mudança por parte de pessoas e departamentos.
• Falta de infraestrutura para entrega contínua.
• Falta de clareza sobre o valor para o cliente.
• Liderança inadequada, que não prioriza a motivação da equipe.
• Falta de confiança e comunicação aberta.
• Acumulação de dívida técnica e má qualidade de código.

• 2001: BitTorrent, um serviço de compartilhamento de arquivos peer-to-peer, é lançado pela BitTorrent, Inc.
• O Mac OS X é lançado.
• Idealizado pelo lendário diretor Stanley Kubrick, mas dirigido por Steven Spielberg após a morte de Kubrick, AI conta a história de David, um robô humanoide que pode sentir e expressar emoções.
• O sistema operacional Windows XP é lançado.
• O iTunes da Apple é lançado.
• 2001: Selenium – Lançado inicialmente como Selenium Core, tornou-se uma das ferramentas de automação de testes mais populares.

2002: Modelo Test Driven Development (TDD)¶

O TDD foi formalizado por Kent Beck, um dos pioneiros das metodologias ágeis, como parte de sua abordagem de desenvolvimento de software dentro do contexto do Extreme Programming (XP). Beck escreveu o livro "Test-Driven Development: By Example", publicado em 2002, que descreve a prática de escrever testes antes de escrever o código funcional, com o objetivo de garantir que o código esteja sempre testado e refatorável.

A prática de TDD já estava em desenvolvimento por alguns anos, mas foi com a obra de Kent Beck que ela foi sistematizada e disseminada.

• 2002: Implantado o e-Business Suite na BBTS, após um ano de suspensão das atividades de levantamento.
• 2002: Implantação do e-Business Suite na Cobra Computadores;
• 2002: OpenOffice Calc – Parte da suíte de escritório OpenOffice, um software de código aberto para planilhas.
• 2002: Primavera P6 – Atualização para projetos mais robustos e integração empresarial.
• 2002: TestNG – Framework de testes inspirado no JUnit, com suporte avançado para funcionalidades como paralelismo.

2003: LEAN Software Development¶

Baseado nos princípios do Lean Manufacturing (Toyota), o Lean Software Development foi introduzido por Mary e Tom Poppendieck. - [x] Características: Foco em eliminar desperdícios, melhorar a eficiência e fornecer valor contínuo ao cliente. - [x] Limitações: Exige um comprometimento com a eliminação de desperdícios, o que pode ser difícil para empresas que já têm processos estabelecidos.

• 2003: Blue Prism – Fundado no Reino Unido, é considerado o pioneiro em RPA empresarial, introduzindo o conceito de “trabalhadores digitais”.
• 2003: Lean Software Development, Mary e Tom Poppendieck, sete princípios "lean" fundamentais, adaptam-nos para o mundo do desenvolvimento de software e mostram como eles podem servir como base para abordagens de desenvolvimento ágil que funcionam.
• 2004: Em 2004, o Google é a primeira grande empresa da Web a lançar uma ação negociada publicamente desde os dias de euforia do boom das pontocom.
• 2004: HP Quality Center (anteriormente TestDirector) – Uma plataforma robusta para gestão de testes e qualidade.

2003: BDD (Behavior-Driven Development)¶

• Criadores: Dan North (inicialmente), mais tarde com contribuições de outros como Aslak Hellesøy

• Ano de publicação: 2003 (inicialmente), com maior difusão a partir de 2008

• Contexto: O BDD surgiu como uma evolução do TDD, com foco em comportamentos e na comunicação mais eficaz entre desenvolvedores, testadores e clientes. Dan North foi o principal responsável por popularizar o BDD ao perceber que a terminologia e a abordagem do TDD, muitas vezes, dificultavam a colaboração entre as partes interessadas no software. Em 2003, ele introduziu o conceito de "Spec by Example" e, em 2008, isso foi formalizado como BDD, com a criação de ferramentas como o Cucumber (em colaboração com Aslak Hellesøy) que ajudavam a descrever os comportamentos do sistema em linguagem natural (Gherkin).

• O BDD enfatiza a colaboração entre as equipes para entender os requisitos e comportamentos do sistema e transformá-los em testes automatizados que verificam esses comportamentos.
• Em vez de escrever testes focados na implementação, o BDD prioriza a especificação do comportamento esperado do software, usando exemplos concretos que são compreensíveis para todos, incluindo stakeholders não técnicos.
• Especificações Executáveis: O BDD transforma exemplos concretos em especificações executáveis, que servem tanto como documentação viva quanto como testes automatizados. Essas especificações são geralmente escritas em uma linguagem compreensível por todos, como Gherkin, usando a estrutura "Dado ... Quando ... Então".
• Feature Injection e Definição de Requisitos: "Feature Injection", que envolve a identificação do valor de negócio, a definição de metas claras, a identificação de stakeholders e a derivação de funcionalidades (features) a partir dessas metas. O processo começa com uma visão clara do produto e a compreensão de como o software beneficiará o negócio.
• Citação: "O primeiro passo na injeção de recursos é "caçar o valor". Mas é muito mais fácil identificar o valor que você espera de um projeto se você tiver uma ideia clara da visão geral do projeto."
• Exemplos e Cenários: Os exemplos desempenham um papel central no BDD. Os exemplos concretos ilustram o comportamento desejado, auxiliando na compreensão e na comunicação. Os exemplos são então formalizados em cenários, usando a estrutura "Dado ... Quando ... Então".
• Citação: "Quando você automatiza seus critérios de aceitação usando esse tipo de ferramenta BDD, você expressa seus exemplos em um formato um pouco mais estruturado, geralmente chamado de cenários."
• Da Especificação ao Código: O BDD não se limita à fase de especificação. Ele também influencia o design e a implementação do software. A estrutura "Dado ... Quando ... Então" é usada tanto em especificações de alto nível quanto em testes unitários de baixo nível, guiando o desenvolvimento do software.
• Automatização e Ferramentas: Diversas ferramentas de automação para BDD, como JBehave, Cucumber-JVM, SpecFlow e Behave, demonstrando como cenários podem ser transformados em testes automatizados. Também destaca ferramentas auxiliares como Thucydides.
• Testes Unitários e BDD: Explora como aplicar os princípios do BDD no nível dos testes unitários, utilizando ferramentas como Spock e RSpec para criar especificações executáveis de baixo nível. O livro reforça a ideia de que os testes podem servir como documentação viva do código, ao usar nomes claros e expressivos e ao focar o comportamento dos objetos sob teste.
• Integração Contínua e Entrega Contínua: O BDD se integra com as práticas de Integração Contínua e Entrega Contínua, garantindo que as especificações executáveis sejam validadas regularmente durante o processo de desenvolvimento.
• A Visão (Vision Statement): É fundamental começar com uma visão clara do produto. Essa visão deve ser expressa através de uma declaração concisa que responde ao "Porquê" do projeto.
• Objetivos de Negócio (Business Goals): Os objetivos de negócio devem ser SMART (Specific, Measurable, Achievable, Relevant, Time-bound) para orientar o desenvolvimento e medir o sucesso. O "Porquê" do projeto é primordial e deve ser explícito.
• Mapeamento de Impacto (Impact Mapping): É uma técnica visual para explorar as ramificações das metas de negócio, identificando os atores, os impactos desejados e as funcionalidades necessárias.
• Capacidades (Capabilities): As capacidades descrevem o que o sistema deve ser capaz de fazer para alcançar as metas de negócio.
• Funcionalidades (Features): As funcionalidades entregam capacidades e podem ser divididas em partes menores e mais gerenciáveis. São descritas com user stories ou através de "In order to ... As a ... I want to..."
• User Stories: São artefatos de planejamento que podem ser descartados no final de cada iteração, mas que ajudam a refinar o entendimento de cada funcionalidade. Uma funcionalidade pode ser decomposta em várias user stories.
• Exemplos Concretos: São a base da especificação, usados para ilustrar o comportamento desejado de cada funcionalidade.
• Cenários: São exemplos formalizados usando a estrutura "Dado ... Quando ... Então". Em ferramentas como Gherkin, os cenários são estruturados em arquivos de feature.
• Arquivos de Feature: Agrupam todos os cenários relacionados a uma funcionalidade.
• Tabelas de Exemplos: Permitem expressar múltiplos cenários relacionados em uma única representação.
• Tags: Permitem categorizar cenários.
• Stubs e Mocks: São usados no nível de testes unitários para isolar dependências e facilitar o teste de funcionalidades específicas.
• Linguagem Ubíqua: A linguagem utilizada nos cenários deve ser a mesma usada por todos os envolvidos no projeto, incluindo os stakeholders.
• Ferramentas: JBehave (Java), Cucumber-JVM (Java), SpecFlow (.NET), Behave (Python), Spock (Groovy), RSpec (Ruby), JUnit/NUnit/TestNG (Java/.NET).
• Ciclo de Vida: O BDD não é restrito a uma fase do ciclo de vida do software. Ele influencia todo o processo, da definição de requisitos ao deployment.

O BDD também envolve uma forma de colaboração, focada na comunicação e no entendimento compartilhado do valor do software para o negócio. Ao seguir esses princípios, as equipes de desenvolvimento podem construir software de maior qualidade, que atenda melhor às necessidades dos usuários e stakeholders.

2005: ATDD (Acceptance Test-Driven Development)¶

• Criadores: Alistair Cockburn, com contribuições de outros, como Ron Jeffries
• Ano de publicação: 2005 (mais ou menos)
• Contexto: O ATDD compartilha algumas semelhanças com o BDD, mas seu foco está na criação de testes de aceitação antes de iniciar o desenvolvimento, com ênfase no entendimento das expectativas do cliente. O conceito foi introduzido por Alistair Cockburn em 2005, em conjunto com outras práticas ágeis. ATDD envolve a colaboração entre clientes, desenvolvedores e testadores para definir claramente os critérios de aceitação de uma funcionalidade e garantir que esses critérios sejam atendidos.

No ATDD, os testes de aceitação geralmente são mais detalhados e orientados para o comportamento funcional do sistema em um nível mais alto, enquanto o BDD foca na especificação do comportamento do software a partir de exemplos.

• 2005: Kit inicial Arduino
• Hadoop é um projeto de software de código aberto desenvolvido inicialmente pelo Google como um meio de extrair resultados de pesquisa de grandes quantidades de dados não estruturados, como dados encontrados na web.
• O veículo autônomo da Stanford Racing Team, "Stanley", vence o "Grand Challenge" da DARPA de 2005, realizado perto de Las Vegas.
• 2005: UiPath (início como DeskOver) – Criado como uma empresa de automação de software em Bucareste, começou como uma ferramenta de automação simples para Windows.
• 2006: O Amazon Web Services é lançado.
• Sistema de jogo Wii da Nintendo não introduz apenas novos jogos e controles, mas novas maneiras de interagir com os sistemas de jogo.
• Fundado por um grupo de jornalistas e registrado na Islândia, o WikiLeaks serve como uma câmara de compensação para informações secretas, vazamentos de notícias e material anônimo.
• 2006: Automation Anywhere – Inicialmente conhecida como Tethys Solutions, lançou uma plataforma de automação com foco em integração empresarial.

• 2006: Google Docs – Lançado como parte do Google Suite, trouxe edições colaborativas na nuvem.

• 2007: A Hitachi Global Storage Technologies anuncia o primeiro disco rígido (HDD) de 1 TB.

• O Amazon Kindle é lançado;
• A Apple lança o iPhone - uma combinação de navegador da web, tocador de música e telefone celular - que podia baixar novas funcionalidades na forma de "apps" (aplicativos) da loja online da Apple.
• 2008: A Apple apresenta seu primeiro ultra notebook – um laptop leve e fino com bateria de alta capacidade.
• 2008: Large-Scale Scrum (LeSS) - Criado por Craig Larman e Bas Vodde, o LeSS baseia-se na simplicidade e no foco nos princípios do Scrum, mantendo a essência do ágil mesmo em escalas maiores.

2008: Large-Scale Scrum (LeSS)¶

O LeSS utiliza o mínimo necessário de processos e regras, incentivando o uso eficiente de recursos e evitando complexidade desnecessária.

Todas as equipes trabalham em um único Backlog do Produto, coordenadas para entregar um único incremento a cada Sprint.

Promove ciclos curtos de feedback e melhoria contínua, tanto no nível do time quanto no nível organizacional.

O LeSS possui dois modelos principais, dependendo do número de equipes envolvidas:

LeSS Básico:¶

• Para 2 a 8 equipes, cada uma com até 10 membros.
• Todas as equipes compartilham um único Product Owner e um Backlog do Produto.
• As reuniões do Scrum (Daily, Sprint Planning, Review, e Retrospective) são adaptadas para envolver todas as equipes de forma coordenada.

LeSS Huge:¶

• Para mais de 8 equipes.
• Divide o trabalho em Áreas de Requisito, com cada área possuindo seu próprio Backlog.
• Um Product Owner principal é responsável pelo produto como um todo, enquanto os Area Product Owners gerenciam Backlogs específicos.

O LeSS é ideal para organizações que desejam escalar o Scrum mantendo os valores ágeis e a simplicidade, promovendo alta eficiência e colaboração em ambientes complexos.

• Simplicidade Escalável: Mantém o núcleo do Scrum intacto, mesmo em grande escala.
• Colaboração entre Equipes: Promove forte alinhamento e coordenação.
• Maior Foco no Cliente: As entregas frequentes garantem que o feedback seja incorporado rapidamente.
• Redução de Complexidade: Evita a criação de estruturas pesadas e burocráticas.

2009: Scrumban: Essays on Kanban Systems for Lean Software Development¶

A ideia central era proporcionar uma transição mais gradual do Scrum para o Kanban, principalmente para equipes que queriam evoluir seus processos ágeis de forma incremental.

O Scrumban aproveita a estrutura bem definida do Scrum, como sprints, papéis e cerimônias, e adiciona a flexibilidade e o foco no fluxo contínuo do Kanban. Essa combinação atende equipes que buscam equilibrar planejamento estruturado com a adaptabilidade para responder às demandas do projeto.

Ele é especialmente útil para equipes que trabalham em ambientes dinâmicos, onde as prioridades podem mudar rapidamente.

• Planejamento por demanda: Ao invés de sprints fixos, o planejamento ocorre quando necessário, geralmente quando o backlog atinge um limite mínimo.
• Limites de trabalho em progresso (WIP): Importado do Kanban, esse conceito limita o número de tarefas que podem estar em andamento ao mesmo tempo, melhorando o foco e a eficiência.
• Quadro visual: Assim como no Kanban, o uso de um quadro visual para gerenciar tarefas (to do, doing, done) é fundamental.
• Melhoria contínua: Promove revisões frequentes para identificar gargalos e ajustar os processos, usando práticas como retrospectivas e análises de fluxo.
• Flexibilidade: O Scrumban é menos rígido que o Scrum, permitindo que as equipes adaptem seus métodos de trabalho de acordo com as necessidades.