terça-feira, 23 de dezembro de 2014

JSON vs XML

Por muito tempo, XML foi a única opção para transferir dados via web. Como não existiam outras opções, XML era utilizado para todas as aplicações que necessitavam transferir dados. Este formato era utilizado para transferir dados de texto e numérico, e também utilizado para transferência de documentos, imagens, áudio, vídeo e muito mais. Agora que temos outras opções, o XML foi sobrepujado em diversas maneiras. Nos dias de hoje temos a opção de escolher entre JSON e XML quando criamos arquivos de dados.

Com o JSON, você estará limitado a enviar apenas dados do tipo texto e numérico, já o XML lhe dá a liberdade de enviar qualquer tipo de dado que você deseja. Esta habilidade permite o XML ser mais flexível que o JSON. Entretanto, isto dificulta a leitura do XML, deixando o arquivo mais extenso, para que possam ser trafegados arquivos de imagens, gráficos, e outros tipos de arquivos. Como a transferência de arquivos clássicos, que contem somente dados, não se torna necessária toda essa ‘extensabilidade’ podendo ser beneficiado da simplicidade do JSON, onde os arquivos são gravados na forma de array, utilizando de uma familiar a linguagem orientada a objetos. Esta formatação permite uma fácil importação de dados do JSON para as linguagens de programação.


Essa simplicidade com a qual o JSON cria os arquivos é o que deixa muito mais rápido o tráfego dos arquivos, pois o arquivo já vem no formato de dados, enquanto no XML você tem que transformar o arquivo no formato de dados antes de importar, o que faz o JSON ser um tipo de formato superior para web APIs.

fonte:
https://www.udemy.com/blog/json-vs-xml/

terça-feira, 28 de outubro de 2014

Test Driven Development (TDD) em PHP

Neste post vamos abordar o Test Driven Development (TDD) em PHP, que é um dos principios core do XP e está disponivel nativo para linguagem java no netbeans. Entretanto, para habilitar essa ferramenta para o PHP no ambiente Windows devemos fazer algumas configurações no ambiente que seguem:


  1. Instalar o NetBeans;
  2. Instalar o Xampp;
  3. Configurar o PHPUnit pelo pear no xampp com os seguintes comandos:
  4. Abrir o Shell;
  5. Digitar “pear config-set auto_discover 1”
  6. Digitar “pear install pear.phpunit.de/PHPUnit”
  7. Agora o PHPUnit já está configurado na pasta c:\xampp\php\
  8. Baixar o arquivo phpunit.phar em https://phar.phpunit.de/phpunit.phar
  9. Baixar o arquivo phpunit-skelgen.phar em https://phar.phpunit.de/phpunit-skelgen.phar
  10. Salvar os dois arquivos em c:\xampp\php\
  11. Para configurar o phpunit no netbeans faça o seguinte:
    1. Vá em ferramentas;
    2. Em opções aponte os arquivos conforme as imagens abaixo:



Agora o NetBeans já está configurado para aceitar projetos com a criação de classes de testes. A proxima etapa é criar um novo projeto PHP. Com o projeto criado deve-se criar a classe PHP que será desenvolvida a partir de testes. Agora deve-se criar os testes. Clique com o botão direito sobre a pasta “Arquivos de Código-Fonte” ir em “Ferramentas” e depois “Criar Testes”.


Deve-se criar uma pasta de testes dentro do projeto, onde serão geradas as classes de testes pelo skelgen, e durante o assistente de criação dos testes assinalar a opção de utilizar o PHPUnit.


O ultimo passo é criar a classe de testes, que é criada automaticamente clicando com o botão direito em cima do arquivo da classe PHP, que foi criada anteriormente e onde serão desenvolvidos os métodos,  ir em “Ferramentas” e depois “Criar Testes”.


Agora o arquivo o testes já foi criado, só tem que ter cuidado de sempre começar o método de testes começando com “testAlgumaCoisa”, segue abaixo uma sugestão de código para as classes onde estarão os métodos e onde estarão os testes:


Salario.php
<?php


/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/


/**
* Description of Salario
*
* @author GUSTAVO
*/
class Salario {
   //put your code here
   
