Feeds:
Posts
Comentários

BU = Unidade de Negócio

Dependendo da situação e das peculiaridades das regras de acesso à registros no Dynamics CRM, na versão 2011 algumas situações só podiam ser resolvidas via compartilhamento de registros.  A nova versão do Dynamics CRM (2013) traz uma solução mais “amigável” e organizada para estas situações, a partir do uso do “Access Team”.

Seguindo o exemplo da imagem abaixo, Pedro e Maria se encontram em BU’s paralelas, ou seja, a única solução para visualizarem os mesmos registros era o compartilhamento (share) do Dynamics. (Ou criação de equipe).

Agora esta situação pode ser atendida pelos Access Team.

Image

Access Team

Visualizando este passo-a-passo da criação e utilização do Access Team… Vocês entenderão a relação com o compartilhamento de registros e o sentido desta funcionalidade.

As entidades precisam ter o Access Team habilitado antes da criação dos Templates. Vá em Configurações -> Customização -> Customizar o Sistema -> Entidades e encontre a opção “Access Team”, como na imagem abaixo.

ENTIDADE_ACCESS_TEAM

Após habilitada a opção para a entidade, vamos criar um template de Access Team para ela. Para isso acesse: Configurações -> Administração -> Template de Time -> New.

ACESSANDO_ACCESS_TEAM_TEMPLATES

Escolha a entidade relacionada e marque as ações que deverão ser habilitadas para o mesmo. Note que as ações são as mesmas que configuramos quando compartilhamos registros: Delete, Append, Append To, Assign, Share, Read and Write.

Obs.: Podemos criar vários templates para a mesma entidade. Um apenas para leitura, outro para leitura e para criação, e assim por diante.

Neste momento estamos apenas criando o template e não definindo as PESSOAS….

ACCESS_TEAM_TEMPLATE

Agora, precisamos adicionar o SubGrid no formulário desta entidade, para permitir a relação das pessoas à este registro.

Edite o formulário e adicione um SUBGRID, seguindo as configurações da imagem abaixo: Mostrar todos os registros, relacionar à Usuário, escolher a View Associated Record Team Members e escolhendo o Template de time relacionado.

SUBGRID_ACCESS_TEAM

Salve e publique.

Neste subgrid, o proprietário do registro poderá adicionar os usuários que deseja. Os usuários relacionados terão o acesso configurado no template relacionado no subgrid.

Esta solução da a liberdade de escolher pessoas distintas para acessarem registros da mesma entidade. Por exemplo:

Projeto ABC: Pedro + Maria

Projeto DEF: Pedro + João.

RELACIONANDO_USUARIOS_ACCESS TEAM

Observações importantes

O Dynamics exige o perfil mínimo, ou seja, se o Template de time diz que o usuário terá acesso à LEITURA de OPORTUNIDADE, e o mesmo não tiver este direito nos perfis atribuídos à ele, dará a mensagem abaixo:

ADICIONANDO_USER_TEMPLATE_USER

E qual a diferença de criar equipes no Dynamics 2011?

Bom, se fosse criada uma equipe com Pedro e Maria como membros e tivesse a necessidade de compartilhar outro registro com pessoas diferentes, por exemplo, Pedro e João, teria que ser criada outra equipe só com o Pedro e João como membros. E isso se repetiria para outras combinações. Ou claro, o proprietário teria que compartilhar o registro com os usuários desejados e para cada um, definir o perfil de acesso…

Com o Access Team, mesmo utilizando o mesmo template, podemos adicionar um grupo de pessoas distinto para cada registro!

Esta nova funcionalidade permite criar regrinhas simples que antes só eram atendidas pelos “Jscripts”.

Com elas é possível esconder campos ou torna-lo obrigatório a partir de uma condição por exemplo, somar campos, entre outras validações e ações em formulário a partir de uma interface simples, intuitiva e sem código.

Neste post vou explicar cada uma destas ações que podem ser “programadas” nas Business Rules do Dynamics CRM 2013.

1) Onde são acessadas as Business Rules?

Em Configurações -> Personalização -> Entidades -> Selecione a entidade que deseja -> Business Rules:

ondeacessarbusinessrules_1

