Categoria: Agile

PoC de Pair Programming com Github Copilot: remoção de fundo de imagens em Python

Fala Devs! Estou empolgado com o Github Copilot, sabe. kkk Compartilho aqui um repositório no Github que criei, após as dicas matadoras do Rafael Bonaldi .

Fiz uma PoC em Python bem simples no VS Code com apoio do copilot, para remover o fundo de imagens via linha de comando (CLI). Foi uma oportunidade para avaliar a pair programming com o copilot em ação.

Como o copilot ajudou?

Pedi via chat para ele fazer a geração do código do arquivo script.py para remover o fundo de imagens, recebendo o nome do arquivo de entrada como parametro.

Daí eu pedi para ele explicar o código e as bibliotecas utilizadas. Depois pedi para ele comentar o código, fazer um code review e uma avaliação do ambiente com @workspace.

Na hora de rodar deu erro e eu pedi para explicar porque estava dando erro e ele sugeriu criar um ambiente virtual do python e explicou que precisava da chave de acesso à API da lib removebg. Entrei no site, baixei a chave e fiz as correções de acordo com as instruções dele e rodou. Gostei bastande e acho que é um apoio que melhora muito a produtividade.

Considero que o conceito foi provado. kkk O mais importante pra mim foi definir o objetivo e conseguir alcançar, com um código simples, útil, que eu consigo entender e que funciona. kkk

O código ficou assim:

import argparse
from removebg import RemoveBg

def remove_background(input_file):
    """
    Remove the background from an image file using the RemoveBg library.

    Parameters:
    input_file (str): The path to the input image file.
    
    Returns:
    None
    """
    try:
        rmbg = RemoveBg("< API KEY >", "error.log")
        rmbg.remove_background_from_img_file(input_file)
    except FileNotFoundError:
        print("The file is not found")
    except Exception as e:
        print("An error occured", e)

def main():
    """
    Parse command-line arguments and call the remove_background function.
    """
    parser = argparse.ArgumentParser(description='Remove background from image.')
    parser.add_argument('input_file', type=str, help='The image file to remove the background from.')
    args = parser.parse_args()
    remove_background(args.input_file)

if __name__ == "__main__":
    main()

Segue o link do repositório: https://github.com/adrianotavares/copilot

Quem quiser colaborar e criar outras funções para tratamento de imagens, manda bala e depois comenta aqui como o assistente ajudou!

Mas tem de usar o copilot ou outra ferramenta, porque o objetivo da PoC é testar a pair programming com assistentes de IA, blz?

Let’s code!

O software devorou o mundo e a IA está digerindo

Em um famoso artigo do Wall Street Journal de 2011, Marc Andreessen explicou por que naquela época o software estava devorando o mundo. A evolução acelerada da tecnologia de software impulsionava o crescimento dos negócios digitais. Seguindo os exemplos dos gigantes da Internet, algumas empresas da velha economia estavam se moldando como empresas de tecnologia.

Vamos voltar um pouco mais… Em 2002, a Amazon enfrentou uma barreira de complexidade. O tamanho de sua página inicial atingiu 800MB e levava de 8 a 12 horas para compilar. Jeff Bezos emitiu um mandato relativo a APIs, que mudou profundamente a forma como o software era criado e como a empresa era organizada.

  1. Todas as equipes deverão expor seus dados e funcionalidades por meio de interfaces de serviços.
  2. As equipes devem se comunicar entre si através dessas interfaces.
  3. Não será permitida qualquer outra forma de comunicação entre processos: sem links diretos, leitura direta do armazenamento de dados de outra equipe, sem modelo de memória compartilhada, nenhum tipo de backdoor. A única comunicação permitida é por meio de chamadas de interface de serviço pela rede.
  4. Não importa qual tecnologia seja utilizada. HTTP, Corba, Pubsub, protocolos personalizados – não importa.
  5. Todas as interfaces de serviço, sem exceção, devem ser projetadas desde o início para serem externamente acessíveis. Ou seja, a equipe deve planejar e projetar de forma a poder expor a interface para os desenvolvedores do mundo externo. Sem exceções.
  6. Aqueles que não seguirem esta regra serão demitidos.
  7. Obrigado; tenha um bom dia!

