Paralelo: Desenvolvimento ERP x SCRUM

Saudações!

Após muito tempo sem postar, resolvi retomar a participação colaborativa na crescente comunidade Dynamics Brasil.

Durante esse tempo, tive algumas experiências legais participando da gestão de projetos de desenvolvimento Dynamics AX.

Isso me levou a refletir sobre metodologias ágeis aplicadas ao cenário ERP, baseado em situações e problemas recorrentes encontrados nas maneiras tradicionais de desenvolvimento e entrega, tais como falhas de comunicação, divergências entre expectativa do cliente e produto final, etc.

As características do desenvolvimento ERP diferem um tanto com relação ao desenvolvimento “from scratch”, pois sua dinâmica consiste muito mais na modificação do produto existente, do que na concepção de algo totalmente novo.

Antes de entrar nas características do SCRUM, é importante citar algumas diferenças que existem entre o mundo ERP e o mundo do desenvolvimento de software tradicional.

Para desenvolvimento ERP, normalmente existe uma figura diferente das existentes no mundo de desenvolvimento tradicional, que é o Consultor Funcional, ou Analista de Negócio.

A figura do consultor funcional é muito importante para refinar o desenho da solução, pois ele age como a engrenagem entre o usuário final e o desenvolvedor, trabalhando as questões políticas e expectativas do cliente com relação ao produto, e deixando o desenvolvedor focado na qualidade da solução e a ser entregue. Assim, o desenvolvimento pode ser abordado com base nos processos de negócio e sua integração com as funcionalidades já existentes dentro do sistema.

Voltando ao tópico principal, sobre utilização da metodolgia scrum no cenário ERP, podemos fazer a aplicação com alguns diferenciais sutis, como descreverei abaixo.

Em tempo, é importante ressaltar que não irei descrever todos os elementos da metodologia nesse post, pois existem excelentes referências na internet com o conteúdo bem abrangente e detalhado sobre SCRUM, portanto, decidi me concentrar em alguns pontos-chave que teriam alguma peculiaridade entre o desenvolvimento tradicional e o aplicado às customizações/processos de negócio.

Ferramentas e elementos

Scrum Team

É composto pelos elementos abaixo, atribuindo-se aos seguintes papéis:

Scrum Master: Este papel pode ser atribuído ao gerente técnico, que é o responsável pela manutenção da metodologia dentro da equipe.

Product Owner: Normalmente, é o responsável pela manutenção do Product Backlog.

Para desenvolvimento de customizações de ERPs, esse papel pode ser atribuído ao gerente de desenvolvimento, em par com o gerente de projetos, para que o time concentre as respostas relativas às entregas em uma única pessoa, facilitando a gestão da comunicação entre as partes.

Team: São as pessoas responsaveis pela concepção e desenvolvimento da solução.

No mundo ERP: Consultores funcionais ou Analistas de Negócio, em conjunto com os consultores técnicos ou desenvolvedores.

Product Backlog
Em poucas palavras, o product backlog consiste em uma lista contendo todos os requisitos levantados, descritos e priorizados em nível um nível mais abrangente.

Quando falamos no desenvolvimento em sistemas ERP, pouca coisa é desenvolvida integralmente, sendo a maioria do trabalho baseado na customização das funcionalidades existentes.

Nesse caso, o Product Backlog pode ser uma lista de todos os processos não aderentes no core do ERP, previamente mapeados pela equipe funcional em campo, e, sempre que possível dividindo as atividades por processos de negócios, com controle de status de “atendidos” ou “não atendidos”.

Sprint backlog

A dinâmica do scrum é dividida em sprints periódicos (normalmente semanais), onde as entregas do período são extraídas do Product Backlog de acordo com sua prioridade.

Em resumo, é uma condensação dos objetivos estabelecidos no product backlog, para entrega definida em um espaço reduzido de tempo.

De maneira análoga ao conceito do Product Backlog, o sprint backlog eventualmente pode ser definido por processo de negócio.

Impediments
São fatores que impedem a equipe de continuar determinada tarefa como por falta de recursos técnicos, infra-estrutura, definições de regras de negócio etc.