Podem também ser acessadas (e novas podem ser criadas), de dentro do formulário:

ondeacessarbusinessrules_2

Elas podem estar vinculadas à todos os formulários ou a um específico;

scopeform

Pode-se criar uma Business Rules a partir de uma existente, pela opção “Save as” e elas devem ser ATIVADAS para funcionarem.

acoes

2) Quando as regras configuradas nas Business Rules são disparadas?

Quando a condição for atendida, as ações são realizadas. Não é possível condicionar uma Business Rules como os JScripts, para acontecerem no On Load, On Save do formulário ou On Change de um campo.

O gatilho portanto, é quando a própria condição é atendida.

É possível comparar o valor de um campo com um valor específico ou com o valor de outro campo.

Para campos do tipo Lookup, aparecerá a lupa para a seleção da informação, assim como para campos do tipo Picklist, aparecerá a lista com os valores do picklist.

condition_2

condition_3_lookup

Observação importante: Tentei criar uma condição com o campo “Assunto” (Subject) do formulário “Ocorrência” (Case). E ao comparar com um VALOR, ele não aparece a opção de selecionar o assunto da árvore de assuntos e nem de colocar o valor do campo.

Ou seja, não é possível criar condições com as Business Rules para o campo Subject. Será um bug?

condition_5_subject_case

3) Quais tipos de ações é possível criar com as

Business Rules?

3.1) Mostrar mensagem de erro

A mensagem de erro deve estar relacionada à um campo específico do formulário.

showmessageerror

A mensagem aparecerá no formulário da seguinte forma:

messageerror

Detalhe importante: A mensagem de erro programada na Business Rules não impede o Save do formulário. Não sei se isso é outro bug ou não…. Mas fiquei bem decepcionada com este detalhe 😦

3.2) Bloquear/desbloquear campo do formulário

lock_unlock

3.3) Mostrar/Esconder campo do formulário

showfield

3.4) Torna um campo obrigatório ou não

notbusinessrequired

 

 

3.4) Criar condições ou ações utilizando “Fórmulas”

É possível criar condições, comparando o valor de um campo com a soma de dois campos, por exemplo.

FORMULA_CONDICAO

 

Também é possível alterar o valor de um campo “Set Field”, com o resultado de uma fórmula. A fórmula pode ser o valor de um campo somado, subtraído, dividido ou multiplicado pelo valor de outro campo, ou por um valor imputado manualmente.

 

É isso! Uma funcionalidade muito interessante!!

O Quick View Form é uma View que você pode criar e inserir em outra entidade relacionada ao registro.

Exemplo:

Quando abrir a Oportunidade, você quer mostrar alguns campos do cadastro do Cliente, como e-mail, endereço e atividades recentes, por exemplo. Isso facilita a operação do usuário, pois em um mesmo formulário, ele conseguirá ter acesso às principais informações do Cliente.

Bom, como criar este Quick View Form.

1_ Vá em Configurações -> Entidades -> Escolha a entidade que deseja criar o quick view. No nosso caso será a entidade “Account” (Conta).

2_ Crie um novo formulário do tipo Quick Form.

quickform

3_ Adicione os campos que deseja. Podem ser campos do formulário ou subgrids de entidades relacionadas. Salve e publique.

quickform_2

4_ Vá até a entidade que deseja adicionar estas informações. No nosso caso: Oportunidade.

5_ Abra o formulário que desejar, clique em “inserir” e escolha a opção Quick View Form.

quickform_3

6_ Escolha a entidade e o formulário que deseja adicionar (que será do tipo Quick View Form).

quickform_4

7_ Pronto. Salve e publique 🙂

quickform_5

quickform_6

 

Observação:

Este formulário, que aparece no painel social (dos novos formulários), também é um quick view form e os campos podem ser alterados.

quickform_7

O Dynamics 2013 está aí, com previsão de chegada em Outubro/Novembro, e para quem ainda não viu e não faz ideia de como será, fiz um apanhado das principais funcionalidades da nova versão.

O layout está sensacional e agora sim, apropriado para uso em tablets, celulares e voltado para telas touch screen.

Vale um destaque para as funcionalidades de formulários voltado à processos e possibilidade de criar uma série de regrinhas, sem a necessidade de Jscripts, apenas com as Business Rules! Isso é sensacional!

