Ainda estou aqui, chefe...

Fala pessoal,

Update rápido só para a galera saber que ainda estou vivo hehe.

Estou com a agenda super atribulada e (obviamente) sem tempo para postar como eu gostaria por aqui. Tenho que dividir o tempo entre o trabalho na CETIP, as aulas no INFNET, os estudos e ainda (é lógico) dar a devida atenção para amigos e família. Não é fácil não...

Fiquem de olho no que está por vir:

- De 13 a 17 de Dezembro ocorre a Semana de Engenharia de Software no Infnet. Vou palestrar 2 dias sobre métodos ágeis e suas implicações para o futuro do desenvolvimento de software. Entrem no link do evento e chequem as datas.


- Tem artigo meu sendo publicado na próxima edição da Java Magazine (Ed 86). Faço uma comparação bem interessante entre dois patterns que uso bastante no dia a dia: SPECIFICATION [EVANS] e STRATEGY [GOF]. Vale dar uma conferida...


- Estou preparando um material bem legal sobre Agile e CMMI, fruto das minhas pesquisas na pós e embrião para os trabalhos de mestrado. Quem se interessar pelo assunto é só entrar em contato comigo por email ou aqui diretamente.


Grande abraço a todos e até breve.

O que é SOA, afinal?

Um assunto um tanto delicado, ainda não debatido aqui no blog, é a respeito de SOA - Service Oriented Architecture. Tanto DDD quanto SOA são assuntos relativamente novos. Porém, enquanto o primeiro está bem definido e estabelecido na comunidade de desenvolvimento de software, o segundo ainda carece de alguns padrões que unifiquem as diferentes visões que existem sobre a técnica. Este post é o início da minha colaboração (meus 2 cents).

Definição

Definir SOA é complicado. A maioria das definições é baseada na ideia de sistemas compostos por serviços independentes. Entretanto, o que exatamente constitui um serviço não está claro. O que não resta dúvida é o fato de SOA ser uma forma arquitetural de se desenvolver software, forma guiada pela reutilização e compartilhamento entre aplicações e componentes. Nas palavras do mestre Udi Dahan:

Specifically, SOA deals with systems or applications that are, or can be, distributed. The acknowledgment that distribution is a primary architectural issue is one of the underlying currents of SOA.

O software que precisa rodar em um ambiente distribuído tem de ser projetado de forma diferenciada. As layers e tiers no mundo SOA são unificadas em "serviços", que são ao mesmo tempo unidades de design e de deployment. Enquanto que numa arquitetura tradicional  não há restrição em como essas camadas irão se comunicar, em SOA os serviços devem se comunicar de acordo com padrões de mensagens definidos por um schema (ou contrato).

O que é um Serviço?

Muito da literatura existente hoje foca em descrever propriedades (e princípios) dos serviços em vez de definir o que um serviço é de fato. Na essência, sabemos que a classe que implementa determinado serviço deve ser desacoplada dos clientes que evetivamente a consomem. Isso é bem diferente dos ambientes Java RMI, COM e .NET remoting, onde o cliente precisa explicitamente referenciar tipos específicos de plataforma. 

Vejamos então os princípios fundamentais de um serviço:

- Serviços são autônomos: autonomia significa a capacidade de se autogovernar, um serviço autônomo é aquele que independe de um elemento externo para executar sua lógica.

- Serviços têm fronteiras bem definidas: essa definição está lado a lado com o princípio da autonomia; torna claro onde um serviço termina e outro começa.

- Serviços abstraem a lógica: serviços devem ser tratados como uma caixa preta, assim como componentes de um sistema. Assim sendo, a programação neles inclusa pode ser substituída a qualquer momento, sem afetar aqueles que o consomem.

- Serviços expõem schema e contratos, não classes ou tipos: contratos são documentos textuais que descrevem o que o serviço faz, os padrões WSDL (Web Service Description Language), UDDI (Universal Description Discovery and Integration) e SOAP (Simple Object AccessProtocol) são muito utilizados no dia a dia.

- Serviços são reutilizáveis: um serviço reutilizável é aquele que não carrega particularidades técnicas de uma implementação ou regras de negócio específicas e é genérico o suficiente para atender outros projetos. 

OO e SOA

Segundo Udi Dahan, apesar de muitos terem previsto que SOA seria a próxima geração do desenvolvimento de aplicações - com a consequente substituição do padrão OO atual - nada  significativo realmente aconteceu. Na verdade, SOA e OO trabalham em diferentes (e complementares) níveis. OO lida com design e código de uma única deployment unit enquanto SOA lida com múltiplas deployment units. Dahan nos explica:

SOA does not suggest new or alternate ways of designing or coding the internal logic of a given application or service. There is no reason SOA and OO should not be  cooperative technologies.

Princípios fundamentais de OO como separation of concerns e dependency inversion estão presentes na construção de aplicações service oriented, tanto na arquitetura externa como na construção interna de seus serviços. SOA é complementado por OO; não é a evolução do OO. No entanto, podemos considerar SOA como a evolução da arquitetura distribuída de componentes.

Conclusão

Há vários anos que SOA é assunto nas rodas de TI. Apesar de haver muito barulho em torno do tema, não há dúvida de que é um conceito interessante e uma técnica atraente para construção de componentes (serviços) reutilizáveis. SOA e OO não são incompatíveis. Em muitos níveis OO fornece insights válidos para construção de serviços robustos e independentes de plataforma. Para os que se interessaram pelo tema, sugiro a leitura e pesquisa para atualização da visão atual da técnica, muita coisa têm mudado a respeito do tema nos últimos anos. Voltarei posteriormente com o assunto aqui no blog.

Palestra na Rio Info 2010

Fala Pessoal,
Tudo bem?

Estarei fazendo uma oficina na Rio Info 2010, junto com meu amigo e mestre Armênio Cardoso, nessa próxima quarta-feira, dia 01/09/2010. Vamos abordar a construção de um aplicativo Java Mobile utilizando o Agile como pano de fundo.

Quem quiser ir na oficina me avise aqui no blog (ou por email) que eu envio a senha para efetivar o convite. Temos um limite de convidados que podemos chamar.

Cliquem aqui para saber mais sobre a oficina e sobre a Rio Info 2010.

Abraços,

Os limites do Agile