É muito importante que o Scrum Master e o gerente do projeto se unam e sejam facilitadores ativos entre o Scrum Team e o cliente final na gestão dos impedimentos, e provisão das respectivas soluções.

O Consultor Funcional também exerce um papel importante ao atuar junto do usuário final com o objetivo de extrair as respostas rápidas às eventuais dúvidas que surgirão ao longo do processo de desenvolvimento da solução.

Os outros elementos podem ser aplicados tais como concebidos na definição geral de SCRUM, como as medidas através dos “Burn Down Charts”, bem como a dinâmica dos Meetings.

Por fim, os objetivos principais são os mesmos de todas as metodologias ágeis, ou seja, através da aplicação de uma metodologia menos burocrática, promover maior integração e transparência entre o time e o cliente-final, evitando retrabalho ocasionado por ruídos de comunicação, através das entregas segmentadas em menores espaços de tempo, e todos os elementos que facilitam de maneira ampla o trabalho da equipe, atendendo plenamente às expectativas do cliente final.

Single Record Cache

Quando estamos desenvolvendo é bom ter em mente o impacto do código que estamos escrevendo em termos de performance do banco de dados. A infraestrura de acesso a dados do Ax permite que o AOS faça o caching de registros pesquisados no banco de dados, diminuindo assim as idas e voltas no banco de dados.


Independente da opção de cache o AOS somente faz o cache do registro quando o select utiliza TODAS as chaves presentes na primary index da tabela e somente se o operador == for utilizado em todas elas, pois o AOS faz o cache de um registro por vez, isto significa que >, <, != não tem efeito nenhum sobre o cache.


Toda vez que o modificador forUpdate é utilizado, caso não tenha sido utilizado previamente na mesma transação, o AOS atualiza o cache.


Como o Ax trabalha com o cache depende da propriedade da tabela chamada CacheLookup. As seguintes opções estão definidas:
1. None - sem cache
2. Found
3. FoundAndEmpty
4. NotInTTS
5. EntireTable


Utilizando Found and FoundAndEmpty o cache é preservado depois do uso do ttsBegin, ttsCommit e ttsAbort.


A opção FoundAndEmpty contém mais um detalhe, caso um select não devolva nenhum resultado, isto é, o registro com aquela PK não existe no banco, aquela PK é marcada como cacheada todos os selects subsequentes são "lidos" do cache e o cache é atualizado somente quando forUpdate seja chamado.


Utilizando NotInTTS o cache é atualizado no primeiro select após o ttsBegin.


A opção EntireTable somente deve ser utilizada para tabelas que não são atualizadas com frequência, como tabelas de parametros, grupos, etc, pois o AOS faz um cache completo da tabela quando a tabela for lida pela primeira vez, o AOS então cacheia a tabela toda do servidor, quando um client le a tabela cacheada no AOS ele envia a linha cacheada para o client sem ir ao banco de dados.


O AOS faz um flush do cache toda vez que um update, delete ou insert é feito na tabela, ela volta a ser toda cacheada na próxima vez que for lida.


O join entre tabelas com esse tipo de cache com tabelas que não tem o tipo de cache EntireTable sempre força o AOS a atualizar o cache não importa o momento do select.

Procurem sempre utilizar os métodos Find e Exists das tabelas pois eles sempre são escritos utilziando a PK da tabelas e garantem o uso do cache para aquela tabela.

Utilizando essas poucas regras e tendo elas em mente quando estão desenvolvendo para seus clientes, sempre tentem verificar se o modo que estão acessando o banco de dados pode ou não afetar a performance geral da fucnionalidade que estão desenvolvendo.

Até a próxima.

AX6 sneak preview - SQL AOD

Preview de uma das grandes mudanças na proxima versão SQL AOD

THIS POST IS PROVIDED AS-IS; AND CONFERS NO RIGHTS.

test post

algum problema com o feed burner

Testes unitários e integração continua

Normalmente não escrevo sobre temas totalmente fora do mundo Ax, porém hoje eu gostaria de comentar sobre um tema que não esta ligado diretamente ao Ax e sim ao desenvolvimento de software em geral, um tema que tenho dado bastante atenção nos últimos tempos.