#animadissima 🙂

 

Configuração de metas no Dynamics CRM é uma das funcionalidades mais interessantes (na minha opinião), mas que gera muita dúvida.

Neste post vou demonstrar a configuração de um exemplo que envolve:

– Metas primárias e metas secundárias;

– O uso da “Consulta Acumulada”;

– Uso de dois campos de acúmulo para a métrica configurada: Tipo “real” e “em andamento”.

1) Conceito

Primeiramente, a configuração da meta é composta por quatro entidades: Meta, Métrica da Meta, Campos de Acúmulo e Consulta Acumulada.

Resumidamente (no decorrer dos exemplos vocês vão entender melhor) é o seguinte:

Meta: Basicamente é onde defino meu objetivo final (a meta), o período e o “dono” da meta.

Métrica da meta: Defino se vou usar campos do tipo valor ou quantidade para medir a meta. Exemplos:

1) Vender R$500.000,00: Métrica do tipo Valor

2) Cadastrar 100 novos prospects: Métrica do tipo Quantidade

Campos de acúmulo: Defino quais registros vou me basear para acumular minha meta.

Exemplo:

1) Oportunidades, com status Ganha (tipo de registro) e o valor da oportunidade está registrado no campo “Faturamento Real” (campo do registro que o sistema deverá utilizar para acumular a meta)

Consulta Acumulada: A consulta acumulada é como se fosse uma localização avançada, onde defino uma série de “filtros” (regras) que no momento que relaciono esta consulta na minha meta, o sistema obedece estes filtros para acumular os registros.

Exemplo:

1) Meta de venda de um Produto ou região específica.

2) Meta de cadastro de Clientes Potenciais de uma origem específica (telefonema, e-mail);

2) Exemplo Prático

Agora, para exemplificar todos estes cadastros, vou descrever uma necessidade de negócio e configurar as Metas no Dynamics.

“- Faço gestão das Oportunidades no Dynamics CRM da minha empresa e tenho um time composto por 2 vendedores, um Sênior e outro Júnior.

– Classifico minhas Oportunidades em “interessado”, “pouco interessado”, “muito interessado”.

– A meta da minha empresa é vender R$500.000,00 a cada seis meses, e divido esta meta entre meus dois vendedores da seguinte forma: O Sênior tem uma meta de R$300.000,00 e o Júnior uma meta de R$200.000,00.

– Gostaria de saber as Oportunidades que foram fechadas, mas além disso, gostaria de visualizar também as Oportunidades que estão para fechar, para ter ideia do que está em andamento. Porém, destas oportunidades em andamento, quero saber somente as que estão classificadas como “muito interessado”, para ter a visibilidade das quais realmente tem chances de serem fechadas.”

Cadastro no Dynamics

Métrica da meta: Nesta entidade determinamos o tipo da métrica, Contagem ou Valor. Neste caso, estamos falando que a meta é vender R$500.000,00 (da empresa), então, a métrica será do tipo valor. Se a meta fosse por exemplo, “Efetuar 100 novos cadastros de Leads por mês”, a métrica seria “Contagem”.

Segue abaixo a tela de configuração da meta:

Metrica_da_meta

Agora precisamos dizer que tipo de registros queremos “acompanhar”. Esta informação será cadastrada nos “Campos de Acúmulo”.

Vamos ver como ficaria no Dynamics:

Primeiro Campo de Acúmulo:

Campo de acúmulo: Podemos criar campos de acúmulo do tipo REAL e/ou EM ANDAMENTO.

É este campo que vai diferenciar o que estou contabilizando como meta atingida (REAL) e o que vou contabilizar como meta que está em andamento (“prestes a acontecer”), EM ANDAMENTO.

Neste caso, estamos falando das oportunidades fechadas e ganhas, que compõe a meta REAL. Alguns campos que precisamos preencher:

Tipo de Registros de Origem: O nome da entidade relacionada.

Campo de Origem: Qual campo o sistema vai utilizar para contar e compor o acúmulo da meta.

Estado do tipo de registro de Origem: Aqui determinamos o status do registro que o sistema se deverá acumular. Neste caso, são apenas as Oportunidades Ganhas.