Ao mudar para a modularidade com APIs, a Amazon se posicionou bem para abrir suas capacidades de distribuição e logística para fornecedores terceirizados. A natureza de autoatendimento da plataforma facilitou para os fornecedores venderem e distribuírem seus produtos eliminando atritos. Isso ajudou a Amazon a competir contra o eBay, alavancando um modelo de negócio diferente.

Desde aquela época o software e o hardware representam uma parte crescente dos produtos e de suas operações de suporte. A arquitetura de software, a arquitetura de produto e a arquitetura de operações devem ser estruturadas de maneira simultânea.

Neste cenário em constante mudança, é essencial que as empresas se adaptem e inovem, reconhecendo o papel cada vez mais importante que o software desempenha em todos os aspectos de suas operações. Afinal, como Andreessen apontou, o software estava realmente devorando o mundo e a Inteligência Artificial (IA) nesse momento está fazendo a digestão. kkk

A IA é a força motriz por trás da transformação digital, permitindo que as empresas processem grandes volumes de dados e obtenham insights valiosos. Ela está automatizando tarefas, otimizando processos e possibilitando novos modelos de negócios. A IA está mudando a maneira como interagimos com o software, tornando-o mais intuitivo, personalizado e eficiente. Assim, a IA não apenas ajuda o software a ‘devorar’ o mundo, mas também a ‘digeri-lo’, transformando dados brutos em informações úteis e acionáveis que impulsionam o progresso e a inovação.

Avançando ainda mais nessa discussão, a IA generativa ocupa um lugar de destaque nesse processo de “digestão”. Esse ramo da IA, que inclui modelos de linguagem como ChatGPT, tem a capacidade de gerar novos conteúdos a partir de dados existentes. Isso significa que a IA generativa pode criar desde artigos e relatórios até designs de produtos e códigos de software, ampliando ainda mais o alcance e a eficiência do software. Além disso, a IA generativa pode aprender e se adaptar a estilos específicos, permitindo uma personalização sem precedentes.

Nesse sentido, a IA generativa não só contribui para a “digestão” do mundo pelo software, mas também para a sua “metabolização”, transformando dados em novas formas de criação e inovação.

A liberdade na agilidade

Vamos mergulhar no mundo do Disciplined Agile (DA), uma abordagem híbrida e agnóstica que combina centenas de estratégias e práticas do Agile, Lean e tradicionais para orientar você a encontrar o seu WoW (Way of Working) a melhor maneira para seu time ou organização trabalhar. Esse post está recheado de links que direcionam para assuntos específicos no site do Disciplined Agile. Tem muito conteúdo bacana e útil lá. Aproveite!

DA é sobre ser pragmático e reconhecer que existem ótimas ideias tanto na comunidade Agile quanto na comunidade tradicional. Devemos mostrar um pouco de humildade e respeitar pelo fato de que a comunidade tradicional construiu muita coisa boa e tinha algumas ideias ótimas.

A verdadeira agilidade vem da liberdade, não de um único framework

O DA é um Toolkit e não um framework! É uma caixa de ferramentas que permite a você escolher e evoluir uma forma de trabalhar adequada ao seu propósito, que seja a melhor para você, dada a situação que está enfrentando. Em vez de prescrever um conjunto de “melhores práticas”, o DA ensina como escolher e evoluir um WoW baseado em praticamente todos os frameworks mais populares, incluindo XP, Scrum, Kanban e SAFe.

Scott Ambler, um dos criadores do DA, enfatiza que é preciso permitir que os times evoluam seu ciclo de vida ao longo do tempo. Por exemplo, um time que começa com o ciclo de vida ágil (Agile Lifecycle) baseado em Scrum pode começar a adotar maneiras mais enxutas (Lean Lifecycle) de trabalhar, com práticas do Kanban e práticas de integração contínua e implantação contínua (Disciplined DevOps), e eventualmente evoluir para um ciclo de vida de entrega contínua ágil ou lean (Continuous Delivery Agile Lifecycle / Continuous Delivery Lean Lifecycle).