Quais são os limites para o desenvolvimento ágil de software? Essa é, provavelmente, uma pergunta que passa pela cabeça de muitas pessoas (inclusive na minha). Infelizmente, não há respostas fáceis para essa questão e, para piorar um pouco, há alguns mal entendidos clássicos a respeito do tema, que ofuscam a nossa mente, e que eu gostaria de ajudar a esclarecer.

Muitos profissionais do nosso meio (desenvolvedores, professores, conferencistas, etc) têm as seguintes ideias (a meu ver equivocadas) sobre Agile:

- É bacana, mas apenas para projetos de pequeno porte.

- Tem a desvantagem de produzir código de baixa reusabilidade.

- Agile e modelos de qualidade são excludentes entre si.

Creio que essas ideias surgem pois tais pessoas têm uma visão muito pequena sobre a realidade da cultura ágil atual. A maioria delas olha para os processos individualmente, como se Agile fosse SCRUM ou XP ou LEAN ou FDD ou WHATEVER. Ora, nenhum profissional sério acredita que qualquer um desses métodos irá, sozinho, resolver todos os problemas e situações que o moderno desenvolvimento de software exige. Realmente nenhum deles tem esse poder. Agile é algo bem mais abrangente do que isso...

Agile é um conjunto de práticas, processos, ferramentas, princípios e valores que formam um arcabouço útil para desenvolver projetos de qualquer porte. É pura Engenharia de Software. Duvida? O SEI, criador do CMMI, não. Publicou um relatório convocando a comunidade de qualidade de software a utilizar práticas ágeis para atender as áreas de processo do modelo CMMI. O título é: "CMMI or Agile: Why not embrace both?". Sugestivo, não?

As técnicas mais quentes da Engenharia de Software atual estão presentes nos métodos ágeis. TDD, DDD, integração contínua, automação do desenvolvimento e testes, cliente on-site, time-boxed iterations, desenvolvimento iterativo, etc. Todas essas técnicas nasceram no seio das comunidades ágeis e estão sendo consumidas por todos os tipos de projetos (os grandes inclusive rs).

Acredito que o que falta para o Agile conseguir mais respeito nas rodas "intelectuais" do mundo do software é um maior número de links entre a Engenharia de Software e as técnicas e práticas ágeis mais utilizadas. Algo que da minha parte pretendo contribuir com a minha futura dissertação de mestrado.

DDD e EJB 3.0

DDD é uma técnica poderosa para se construir software focado no negócio da organização e apoiado na linguagem corrente dos que irão utilizar o sistema. Dessa forma, o aplicativo é construído de "dentro para fora", permitindo que regras de negócio sejam implementadas (e testadas) bem antes da construção das outras camadas e partes importantes do sistema como telas, controles e bancos de dados.

Em algum momento, teremos que implementar funcionalidades para outras camadas  e alguns serviços essenciais como controle de transações, object pool, injeção de dependência, persistência dos objetos de domínio, etc. Nesse post vou apresentar uma ideia geral de como poderíamos realizar essas tarefas de modo bem simples usando EJB 3.0.

Antes de tudo uma observação: se você (como eu) odeia as complexidades e complicações do EJB 2.0 e torceu o nariz no instante que leu o título desse post, saiba que a versão 3.0 é completamente diferente da anterior. Os session beans e entidades JPA são agora objetos leves e que permitem (entre outras coisas) que sejam testados fora do container que os gerencia. Se você gosta da ideia de trabalhar segundo as premissas de Eric Evans e curte criar POJOs para resolver seus problemas então EJB 3.0 é a ferramenta perfeita para suas necessidades.

Primeiramente, vamos criar uma interface genérica para nossos repositórios:

@Local
public interface Repositorio<T> {
   
    List<T> buscarTodos();

    T buscarPorID(int id);

    void add(T object); 

    void remove(T object);

    void update(T object);
}

Não fosse pela anotação @Local poderíamos dizer que essa seria uma interface comum escrita em Java. Aquela anotação diz que essa interface permitirá acesso a uma referência de um session bean que reside na mesma máquina que o container web. Caso precisássemos de acesso remoto, bastaria anotar a interface com @Remote para termos acesso a um enterprise bean residente em outro servidor.

Vamos agora implementar a interface Repositorio em uma classe RepositorioDeClientes:

@Stateless
public class RepositorioDeClientes implements Repositorio<Cliente> {

    @PersistenceContext()
    private EntityManager entityManager;

    public List<Cliente> buscarTodos() {

        Query query = entityManager.createQuery("select c from Cliente c");
        return query.getResultList();

    }

    public void remove(Cliente object) {

            entityManager.remove(entityManager.merge(object));
    }

    public Cliente buscarPorID(int id) {

        Cliente cliente = entityManager.find(Cliente.class, id);
        return cliente;
    }

    public void add(Cliente object) {

            entityManager.persist(object);
    }

    public void update(Cliente object) {

            entityManager.merge(object);
    }
   
}

RepositorioDeClientes é uma classe POJO normal, transformada em um poderoso session bean sem estado através da anotação @Stateless. O container gerencia um pool de objetos RepositorioDeClientes para servir aos usuários de seus serviços - usuários dessa e de outras aplicações. Além disso, usamos o recurso de dependency injection com a anotação @PersistenceContext, que serve para injetar um objeto EntityManager, elemento JPA responsável em gerenciar o provider OR/M usado na camada de infra-estrutura.

JPA, através da interface EntityManager, gerencia as entidades marcadas com a anotação @Entity fornecendo serviços de  persistência para os objetos. Funciona como um "guarda-chuva" para os diversos providers de mapeamento objeto relacional existentes no mercado como TopLink e Hibernate (para o exemplo o provider utilizado foi o Hibernate).

Anotando a entidade cliente:

@Entity
@Table(name="CLIENTES")
public class Cliente implements Serializable {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    @Column(name="CLIENTE_ID", nullable=false)
    protected int clienteID;

    @Column(name="NOME", nullable=false)
    protected String nome = "";

    @Column(name="LOGIN", nullable=false)
    protected String login = "";

    @Column(name="EMAIL", nullable=true)
    protected String email = "";

    @Column(name="SENHA", nullable=false)
    protected String senha = "";

    @Column(name="TELEFONE", nullable=true)
    protected String telefone = "";

    @Embedded
    protected Endereco endereco;

    public Cliente() {
        this.endereco = new Endereco();
    }

    //getters, setters e outros métodos 

}