   public function index($bonus = null){
       $salario =  1500.35;
       
       if($bonus){
           $salario += $bonus;
       }
       
       return $salario;
   }
   
   public function desconto($salario){
       
       $desconto = 8;
       
       if(($salario > 1317.07) and ($salario < 2195.13)){
           $desconto = 9;
       } elseif($salario > 2195.12){
           $desconto = 11;
       }
       
       return $desconto;
   }


   public function descontoINSS($salario) {
       
       if($salario > 4390.24){
           $salario = 4390.24;
       }
       
       $percentual = $this->desconto($salario);
       
       $desconto = $salario * $percentual / 100;
       
       return number_format($desconto, 2);
   }


}


SalarioTest.php
<?php
require_once "../Salario.php";


/**
* Generated by PHPUnit_SkeletonGenerator on 2014-10-21 at 14:01:05.
*/
class SalarioTest extends PHPUnit_Framework_TestCase
{


   /**
    * @covers Salario::index
    * @todo   Implement testIndex().
    */
   public function testIndex(){
       $salario = new Salario();
       $this->assertEquals(1500.35, $salario->index());
   }
   
   public function testIndexComBonus(){
       $salario = new Salario();
       $this->assertEquals(1550.35, $salario->index(50));
   }


   public function testDesconto(){
       $salario = new Salario();
       $this->assertEquals(11, $salario->desconto(10000));
   }
   
   public function testValorINSSMinimo(){
       $salario = new Salario();
       $this->assertEquals(80, $salario->descontoINSS(1000));
   }
   
   public function testValorINSSMedio(){
       $salario = new Salario();
       $this->assertEquals(180, $salario->descontoINSS(2000));
   }
   
   public function testValorINSSAlto(){
       $salario = new Salario();
       $this->assertEquals(440, $salario->descontoINSS(4000));
   }
   
   public function testValorINSSTeto(){
       $salario = new Salario();
       $this->assertEquals(482.93, $salario->descontoINSS(9390.24));
   }


}

quinta-feira, 16 de outubro de 2014

Resumindo o Disciplined Agile Delivery

Livro do Scott W. Ambler sobre a metodologia aplicada na IBM.



Essa metodologia de trabalho promove uma colaboração entre os desenvolvedores e os contratantes do software. Este método visa a adicionar valor à organização, mantendo a agilidade e se focando na qualidade do sistema a ser entregue (e.g., work smarter, not harder).

Não deveria ser uma surpresa que trabalhar em uma equipe unida e colaborativa que visa a produzir software em funcionamento obtém melhores resultados do que times que trabalham em locais separados onde se importam somente em sucesso individual ao invés do desempenho de equipe. Também não seria uma surpresa que reduzir documentação e a burocracia administrativa reduziria custos e diminuiria o tempo de entrega do produto.

Utilizar metodologias ágeis não é desculpa para ser indisciplinado. A execução destas novas metodologias, como XP, por exemplo, sempre demandaram uma abordagem disciplinada, e certamente muito mais do que as metodologias tradicionais como waterfall. Não se deve misturar o alto nível de burocracia e controle dos métodos tradicionais como sinal de disciplina.

Pessoas em Primeiro Lugar

O DAD promove uma busca para ajudar os times de desenvolvimento a melhorar sua efetividade, entretanto não prescreve procedimentos obrigatórios para se chegar neste objetivo.

Alguma documentação será exigida, mas raramente tanto quanto é exigida nos métodos tradicionais. A integração entre pessoas (clientes e desenvolvedores) dá oportunidades para sanar mal-entendidos e diminuir os defeitos dos sistemas a serem entregas, o que é tratado na cultura de prevenção de desperdícios da metodologia Lean. Pois quando criamos um documento raramente pomos no papel nosso completo entendimento do que estamos descrevendo, e inevitavelmente algum conhecimento é ‘deixado para traz’ eis o que o conhecimento tácito não é passado adiante.

Os membros de um time que aplica a metodologia DAD devem possuir os seguintes atributos:
  •   Disciplina para se comprometer apenas com o trabalho que conseguem realizar e trabalhar da melhor maneira possível para realizar o seu trabalho;
  • Organização para estimar e planejar o seu trabalho de uma maneira que possam realizar entregas constantes;
  • Autodidata para identificar o que melhor funciona para si e o que não funciona, tendo oportunidade de aprender e se ajustar.

