Pesquisar neste blog

12 de abr. de 2012

Agile: o conhecimento de negócio vai mesmo emergir?

Por: iMaster
Em: https://www.ibm.com/developerworks/mydeveloperworks/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/agile_o_conhecimento_de_neg_C3_B3cio_vai_mesmo_emergir?lang=pt_br


Já tem um tempo que quando se pensa em desenvolvimento de software corporativo, com lógica de negócio muito complexa, a Qualidata tem dado bastante foco ao Domínio. Nossos holofotes estão voltados pra entender como funciona o negócio do cliente, independentemente de sistema, para só depois pensar em sistematizar tudo. E como temos feito isso?

Para cada projeto de desenvolvimento, nós montamos duas equipes: uma de análise de domínio e outra de construção. O objetivo do trabalho da equipe de análise é entender o domínio do cliente para depois mapear o que um sistema deveria ter para atendê-lo. Com isso em mente, e após uma série de reuniões, pesquisas e refinamento do entendimento, produzimos o que chamamos de Artefatos de Representação do Conhecimento (ARCs), que visam explicar de maneira detalhada e organizada o nosso entendimento das necessidades e das regras de negócio do cliente. 

O trabalho da equipe de construção é lidar com todas as questões necessárias para o desenvolvimento do sistema, desde a preparação da infra até a construção das interfaces com usuário. Basicamente, com todos os problemas conhecidos para se construir um software, com exceção do conhecimento de negócio e definição de como este será mapeado para o sistema.

Nas duas equipes trabalhamos utilizando uma série de técnicas das metodologias ágeis. Além disso, fizemos essa divisão ao entender que, para sistemas grandes e negócios complexos, deixar o conhecimento emergir na equipe de desenvolvimento ao longo do projeto, como alguns prezam, na nossa experiência tem se mostrado inviável. Podemos escrever outro artigo só para discutir esse ponto.

Porém, apesar dos benefícios que tal abordagem trouxe, notamos que, como as decisões chaves de domínio já chegam tomadas para a equipe de construção, a mesma acaba se colocando instintivamente numa posição mais passiva. Entretanto, todas as decisões de construção continuam necessitando de grande atenção e de uma postura mais pró-ativa. Em nossa visão, não virá da equipe de análise de domínio, por exemplo, quais mecanismos de inversão de controle serão adotados para garantir desacoplamento do código. Utilizarão o pattern Fábrica Abstrata? Frameworks de Injeção de dependência? Enfim, uma série de decisões arquiteturais e de projeto serão tomadas pela equipe de construção. 

Além dessas decisões de projeto, essa equipe também precisa definir qual será a política de cobertura de testes, padrões de nomenclatura e organização do projeto e outras atividades relacionadas à construção. Portanto, todos os problemas de construção que já estamos acostumados continuam existindo e precisam receber grande atenção. Nosso método busca dar uma solução para as questões de domínio, evitando assim que as diversas complicações do negócio aumentem ainda mais a complexidade que existe naturalmente para se construir um sistema.

Claro, não é tão simples implementar esse modelo de trabalho, quando a maioria dos desenvolvedores vem de experiências nas quais eles fazem de tudo, desde discutir com o cliente até testar e treinar os usuários. Então qual seria a solução? Não sabemos. Ainda! Temos segurança que essa divisão das equipes tem mostrado resultados muito bons, e para amenizar esses problemas, seguimos utilizando a boa e velha conversa, visando sempre deixar claro qual o objetivo dessa divisão, qual o papel de cada um e onde queremos chegar.

Porque o que menos queremos é construir software como numa fábrica, apertando parafusos por anos sem saber exatamente o que estamos construindo.

Nenhum comentário:

Postar um comentário