Várias anotações (como @Table, @ID e @Column) dão importantes informações ao JPA de como deve ser feito o mapeamento objeto-relacional de uma maneira fácil e segura. O mais interessante é que as anotações são ignoradas pela JVM fora do contexto do container EJB e do controlador de entidades JPA. Em outras palavras, podemos testar tudo sem a necessidade de um aparato complicado que certamente prejudicaria a testabilidade dos componentes (conceito caro para quem trabalha com TDD).

Com tudo isso pronto, poderíamos ter um servlet controlador com um código parecido com esse:

public class GerenciarClienteServlet extends HttpServlet {

    @EJB
    Repositorio repositorio;

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
    

        Cliente cliente = new Cliente();

        RequestDispatcher rd = null;

        try {
  
            //validações excluídas para melhorar a legibilidade
            cliente.setNome(request.getParameter("nome"));
            cliente.setLogin(request.getParameter("login"));

            //dados de endereco
            cliente.getEndereco().setRua(request.getParameter("rua"));
            cliente.getEndereco().setBairro(request.getParameter("bairro"));
            cliente.getEndereco().setCidade(request.getParameter("cidade"));
            cliente.getEndereco().setEstado(request.getParameter("estado"));

            cliente.setSenha(request.getParameter("senha"));
            cliente.setTelefone(request.getParameter("fone"));
            cliente.setEmail(request.getParameter("email"));

            repositorio.add(cliente);

            request.setAttribute("cliente", cliente);
            request.setAttribute("mensagem", "Cliente cadastrado com sucesso!");

            rd = request.getRequestDispatcher("/cadastroCliente.jsp");
            rd.forward(request, response);

        } catch (Exception e) {
           //gero log, direciono para página de erro, etc
        }

    }

A anotação @EJB injeta uma instância de RepositorioDeClientes e passa a controlar o seu ciclo de vida, facilitando muito o trabalho do desenvolvedor. Quem fica responsável pela criação do objeto é o  próprio container, que também se encarrega de sua destruição. O container irá criar um pool de objetos para otimizar o desempenho da aplicação. É importante observar que um servlet compartilha a mesma instância com vários clientes e por isso não devemos injetar um session bean @Stateful pois esse manterá o estado do objeto entre todas as requisições. Como nosso EJB do exemplo é  anotado com @Stateless podemos injetá-lo sem problemas.

Concluindo, nessa breve introdução, vimos como é viável trabalhar com um design limpo (orientado ao domínio e utilizando POJOs) e utilizar os recursos oferecidos pelo EJB de maneira fácil e descomplicada. A maior parte da "magia negra" do EJB é devida aos recursos oferecidos pelas anotações Java. Transformar uma classe em um poderoso enterprise bean apenas usando uma anotação @Stateless é simplesmente bom demais para ser ignorado.

Para saber mais: 

http://www.amazon.com/EJB-3-Action-Debu-Panda/dp/1933988347
http://www.amazon.com/Enterprise-JavaBeans-3-1-Andrew-Rubinger/dp/0596158025 (previsão 09/2010)

OO, eu?

Mesmo uma linguagem orientada a objetos, como Java ou C#, pode ser utilizada, de forma consciente ou não, para criação de programas com base no paradigma estruturado. Nesse paradigma é grande a quantidade de estruturas de controle (como IF, IF-ELSE e SWITCH) e repetição (FOR, DO/WHILE). A pergunta que fica é: programas escritos utilizando orientação a objetos não precisam de tais estruturas? Como ficariam essas situações no código? Vejamos...

POO é sobre design. É o design da aplicação que determina se ela está aderente à metodologia estruturada ou à metodologia de objetos.

É claro que mesmo nas aplicações OO sempre haverá a necessidade de seleções e decisões. A diferença está na forma e na quantidade que tais elementos aparecem. Utilizando polimorfismo, um método que receba um parâmetro do super-tipo, por exemplo, não precisará de teste condicional, pois a implementação concreta será decidida somente no momento da passagem do objeto.