Metodologias Ágeis

Times de desenvolvimento que buscam trabalhar de maneira iterativa tem mostrado que produzem soluções de maior qualidade, proporcionando um maior retorno do investimento, bem como a satisfação dos clientes e entregando as soluções mais rápido que as abordagens tradicionais, como a waterfall. A satisfação dos clientes está diretamente ligada a participação deles no projeto durante cada iteração, e em conjunto com eles melhorando os requisitos do software que será desenvolvido no final do projeto.

Processo Hibrido de Desenvolvimento

DAD é um conjunto de diversas estratégias e praticas de tanto de metodologias ágeis quanto dos métodos tradicionais. No DAD é utilizado o ciclo de vida do Scrum adotando entregas continuas de software bem como utilizando técnicas Lean de desenvolvimento. Muitas das praticas sugeridas pelo DAD são comumente discutidas na comunidade ágil, tais como integração contínua, reuniões diárias e refatoração bem como algumas praticam avançadas que são muito aplicadas, porém pouco discutidas por alguma razão. São, dentre outras, o levantamento inicial de requisitos, estudo da arquitetura a ser utilizada, e testes no final do ciclo de desenvolvimento.

Consciência Empresarial

Os times DAD trabalham dentro do seu ecossistema empresarial, assim como outros times, e visam a aproveitar as vantagens apresentadas a eles – personificando o clichê: “agir localmente e pensar globalmente”. Em outras palavras, os times DAD devem adotar como mentalidade ‘a empresa como um todo’.

Ter uma consciência empresarial é importante que os times busquem, como profissionais, o que é melhor para organização e não somente o que lhes interessa.

Foco no Risco e Valor

DAD adota um ciclo de vida voltado ao chamado foco no risco e valor, o que é muito comum nos métodos ágeis como Scrum e XP. Trabalhando com foco no risco e valor o time acaba produzindo material entregável em cada iteração, ou mais precisamente a partir da perspectiva do DAD, um material potencialmente consumível em cada iteração. Essas entregas representam aqueles que tem maior valor na perspectiva dos clientes. Deve ser considerado também o risco de entrega nos itens de alta prioridade e não somente os de maior valor. Sempre tomando cuidado com os três principais riscos:
1.       O risco de não entregar nada;
2.       O risco de entregar o software sem funcionalidade;
3.       O risco político de ter pouca visibilidade sobre o que o time esta produzindo.

Conclusão


Disciplined Agile Delivery (DAD) é um processo hibrido que combina as praticas e estratégias do Scrum, Extreme Programming (XP) e Agile Modeling (AM) e complementa com algumas outras, como Agile Data e Kanban, adotando um ciclo de vida de entrega total.

segunda-feira, 6 de outubro de 2014

Disciplined Agile Delivery – Scott W. Ambler

Essa postagem é uma introdução ao livro do Scott Ambler, que trata de DAD.

Scott Ambler percebeu que a realidade de muitas empresas era algo parecido com uma water-scrum-fall, na forma de que a maioria das empresas não aceitava iniciar seus projetos sem que antes tenham uma lenta fase de definição de requisitos, planejamento detalhado do projeto e até fazendo algum design. Essa abordagem não é de todo mal, ela permite que as empresas se beneficiem de práticas ágeis, como trabalho iterativo, desenvolvimento voltado a testes e entregas contínuas. Entretanto não é liberado todo o potencial da abordagem ágil. Empresas ágeis não somente criam os softwares de maneira mais eficiente, mas o mais importante é que entregam um software com grande valor de negocio.  

Porque Disciplined Agile Delivery?

Está constatado que métodos ágeis, como Scrum, funcionam muito bem para times de pequenos projetos, onde são trabalhados problemas com baixo risco ou consequências de falhas. Entretanto, esses métodos não trazem segurança para projetos de maior escala, e o resultado acaba sendo que as empresas investem muito esforço criando processos híbridos, combinando metodologias de diferentes fontes. O processo Disciplined Agile Delivery (DAD), como é descrito no livro do Scott Ambler, é uma abordagem hibrida, que busca técnicas do Scrum, Agile Modeling, EX, Unified Process e Kanban dentre outras metodologias. O processo do DAD inclui praticas que estão faltantes no Scrun e XP como modelagem e documentação. O mais importante é que o DAD permite que o processo seja ajustado efetivamente as necessidades da situação em que você se encontra. Descrevendo o que funciona e o que não funciona, e o mais importante porque, o DAD ajuda a aumentar as chances de adotar estratégias que vão funcionar para você. 