Ele reforça que, DA é sobre fazer escolhas inteligentes e experimentar práticas para ver o que funciona melhor para o time e que eles experimentem uma prática por algum tempo para ver se ela realmente funciona bem para eles.

Por que ágil disciplinado?

Sobre isso, Scott Ambler, destaca que o ágil disciplinado é necessário porque cada time é único e enfrenta uma situação única, portanto, precisa ter sua própria maneira de trabalhar e as organizações precisam permitir e habilitar os times, para obter a verdadeira agilidade.

  • O DA começa onde você está. Sua organização fez um grande investimento em sua maneira atual de trabalhar (WoW), e com o DA você pode evoluir sobre esse investimento.
  • O DA permite que você melhore cada vez mais. O DA está focado em ajudá-lo a aprender e transformar sua organização em uma organização que aprende, através da melhoria contínua guiada. Ao invés de simplesmente fornecer uma coleção de “melhores práticas” que podem não ser aplicáveis ao contexto da sua organização.
  • O DA fornece uma base sólida para a agilidade organizacional. Pessoas e times em toda a sua organização, independentemente da função de negócios, podem se beneficiar de orientações diretas para otimizar seus processos. O DA aborda toda a empresa, não apenas o desenvolvimento de software.
  • A maneira de pensar ágil disciplinada do DA, é capturada na forma de princípios, promessas e diretrizes. Os agilistas disciplinados acreditam nesses princípios, por isso adotam esses comportamentos e seguem essas diretrizes de maneira sensível ao contexto.

Verdadeira agilidade em escala

Os frameworks ágeis em escala tendem a ter uma visão bastante estreita do que significa agilidade em escala, escolhendo focar na agilidade de um programa para o desenvolvimento de um produto baseado em software ou na aplicação da agilidade em todos (ou pelo menos na maioria) dos times de software de sua organização. Embora esse seja um bom ponto de partida, ele claramente não é suficiente. O que dizer dos times que não estão focados no desenvolvimento de software? E os times que estão em situações mais simples?

O contexto importa

O Disciplined Agile (DA) fornece orientações diretas para ajudar as organizações a otimizar seus processos de maneira sensível ao contexto, fornecendo uma base sólida para a agilidade dos negócios, fornecendo maneiras de avaliar os fatores que impactam a escalada da agilidade no contexto da sua organização.

Fonte: A Solid Foundation for Business Agility with Disciplined Agile https://www.pmi.org/disciplined-agile/

Para saber mais: Faça os cursos oficiais de Disciplined Agile com a JUMP http://jump.bhz.br

Arquitetura Ágil na Era Digital: Desafios e Vantagens

Na era digital em constante evolução, a arquitetura ágil emerge como uma abordagem revolucionária para impulsionar a inovação e a entrega contínua. Com a comunicação assíncrona e o uso de microserviços, essa abordagem desafia as limitações impostas pelas antigas práticas de compartilhamento de bancos de dados e bibliotecas. Neste post, vou explorar os desafios e vantagens da arquitetura ágil e como ela está moldando o cenário atual. Vamos juntos!

A arquitetura ágil na era digital se baseia na comunicação assíncrona, em que mensagens ou eventos conectam serviços por meio de protocolos eficientes, como o de publicação e assinatura. Essa abordagem rompe com as práticas antigas de compartilhamento de bancos de dados e bibliotecas, permitindo maior flexibilidade e independência entre os serviço

Uma das principais vantagens da arquitetura ágil é a liberdade na escolha das ferramentas e da stack de desenvolvimento. Sem restrições impostas por padrões tecnológicos obsoletos, a inovação ganha espaço para florescer. As equipes têm a autonomia de decidir quais ferramentas utilizar, resultando em uma entrega contínua mais eficiente e alinhada com as necessidades do negócio.

Além disso, os serviços podem ser testados e implantados de forma isolada, facilitando uma implementação rápida e contínua. A capacidade de containerizar facilmente esses serviços contribui para agilizar ainda mais o processo de implantação e permite uma escalabilidade mais eficiente.