Observe (em C#):

    //uma Classe qualquer
    public void CalcularSalarioFuncionario(Funcionario funcionario)
    {
        //Gerente ou Vendedor? Só na hora será decidido.
        decimal valor = funcionario.CalcularSalario();

        //continuacao do método
    }

Um bom design OO diminui a necessidade de estruturas condicionais e de controle, porém não a elimina por completo. O fato é que isso (a eliminação) não é necessário para se obter um bom design, que seja robusto, de fácil manutenção e flexível.

Ex: Repositorio (em Java)

    //Classe RepositorioDePedidos
    public List buscarPedidosPorClienteID(int clienteID) {

     List pedidosDoCliente = new ArrayList();

     if (pedidos !=null) {

           for (Pedido pedido : pedidos) {   
                
                 Cliente cliente = pedido.getCliente();            
     
                 //aqui seria melhor usar o método equals() sobrescrito
                 if (cliente.getClienteID == clienteID) {
                      pedidosDoCliente.add(pedido);
                 }
           }
      }

      return pedidosDoCliente;
    }     


Repare que o método buscarPedidosPorClienteID tem elementos de decisão, seleção e controle. Tal situação ocorre a todo momento dentro dos repositórios.


E como poderia ser um cliente desse repositório?


    //uma Classe de controle qualquer
    public void gerarListaDePedidos(int clienteID)
    {
        RepositorioDePedidos repositorio = new RepositorioDePedidos();

        List pedidos = repositorio.buscarPedidosPorClienteID(clienteID);

        //renderizo uma tela, gero um relatorio, etc
    }  


O consumidor da classe RepositorioDePedidos  dispõe de uma API útil para buscar pedidos de um determinado cliente, dado o seu ID. Ele não sabe como o método funciona (encapsulamento), sabe apenas que funciona. A classe é reutilizável (várias instâncias podem ser criadas), fortemente tipada (somente o tipo Pedido) e tem detalhes de implementação desconhecidos (classe concreta ArrayList).

Com essas características não temos dúvida que o código de exemplo é OO, mesmo com a presença de elementos fundamentais de programação.

Um bom design OO diminui a necessidade de estruturas condicionais e de controle. Patterns, polimorfismo e outras técnicas podem ser utilizadas para tornar o código melhor escrito.

Mais informações sobre sobre estruturas de controle em programas aqui.

Arquitetura para o DDD

Continuando a série sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicação de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.

Antes de mais nada, convém salientar que essa não deve ser vista como a única arquitetura que existe e que irá atender a todos os sistemas e situações do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.

As camadas são representadas como abaixo:

Explicação sobre as camadas:

É importante dizer que não considero a camada Application como mandatória; ela é criada apenas se realmente adicionar valor à aplicação. Como a camada Domain é bastante rica em funcionalidades, muitas vezes não é necessário implementar mais essa divisão.

A criação de um Domain Model  traz uma série de vantagens para aplicações de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se você utilizar DDD para um projeto, você provavelmente irá cogitar utilizar a mesma técnica para outros (mesmo para os pequenos)."

Um design focado na criação de um Domain Model tem melhor manutenção no longo prazo devido à clareza da relação entre o negócio e a implementação. Além disso, é uma importante ferramenta para evitar a duplicação de código. Também aumenta a testabilidade do sistema.

Pesquisa Agile.

Laurie Williams, uma professora da North Carolina State University, vem conduzindo uma pesquisa para descobrir quais as práticas e os princípios que são mais utilizados pelas equipes ágeis.

A pesquisadora também convida os participantes a repensarem os princípios e práticas, propondo sugestões de melhoria (quando aplicável). 

Vejam os cinco princípios considerados mais importantes até o momento:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

E as cinco práticas mais importantes:

1. Short iterations (30 days or less)
2. Continuous integration
3. “Done” criteria
4. Automated tests are run with each build
5. Automated unit testing

Você pode conferir as atualizações da pesquisa aqui.

Caso queira participar da pesquisa é só vir aqui.

Toque do Gênio

Na última segunda-feira, estive no seminário da PUC - Design de Software para o século XXI. A palestra principal era de Martin Fowler, um nome que dispensa apresentações. Basta dizer que a maioria dos livros de desenvolvimento de software dos últimos dez anos cita, em alguma medida, seu nome e referencia seu vasto trabalho em áreas como enterprise patterns, agile, TDD, Refactoring, UML e, mais recentemente, Domain Specific Languages (DSLs).

A primeira parte da palestra foi focada em discutir as DSLs, que é o tema de seu último livro (provavelmente sairá em outubro, segundo ele mesmo). Ele mostrou com podemos criar linguagens específicas a um determinado domínio, desmistificando o tema ao provar que estamos diariamente expostos a coisas semelhantes, tais como SQL, Linq, Struts e Hibernate. Esses são alguns exemplos, não de DSLs, mas de algumas ferramentas e linguagens dedicadas a resolver um único propósito. Por outro lado, Java e C# são o que ele chama de general programming languages, usadas para resolver qualquer tipo de problema e em qualquer domínio. O assunto foi quente e deixou a platéia com gostinho de "quero mais". É claro que irei encomendar o livro. -:)

A segunda parte foi mais árida e dedicada a falar sobre REST. Foi uma palestra MUITO técnica (algumas pessoas não faziam a menor ideia do que se tratava) e um pouco cansativa. Ele explicou os quatro níveis de arquitetura REST (0, 1, 2 e 3) e comentou os fundamentos de cada parte. Confesso que pelo que foi explicado, o que implementei até hoje pode ser classificado no máximo como nível 1. Estou precisando "comer um pouco mais de feijão" nesse assunto hehe.

A terceira parte da apresentação foi bem interessante e divertida. Martin mostrou os benefícios da integração contínua e da automação de builds e testes. Nessa parte ele já estava bem à vontade com a platéia e presenteou a todos com seu humor fino e colocações pertinentes. É muito inspirador vermos que podemos chegar a um nível tal de automação que nos permita entregar software para produção em intervalos cada vez mais curtos, podendo até ser diários. Ele comentou brevemente sobre o Cruise, que é uma ferramenta de CI da ThoughtWorks (com versão free, vale à pena verificar).

Por último, Martin abriu para perguntas e respondeu prontamente a todos que tinham questões.

E então, como última pergunta, um iluminado da platéia perguntou ao Martin se ele voaria em um avião que tivesse sido construído utilizando métodos ágeis. Ele calmamente respondeu que temos que, gradativamente, encontrar quais são as fronteiras do desenvolvimento ágil, simplesmente testando os seus limites (obviamente sem colocar a vida de ninguém em risco). Métodos ágeis ganham mais espaço em todo o tipo de projeto e assim tem sido diariamente ao redor do globo. Completou dizendo que não sabia o suficiente sobre aviação para uma resposta mais acurada e terminou contando a seguinte piada:

"Um grupo de alunos havia construído um sistema para determinado avião. 

Perguntaram ao professor desses alunos: - mestre, o senhor viajaria nesse avião?

O professor disse: - viajaria com toda certeza e estaria 100% seguro.

- Mas como o senhor pode ter tanta certeza que o avião não iria cair?

O professor então respondeu: - ora meu caro, se meus alunos fizeram esse sistema, é óbvio que o avião nem irá sair do chão!"

hahahaha

Ele terminou com essa piada e o pessoal foi ao delírio.

Toque do gênio!

Alguns livros que considero importantes...

link para o livro

link para o livro

link para o livro

link para o livro

link para o livro

Ubiquitous Language

Sempre que encontro com meus amigos guitarristas é uma festa... O assunto principal, como não poderia deixar de ser, é sempre sobre guitarras e tudo que essas preciosidades podem fazer. Falamos sobre as pickups que nossos ídolos utilizam, se vamos colocar jumbo frets em nossos necks para obter maior sustain, comentamos sobre os tipos de bridge que mais gostamos, entre outros assuntos.

Não está entendendo nada desse assunto? Não esquenta, somente nós guitarristas (malucos) entendemos. Essa é a nossa linguagem, a que usamos normalmente para comunicar nossas ideias e nossa paixão pela música.

Imagine uma situação hipotética, na qual esse grupo de amigos tivesse encomendado a uma equipe de programadores um sistema de controle de guitarras, um software no qual pudéssemos encontrar e colocar todo o tipo de informação pertinente da nossa área de atuação. De que modo você pensaria em modelar esse sistema? Qual seria um design apropriado para esse problema?

Um programador com linguagem puramente técnica tentaria explicar como desenvolveria o sistema usando DAOs, controladores, queries, Design Patterns e outras coisas que nada tem a ver com a área (apenas me deixando preocupado se ele realmente teria entendido) o negócio que gostaríamos de ver solucionado.

De outra forma, um programador poderia aproveitar o nosso vocabulário para modelar uma solução que usasse a nossa linguagem como apoio para o design. Nesse modelo, ele me mostraria como criaria guitarras, pickups, tremolos e repositórios diretamente na solução. Deixaria bem claro como esses elementos estão associados usando a mesma linguagem que nós utilizamos normalmente. A essa linguagem damos o nome de ubiquitous language.


Repare onde a ubiquitous language naturalmente se encontra, um meio-termo que une especialistas em domínio com especialistas em tecnologia:

A ubiquitous language é fundamental para o Domain Driven Design, metodologia que foca na construção de sistemas a partir do desenvolvimento (e isolamento) de um rico domain model, capaz de resolver problemas com eficiência e apoiado na linguagem que os usuários utilizam no dia a dia.

Eric Evans nos dá a direção:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communications within the team and in the code. Use the same language in diagrams, writing, and especially speech. Recognize that a change in the ubiquitous language is a change to the model."

Nós devemos ser capazes de desenvolver sistemas que comuniquem bem seu design para os usuários que realmente o utilizarão. Mantenha apenas o modelo, código e testes como artefatos permanentes do desenvolvimento. Use a linguagem no dia a dia e a incorpore em todo o lugar, dos diagramas de classe aos códigos Java e C#. Isole o domain model e deixe o aparato técnico para ser discutido apenas por especialistas em tecnologia.

Próximos posts veremos como a arquitetura DDD é feita de forma a permitir o isolamento desse domain model.

Curso agile pronto

Fala pessoal!
Tudo bem?

O curso agile ficou pronto e já saiu do forno... Montei um compacto das melhores práticas de engenharia do XP com as práticas de gestão de projetos do Scrum.

Modéstia à parte, ficou bem bacana. hehehe

Quem quiser conferir clique aqui.

Abração e qualquer dúvida é só postar que eu respondo. :)