quinta-feira, 25 de setembro de 2014

Bad Smell


- 4 características que eu considero essenciais, presentes em um código ruim:

Código duplicado: Esse smell geralmente acontece quando temos uma classe god, e acabamos escrevendo duas ou mais vezes a mesma lógica, que poderia ser escrita uma vez só, caso aplicássemos as regras de orientação a objetos e polimorfismo.  Nesse caso é gerado código muito grande e desnecessário.

Lista de parâmetros longa: Essa regra é muito utilizada quando começamos a programar, mas pode causar um transtorno quando não vamos utilizar todos os parâmetros, bem como dificulta o entendimento do código. A ideia de passar um objeto ao invés de parâmetros.

Classes alternativas com diferentes interfaces: Esse smell é gerado quando temos duas ou mais classes que fazem (ou fazem quase) a mesma coisa, porém com nomes diferentes.

Classe de dados: São classes que só contem atributos (getters e setters), que geralmente são acessadas e manipuladas por outras classes. Geralmente são nada mais que depósitos de dados

- 4 características que eu considero essenciais, presentes em um código bom:

Nomes significativos: Usar nomes nos atributos e métodos que transcrevam o modelo de design ajuda na manutenção e no entendimento do código por outros desenvolvedores.

Indentação de código: Deixar o código bem organizado e ter um padrão a ser seguido pelo time é essencial para o bom entendimento da estrutura lógica do código.

Uso de Exceções: Além de deixar o código mais legível, previne o código contra falhas nos tratamentos de arquivos, entradas de dados inválidas, erros de consultas à base de dados, entre outras.

Test Driven Development:  Ajuda a focar no resultado final, e nos garante uma refatoração mais segura das classes, garantindo que ao alterar um método, todos os requisitos do software serão atendidos, sem a necessidade de testar os mesmos a cada mudança, deixando essa parte automatizada.

terça-feira, 16 de setembro de 2014

Domain Driven Design 3

Este é o ultimo post sobre DDD, onde farei o resumo do capítulo 3 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:


Para a criação de um modelo correto, que venha realmente a capturar as regras do domínio, os analistas de software e os peritos no domínio se reúnem por meses, para descobrir os elementos fundamentais do domínio, enfatizando os relacionamentos. Os desenvolvedores podem vir a se juntar ao time para verificar a possibilidade de expressar no código esses conceitos e relacionamentos desenhados no modelo. Assim começa a criação de um modelo, com inspiração no modelo original, adicionando algumas ideias da equipe técnica.

Uma técnica muito utilizada é a criação do modelo de análise, que é separado do código e feito por pessoas diferentes. Neste modelo temos ênfase na regra de negocio, e nenhuma ênfase na codificação a ser implementada no software. É gerado certo nível de conhecimento a respeito do software a ser desenvolvido. Com base nesse modelo, os desenvolvedores irão adapta-lo para um modelo que irá guiar a equipe de desenvolvimento.

Um dos principais problemas dessa técnica é que como os analistas não conseguem enxergar além das regras de negócios, o modelo pode se aprofundar em determinadas questões que não irão ser tão pertinentes para a regra de desenvolvimento. E podem esquecer outros pontos, que podem vir a ser importante para elucidação da equipe de desenvolvimento.

Em razão desta falta de documentação, os desenvolvedores terão que tomar algumas decisões por sua conta, que visarão resolver ou solucionar algum problema real que não foi considerado no modelo criado e acabam criando um modelo que foge um pouco do modelo original.

Normalmente os analistas têm reuniões fechadas, onde discutem a respeito do modelo a ser desenvolvido, e neste momento muita informação valiosa é compartilhada nessas reuniões. Eles criam um modelo que supostamente contem toda informação de uma maneira condensada, e os desenvolvedores deverão assimilar essa informação lendo a documentação que lhes foi dada. Uma sugestão é que seria muito mais produtivo que os desenvolvedores participassem dessas reuniões com os analistas para conseguir capturar um melhor conhecimento da regra negocio e poderem desenhar um modelo mais completo.