No entanto, a decomposição de um domínio em serviços requer um profundo conhecimento dos fluxos de valor, para delimitar os domínios de negócio. A exposição de APIs eficientes e escaláveis é um desafio crucial nesse processo. Aqui é onde entra o “Domain-Driven Design” (DDD) de Eric Evans, uma abordagem amplamente adotada que oferece um conjunto de processos e práticas para modularização eficaz de sistemas complexos.

A arquitetura ágil está transformando a maneira como as empresas desenvolvem e entregam software na era digital. Ao romper com as práticas tradicionais, ela proporciona maior flexibilidade, autonomia e eficiência no processo de desenvolvimento. No entanto, é importante lembrar que não existe uma abordagem única para todos os casos. O conhecimento do contexto e a compreensão das necessidades do negócio são, mais do que nunca, os fatores críticos para o sucesso.

Para saber mais:
The Open Agile Architecture™ Standard https://publications.opengroup.org/c208
DDD Crew https://github.com/ddd-crew

Os 7 princípios do Lean para desenvolvimento de software e os mitos que você deve evitar com todas as forças

O Lean tem se tornado cada vez mais popular no desenvolvimento de software entre as empresas que buscam entregar produtos com alta qualidade e valor aos clientes.

No entanto, ainda existem muitos mitos e equívocos que podem prejudicar o sucesso dos times ágeis. Nesse post, vamos desmistificar os mitos relacionados aos 7 princípios do Lean para desenvolvimento de software, que você deve evitar com todas as forças.

Vou citar cada um dos princípios do Lean e um mito relacionado a ele. Ao seguir os princípios do Lean, as equipes de desenvolvimento podem alcançar resultados significativos em termos de eficiência e satisfação do cliente.

Então, vamos lá!

Princípio 1: Eliminate Waste (Eliminar Desperdício)

Mito: Mais especificações no início do projeto reduzem o desperdício.

Alguns times acreditam que ter muitas especificações no início do projeto pode ajudar a eliminar o desperdício, pois todas as necessidades e requisitos já estarão documentados. No entanto, isso pode levar a uma abordagem de “big design upfront”, que pode levar a muitas especificações desnecessárias ou imprecisas, desperdiçando tempo e recursos.

Princípio 2: Build Quality In (Construir a Qualidade):

Mito: Testadores são responsáveis por encontrar defeitos.

Muitos times acreditam que é responsabilidade dos testadores encontrar e corrigir defeitos. No entanto, o objetivo do Lean é construir a qualidade desde o início, o que significa que todos os membros da equipe devem se esforçar para prevenir defeitos e encontrar soluções antes que eles aconteçam. Ressalto que bug, ou seja defeito, o que foi reportado depois de estar em produção. Os chamados “bugs internos” são acertos e parte do desenvolvimento.

Princípio 3: Create Knowledge (Criar Conhecimento):

Mito: Conhecimento é criado somente através de documentação.

Alguns times acreditam que criar documentação é a única forma de criar conhecimento, mas o Lean enfatiza a importância de aprendizado contínuo e comunicação efetiva. O conhecimento é criado através de experimentação, feedback e conversas entre membros da equipe.

Princípio 4: Defer Commitment (Adiar Compromisso):

Mito: Planejar é comprometer-se.

Alguns times acreditam que fazer um plano detalhado é se comprometer a seguir esse plano. No entanto, o Lean enfatiza a flexibilidade e a adaptação às mudanças. Em vez de se comprometer com um plano detalhado, a equipe deve se comprometer com os objetivos do cliente e trabalhar para entregá-los da melhor maneira possível.

Princípio 5: Deliver Fast (Entregar Rápido):

Mito: Pressa gera desperdício.

Alguns times acreditam que ter pressa para entregar o software pode gerar desperdício, pois não há tempo suficiente para fazer as coisas corretamente. No entanto, o objetivo do Lean é entregar valor ao cliente o mais rápido possível, sem sacrificar a qualidade. Isso significa que a equipe deve trabalhar de forma eficiente para entregar valor em ciclos curtos e frequentes.