Formação Agile

Fala pessoal!

Ando meio sem tempo para postar por conta da formação agile que estou criando em parceria com o Infnet.

Será um mix de Scrum e XP com muita informação legal para desenvolvedores e gestores.

Aguardem notícias muito em breve aqui no blog!

Abraços.

Agile Project Management

Debates fervorosos acontecem, atualmente, na comunidade de gestão de projetos de sotware. O grande centro das discussões encontra-se na questão sobre qual seria a melhor metodologia a ser aplicada no gerenciamento desses projetos. Devemos seguir as boas práticas do PMBOK ou aplicar uma abordagem ágil, utilizando métodos como Scrum e XP? Minha resposta: devemos sempre adotar o que for melhor para cada projeto em particular.

Não devemos gerenciar projetos no estilo "by the book". Procurar por cartilhas que nos digam exatamente o que fazer é um caminho perigoso e que tem poder de levar um projeto ao fracasso. Um profissional sério deve se aprofundar no conhecimento dos frameworks e metodologias existentes no mercado para, como um médico, diagnosticar um quadro geral e indicar o tratamento mais adequado. É preciso entender a situação primeiro para depois poder traçar uma estratégia coerente, um plano de ação que seja eficaz para o case específico.

E por que não mesclar as técnicas para preencher as lacunas que cada método possui?

Podemos estar gerenciando com foco no PMBOK e mesmo assim aplicar técnicas ágeis como abordagem iterativa, cliente-onsite e reuniões de retrospectivas. Analogamente, podemos utilizar Scrum e aplicar técnicas como gestão de riscos e construção de uma visão para o produto. Conhecer mais ferramentas dá maior poder de escolha para o gestor, evitando vícios como a incessante procura pela "bala de prata" das metodologias, comportamento que engessa a atuação de qualquer profissional (não apenas de gestão).

Sendo assim, independente do método utilizado, há sempre dois pontos que são os mais importantes em qualquer projeto (especialmente os de software): pessoas e comunicação. Qualquer abordagem que priorize os complexos relacionamentos que existem entre os interessados de um projeto, facilitando a comunicação entre os envolvidos e buscando dar mais autonomia e responsabilidade às pessoas tem muito mais chance de terminar com sucesso.

Verdades e Mitos sobre a Programação Orientada a Objetos

1- Objetos são "abstrações" do mundo real.  

Mito. Objetos nem sempre representam "coisas" do mundo real. Eles são unidades especializadas compostas por dados e comportamento, que atuam de forma colaborativa para compor uma aplicação. Podem ou não representar algo do mundo real. Por essa definição, tanto um servlet, um dataset ou um cliente podem representar objetos válidos em um sistema. A confusão se dá devido às instâncias de classes que representam conceitos de um domínio e que são chamadas de business objects. Essas são bastante valiosas para vários tipos de aplicações, pois servem como Domain Model do negócio que o software pretende atender, com suas regras de negócio, linguagens compartilhadas e necessidades específicas (abordagem da técnica conhecida como Domain Driven Design).

Obs: objetos que não possuem comportamento são conhecidos como objetos anêmicos, termo cunhado por Martin Fowler para designar entidades "burras" que funcionam apenas como depósito de dados.

2 - O Desenvolvimento OO é mais lento.

Verdade. Aplicações OO são compostas de pequenas classes especializadas nas várias funcionalidades que uma aplicação necessita para atender a uma área de negócio. O foco é nas entidades que realizam o processo e não no seu fluxo (marcante no desenvolvimento procedural). Há "seres" responsáveis em gerenciar conexões, executar cálculos, mapear dados, imprimir relatórios, gerar visualizações, etc. A criação dessas classes demanda um esforço inicial maior por parte do time de desenvolvimento - esforço que será recompensado por uma maior facilidade de manutenção, reutilização e evolução do software em questão.

Obs: esse atraso no desenvolvimento é parcialmente compensado pelo uso de frameworks que auxiliam na construção da infra das aplicações como mapeamento de entidades, segurança, configuração e logs.

3 - Programar em Java ou C# gera automaticamente software OO.

Mito. O desenvolvimento OO começa na mente do programador. É, acima de tudo, uma forma de design. Linguagens como Java, C# e VB.Net são ótimas pois permitem que o design OO imaginado  pelo projetista/programador seja facilmente implementado pelo time de desenvolvimento. Elas são equipadas de recursos como herança, polimorfismo, encapsulamento e permitem a criação de classes, objetos, interfaces, enumerações, etc. Porém, sem o domínio de como fazer design OO, estaremos usando essas ferramentas, na melhor das hipóteses, para gerar um código procedural "disfarçado" de software OO.

4 - Para aprender OO é preciso aprender UML.