Campo de data: Este campo determinada qual a data que o sistema irá considerar, para compor a meta no período pré-estabelecido.

Exemplo:

1) Data de criação da Oportunidade: 01/01/2013

2) Data de fechamento da Oportunidade: 31/03/2013

Se configurarmos a “data de criação” como o campo de data para o sistema se basear, esta oportunidade quando fechada, entrará na meta do mês da data escolhida, no caso, janeiro. Como não é isso que queremos, a data deverá ser “data de fechamento da oportunidade”.

Campo_de_Acumulo_1

Segundo campo de acúmulo: Agora quero contabilizar aquelas Oportunidades que fazem parte das “Oportunidades quase fechadas”, para ter uma visão do que está prestes a fechar.

A única diferença é que agora o Campo de Acúmulo é do tipo “Em andamento”, pois os registros acumulados com base neste cadastro deverão compor a barrinha “meta em andamento” do gráfico, e as Oportunidade em questão possuem outro status, “Aberta”, com outro campo de valor para acúmulo, “Receita estimada”.

Campo_de_Acumulo_2

Definindo a(s) Meta(s): Pronto, agora temos uma métrica e os campos de acúmulo que compõe esta métrica. Só não temos ainda as METAS.

Como definimos que a meta da empresa é composta por duas outras metas, que é a dos dois vendedores, teremos que cadastrar três metas e relacionar a Meta da EMPRESA como meta PRIMÁRIA das outras duas metas. Além disso, na meta da EMPRESA, temos que dizer que ela é calculada apenas com base nas metas secundárias (está na última sessão do cadastro).

meta

A Meta dos Vendedores é praticamente o mesmo cadastro, a única diferença é que:

– Não precisamos setar a informação de que a meta é calculada com base nas secundárias, porque elas já são metas secundárias;

– O proprietário de cada meta deverá ser os Vendedores em questão (sim, devem ser cadastradas metas para cada usuário do sistema);

– O campo “Meta primária” deverá ser preenchido com a meta da empresa, isso torna estas metas secundárias da meta da empresa;

3) Visualização das Metas sem consulta acumulada

Antes de definir os campos de acúmulo e vocês entenderem como eles funcionam, vou mostrar o que tenho no meu Dynamics de Oportunidades Abertas e Fechadas:

Esta é a consulta que vou utilizar para buscá-las, referente à Oportunidades GANHAS. A consulta das Oportunidades ABERTAS é exatamente a mesma coisa, exceto o Status que é “ABERTA”.

consulta_oportunidades_ganhas

Temos este total de Oportunidades Ganhas e Abertas por Usuário:

oportunidades_Abertas

Oportunidades GanhasTotal usuário

Vamos ver como nossa meta ficou até agora, sem nossas Consultas Acumuladas (ainda).

A parte em VERDE, é referente ao primeiro campo de acúmulo, onde definimos que as oportunidades ganhas seriam acumuladas como meta REAL;  

A parte em CINZA, é referente ao segundo campo de acúmulo, onde definimos que as oportunidades abertas seriam acumuladas como meta EM ANDAMENTO; 

Metas sem campo de acumulo

4) Visualização das Metas com a Consulta Acumulada

A consulta acumulada quando criada, deve ser relacionada no cadastro da meta (últimos campos do formulário). Posso adicionar uma consulta diferente para cada acúmulo (real e em andamento).

Vejam a consulta que criei para atender esta necessidade: “[…] destas oportunidades em andamento, quero saber somente as que estão classificadas como “muito interessado”, para ter a visibilidade das quais realmente tem chances de serem fechadas.”

consulta_acumulada

Quando trabalhamos com metas Primárias e Secundárias, as consultas acumuladas devem ser relacionadas sempre nas metas secundárias, até porque na meta primária, esta opção estará bloqueada. Então agora, é só entrar na meta e relacionar a consulta.

Percebam na imagem abaixo que o conjunto de registros para acúmulo continua sendo “que pertence ao usuário da meta”. Caso contrário, você teria que selecionar “tudo” e aí o sistema obriga que você relacione uma consulta acumulada para cada tipo de acúmulo (real e em andamento).

consulta_acumulada_na_meta