Princípio 6: Respect People (Respeitar as Pessoas):

Mito: Trabalhar mais horas é a melhor forma de aumentar a produtividade.

Alguns times acreditam que trabalhar mais horas é a melhor forma de aumentar a produtividade. No entanto, o Lean enfatiza a importância de respeitar as pessoas e seus limites. Trabalhar excessivamente pode levar a problemas de saúde e estresse, o que pode diminuir a produtividade e a qualidade do trabalho.

Princípio 7: Optimize the Whole (Otimizar o Todo):

Mito: Otimizar partes individuais leva à otimização do todo.

Otimizar partes individuais do sistema não é suficiente para tornar todo o sistema eficiente, pelo fato das partes individuais estarem interligadas e afetarem umas às outras. Se apenas uma parte do sistema for otimizada, outras partes podem ser até prejudicadas, o que pode levar a problemas no sistema como um todo.

Bom, pra finalizar, é fundamental estar ciente desses mitos e trabalhar para superá-los, a fim de obter o máximo benefício do Lean no desenvolvimento de software.

Para saber mais…

Os mitos e princípios Lean foram extraídos do livro Implementing Lean Software Development, Mary and Tom Poppendieck, o meu livro preferido sobre Lean aplicado ao desenvolvimento de software em times ágeis.

Esses princípios fazem parte do treinamento DASM – Disciplined Agile Scrum Master da jornada ágil do PMI. Eu sou o instrutor desse treinamento pela JUMP TREINAMENTO PROFISSIONAL.

Mais informações sobre o Preparatório DASM da JUMP: https://www.jump.bhz.br/dasm

Agile na Capital One: a polêmica sobre as demissões

Capital One

Primeiro vamos aos fatos.

Conforme anunciado pela Bloomberg em 19 de janeiro de 2023, e no The Register em 20 de janeiro de 2023 a Capital One cortou, entre outros cargos de tecnologia, alguns papéis de agilidade como Agile Coaches, Scrum Masters.

Vejamos alguns trechos de declarações da empresa:

“Em 19 de janeiro, a Capital One cortou 1.100 cargos de tecnologia, disse uma fonte familiarizada com o assunto à Bloomberg – a Capital One não confirmou o número de cargos que seriam cortados, embora um porta-voz tenha dito à Forbes que os funcionários afetados foram informados de que poderiam se candidatar a outras funções na empresa.”

A empresa disse ao The Reg que sua organização de tecnologia “não estava se afastando do Agile e continuará a usar metodologias Agile para entregar software”, acrescentando: “essa mudança reflete como os processos ágeis se tornaram parte de nossas principais práticas de engenharia.“

“O papel Agile em nossa organização de tecnologia foi fundamental para nossas fases de transformação anteriores, mas conforme nossa organização amadureceu, o próximo passo natural é integrar os processos de entrega ágil diretamente em nossas principais práticas de engenharia.”

“Com a mudança desta semana, a empresa está eliminando cargos focados na chamada Agile Delivery de tecnologia. Em vez disso, espera-se que engenheiros e gerentes de produto usem rotinas ágeis naturalmente.”

“A Capital One continua comprometida em recrutar os melhores talentos, incluindo investimentos contínuos no recrutamento de novos profissionais e contratações de campus. Nossa organização de tecnologia está recrutando ativamente para uma variedade de posições, incluindo funções de engenharia focadas em nuvem, dados, aprendizado de máquina e segurança cibernética, bem como como Gerentes de Produto.”

Acredito que no caso da Capital One especificamente, nao se trata de estarem demitindo o Agile da empresa. Como foi dito, eles estão reestruturando após uma primeira transformação ágil, talvez “by the book”, para que nessa próxima fase a agilidade esteja mais integrada a todos os processos e ao Gerenciamento de Produtos.