Mito. A Unified Modeling Language (UML) é uma excelente ferramenta para comunicar ideias de modelagem, ajudando no processo de desenvolvimento de uma determinada aplicação. Entretanto, ela não ajudará na construção do design da solução. Em outras palavras, sem a atitude mental correta, servirá  apenas para modelar perfeitamente uma aplicação ruim. O interessante da UML é o fato de ser uma forma de notação conhecida por inúmeros desenvolvedores ao redor do globo, possibilitando uma linguagem de modelagem comum para o time e outros stakeholders do projeto. Profissionais de OO experientes utilizam a UML para modelar soluções de forma livre em white boards e/ou ferramentas case (geralmente em conjunto com outros membros do time). Outro benefício (secundário) da UML é a possibilidade de geração de documentação.

5 - Programadores mais antigos têm dificuldades com OO.

Verdade. A última década consolidou o modelo de desenvolvimento OO, principalmente devido à popularização do Java e ao crescimento da plataforma .Net. Por que então tantos programadores ainda têm dificuldades com esse paradigma? A resposta é simples: a maioria desses programadores com dificuldades foi formada sob a ótica procedural e ao desenvolvimento orientado a banco de dados. A programação OO vira o mundo desses profissionais de cabeça pra baixo, propondo uma forma diferente de se construir software, com a promessa de gerar aplicações mais fáceis de manter (e estender) e mais resistentes a mudanças, requisitos-chave para atender às exigências do mundo moderno.

6 - A programação OO favorece a reutilização.

Verdade. A criação de várias instâncias de objetos de uma mesma classe já é um grande exemplo, por si só,  de reutilização de código. Cria-se a classe apenas uma vez. Instâncias de objetos são obtidas com base nessa "forma" que molda as características e o comportamento da entidade. Outras formas de reutilização são a componentização e o uso de patterns (Design Patterns e Architectural Patterns).

O futuro das Fábricas de Software

Há tempos venho discutindo com alunos, colegas e amigos sobre a ineficácia do modelo atual de  trabalho das "fábricas de software". O post de Fabio Akita, no BlogInfo, trouxe à tona esse debate novamente. Ok, ok. Admito que o autor foi meio radical em sua tese ao condenar - por completo - todo o modelo, mas é inegável que essas fábricas, da forma como existem hoje, estão com os dias contados.

Uma razão para seu declínio é, talvez, o fato delas estarem focadas no modelo waterfall de desenvolvimento e nas práticas Tayloristas e Fordistas de produção. Como já discuti aqui no blog, nesse post, não adianta (pelo menos não na maioria das vezes) tentar um caminho preditivo e baseado em uma rígida divisão de papéis. Nesse ambiente, há uma super-especialização do trabalho, ou seja, o analista não programa, o programador não testa, o gerente só se ferra e por aí vai...

Os problemas acontecem pois fábricas de software não estão organizadas de forma a maximizar as chances de um projeto ser bem sucedido, pois não dão a liberdade necessária para que a inovação aconteça, ingrediente fundamental para se criar efetivamente software de alta qualidade e valor agregado ao negócio. Projetos que hoje são bem sucedidos, são realizados por equipes que se envolvem em todas as fases do processo, com constante troca de papéis e colaboração entre as pessoas do time.
 

As fábricas de software irão acabar? Evidentemente, não tenho (e  acredito que ninguém tenha) essa resposta. Meu melhor palpite é que sobreviverão as que souberem reinventar o próprio negócio, incorporando elementos como requisitos ágeis, escopos negociáveis, times auto-organizados e outras práticas fundamentais.

Quem viver, verá...

Como trabalham os desenvolvedores profissionais?

Esses dias estive pensando a respeito de práticas de programação que são comuns a todos os desenvolvedores profissionais que conheço. Apesar de haver estilos e características diferentes em cada um deles, há um conjunto de atividades que eles compartilham quase sempre. Portanto, resolvi agrupar uma "lista" dessas atividades principais e divulgá-las aqui no blog.

Vamos à lista:

Desenvolvedores profissionais...

Estudam muito, sempre. 

Eles bebem de várias fontes. Fazem cursos, leêm as obras mais relevantes da área, frequentemente conhecem mais de uma linguagem (e plataforma), gostam de "fuçar" para obter mais conhecimento e estão sempre praticando e testando novas ideias. Para esses profissionais, o importante é aprender sempre e estar  em constante evolução. 

Gostam de compartilhar conhecimento. 

Desenvolvedores profissionais, geralmente, são membros ativos de blogs, grupos de discussão e comunidades. Ajudam seus colegas de trabalho a entenderem técnicas e conceitos importantes, disseminando o conhecimento por todos da equipe. São definitivamente pessoas altruístas e com grande sentimento de colaboração e cooperação. 

Escrevem seus próprios testes.

Desenvolvedores profissionais escrevem seus próprios testes. Como Phillip Calçado expôs nesse excelente post , é bobagem achar que um desenvolvedor profissional não deva produzir seus próprios testes unitários automatizados. Pior ainda é considerar que ninguém deva produzir esses testes alegando questões de prazo e/ou custo. Leia esse post do José Papo e entenda por que isso é um contra-senso  econômico.

Escrevem código para pessoas e não para máquinas.

Qualquer um pode escrever alguma coisa que compile e funcione. Entretanto, somente os profissionais escrevem código limpo, claro e organizado que pessoas conseguem entender e manter. O design é feito pensando nos outros programadores - os que irão passar a maior parte do ciclo de vida do sofware mantendo o produto.

Refatoram de forma disciplinada e habitualmente. 

Na vida real todos nós sempre temos um prazo e um budget. Desenvolvedores sérios sabem disso e são comprometidos com as necessidades de seus clientes. Para respeitar esse prazo, muitas vezes entregam uma solução que ainda não consideram como "excelente" e, para resolver esse problema, assumem e se responsabilizam pelo "débito técnico" gerado, refatorando o código de forma habitual e controlada (obviamente, sempre possuem uma suíte de testes automatizados para tornar a tarefa possível).

Evoluem com o design tendo o business em mente.

Desenvolvedores profissionais criam soluções, de forma incremental, que reflitam o negócio da empresa (e do cliente) em primeiro lugar. Desenvolvedores sérios trabalham com técnicas que facilitem a criação de uma aplicação que contenha elementos comuns a todos os stakeholders do projeto da organização. Geralmente indicam o livro do Eric Evans, "Domain Driven Design", como leitura  obrigatória (e realmente considero um excelente livro).