Vamos clicar em RECALCULAR META (pois lembrando que ela recalcula a cada 24 horas apenas) e perceber que a meta do Vendedor Júnior não está mais contabilizando registros em ANDAMENTO, pois como vocês perceberam na imagem das Oportunidades Abertas, apenas a Oportunidade do vendedor Sênior estava classificava como “Muito interessada”.

meta com consulta acumulada

Bom, espero que tenha tirado pelo menos a maioria das dúvidas de vocês 🙂

Qualquer coisa postem nos comentários que respondo, se puder ajudar.

Conheço a prática Planing Poker faz um tempo, porém não tinha tido a oportunidade de aplicar e desfrutar dos ótimos resultados, como tive há alguns dias atrás.

Na empresa onde trabalho ainda não temos aplicado o Scrum propriamente dito, mas trabalho com muitas práticas da metodologia [método, framework, seja o que for, rsrs] e estamos tendo ótimos resultados! O Planning Poker foi uma delas!

O Planning Poker é uma prática de estimativa de tarefas bem simples e inclusive divertida, mas muito eficiente. Muito utilizada no SCRUM, esta prática funciona da seguinte forma:

– Ao invés de estimar horas exatas estima-se em pontos;

– Os pontos utilizados no ‘jogo’ são parecidos com a sequencia do Fibonacci, ou seja, o próximo número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, … Para simplificar é muito utilizada esta sequencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Mas vai de cada um; eu por exemplo não chegaria até o 100 porque prefiro trabalhar com tarefas menores;

– Porque números tão distante entre si? Porque quanto maior uma tarefa, mais difícil de prever com precisão quantos pontos a mesma terá (e muito menos horas). Isso significa que uma estimativa de 13 pode estar entre 8 e 21… Por isso que quanto menor as tarefas, melhor para serem estimadas e a variação de pontos é melhor administrada. Sempre procure chegar no menor nível de granularidade, evitando tarefas muito grandes;

– O time do projeto se reúne com o responsável pelas regras de negócio (Analista, PO, Gerente, Cliente…) e cada um recebe as cartas do Planning Poker. Mas que isso não seja um impedimento! Se não tem cartas, improvise com os dedos (foi o que fiz, rsrs);

– As funcionalidades/tarefas são apresentadas, uma a uma e as dúvidas do time são sanadas;

– Atribui-se o peso 2 para a menor tarefa, para que esta sirva de comparativo para as demais (ex: uma laranja é maior que um morango? E que uma manga? E assim as tarefas são comparadas tendo essa de peso 2 como parâmetro);

– Inicia-se com uma atividade (pode ser por ordem de prioridade), e todos jogam a carta ao mesmo tempo;

– A ideia é discutir a variação de estimativa; porque Fulano estimou X e Ciclano estimou Y… e aí… só fazendo para ver o que acontece; a discussão que é gerada em torno das estimativas e diferentes concepções é sensacional!

– No final a equipe chega a um consenso e define o peso da tarefa, partindo para a estimativa das demais, até que todas estejam estimadas;

Bom, quando apliquei esta prática foi com um time de  8 desenvolvedores que estavam atuando diretamente no projeto e 1 desenvolvedor Sênior, fora do projeto, que participou apenas para observar a equipe e tirar eventuais dúvidas. Acabei não envolvendo quem participou da criação do layout e testes, mas seria o ideal.

O objetivo da reunião, utilizando ou não os pontos depois, foi de colaborar com o entendimento e concepção que cada um têm sobre determinada funcionalidade. Isso foi muito bom! As opiniões eram diferentes, enquanto um achava que a funcionalidade era fácil por determinados fatores, outro achava que já era complicada por outros motivos… E nessa dinâmica de cada um expor sua opinião e justificar os pontos estimados, houve uma troca de conhecimento, um amadurecimento muito interessante! Tenho certeza que cada um saiu da reunião com uma ideia diferente sobre as tarefas!

Ah mas não quero usar cartas e quero que cada um fale a estimativa que achar que seja! Não vai dar certo, sabe porque? Faça um teste. Se um falar 5, por exemplo, o restante das estimativas sempre será o mais próxima de 5 possível; as pessoas são influenciadas e com o jogo de cartas, cada um estima o que realmente acha que é. 🙂