Confesso que fiquei curioso em conhecer mais a fundo essa nova fase e não me parece um enfraquecimento da agilidade. pelo contrario. Vejo que é um ganho de consciência, um entendimento do contexto da empresa com o objetivo de criar um sistema de trabalho que funcione melhor, mais alinhado ao negócio dela.

Essa consciência corporativa é um dos princípios importantes para o sucesso das iniciativas de transformação ágil nas organizações.

Big Techs estão demitindo

É fato. A Forbes publicou uma lista dos layoffs das BIG TECHs em 2023. Isso inclui IBM, Microsoft, Google, Spotify, Amazon, Facebook (Meta) entre outras outras.

Nesse cenário mais amplo de demissões, minha opinião é que estamos em um momento de recessão pós-COVID, que desencadeou reduções de quadros em diversas Big Techs e não me parece que termina por aqui. A maior motivação é à diminuição da demanda por serviços digitais após a pandemia, devido ao término dos períodos de lock-down pelo mundo.

Portanto, como é fato que não é apenas a Capital One que está demitindo e essas demissões não me parecem focadas em um ponto específico passando longe de ser culpa do Agile, sejamos mais coerentes e vamos olhar para o futuro. Essa polêmica não tem fundamento.

Acredito que as empresas que fizeram o para-casa, se transformando rumo a agilidade de negócios, tem um modelo operacional ágil com mais capacidade de responder às oscilações do mercado nesse momento de recessão.

E você, o que vc acha?

Workshop e palestra no CBGPL 2019

No mês de maio tive a honra de participar do XIV Congresso Brasileiro de Gestão, Projetos e Liderança 2019 em Campinas a convite do capítulo PMI de São Paulo, rodando um workshop e uma palestra.

No Workshop de Kanban  aplicamos os princípios e práticas do Kanban para um grupo de 32 pessoas. O workshop foi bem divertido com participação ativa do pessoal.

A palestra foi sobre Transformação ágil. O assunto foi apresentado para um grupo grande de líderes que escolheram a minha apresentação dentre tantas outras que aconteciam no mesmo horário.

Agradeço ao time do PMI São Paulo pelo convite e parabenizo pelo evento de alto nível e pela organização impecável.

Segue o link da apresentação:

 

Arquitetura Ágil = Design Emergente + Arquitetura Intencional

Metodologias de desenvolvimento tradicionais costumam usar Big-Design-Up-Front (BUFD) para criar uma infra-estrutura de roadmap arquitetônico destinado a atender plenamente as necessidades do futuro sistema. A crença é que um esforço único no início poderia capturar requisitos e planos arquitetônicos suficientes para suportar o sistema para os próximos anos.

No entanto, esta abordagem vem com muitos desafios. Um deles é o delay no início da execução. Um outro desafio surge quando a arquitetura planejada, que possui um conjunto grande de especulações, se encontra com o mundo real. Pouco tempo é suficiente, para que os desenhos se tornem frágeis e difíceis de mudar e eventualmente surge um Big-branch-and-merge para que um novo conjunto de suposições especulativas seja colocado em ação. Para endereçar esses desafios combinamos o design emergente e a arquitetura intencional, impulsionados pela colaboração.

Design Emergente

O princípio 11 do Agile Manifesto é o principal motor por trás do conceito de design emergente: “As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.” As implicações disso são:

  • O design é cultivado de forma incremental por aqueles que estão mais próximos a ele.
  • O projeto evolui de mãos dadas com a feature de negócios. Ele é constantemente testado e ativado por refatoração, TDD e integração contínua.
  • Equipes evoluem rapidamente o projeto de acordo com os requisitos atualmente conhecidos; o projeto é estendido somente conforme necessário para implementar e validar o próximo incremento de feature.

Esta nova prática de design emergente é eficaz no nível de equipe. No entanto, o design emergente por si só é insuficiente para o desenvolvimento de grandes sistemas.

  • Ele pode causar redesenho excessivo para coisas que poderiam ter sido antecipadas.
  • Equipes nem sempre são capazes de sincronizar com as outras, criando assim uma entropia de suposições e divergência de arquitetura.
  • As equipes podem mesmo não estar cientes de algumas das necessidades futuras de negócios maiores; fatores fora de seu alcance que direcionam a necessidade da arquitetura futura.
  • Bases comuns de arquitetura melhoram a usabilidade, extensibilidade, desempenho e manutenção de um sistema de sistemas maior.
  • Novos, padrões do usuário transversais afetam o propósito futuro da arquitetura.
  • Fusões e aquisições direcionam integrações e a necessidade de padronização da infra-estrutura.