Uma melhor abordagem é relacionar o domínio de modelo com o design. O modelo deve ser desenhado com foco no desenvolvimento do software e nas considerações de design. Os desenvolvedores devem ser incluídos no processo de modelagem. A ideia principal é escrever um modelo que melhor expressa o software a ser desenvolvido, deixando ele fortemente relacionado com a codificação a ser escrita, e consequentemente tornando o modelo mais relevante.

Manter os desenvolvedores envolvidos neste processo ocasiona feedback por parte dos mesmos. Acaba gerando uma segurança de que o modelo poderá ser implementado no software. Se algo estiver errado, poderá ser identificado logo, e o problema será facilmente corrigido.

É importante que todo time técnico, responsável por desenvolver e manter o código tenha algum contato com o modelo. Todos tem ter algum nível de contato e discussão a respeito do modelo e com os especialistas na regra de negocio.  Esse envolvimento entre todas as partes interessados ajudaram a criar a Ubiquitous Language.

Programação Orientada a Objetos é a mais adequada e que mais combina com a implementação de modelo. Ambas se baseiam nos mesmos paradigmas. O desenvolvimento OO trabalha com classes de objetos, associações entre as classes e instancias de objetos. Linguagens OO torna possível a criação de mapeamentos diretos entre objetos do modelo com seus relacionamentos.


terça-feira, 2 de setembro de 2014

Domain Driven Design 2

Neste post farei o resumo do capítulo 2 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

Existe uma grande diferença entre a mentalidade de desenvolvedores e analistas de negocio. Os desenvolvedores costumam pensar e imaginar o sistema na forma de classes, métodos, algoritmos, e tendem sempre a fazer uma ligação entre os conceitos do mundo real com os conceitos de relações e modelagens. Eles pensam em termos de herança, polimorfismo, Orientação a Objetos, etc,... Já os especialistas no negocio não entendem nada a respeito de bibliotecas, frameworks, persistências, e, em muitos casos, não conhecem até mesmo banco de dados. Eles sabem somente a respeito das regras do negócio.

Um dos princípios fundamentais do DDD é usar uma linguagem focada no modelo, e é sugerido que esta linguagem seja adotada em comum tanto para documentação quanto para programação. Este princípio é essencial para integração entre os especialistas de negocio e desenvolvedores.

Quando o time como um todo começa a usar essa linguagem comum em todas as partes do projeto, tanto para se comunicar, como documentar e desenvolver, acabam gerando uma linguagem conhecida no DDD como Ubiquitous Language.

Essa linguagem em comum cria a premissa de que toda a equipe, ao usar a mesma linguagem, irá descobrir ao longo dos meses, como o sistema deverá funcionar e ajudará a descobrir inconsistências e conceitos inadequados no design.

Para tanto, os especialistas no negócio deverão se opor a termos técnicos ou difíceis de entender no modelo de negocio. Se no modelo tiver algum termo que eles não consigam entender, então provavelmente algo está errado. Assim como os desenvolvedores devem ficar atentos a inconsistências ou ambiguidades no modelo.

Ao escrever o código usando a Ubiquitous Language para criação de classes, métodos e atributos estará sendo feita uma ligação entre o modelo e código. Esta prática vem a ser de extrema utilidade, visto que torna o código muito mais legível, e auxiliará, posteriormente, nas alterações do código conforme o crescimento do projeto.

Uma maneira eficaz para expressar classes, atributos e relacionamentos é através da UML, entretanto, o comportamento entre as classes não é tão facilmente expressado através desta documentação. Entretanto, pode-se utilizar de notações no diagrama para tentar explicar o comportamento esperado dos objetos. Esta documentação explicativa pode vir através de pequenos diagramas de uma parte do modelo contendo a explicação necessária. Nestes diagramas podem aparecer diversas classes e seus respectivos relacionamentos.