Enfim, essas são as atividades que considero comuns aos desenvolvedores profissionais. Servem como uma "luz" para o nosso próprio desenvolvimento profissional.

E você? Acredita que há mais atividades importantes?

Comente...

As 10 melhores práticas para se construir software.

1 - Desenvolva uma visão do produto.

2 - Trabalhe de modo iterativo e evolutivo.

3 - Envolva o cliente no processo.

4 - Gerencie requisitos.

5 - Acolha mudanças.

6 - Construa o design e a arquitetura incrementalmente.

7 - Diminua o tempo de feedback.

8 - Gerencie riscos.

9 - Aplique técnicas de engenharia.

10 - Confie na equipe.

Devagar com o Andor que o Santo é de Barro

Recebi vários emails de pessoas que ficaram confusas com meu último post... Muitos acharam que havia uma incoerência em defender uma prática comum no PMBOK - a gestão de riscos- já que sou um estudioso e propagandeador de métodos ágeis de gestão e desenvolvimento de software.

Deixe-me esclarecer melhor: por mais que eu escreva coisas como nesse post aqui, não é a minha intenção desmerecer um trabalho de anos realizado pela comunidade do PMI. Em qualquer método, framework e guia de práticas, sempre haverá pontos positivos e negativos, relativizados de acordo com o contexto de  aplicação em cada organização ou projeto. O próprio Scrum, que sou entusiasta como muitos na comunidade agile, é cheio de lacunas em áreas como engenharia e risco.

O que aprendi é que realmente não existe uma "bala de prata" em processos da área de TI. É preciso conhecer (e estudar) vários deles para obter aquilo que melhor se encaixa ao ambiente em que estamos trabalhando e que irá contribuir para o resultado do negócio.

Logo, por mais que gostemos de Agile, Scrum, XP, Lean e Kanban não podemos ignorar que RUP, CMMI, PMBOK, SWEBOK têm grande valor e que devem ser considerados por qualquer profissional sério da área de software e/ou TI.

O Poder do Pensamento Negativo

Recentemente, li um artigo intrigante sobre o poder do pensar negativamente a respeito das coisas. Esse autor defende uma tese muito interessante: de que ter uma visão mais pessimista nos torna mais preparados diante das situações do dia a dia, devido ao comportamento "pé atrás" que passamos a assumir ao agir. Em vários pontos do texto, ele mete o malho nos "polianas" de plantão e nos propagadores de ideias como "lei da atração", o "segredo" e outras baboseiras clássicas. 

De fato, esse "pessimismo defensivo" é um excelente neutralizador de surpresas desagradáveis. Ao pensar no que pode dar errado, bolamos maneiras de contornar o problema e proteger nossas atividades dos inevitáveis imprevistos.

Em gestão de projetos essa atitude tem um nome: chama-se Gestão de Riscos.

E o que seria um risco para o projeto? Segundo o PMBOK, a definição é a seguinte:

"Evento ou condição incerta que, caso ocorra, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade."

Esssa definição é interessante pois mostra que há também riscos positivos para qualquer projeto. Muitos acreditam que o risco é sempre algo negativo e que sempre resultará em efeitos adversos à atividade realizada. Obviamente, não estamos preocupados com os efeitos positivos inesperados e sim com os de efeito negativo.

Métodos e frameworks como RUP, PMBOK e CMMI encorajam uma abordagem disciplinada a respeito dos riscos de um projeto. A ideia é listar, tão cedo quanto possível, os riscos principais do projeto e tratá-los logo nas primeiras iterações. Entretanto, frequentemente essa prática é sumariamente ignorada pelas equipes, em prol da realização de atividades que mostrem "mais serviço pronto" ao chefe, como o desenvolvimento dos cadastros de uma aplicação. Essa atitude é a que provoca falsos inícios em um projeto, postergando as atividades de maior risco que podem gerar surpresas desagradáveis mais à frente (e é o que geralmente acontece).

Por isso, entre sempre com o "pé atrás" em qualquer projeto.

Ajuda a evitar dores muito fortes de cabeça...

Scrum e a Gestão Ágil

É consenso de que em projetos ágeis de software não há lugar para o gestor do tipo sabe-tudo,  aquele que controla o projeto por completo, assumindo a total responsabilidade pelo seu sucesso ou fracasso. Esse papel é frequentemente desempenhado pelos profissionais que seguem a cartilha do PMI, criando pouco (ou nenhum) espaço para adaptação e colaboração.

Por outro lado, há sim a necessidade de um modelo de gestão. É um erro achar que projetos ágeis se auto-gerenciam, como corretamente apontam Mike Cohn e Ken Schweber no artigo "The Need for Agile Project Management":

"One of the common misperceptions about agile processes is that there is no need for project management, and that agile projects run themselves. It is easy to see how an agile process’ use of self-organizing teams, its rapid pace, and the decreased emphasis on detailed plans lead to this perception."

Para gerenciar projetos, o Scrum trabalha com o modelo de gestão compartilhada, distribuindo responsabilidades entre os vários papéis presentes na equipe do projeto, a saber:

1 - Product Owner 

• Responsável pela Visão do produto.
• Controla o Product Backlog.
• Monitora o projeto contra os objetivos de ROI e Visão.
• Prioriza e refina o Product Backlog, medindo o seu sucesso.

2 - Scrum Master

• Monitora o processo para garantir o sucesso da equipe.
• Permite que o time se auto-organize.
• Remove obstáculos.
• Blinda o time contra perturbações externas.
• Promove rápidas reuniões diárias.
• Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint.

3 - The Team

• Seleciona e desenvolve as estórias do Sprint Backlog
• Expande as estórias em tarefas mais detalhadas.
• Completa 100% de cada tarefa escolhida.
• Gerencia e auto-organiza o próprio trabalho.
• Diariamente inspeciona o projeto para atingir os objetivos do Sprint

Cada papel dentro da Gestão Ágil direciona esforços para entrega frequente de valor e antecipação do ROI do projeto. Em projetos tradicionais espera-se a finalização completa do projeto para se ter retorno sobre o investimento aplicado; em Scrum gera-se valor a cada pequeno incremento durante o tempo, retornando o investimento muito antes da entrega do release final e oferecendo oportunidades reais de lucro antecipado.

 

