O desenvolvimento ágil precisa de um framework primeiro?

4

Estamos planejando um novo projeto e queremos ir com uma arquitetura orientada a serviços. Todos concordam que este é o caminho a percorrer, mas como isso se encaixa no início do desenvolvimento usando metodologias ágeis?

Eu não tenho experiência com o SOA, embora eu tenha alguma experiência com o TDD (desenvolvimento orientado a testes). A equipe com quem trabalho pensa que precisamos de um framework antes de podermos começar a olhar para os desenvolvedores que trabalham com o TDD. Em outros, passamos semanas instalando um framework (um framework SOA) e então os desenvolvedores podem construir sobre esse framework para fazer seu trabalho.

Do ponto de vista do TDD, eu esperaria que cada desenvolvedor apenas desenvolvesse a funcionalidade usando MOCKs, etc., enquanto o framework estivesse sendo desenvolvido (embora eu não tenha idéia do que um framework em SOA envolveria). Então, poderíamos ligar as chamadas da estrutura real quando precisarmos. Não tenho certeza se isso está certo, mas parece correto.

    
por JD01 21.08.2011 / 19:48
fonte

8 respostas

5

Agile é muitas coisas para muitas pessoas e algumas se sentem strongmente sobre essas coisas do que outras. Leia o manifesto Agile. Esta é apenas a minha opinião, mas no final do dia Agile é sobre fazer o que é certo com quantidade mínima de sobrecarga e usando quaisquer métodos / técnicas bons e comprovados (ou seja, TDD ...) que façam sentido para a sua situação específica. p>

Como outros já mencionaram, a maioria das equipes ágeis se esforça para fornecer pequenos incrementos em pequenas iterações. E sempre que possível você deveria estar fazendo a mesma coisa. Ao mesmo tempo, vale a pena ter o projeto certo feito antecipadamente. Se a sua aplicação requer uma estrutura, por todos os meios, vá em frente e coloque a estrutura no lugar. Sim, você não poderá entregar nada que funcione por várias semanas e talvez mais, mas se você e sua equipe acharem que você precisa, faça isso. A pedra angular do Agile é que é sobre as pessoas, fazer o que as pessoas acreditam que você precisa fazer e eles vão ter suas costas e ser investido no produto. Costumávamos forçar restrições que faziam toda a equipe se sentir esquisita e desajeitada e isso é ruim.

Ao mesmo tempo, lembre-se de que você pode tratar sua estrutura como um produto separado que deve ser entregue a uma "equipe de desenvolvimento" para que a equipe possa entregar o produto final. Na maioria das vezes, após a fundação mínima, você pode trabalhar na estrutura em incrementos, da mesma forma que faria com o produto real. Decida o mínimo absoluto que você precisaria da estrutura para fazer com que o produto faça algo e se concentre nele primeiro.

Além disso, IMHO, tome a frase "sem grande projeto inicial, porque você é ágil" com um grão de sal. Embora você definitivamente não precise entrar em detalhes e passar seis semanas escrevendo documentos de design, para um projeto de grande porte ainda vale a pena gastar algum tempo pensando em arquitetura geral e design de alto nível. Coloque as peças grandes em seus lugares certos para que sua equipe tenha um roteiro claro onde você quer acabar. Como você faz apenas design de alto nível, se sua direção mudar, você só precisará atualizar a documentação de alto nível (não deve ser muito). Eu nunca confiaria apenas na refatoração para ditar a estrutura final de uma grande aplicação. Seu objetivo é fazer um projeto mínimo NECESSÁRIO, não um mínimo absoluto a um ponto em que praticamente não haja design antecipado e os requisitos impulsionem a evolução de seus módulos.

Finalmente, só porque você não pode entregar nada realmente trabalhando até que todo o framework esteja pronto, isso não significa que você não pode dividir o framework em várias partes e focar em cada um individualmente junto com o TDD. Você pode abstrair interfaces SOA, banco de dados, comunicações de rede, alguma outra lógica de back-end e mesmo que tudo isso esteja no framework, você pode escrever cada um usando TDD e simular quaisquer interfaces com as quais as partes conversarão. Alguns de sua equipe podem começar a trabalhar no código real do aplicativo usando classes simuladas que fingem que sua estrutura final está em vigor.

Então, esqueça a metodologia, dê um passo para trás e pergunte a si mesmo (e à equipe) se a SOA é a abordagem correta para essa aplicação? Se for, você pode fazê-lo funcionar com agilidade.

    
por 21.08.2011 / 22:15
fonte
4

O Agile é apenas uma metodologia de desenvolvimento de software. Para entender melhor, imagine que você trabalha em uma empresa de fabricação de automóveis. Ágil apenas diz a você como gerenciar seu trabalho para criar um carro melhor (não necessariamente para criar um carro melhor). No entanto, isso não exige que você tenha o pipeline de fabricação do motor em primeiro lugar.