Esta documentação é de caráter temporário, podendo ser feita, inclusive, a mão, significando pode ser mudada em um futuro próximo, assim como o modelo pode ser alterado diversas vezes até ficar estável. De acordo com as práticas da comunidade de Extreme Programming pode-se incluir o código na documentação, pois um código bem escrito, utilizando as praticas de TDD (Test Driven Development) e a Ubiquitous Language nas classes e atributos pode deixar a codificação muito comunicativa.

quarta-feira, 27 de agosto de 2014

Domain Driven Design 1

Recentemente comecei a estudar mais a fundo UML e me foi apresentada a técnica de Domain Driven Design de Eric Evans, que vem a combinar a linguagem de domínio com a linguagem de programação, ajudando a criação da documentação UML e uma codificação mais voltada as expectativas do cliente.
Para tanto, fiz umas pesquisas e encontrei o Livro: Domain Driven Design Quickly na InfoQ:
Com base no que li no livro fiz uma serie de resumos por capítulos, que visam explicar do que se tratam DDD e como podemos utilizar dessa técnica para entregar um software de qualidade e de fácil manutenção.

CAPITULO 1

Domain Driven Design combina práticas de projeto (analise) e desenvolvimento, e nos mostra como o design (documentação) e desenvolvimento podem trabalhar juntos para criar um melhor software. Um bom design vai acelerar o desenvolvimento, enquanto o feedback vindo do processo de desenvolvimento irá melhorar o design.
Nós não podemos apenas sentar e começar a codificar. Até podemos fazer isto, e até que funciona bem para casos triviais. Mas não podemos criar um software complexo com essa metodologia.
É possível criar um software bancário complexo sem um bom conhecimento de domínio (regra de negócio)? De jeito nenhum. Nunca.

Quem é que sabe como o software bancário deve funcionar? O arquiteto de software? Não, ele só usa o banco para manter seu dinheiro seguro e disponível. O analista de software? Não. Ele até que sabe analisar um determinado tema, quando lhe é dado a ele todos os ingredientes necessários. O desenvolvedor? Nem pensar. Quem, então? O sistema bancário é muito bem compreendido pelas pessoas que trabalham no banco, por seus especialistas. Eles sabem de todos os detalhes, todos os possíveis problemas, todas as regras de negocio. É por eles que devemos sempre começar. Eles são detentores do domínio.

Existem dois grandes tipos de diferentes abordagens para o desenvolvimento de software. Um deles é o método waterfall. Este método envolve uma série de etapas. Primeiramente os especialistas em negócios recolhem um conjunto de requisitos que são passados aos analistas de negócios. Os analistas criam um modelo com base nesses requisitos, e passam a documentação para os desenvolvedores, que começam a codificação com base no que eles receberam. É um fluxo contínuo de trabalho. Embora esta tenha sido uma abordagem tradicional em design de software, e tem sido usado com certo nível de sucesso ao longo dos anos, ele tem seus defeitos e limites. O principal problema é que não há feedback dos analistas para os especialistas em negócios ou dos desenvolvedores para os analistas.

Outra abordagem é a utilização de metodologias ágeis, como Scrum. Estas metodologias são um movimento coletivo contra a abordagem waterfall, decorrente das dificuldades de reunir todos os requisitos do software, considerando que normalmente ocorrem mudanças destes requisitos. A realidade é de que é difícil criar um modelo completo que abranja todos os aspectos de um domínio inicialmente. Normalmente um design possuiu diversas regras de negócios, e dificilmente irá prever alguns dos efeitos colaterais negativos ou erros que podem surgir durante o projeto.

Outro problema os métodos ágeis tentam solucionar é a chamada "analysis paralysis", que acontece quando membros da equipe ficam com tanto medo de tomar qualquer decisão de design que eles acabam não fazem nenhum progresso. Embora os defensores ágeis reconheçam a importância da definição de design, não ficam presos ao design inicial. Em vez disso, eles empregam uma grande flexibilidade nas implementações, e através do desenvolvimento iterativo com a participação contínua das partes interessadas do negócio e bastante refatoração de código, a equipe de desenvolvimento começa a aprender mais sobre a regra de negocio e poderá produzir um software que melhor atenda às necessidades dos clientes.