Tem um artigo muito bom do Ramon Durães “O efeito do Planning Poker na prática“, que também vale ler.

Para quem já utilizou o Planning Poker, comente e compartilhe essa experiência!! 🙂

Wireframe é um desenho básico que representa o esqueleto do produto final. Seu objetivo é auxiliar tanto o desenvolvedor, analista ou mesmo o cliente no entendimento de como os requisitos serão representados no sistema. Mas não é utilizado apenas para desenvolvimentos de sistemas de TI, vejam abaixo alguns exemplos de rascunhos e tentem imaginar esses produtos finais sendo desenvolvidos sem eles. (Rsss)

Objetivo do Wireframe

O objetivo do Wireframe em sistemas é indicar a correta marcação de textos, campos, breadcrumbs, guidelines de marca, arquitetura da informação, usabilidade e navegação. Dependendo do nível do wireframe ele proporciona uma rica discussão com o cliente, onde muitos detalhes e requisitos são descobertos no período de elaboração/apresentação do mesmo, pois é uma forma do cliente visualizar todas as ideias discutidas e propostas.

Nível de detalhamento

Depende do nível do wireframe, pois eles podem ser construídos com diferentes níveis de detalhamento; depende de cada projeto (principalmente do tempo destinado ao wireframe). Para entenderem melhor, vejam as imagens abaixo:

Baixo nível de detalhamento

Alto nível de detalhamento 

Com certeza nesta etapa da construção do wireframe tem-se muito trabalho, mas é necessário para evitar transtornos e mudanças durante o desenvolvimento. (Posso dar um retrato falado, rsrs).

Portanto: Nunca pule a etapa do Wireframe!!! E lembre-se: Wireframe não é para ser bonito, é para ser entendido!

Propósito do Wireframe

Muitos clientes e até web designer não entendem o propósito do wireframe, achando que é o espelho do sistema final. Na verdade não é o propósito. Depois do wireframe vem toda a questão de arte e layout e se o web designer se prender no que está desenhado no wireframe, o produto poderá perder o nível da criatividade e inovação. Por isso, devemos tomar cuidado e alinhar os objetivos.

Vejam os exemplos abaixo:

Exemplo1 wireframe x site final

Exemplo2 wireframe x site atual

E para se chegar no nível do wireframe???  

Segue um video abaixo que mostra algumas etapas antes de sua elaboração. É uma das melhores formas de expor as ideias (quadro grande e post its).

Que ferramentas posso utilizar para construir um wireframe???

Existem várias ferramentas que podem ser utilizadas para criação de wireframes.

Vou mostrar abaixo exemplo de três das diversas que existem.

MockFlow

Axure

 

Balsamiq Mockups

 

 

Outras ferramentas:

  • Pencil
  • FlairBuilder
  • ForeUI
  • OmniGraffle
  • GUI Design     Studio
  • OverSite
  • Microsoft     Visio
  • FluidIA
  • WireframeSketcher
  • Justinmind Prototyper
  • DENIM
  • EasyPrototype
  • DesignerVista
  • MockApp
  • iPlotz
  • ProtoShare
  • MockFlow
  • HotGloo
  • Mockingbird
  • Cacoo
  • Jumpchart
  • Gliffy
  • Lovely     Charts
  • Lumzy
  • JustProto
  • Pidoco
  • iPhone     Mockup

Bom trabalho!

Quadro de tarefas

Obs.: Backlog é uma lista de itens priorizados a serem desenvolvidos para um software.

No projeto que estou, colocamos um quadro com post its para o acompanhamento das tarefas. A prática é do Scrum: acompanhar as tarefas que precisam ser feitas (“backlog”), as tarefas em execução e as terminadas. Simples assim já está ajudando muito a equipe toda visualizar o andamento do projeto, a qualquer momento. A divisão de tarefas ficou muito mais fácil, assim como a discussão sobre cada uma delas. Nos reunimos ao redor do quadro e movemos as tarefas “pra lá e pra cá”.

Bom, vamos deixar de lado por enquanto todos os valores e práticas do Scrum e vamos falar apenas do “quadro de tarefas”, de uma forma bem simples, para que leitores que nunca ouviram falar de Scrum possam entender.