Hoje em dia existe uma série de boas praticas de desenvolvimento sendo aplicadas mundo afora que também poderiam ser aplicadas no desenvolvimento de customizações para o Ax, uma destas boas praticas esta no desenvolvimento de testes unitários.

A criação de teste unitário tem um papel importante no desenvolvimento centrado em testes (TDD), ele não substitui o teste integrado ou teste funcional mas é importante em todas as fases de desenvolvimento forçando o desenvolvedor a escrever métodos de uma maneira mais testável, mais simples, da mais confiança quando é necessário adicionar novas funcionalidades, previne regressão do código, isto é, o que estava funcionando, deve continuar a funcionar após uma modificação.

Existem toneladas de informação sobre unit tests na internet e eu encorajo todos os desenvolvedores a introduzirem o uso de unit teste no desenvolvimento de suas customizações.

Gostaria indicar 2 screencasts e 1 artigo, mesmo que básicos:
Dynamics AX 4.0 - Unit testing - Introduces the Unit Test Framework in Dynamics AX 4.0. – mostra como criar unit tests no Ax para testar seu código.

Continuous Integration por Martin Fowler – bom artigo para iniciar em integração continua

Continuous Integration and Better Unit Testing – visão geral sobre integração continua e a maneira que os testes unitários podem ser integrados ao processo de build, não é ligado ao Ax, mas da uma boa idéia de como se criar algo semelhante com o Ax (alguém se habilita?)

Dica de performance

Uma dica legal de performance é, desabilitar a chave de configuração “Manter objetos atualizados” (SysDeletedObjects40).

Essa chave controla se objetos obsoletos da aplicação são deletados ou não. Objetos obsoletos possuem o prefixo “DEL_”, e são automaticamente deletados na próxima versão do AX, ou seja, quando você atualizou para o Microsoft Dynamics AX versão 4.0, todos os itens com a Chave de Configuração SysDeltedObjects30 foram excluídos e os objetos controlados por SysDeletedObjects40 serão excluídos quando você desabilitar essa chave ou atualizar com a próxima versão do Microsoft Dynamics AX.

Esses objetos são necessários, portanto, apenas para importar e atualizar dados de antigas versões do Microsoft Dynamics AX. De modo geral, eles desperdiçam espaço e diminuem a performance - alguns destes registros estão relacionados a tabelas com grande volume de transações (como a TaxTrans por exemplo) – e podem ser removidos.


A chave de configuração pode ser ajustada na seguinte localização:
Administração > Configuração > Sistema > Configuração.

Mais upgrade!

Com o lançamento do Ax 2009 no Brasil muitos desenvolvedores terão que trabalhar no upgrade das customizações feitas para seus clientes no Ax 4.0 para a 5.0. Deixo aqui a dica para verem o ultimo post no blog Palle Agermark on AX, principlamente se vocês planejam mudar aquele desenvolvimento feito para o cliente x na camada cus para a camada var, por exemplo, para reutilizar em outros clientes.



Abs

Smart customizations pt. 2

Toda implantação de um ERP exige algum nivel de customização para o cliente: seja um novo processo um modificação de um processo existente ou um novo relatório, os desenvolvedores devem seguir alguns principios no desenvolimento de suas customizações para fazer isso de uma maneira mais eficaz, tanto na manutenção, quanto no upgrade, aqui vão algumas dicas:

1. Mantanha a lógica do negócio e logica de interface separados - isto significa: não escreva lógica relacionada a funcionalidade que esta criando em forms, utilizar o máximo possível classes.


2. Quando for utilizar tabelas, trabalhe com um registro por vez em table instance methods (custInvoiceJour.initFromSalesTable por exemplo), enquanto table static methods devem cuidar de um grupo de registros.


3. Sempre tente utilizar field groups nos formulários. eles são automaticamente atualizados nos formulários quando um novo campo é inserido.