Os métodos ágeis também têm seus problemas e limitações, eles defendem a simplicidade, mas como todo mundo tem sua própria visão de simplicidade pode acabar numa documentação desatualizada. Em razão disto, uma a refatoração contínua feita pelos desenvolvedores sem um design sólido e atualizado irá produzir um código que é difícil de compreender e dar manutenção.

O modelo de Design será moldado durante as entrevistas iniciais de analise com base nas respostas coletadas. Assim acabarão surgindo conceitos essenciais do domínio do sistema a ser desenvolvido. Esses conceitos poderão aparecer de forma desorganizada, mas mesmo assim são essenciais para a compreensão da regra de negocio. Devemos aprender o máximo possível sobre o domínio com os especialistas nas entrevistas. Fazendo as perguntas certas para poder processar a informação da maneira correta para começar a criação modelo de domínio. Este modelo não será completo nem definitivo, mas já é o começo que precisamos.

Os especialistas conhecem bem sua área de atuação, e conseguem organizar e utilizar seus conhecimentos de uma maneira específica para realizar o seu trabalho, entretanto não sabem a melhor maneira a ser implementada em um software. A mente analítica do designer de software deverá desvendar alguns dos conceitos chave do domínio durante as entrevistas com especialistas de domínio, e assim construir uma estrutura que norteará futuras discussões.

terça-feira, 19 de agosto de 2014

Entendendo as métricas e indicadores para desenvolvimento LEAN



Quando utilizamos uma metodologia de trabalho LEAN com base no Kanban dividimos o trabalho em pequenas etapas, como, por exemplo, em um processo de desenvolvimento de softwares temos as etapas de Backlog (aprovação e documentação), Desenvolvimento, Teste Solicitante, Teste Suporte, Publicação, Finalizar (manualizar e comunicar clientes).

Adotar métricas e indicadores é uma medida eficaz para que as equipes possam entregar software em menor tempo e com melhor desempenho para seus clientes. Existem diversas métricas que serão explicadas na tabela abaixo. Estes indicadores são feitos para times que utilizam o Kanban como ferramenta para gerenciar o seu processo de desenvolvimento.

Além de que, o Kanban em si só já ajuda a limitar e monitorar o trabalho em progresso e consequentemente aumentando a qualidade e a velocidade de entrega do software.


METRICA
DESCRIÇÃO
VALOR AGREGADO
MEDIÇÃO
Inicio ao Fim
Lead Time
Da data de registro da ideia até o final do processo de desenvolvimento incluindo tempo que o projeto ficou trancado
Prove uma visão inteira do tempo que demora um projeto desde o tempo de sua concepção até a entrega para o usuário
Desempenho Histórico
Entrega
Lead Time
Tempo que o software ficou desde o registro do backlog até a conclusão
Permite a empresa ter uma data de entrega precisa para cada tipo de solicitação
Promessa de Entrega
Processo
Cycle Time
Registra o tempo em cada etapa do quadro Kanban
Permite identificar gargalos e verificar as causas de demora de entrega de software
Melhoria de Processo
Solicitações
Verifica o numero de solicitações sendo desenvolvidas durante o mês
Prove uma visão da quantidade de pedidos sendo feitos pelos clientes
Lançamento de versões
Entregas
Numero de entregas de desenvolvimentos realizados por mês
Fornece dados a respeito da quantidade de entrega de novos softwares aos clientes
Lançamento de versões
Capacidade de Trabalho
Quantidade de processos sendo realizados por cada equipe
Quantificar os limites das raias baseados com o trabalho realizado pelas equipes
Métrica de Performance
Acerto de Previsao
Percentual de desenvolvimentos que foram realizados dentro do prazo previsto / orçado
Identifica qual parte do processo precisa ser revista e se está faltando alguma fase do processo
Métrica de Performance
Tempo de Correção
Quantidade de horas gastas resolvendo um erro ou um problema de negocio que impede um trabalho de ser completado
Prove uma visão interna a respeito de quanto um defeito / erro está interferindo nas atividades
Métrica de Performance
Melhoria de Processo
Erros Encontrados
Quantidade de idas VS voltas de solicitações sobre um determinado período de tempo
Frequência que um software é desenvolvido sem retornar etapas
Melhoria de Qualidade

fonte:
http://leanagilechange.com/leanagilewiki/index.php?title=Kanban_Metrics_%26_Improvements