Na Gestão Ágil a responsabilidade pelo sucesso de cada projeto depende da colaboração e do comprometimento de cada um dos papéis da equipe, o que diminui o risco de se ter o destino da empreitada nas mãos de uma única pessoa.

It`s Only Rock `n Roll (But I Like It)

Simplicidade é uma ideia poderosa. Capaz de transformar o ruído em comunicação, o desarrumado em elegante, o complicado no fácil. O Rock, gênero musical de maior sucesso e impacto cultural da atualidade, ergueu suas bases nessa ideia genial, como definido pela Wikipedia: "sua forma pura tem alguns poucos acordes, um forte e insistente contratempo e uma melodia cativante."

Essa economia é misteriosamente cativante e sedutora. A relação criada entre a música e o ouvinte é direta e íntima. Visceral. Ela acontece, por exemplo, quando cantamos a melodia de uma peça que gostamos ou quando colocamos a nossa trilha sonora predileta para tocar no celular.

Porém, atingir tamanho grau de simplicidade não é nada fácil. É necessário trabalho duro. Suor.

Veja uma das mais famosas fórmulas da Física:




Espantosamente simples, não? A fórmula relacionando massa com energia parece que esteve sempre ali, apenas esperando para ser descoberta... Entretanto, para chegar a essa elegância, foi preciso muito trabalho para "polir" as arestas e jogar fora tudo o que estava atrapalhando (obviamente, com um "empurrãozinho" da mente brilhante de um dos maiores cientistas do século XX).

Seguindo esse raciocínio, para desenvolvermos software que seja fácil manter, atualizar e compreender, é preciso prestar atenção aos mestres da simplicidade, como Albert Einstein e Keith Richards. Para esses monstros sagrados, o que é deixado de fora é tão (ou mais) importante do que aquilo que será utilizado.

Atualmente, devido ao vasto arsenal de patterns e frameworks disponíveis no mercado, é muito comum o desenvolvedor pecar pelo excesso na codificação, seja para tornar o código mais "elegante" ou simplesmente numa tentativa de impressionar os seus pares e mostrar "serviço".

Por exemplo, veja aqui o famoso "Hello World", totalmente redesenhado utilizando vários padrões de projeto [GoF] como AbstractFactory, Strategy e State. É uma caricatura interessante de como a "sobre-engenharia" do código pode resultar, paradoxalmente, em código ruim e de difícil manutenção.

É claro que não sou contra a utilização de padrões, na verdade é exatamente o oposto:  encorajo e apoio a sua adoção. Porém, assim como um guitarrista não faz música apenas subindo e descendo escalas, um desenvolvedor de software não irá criar peças de qualidade apenas copiando e entupindo o código com padrões sem sentido.

É preciso um equilíbrio entre técnica, arte, sensibilidade, experiência e talento.

Uma dica de como começar?

Dê uma espiada aqui.

"Life is what happens to you while you're busy making other plans..."

Esta frase, de "Beautiful Boy", mostra que John Lennon sabia muito bem que é inútil tentar planejar nossas vidas em cada mínimo detalhe. No máximo poderíamos ter um plano básico, do tipo que diria que faculdade cursar ou quando seria a melhor hora para financiar uma casa bacana. A vida é muitíssimo mais poderosa que os nossos planos, várias vezes modificando o rumo que pensávamos ser o mais correto a tomar.

Uma oportunidade de emprego inesperada, um filho não planejado, um romance casual que se transforma em casamento, um hobby que vira profissão, tudo pode acontecer num instante e nos desviar de nossa "infalível" rota, tão meticulosamente traçada...

Sim, o controle é uma ilusão!

Mas o que Lennon não sabia é que essa ideia poderosa também é válida para o mundo do software. Há um processo de desenvolvimento que foca exageradamente na ideia do "plano perfeito", no detalhamento precoce da solução antes de qualquer codificação, de modo a termos maior "controle" sobre o que será desenvolvido, após extenso período de reflexão e análise.

Esse processo ficou conhecido como waterfall (cascata) e é representado graficamente assim:

Parece fazer sentido, não? Planejar tudo antes e implentar com segurança depois... Entretanto, o tempo mostrou que a adoção desse processo foi toda baseada em boatos e suposições, em vez de evidências claras da eficácia do método. As pessoas adotaram essa visão achando que era a "coisa certa a fazer" e não mediram os resultados que estavam obtendo. Conclusão: vários projetos engordando as estatísticas já obesas de fracassos empresariais em TI.


Contrapondo essa visão surgiram os métodos iterativos e evolutivos. RUP, OpenUP, Scrum, eXtreme Programming, são alguns exemplos de métodos que adotam o modulo iterativo de desenvolvimento. Em vez de fases passamos a trabalhar com pequenas iterações curtas (2-4 semanas, em média), agindo de forma adaptativa e sempre produzindo software com qualidade de release final. A cada dia, inspecionamos o trabalho para termos a certeza de que o objetivo da iteração será alcançado.

Esse modelo, graficamente, pode ser representado (resumidamente) da seguinte forma:

Cada release da iteração é software potencialmente entregável. Passou pelas etapas de análise, planejamento, construção e testes e está pronto para ser integrado às outras partes já produzidas do sistema. Os insights adquiridos são debatidos nas retrospectivas e servem de baseline para as próximas iterações, um processo que se retro-alimenta todo o tempo.

O Cliente, presente em todas as etapas do projeto - em pessoa ou como um papel específico, ajuda a refinar o entendimento do negócio, apoiando para que o desenvolvimento agregue o máximo valor à empresa e acelere o ROI. O feedback é obtido cedo e ajuda a corrigir a rota para que esteja de acordo com as necessidades dos stakeholders.

Esse fluxo se repete por várias vezes, fazendo a equipe evoluir e aprender com erros e acertos...

É provável que você hoje trabalhe em uma empresa que utilize o modelo waterfall de desenvolvimento. Caso os projetos estejam sendo entregues no prazo, satisfazendo os clientes e gerando grande valor ao negócio não há nenhuma razão para mudar. Caso contrário, considere a adoção do modelo iterativo de desenvolvimento na empresa em que você trabalha.

Seja uma empresa privada ou empresa pública certamente haverá desafios para mudar a cultura como um todo. Não desanime, pois o processo é lento. É necessário tempo para que as pessoas - clientes e fornecedores - aprendam a trabalhar de uma maneira totalmente diferente do que estão acostumadas.

Be patient!

"All you need is love."