Colocar algumas tarefas do projeto no Backlog, discutir todos os dias sobre as tarefas com a equipe e acompanhar o status de cada uma, não responde algumas questões muito importantes para o Projeto, como:

– Estamos dentro do prazo?

– Quantas tarefas faltam para a primeira entrega?

– Qual nossa meta de tarefas para esta semana (poderia ser “duas” ou “três” semanas)?

Para isso, alguns passos devem acontecer antes das tarefas chegarem no quadro; são eles:

– Defina o tamanho do “ciclo do projeto” (lembrando que o projeto pode ter vários ciclos, claro). Vamos chamar este ciclo de Time Box. O Time Box é um período fixo de dias (por exemplo, uma semana) que seja possível entregar um valor para o Cliente. O que quero dizer é que se o projeto é muito longo e o Time Box é de uma semana, talvez uma semana não seja o suficiente para “produzir alguma entrega possível de ser testada”.

– Divida as funcionalidades do projeto em pequenas tarefas. A tarefa não pode durar mais que o tamanho do Time Box, claro, se não, não é possível de concluí-la no tempo determinado. Se ela estiver muito grande, quebre-a em tarefas menores;

– Estime o tempo de cada tarefa. Existem práticas para isso, como Planning Poker, por exemplo, mas a ideia não é entrar em detalhes neste post. O tempo precisa ser estimado para conseguir identificar “quantas tarefas cabem em cada Time Box” (considerando o tamanho da equipe, claro);

– Defina por fim as tarefas que serão feitas em cada Time Box. Com isso têm-se um objetivo traçado, uma meta, um prazo para toda a equipe;

– Acompanhe diariamente as atividades da equipe, fazendo três perguntinhas famosas:

 – O que você tem feito desde ontem?

– O que você está planejando fazer hoje?

– Você tem algum problema impedindo você de realizar seu objetivo?

Com isso é possível responder aquelas três perguntas anteriores:

– Estamos dentro do prazo?

– Quantas tarefas faltam para a primeira entrega?

– Qual nossa meta de tarefas para esta semana (poderia ser “duas” ou “três” semanas)?

Somente com algumas tarefas no quadro e o  “move pra cá move pra lá” não é possível ter essa visão 🙂 É preciso definir quantas tarefas serão entregues num tempo “x” determinado.

Por isso, não achem que um quadro com post its basta para dizer que estamos usando Scrum. Tem muito para evoluir,
mas é importante começar… Um passo de cada vez 🙂

Tem um post que eu falo sobre este assunto, que pode ser interessante ler: Você usa esmo Scrum?”

Alguns meses atrás enviei um e-mail com algumas dúvidas sobre Scrum para o Ramon Durães. Quem não o conhece o site dele é http://www.ramonduraes.net/. E ele acabou fazendo um post sobre as respostas. MUITO OBRIGADA PELA ATENÇÃO e pelas respostas que foram muito esclarecedoras!

Para quem quiser saber mais sobre Scrum ele tem váaarios posts ótimos!! Vale a pena visitar seu site.

Bom, como minhas dúvidas podem ser também as suas, vou dar um CTRL+C, CTLR+V no Post dele rsrs.., que se encontra em http://www.ramonduraes.net/2011/06/02/duvidas-sobre-scrum/.

O Scrum é um framework interativo e incremental utilizado para gestão ágil de projetos de software e vem conquistando um grande número de adeptos em todo o Brasil. Com poucas regras focando no resultado e colaboração entre as pessoas tem atraído a atenção dos profissionais pela simplicdade e transparência que se conquista já nos primeiros Sprints. O Scrum acaba mostrando problemas que antes ficavam escondidos dentro dos famosos cronogramas, documentos e processos intermináveis.

Hoje recebi um e-mail com algumas dúvidas de quem está iniciando no estudo do SCRUM e estarei comentando juntamente com vocês. A minha ideia não é resolver as mesmas e sim contribuir para que juntos possamos conversar sobre cada questão e criar um entendimento usando nosso principal principio que é justamente formar um time. Ter uma cultura forte nos projetos é o maior fator de sucesso nos projetos e é algo que deve nascer e circular por toda a organização.