O Agile tem tudo a ver com quebrar longos períodos de desenvolvimento em períodos menores (sprints) para dar aos desenvolvedores e empresários a oportunidade de entender o caminho que devem seguir antes, para que possam agir com mais flexibilidade.

Uma equipe pode iniciar uma metodologia ágil, mesmo sem ter um framework. Nesse caso, um dos itens do Backlog do produto poderia ser Como desenvolvedor, eu quero criar um framework, para que eu possa desenvolver mais rápido .

Assim, a resposta é no , o agile não precisa que você tenha um framework em primeiro lugar.

    
por 21.08.2011 / 22:43
fonte
3

Definitivamente não. Ágil é baseado em pequenos incrementos e feedback constante. Começar com um framework é mais provável de gerar fluência de escopo e, além disso, você não terá nada para mostrar, pelo menos, no primeiro mês de desenvolvimento. É muito mais importante estar no mesmo comprimento de onda com as partes interessadas, portanto, ser capaz de mostrar alguma funcionalidade de trabalho (mesmo que seja apenas uma maquete) muito rápido é mais importante do que uma estrutura. Você pode desenvolver o framework à medida que desenvolve seu aplicativo e depois pode evoluí-lo para algo que você usará em outros projetos.

    
por 21.08.2011 / 20:43
fonte
3

Você definitivamente não deve planejar escrever uma estrutura. Você poderia planejar usar um que já tenha sido escrito (por exemplo, JEE com Jersey ou muitos outros), mas tentar escrever uma estrutura proprietária para atender a alguns requisitos imaginários é, no máximo, equilibrado. Na pior das hipóteses, torna-se um erro de vários milhões de dólares. Os desenvolvedores que querem escrever um framework estão apenas adiando o trabalho real de atender às necessidades de seus clientes. Se você seguir o desenvolvimento orientado a testes e refatorar continuamente, a estrutura exata de que você precisa cairá à medida que você refatorar.

    
por 22.08.2011 / 06:01
fonte
2

A abordagem de desenvolvimento ágil pode ser muito complementada por um framework e a estrutura do seu código.

Correndo o risco de ser criticado por vincular ao meu próprio projeto, tenho trabalhado em uma estrutura especificamente otimizada para o Desenvolvimento Ágil. Aqui é pequeno, exceto na documentação que explica a abordagem à criação de aplicativos com requisitos muito vívidos. Ainda é um trabalho em andamento, mas deve ser capaz de responder à sua pergunta.

link

    
por 21.08.2011 / 22:50
fonte
0

Fazer muito design inicial (o que você precisará se quiser construir um bom framework) não é o que é ágil. Especialmente os primeiros incrementos são rapidamente implementados usando metodologias ágeis.

Meu instinto diz que sua escolha por uma arquitetura orientada a serviços pode ser o problema. Eu não estou dizendo que você não deve fazer qualquer arquitetura em um projeto ágil, mas os primeiros incrementos irão guiá-lo para uma boa arquitetura. Se você estiver realmente fazendo um projeto ágil, permitirá que os requisitos o orientem para a arquitetura correta, refatorando códigos antigos para novos insights.

    
por 21.08.2011 / 21:37
fonte
0

Simplicity -- the art of maximizing the amount of work not done -- is essential.

Não assuma nada sobre quais frameworks você usará. Concentre-se em satisfazer suas necessidades de clientes / usuários o mais rápido e profissional possível. Adicione estruturas quando você tiver uma necessidade real, real e mensurável para isso.

    
por 22.08.2011 / 10:06
fonte
0

Eu acho que você estaria indo na direção errada tentando usar o TDD como uma maneira de desenvolver elementos de arquitetura de alto nível, como a escolha de um framework (com exceção de um framework de zombaria talvez, a necessidade de qual pode ser descoberto à medida que sua suíte de testes cresce). A parte refatorada do ciclo TDD é muito mais sobre microdecisões, como mudanças no design de classes ou métodos, do que as reorientações das grandes figuras. Se você precisa de um framework ORM, por exemplo, você certamente não irá descobri-lo através do TDD.

Você pode estar certo ao dizer que o TDD permitirá que você trabalhe com grandes partes de sua base de código isoladamente do resto e, assim, atrase a escolha de uma estrutura SOA para o exato momento necessário.

No entanto, o fato de você poder arcar com atrasar a escolha não significa que é proibido escolher antecipadamente, especialmente para grandes decisões de arquitetura de base que terão um impacto em como seu aplicativo é estruturado. Também tenha em mente que infelizmente alguns frameworks são invasivos e você acaba sendo forçado a codificar as coisas de uma certa maneira, o que poderia arruinar uma parte de seus esforços se você já desenvolveu uma grande parte da sua camada de Serviços de forma agnóstica através do TDD. / p>     

por 22.08.2011 / 11:50
fonte

Tags