Arquitetura Intencional

Portanto, chega um ponto em que o design emergente é uma resposta insuficiente à complexidade do desenvolvimento de sistemas em larga escala. Simplesmente, não é possível para as equipes se antecipar às mudanças que podem muito bem ocorrer fora do seu ambiente. Também não é possível para as equipes individuais entenderem completamente todo o sistema e, assim, evitar a produção de código e design redundante e ou conflitantes. Para isso alguma arquitetura intencional é necessária – um conjunto de iniciativas de arquitectura intencional, planejado para aumentar o design da solução, desempenho e usabilidade e fornecer orientação para o projeto entre as equipes e sincronização da implementação.

Arquitetura é uma colaboração

Claramente, é melhor ter ambos: rápido, controle local do design emergente e uma visão global da arquitetura intencional. A combinação, proporciona a orientação necessária para assegurar que o sistema como um todo tenha integridade conceitual e eficácia. Alcançar o equilíbrio certo de design emergente e arquitetura intencional impulsiona a evolução eficaz do sistema, como mostrado no diagrama desse post. 

O diagrama mostra que eles não são construções independentes. Arquitetura intencional restringe o design emergente, mas a um nível suficientemente elevado de abstração para permitir que as equipes possam se adaptar eficazmente a parte “intencional” para seu contexto específico. Ao mesmo tempo, influências e design emergente corrigem a arquitetura intencional e também alimentam novas ideias para o futuro, centralizando o esforço intencional.

Tal reciprocidade profunda entre design emergente e arquitetura intencional só pode ocorrer como resultado da colaboração entre as equipes ágeis, arquitetos de sistemas e gestores de produto.

Fonte: SAFe

 

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

  • Guiar a criação e evolução da arquitetura da solução.
  • Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
  • Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
  • Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
  • Garantir que o sistema seja testado e integrado frequentemente.
  • Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
  • Lidera o esforço de visualização inicial da arquitetura.
  • Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Enterprise Agile

Como ponto de partida o Scrum é um excelente método ágil. No Brasil ele abre as portas das empresas para a agilidade. Isso se dá pela sua grande difusão entre os profissionais de gerenciamento de projetos nas áreas de TI. Agora, quando as empresas começam a levar o agile para um patamar corporativo o Scrum sozinho se mostra insuficiente.

Na prática, para uma abordagem corporativa é necessário recorrer a outros métodos para preencher os gaps de processo que o Scrum não trata. É aí que surgem as dificuldades. Quando as empresas começam a olhar para outros métodos surge o conflito de terminologias e a sobreposição de conceitos. Isso gera uma certa confusão na hora de definir e instalar esse novo processo. Faltam elementos para integrar o agile com as estratégias de governança das empresas.

Nesse contexto surgiu o Disciplined Agile Delivery (DAD). O DAD é uma abordagem híbrida que faz a “costura” de diversos métodos no formato de um framework de decisão. Esse framework te ajuda a definir o processo mais adequado de acordo com o contexto e a cultura organizacional da sua empresa. Diferente do Scrum, o DAD considera que existe um ecossistema corporativo e ele não pode ser ignorado.

O DAD estende o Scrum com estratégias do Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Lean Software Development, SAFe entre outros. Ele aborda práticas técnicas como Continuous Delivery, TDD, arquitetura, modelagem e também documentação e governança, fornecendo alternativas que aumentam a chance de você adotar estratégias que funcionem no seu contexto. Se você tem interesse em DAD entre em contato comigo. Vamos bater um papo.

Para mais informações acompanhe o blog Disciplined Agile Delivery. Para saber mais sobre treinamentos e certificações acesse o site do Disciplined Agile Consortium.