1) Pelo que entendo cada projeto novo tem as suas Sprints. Como Scrum trabalha com a necessidade de um dos integrantes do time precisar resolver situações de outros projetos (pontuais)? Colocam essas estórias na Sprint do projeto atual como “impedimentos”, “outras atividades”?

Com o fim da era ‘recurso’ onde você é encarado como um equipamento que tira e pluga em qualquer lugar prejudicando todos os projetos e a sua expectativa de entrega nós entramos no conceito de ‘Time” onde o seu trabalho é importante para o resultado do projeto que está participando e sua saída para fazer qualquer outra atividade seja qual for vai prejudicar a entrega do Sprint e todo esforço dos seus colegas. Estou levando em consideração que você é um membro do time. Dentro do Scrum nós trabalhamos dedicados a entregar ao final do Sprint todos os itens que assumimos como Sprint Backlog. O Sprint segue o conceito de indivisível. Portanto por padrão não deve sofrer interferências senão você quebra as expectativas e volta ao ciclo tradicional em cascata.

2) O integrante de um time pode participar de mais de um projeto ao mesmo tempo (as vezes para apoio em determinadas funcionalidades)?

O membro do time é dedicado a entregar aquele determinado Sprint. Se uma pessoa está participando de vários estará ferindo o principal principio do comprometimento por que inevitavelmente terá conflitos e ira prejudicar todos os times. A ideia de Sprint curtos de 2-4 semanas permite justamente ter entregas rápidas e contornar esse tipo de necessidade.

3) Quando o time não tem nenhum projeto novo mas está trabalhando em diversas manutenções… É criada uma “Sprint geral” do trabalho do time (envolvendo todas essas solicitações)? (Neste caso as estórias podem ser de PO’s diferentes… )

O ciclo do Scrum se repente enquanto tiver itens no backlog do PO. Cabe o mesmo adicionar mais itens e priorizar para o próximo Sprint conforme seu entendimento de valor de negócios. Em um caso de ter vários os mesmos vão organizar o backlog geral. Lebrando que toda e qualquer decisão de negócio é sempre com o Product Owner.

4) O Scrum Master pode desenvolver também?

Segundo o Scrum ele pode participar sim, porém corre um grave risco devido a função de Scrum Master ter que resolver outras questões externas e prejudicar o time deixando de contribuir como desenvolvedor do mesmo. Outro ponto importante é direto ao Scrum Master que deve está atento a deixar claro que ele não tem autoridade sobre o time e deve atuar como qualquer membro.

5) Como o cliente contrata projetos longos que usam Scrum? Por “pacote de horas”? Ou a empresa faz análise (GAPS), levanta requisitos macro, fecha ume escopo e estima um tempo?

O primeiro caminho é estimar o backlog e a depender do tamanho e das características do mesmo vocês vão decidir a profundidade dessa estimativa. Depois disso usando a experiência de vocês em Sprints anteriores terão a velocidade do time que indica quantos pontos de complexidade conseguem se comprometer e com isso podem estimar o número de sprints necessários. Com os Sprints e quantidade de pessoas que participam vocês terão uma estimativa de custo e previsão. Depois de anos de crises o mercado esta aberto a outras abordagens e uma delas é justamente o cliente contratar por Sprint e pagar até o momento que ele fique satisfeito com o valor de negócio entregue e não necessariamente o projeto completo.

Em resumo eu sempre me divirto conversando sobre Scrum principalmente por que para min ‘e uma oportunidade de crescimento constante entendo as mais variadas visões e abordagens. O Scrum ‘e tão simples que pode-se resumir a uma pagina e esse ‘justamente o objetivo de sua criação reunindo as melhores praticas e somente o necessário para você ter um norte. Com a evolução dos ciclos de Sprint vocês terão a oportunidade de reavaliar e ir adaptando conforme as necessidades que forem aparecendo. O mais importante ‘e ter em mente que a melhoria será continua e nunca terá um processo definido.

[],

Ramon Durães

Especialista em desenvolvimento de software

MVP, Visual Studio ALM

PSM, Professional Scrum Master

PSD, Professional Scrum Developer

CSM, Certified ScrumMaster