4. Classes: lógicas que envolvam diferentes tabelas como processos de atualização (faturamento ou um cálculo de comissão) devem estar escritos em classes. Tente utilizar o princípio de "Single Responsibility (SRP)" em suas classes, esse principio diz que uma classe deve ser implementada tendo apenas um único e exclusivo objetivo, portanto não faça das suas novas classes um canivete suiço.
   
5. Evite overlaying em suas classes e tabelas: caso você modifique um método que ja exista em uma camada abaixo da que esta trabalhando e depois acabe desistindo dessa modificação não esqueça de remover a modificação da camada que esta trabalhando, caso o método permaneça em uma camada acima mesmo sem nenhuma alteração, caso ele seja alterado em sua camada original, seja por uma nova versão ou fix, o Ax não vai executar essa nova alteração. O overlaying também pode acontecer quando se imposta um XPO, portanto, verifique sempre se os metodos alterados realmente contém alterações!

Um bom lugar para iniciar o estudo sobre desenvolvimento no Ax é a página do MSDN do Dynamics Ax, ele é aberto ao publico e e tem informações que vão desde a arquitetura do Ax, cutomizações basicas e desenvolvimento em X++.

Vale a pena dar uma revisada no meu post sobre upgrade.

Até a próxima.

Query com range de valores

Olá!
Antes de mais nada, Feliz 2009 a todos!!!

Em posts anteriores, nos foi mostrado como se pode negar valores utilizando o objeto Query, hoje vamos ver como podemos fazer um range de valores com este objeto.

Do mesmo jeito que existe uma função queryValue(AnyType A), também existe a função queryRange(anyType _From, AnyType _To), que faz uma chamada a função SysQuery::range(_From,_To), que por sua vez, trata os valores passados como parâmetro. Por exemplo:


queryRange(1,10); //Retorna “1..10”


Com isso em mente podemos fazer um pequeno código que busca as NFs faturadas em um determinado range de datas:

static void RangeTest(Date _from, Date _to)
{
   Query query = new query();
   QueryRun queryRun;
   QueryBuildDataSource qbds;
   CustInvoiceJour custInvoiceJour;
   ;
   qbds = query.addDataSource(TableNum(CustInvoiceJour));
   qbds.addRange(FieldNum(CustInvoiceJour,InvoiceDate)).value(queryRange(_from,_to);
   queryRun = new queryRun(query);

   while(queryRun.next())
   {
       custInvoiceJour = queryRun.get(TableNum(CustInvoiceJour));
       print (CustInvoiceJour.InvoiceDate);
   }
   pause;
}

Mas, num caso em que precisarmos buscar NFs faturadas a partir de/até uma determinada data, fazemos a chamada a queryRange utilizando outra função estática de SysQuery, a valueUnlimited(). No exemplo abaixo buscamos por NFs geradas a partir da data X passada como parâmetro.

static void RangeTest(Date X)
{
   Query query = new query();
   QueryRun queryRun;
   QueryBuildDataSource qbds;
   CustInvoiceJour custInvoiceJour;
   ;
   qbds = query.addDataSource(TableNum(CustInvoiceJour));
    qbds.addRange(FieldNum(CustInvoiceJour,InvoiceDate)).value(queryRange(X,SysQuery::valueUnlimited()));
   queryRun = new queryRun(query);

   while(queryRun.next())
   {
       custInvoiceJour = queryRun.get(TableNum(CustInvoiceJour));
       print (CustInvoiceJour.InvoiceDate);
   }
   pause;
}

A classe SysQuery possui outras funções estáticas muito interessantes que ajudam, e muito, o desenvolvedor a montar suas Queries, como por exemplo:
- valueEmptyString();
- valueNot(AnyType A);
- valueNotEmptyString();

Espero que tenha ajudado!
Abs

MSBuild tasks for Dynamics Ax updated!!!

Fiz um upload de um projeto de exemplo hoje, ele limpa um AOS, pega a ultima versão do SourceSafe, gera um xpo, importa e compila, deixando o diretório com um aod pronto, porém falta completar o projeto para copiar o aod pronto para a pasta de build, alguem se habilita?

Coloquei o feed do projeto no nosso blog, assim so vou postar major updates no blog, o resto da atualizações podem ser conferidas pelo feed.

Abs,
Rodrigo