Month: February 2018

VSTS – Processo de Release

Contexto: criar e configurar o processo de Release dentro do VSTS, gerenciando os artefatos e pipelines

Leitura recomendada: recomendo a leitura do artigo VSTS – Build e Release para entendimento do processo de Build e Release utilizando o VSTS

Criando o Processo de Release

O primeiro passo para criar um novo processo de Release é acessar o Visual Studio e escolher a opção “Releases” dentro do Menu “Build and Release”.

No canto esquerdo, clique no botão “+” e escolha a opção “Create release definition“. release-definition

E então é criada a Pipeline para a publicação dos binários:release-pipeline

Escolha o template que será utilizado para o projeto ou a opção “Empty Process”. Defina o nome para o ambiente que será feito o deploy no servidor e os owners do ambiente.release-environment

Adicionando o artefato de Build

A etapa posterior é testar os binários nos ambientes. Para isso, devemos adicionar o Build que será promovido nos ambientes. No Pipeline de Release, clique em “+ Add Artifact” e selecione o Build que será promovido no Pipeline de Release:

  • Source Type: escolha a opção Build
  • Project: (defina o nome do projeto que será utilizado)
  • Source (Build Definition): será o Build da última versão desenvolvida
  • Clique em Add…

release-artifact

 

Adicionando Tasks nos ambientes

E agora podemos adicionar as Tasks em cada um dos servidores. Para isso, acesse a Release criada (clicando no nome da Release) > Environments. Clique no link para adição / edição das tasks:
release-environments

Em Agent Phase, defina os seguintes parâmetros:
release-agent-phase

E em “+” para adicionar uma nova Task:
release-agent-phase-I

 

Em Add Tasks, no campo Search, digite Tokenize:
tokenize
Caso a task não esteja instalada no seu VSTS, ela deve ser baixada através do Market Place. Ela tem por objetivo mudar as linhas do Web.confg de acordo com o ambiente.  Clique em Add para adicionar a task e configure a task de Tokenize:
tokenize_I

Na aba Variables, podemos configurar as variáveis de ambiente oriundas do Web.Config
release-web-config

Em seguida, adicione uma Nova Task chamada Windows Machine File Copy e configure os parâmetros abaixo:
windows-machine

No VSTS existe a possibilidade de clonar os ambientes afim de aproveitar as configurações prévias. Para isso vá ao Pipeline > Environments > e clique em Clone. Será criado um novo ambiente para promoção do binário. Assim, teremos a esteira pronta para os servidores.
esteira

 

101 (one-on-one) Meetings – reuniões de engajamento com sua equipe

1 Comment

As reuniões de 101 (one-on-one) são realizadas individualmente entre gestor e liderado, considerando um ambiente seguro e privado para uma boa comunicação. Elas trazem benefícios as empresas e aos colaboradores, como alguns temas citados no livro First, Break All The Rules da Gallup – autoridade mundial em engajamento – que menciona aspectos fundamentais para gerar engajamento no ambiente de trabalho.

A sensação de ser ouvido pela organização e a preocupação com o lado pessoal do colaborador são alguns destes aspectos. Outrossim, itens como desenvolvimento, carreira e feedback são outros benefícios percebidos nas reuniões de one-on-one.

Tenha em mente que 101 não é uma reunião de status report, e sim, uma reunião de:

  • Engajamento dos colaboradores, ouvindo abertamente e provendo feedbacks
  • Aumentar a confiança entre gestor e liderado
  • Ofercer suporte
  • Comunicação direta, evitando ruídos e interpretações erradas
  • Entender como as coisas estão indo: frustações e o que está indo bem com o colaborador


Cadência das reuniões 101
Em geral, a cada 15 dias os gestores conversam 101 com seus liderados. Utilize bem o tempo para conversar sobre prioridades, gestão, carreira, feedback e principalmente engajar o relacionamento com seus colaboradores. Tente não cancelar nem remarcar as reuniões, elas são muito importantes para avaliar o momento da sua equipe. Uma insatisfação momentanea, por exemplo, pode gerar turnover no time. Isso poderia ser evitado com uma ação identificada na reunião de 101.

Em equipes que trabalham com métodos ágeis – sprints de 10 a 15 dias – a identificação de motivadores na equipe pode influenciar totalmente os resultados de entrega da sprint. Por isso, a cadência e engajamento são importantes e devem ser mantidos afim de encontrar os desvios na equipe as soon as possible.

As reuniões duram cerca de 30 minutos e há diversas formas de conduzir 101 meetings. Mantenha o foco em ouvir o funcionário e solicite uma preparação prévia. Bill Campbell (mentor de Steve Jobs e Jeff Bezos) recomenda que “líder e liderado preparam suas pautas antes da 101 e, no momento da reunião, comparam suas pautas e definem os assuntos que irão priorizar”.

Anote os principais tópicos da conversa e estabeleça um plano de follow up até o próximo encontro, que já deve ser acordado no final da reunião. Assim, a reunião será mais produtiva.
Roteiros sugestivos para realização de 101 meetings

1. 80% da reunião fica com o funcionário e 20% para falar sobre a empresa

Caso o funcionário não tenha claro um roteiro para a reunião, sugira itens como:
– Como está sua satisfação no trabalho?
– E com relação a equipe? Há algum problema ou ponto a ser melhorado em alguém?
– Tudo ok com sua vida pessoal?
– Tem algo que eu possa te ajudar no trabalho? Ou que preciso melhorar?
– Sente falta de alguma tecnologia, forma de trabalho ou recurso?
– Sinta-se a vontade para falar sobre qualquer outro item

Sobre a empresa:
– O que podemos fazer para melhorar o ambiente da empresa?
– Descrever um pouco mais sobre as diretrizes da empresa e visão futura
– Esclarecer o que a empresa espera do colaborador
– Benefícios e carreira está ok?
– Há algum colega de trabalho que você admira ou precisa melhorar?
– Tem algo te incomodando na empresa? Ou que podemos fazer?
2. 10 minutos para o funcionário; 10 minutos para o gestor; 10 minutos para falar sobre a empresa

O clima e relacionamento devem ser mantidos como fundamentais na reunião. As perguntas mencionadas anteriormente ajudam a entender melhor sobre a equipe e ambiente de trabalho. Fique a vontade para falar sobre questões pessoais, como viagem e filhos, isso contribuirá para uma relação de confiança entre ambos.

Como gestor não deixe de falar sobre a performance alinhada com as entregas e metas estabelecida. Serão inputs valiosos para o desenvolvimento e evolução profissional. O feedback é outro ponto valorizado, colaborando com o que deve ser melhorado no liderado. Solicite também feedback do que pode ser melhorado como gestor.

A 15 Five sugere que ocasionalmente as reuniões sejam feitas junto a uma caminhada para facilitar a discussão dos tópicos, devido ao ambiente mais descontraído.

15-five


Por fim…
O propósito deste post não é recomendar um método de como executar 101 meetings, e sim, criar provocações sobre o tema e a importância de conhecer melhor sua equipe. As reuniões 101 certamente contribuem com o engajamento do time e melhoria dos resultados. Andy Grove (ex-CEO da Intel) compartilhou sobre a frase abaixo, ressaltando a importância de dedicar um tempo com seus funcionários para ter melhoria na qualidade do trabalho.

Andy-Grove-Value-101

 

 

Referências

VPL e TIR – Análise de Projetos de Investimento

No último POST fizemos a introdução sobre Análise de Projetos de Investimento, utilizando CAPM e Payback para analisar o risco e retorno dos projetos organizacionais. Fica como leitura recomendada antes de continuar esta publicação.

Complementando o estudo de viabilidade econômica dos projetos de investimento, a VPL (Valor Presente Líquido) e a TIR (Taxa Interna de Retorno) são métodos que apoiam a tomada de decisões por analisar cenários possíveis de investimento que a empresa pode realizar.


VPL – Valor Presente Líquido
Consiste em encontrar o valor presente dos fluxos de caixa futuros líquidos, descontados ao custo de capital da empresa ou à taxa de retorno exigida. Para isso:

  • Inclui-se entradas e saídas, descontadas ao custo de capital do projeto
  • Soma-se todos os fluxos de caixa do projeto
  • Se o VPL for positivo, o projeto deve ser aceito
  • Se o VPL for negativo, o projeto deve ser rejeitado

Utilizando a fórmula:VPL

É o método mais recomendado (do ponto de vista econômico) por considerar o valor do dinheiro no tempo e o custo de capital da empresa.

Exemplo
A partir de um investimento em um projeto com as seguintes características:

  • Investimento inicial de R$ 100.000,00
  • Valores retornados no 1º período R$ 30.000,00
  • Valores retornados no 2º período R$ 20.000,00
  • Valores retornados no 3º período R$ 40.000,00
  • Valores retornados no 4º período R$ 50.000,00
  • Valores retornados no 5º período R$ 60.000,00
  • Taxa de desconto: 15% (pode ser a inflação ou outro índice desejado)
Ano Fluxo de caixa Descontado Acumulado
0 (100.000) (100.000) (100.000)
1 30.000 26.087 (73.913)
2 20.000 15.123 (58.790)
3 40.000 26.301 (32.490)
4 50.000 28.588 (3.902)
5 60.000 29.831 25.929

* Lembre-se de utilizar a fórmula payback-descontado para incluir a taxa de desconto no fluxo de caixa (coluna “Descontado”). O Acumulado é a diferença entre o saldo do FC e o Descontado.

O Valor Presente Líquido do projeto é de R$ 25.929, positivo no cenário dos próximos 5 anos. Para calcular utilizando a HP 12c:

hp12c
[f] REG para zerar todos valores
100000 CHS (valor negativo) [g] CFo
30000 [g] CFj
20000 [g] CFj
40000 [g] CFj
50000 [g] CFj
60000 [g] CFj
15 i (taxa de desconto considerada)
[f] NPV

E pronto! O resultado é de R$ 25.928,74. VPL Positivo.

 

TIR – Taxa Interna de Retorno
É a taxa de desconto que iguala o VPL das entradas e saídas de caixa esperadas de um projeto.

  • TIR indica a rentabilidade do projeto
  • Simula-se o VPL para diversas taxas de desconto
  • O ponto em que se zerar o VPL corresponde à TIR
  • É uma taxa intrínseca ao projeto, não dependendo de fatores externos

TIR

A Taxa de retorno exigida é a taxa de desconto (custo de capital) que a TIR deve superar para que um projeto seja aceito. A TIR e VLP de um projeto levam às mesmas conclusões de aceitação ou rejeição:

  • TIR superior ao Custo de Capital leva a um VPL positivo
  • TIR inferior ao Custo de Capital leva a um VPL negativo


Exemplo
Considerando os mesmos valores do exemplo anterior (cálculo da VPL), a TIR percorre os mesmos passos na HP 12c:

[f] REG para zerar todos valores
100000 CHS (valor negativo) [g] CFo
30000 [g] CFj
20000 [g] CFj
40000 [g] CFj
50000 [g] CFj
60000 [g] CFj
15 i (taxa de desconto considerada)
[f] IRR

A única diferença é o último comando IRR que representa a TIR (no caso do VPL utilizamos NPV). O resultado é de 23,91%. TIR Positiva.

 

TIRs Múltiplas

  • Projeto Normal: se tiver uma ou mais saídas de caixa seguidas de uma série de entradas
  • Projeto Não-normal: projetos com grandes saídas de caixa em alguma ocasião durante a vida do projeto

** TIR não podem ser usadas com projetos de Fluxo de Caixa “anormais”, porque há mais de uma resposta

 

TIR Modificada
A TIRM é a taxa de descontos na qual o valor presente do custo de um projeto é igual ao valor presente de seu valor terminal, em que o valor terminal é encontrado como a soma dos valores futuros das entradas de caixa, compostas ao custo de capital da empresa.

  • Utilizada para melhorar as deficiências da TIR e manter o aspecto intuitivo que os executivos apreciam
  • A TIRM leva vantagem sobre a TIR, pois supõe que os fluxos de caixa são reinvestidos ao custo de capital

TIRM

 

Referências

financas-corporativas-fgv

CAPM e Payback – Análise de Projetos de Investimento

1 Comment

Objetivo: apresentação de três métodos de análise de projetos de investimento – CAPM, Payback Simples e Payback Descontado – para apoiar a visão de retorno de capital e critérios de aceitação de projetos, considerando os riscos e fluxos de caixa projetados.


Análise Financeira

Há três variáveis que permeiam durante todo o processo de análise financeira: o risco, o retorno e preço (FGV Management – Finanças Corporativas). E assim, o administrador financeiro precisa considerar as seguintes funções:

  • Captação de recursos: capital próprio x capital de terceiros. Deve ser considerado o custo de oportunidade – por exemplo utilizando capital próprio, a empresa perde dinheiro em caixa e considera o custo de oportunidade por não aplicar em outras frentes como expansão, fusões, aquisições, entre outros
  • Aplicação de recursos: onde os recursos serão aplicados? Inovação, novos produtos, novas filiais, etc.
  • Relação risco x retorno: analisar rentabilidade e risco
    • Risco econômico – conjuntura (políticas econômicas e tecnologias), mercado e a gestão da empresa (vendas, custos, preços, investimentos, etc.)
    • Risco financeiro – relacionado com o endividamento e capacidade de pagamento da empresa
    • Retorno esperado e Retorno efetivo
  • Política de Hedge: proteção contra taxa de juros e câmbio
  • Relação com outras áreas: minimizar o capital empregado na operação
  • Criar valor: gerar valor para a empresa no longo prazo
  • Administração do fluxo de caixa: montante de caixa recebido/gasto pela empresa em um período específico
  • Preço
    • Estimativa: com base no VPL (valor presente dos fluxos futuros de caixa esperados para o ativo)
    • Estabelecimento da taxa: mínimo de retorno esperado para “carregar” o ativo
    • Negociação: mercados secundários e jogo de forças de oferta e demanda

 

Risco e retorno sobre investimento

Retorno sobre o investimento

retorno-investimento

Risco de investimento
É a probabilidade de obter um retorno menor que o esperado. Em dívida, não receber juros ou o principal nas datas acordadas. Já em ações, volatilidade do preço e dos dividendos.

A diversificação elimina riscos? Em que condições ela será melhor? E a diversificação internacional? Os riscos sistemáticos – afetam a economia de uma forma geral (ex: Banco Central aumenta a taxa de juros) e não sistemáticos – referente a uma empresa ou setor específico – são fatores considerados nesta análise. Também a correlação de mercados, por conta de um problema no país poder afetar outros mercados, que estão correlacionados.


CAPM – Capital Asset Pricing Model
O CAPM é um modelo de precificação de ativos, utilizado para demonstrar a relação entre retorno requerido e risco.

A fórmula é representada por Ki= Rf + β (Rm-Rf), onde:

  • Ki: retorno médio requerido
  • Rf : taxa livre
  • β: coeficiente beta (medida de risco)
  • Rm: retorno médio esperado

O β (coeficiente beta) médio de mercado é 1,0. Considera aspectos operacionais (custo fixo operacional), financeiro (endividamento) e negócio (volatilidade e fluxo de caixa).

Exemplo
Uma empresa utilizando capital próprio está considerando os seguintes projetos:

Projeto β Retorno esperado Retorno requerido
W 0,75 12%
X 0,85 14%
Y 1,20 18%
Z 1,50 19%

Considerando a taxa de letras do tesouro igual a 5%, e o retorno esperado do mercado é de 15%, quais projetos deveriam ser aceitos?

Para calcular o retorno requerido, vamos utilizar a fórmula:
Ki= Rf + β (Rm-Rf)
Kw= 5 + 0,75 (15 – 5) = 12,5%
Kx = 5 + 0,85 (15 – 5) = 13,5%
Ky = 5 + 1,20 (15 – 5) = 17%
Kz = 5 + 1,50 (15 – 5) = 20%

E assim, os projetos X e Y deveriam ser aceitos, pois o retorno esperado (quanto o projeto falou que vai dar) é maior que o retorno requerido (mínimo que o projeto deve dar em função dos riscos).

 

Payback Simples
É o tempo necessário para a recuperação do valor investido. Os projetos que recuperam o capital em período menor ou igual a (t) tendem a ser aceitos.

No exemplo abaixo, consideramos um fluxo de caixa com investimento inicial (t=0) de R$ 1.000. Para os 4 anos iniciais do projeto (ou da empresa), geralmente as empresas consideram a projeção de vendas, os investimentos, economia etc. para projetar fluxos de caixa futuros. Aqui, apenas para ilustrar o exemplo, consideramos um saldo positivo de R$ 100 no ano 1, R$ 300 no ano 2, R$ 400 no ano 3 e R$ 600 no ano 4.

payback

E assim, o Projeto L teria um Payback – retorno do investimento – em 3,33 anos. Isso é bom ou ruim? A recomendação é comparar com outros investimentos de mercado e verificar qual seria o retorno para te ajudar com a melhor decisão.

payback-resolvido

 

Payback Descontado
Considera o valor do dinheiro no tempo, pois sabemos que há inflação e deflação na economia. Assim, como no Payback Simples, calcula o tempo necessário para a recuperação do investimento, porém a partir de fluxos de caixas líquidos descontados.

payback-descontado

A fórmula do Payback Descontado considera:

  • FV: fluxo de caixa
  • i: taxa
  • n: período

E assim, considerando o mesmo exemplo:

payback

E por hipótese um custo de capital de 10%, aplicamos a fórmula:

PV1 = 100 / (1+0,10) 1 = 91
PV2 = 300 / (1+0,10) 2 = 248
PV3 = 400 / (1+0,10) 3 = 301
PV4 = 600 / (1+0,10) 4 = 410

Para então encontrarmos o Payback Descontado em 3,88 anos conforme abaixo:

payback-descontado-resolvido

A leitura da análise é que o projeto ou investimento em um negócio teria retorno em 3,88 anos. Vale a pena comparar com outros meios e assim aplicar o dinheiro em frentes favoráveis de investimento.

 

Referências

financas-corporativas-fgv

VSTS – Build e Release – DevOps

1 Comment

Objetivo: descrever a importância do Build e Release no processo de DevOps

Contexto: colocar um novo sistema em produção (ou incremento) é uma demanda frequente nas organizações que trabalham com desenvolvimento de sistemas. Não pode haver bottlenecks! Há um constante monitoramento para checar se os usuários estão realmente utilizando as releases e o que podemos fazer para melhorar a experiência do usuário.

Tudo isso exige um processo de Continuous Integration / Delivery / Deployment. As práticas de DevOps, incluindo a configuração de Build e Release, são essenciais para melhorar a qualidade, controle e integração dos sistemas a serem publicados. Evitar versões erradas em produção e a famosa frase do desenvolvedor “na minha máquina funciona” são dilemas que as empresas mitigam com um bom modelo de versionamento e gestão de fila da implementação.

E assim, desde a criação de máquinas de Build até a transição nos servidores de DEV, QA, Homologação, Pré-produção e Produção, compartilho no post abaixo uma orientação de configuração de Build e gestão dos artefatos no ambiente VSTS.


Build e Release

O processo de Build envolve funções de integração, construção, versionamento, qualidade e compilação do código-fonte produzido. As ferramentas VSTS, Maven e GitHub são utilizadas para auxiliar na integração e monitoramento dos artefatos. Quando há quebra no Build devido a problema neste processo, os desenvolvedores precisam corrigir e fazer o check-in novamente. O processo de integração contínua e o apoio da infraestrutura são necessários para manter a esteira de publicação rápida, principalmente para organizações que trabalham em larga escala.

Posteriormente, o Release é a liberação da nova versão do sistema em produção. Considera-se que no Build já tenha sido avaliado e testado a qualidade para garantir que não haja erros. Este processo consome recurso de servidores, que dependendo da complexidade, exige escalabilidade para realizar o deploy do código.

Para automatizar as etapas do processo de Build e Release e envio dos scripts ao repositório, os times geralmente utilizam ferramentas como Jenkins. Outros aspectos a serem considerados:

  • Criar servidor(es) para execução de Builds
  • Automatizar etapa de compilação e deploy
  • Ambientes (Dev | QA | Homologação | Produção)
  • Processo de qualidade para validação do negócio
  • Testes automatizados
  • Padrnoização de regras para arquitetura
  • Utilização de teste unitário, Sonarqube (qualidade do código) e práticas como BDD ou TDD


Utilizando VSTS

Build
Acesse o VSTS > Build and Release > Builds para configurar as definições de Build:

build

Todas as opções abaixo estão disponíveis para configuração:

  • Tasks – Build Name / Agent Queue / Path to solution / Artifact Name
  • Variables
  • Triggers – Continuous Integration (Build every change to matching branches: Disabled) | Gated Check-in (Accept check-ins only if the submitted changes merge and build successfully: Enabled) | Scheduled (Build matching branches for each schedule: Disabled)
  • Options – Build properties (Description / Build number format) / New build request processing: Enable / Automatically link new work in this build… / Create work item on failure / Allow scripts to access OAuth token / Build job / Define build job authorization and timeout settings / Build job authorization scope / Build job timeout in minutes / Build job cancel timeout in minutes / Demands / Specify which capabilities the agent must have to run this process
  • Retetion – Days to Keep / Minimum keep / When cleaning up builds… / History


Release
Também no VSTS > Build and Release > Release para criar as definições de Release:

release

E assim será criado o Pipeline para publicação dos binários, com a escolha do Template, nome do ambiente (que será realizado deploy) e owners do ambiente.

Artefatos de Build
Também podemos criar artefatos de Build, selecionando o Build (na Source Type) que será promovido na Pipeline de Release. Escolha também o projeto e a última versão desenvolvida.

artefato

Há outras configurações como tarefas, variáveis e opções que estão disponíveis no VSTS. Como o propósito foi introduzir o tema, sugiro acessar o Docs da Microsoft para ter mais detalhes sobre as configurações de Build e Release.

 

PO – Product Owner – papel no desenvolvimento ágil

PO – Product Owner

O PO (Product Owner) é uma figura extremamente importante em equipes de desenvolvimento ágil. Além de trazer a visão estratégica da empresa, deve ser empoderado a tomar decisões e manter os objetivos organizacionais em priorização.

Podem estar alocados part time ou full time no projeto. Geralmente, o PO está alocado nesta função em mais de um time paralelamente, delegando responsabilidades. Porém, continuam sendo responsáveis pelo valor do produto.

Entre as suas principais atribuições estão:

  • Responsável pelo Product Backlog e priorização dos itens nas Sprint Planning Meetings. Este backlog priorizado é o Sprint Backlog e será trabalhado pelo time.
  • Manter o conteúdo do Product Backlog atualizado e com os principais insights de mercado e do cliente
  • Maximizar o ROI – Retorno do Investimento
  • Visão do Produto
  • Trabalha constantemente com Scrum Master removendo impedimentos
  • Utilizam a Sprint Review para atualizar os stakeholders e previsões de entregas do produto

Também devem ter alta interação com o time, respondendo aos questionamentos de desenvolvedores e escrevendo boas User Stories:

Como um <papel>
Eu quero <objetivo>
Para então <valor>

Veja mais detalhes sobre User Story e as recomendações para criar boas estórias:

  • 3Cs (Card – Conversation – Confirmation) – [Ron Jeffries]
  • INVEST (Independent / Negotiable / Valuable / Estimable / Small / Testable) – [Bill Wake]
  • Estimativas: utiliza técnicas como Estimating Poker baseado em Story Points – número que representa a combinação de Volume, Complexidade, Conhecimento e Incerteza para estimar as tarefas. A modificada sequência Fibonacci é utilizada para refletir a inerente incerteza das estimativas.

E o mindset do Product Owner sob a visão – BE – DO – KNOW…

…BE – available / knowledgeable / empowered
…DO – product management / project management / leadership / business analysis
…KNOW – business value / technical feasibility / user experience
Na visão on page de Roman Pichler, podemos resumir o Product Owner com as interações abaixo:

roman-pichler

 

Eventos DevOps 2018 – Trilhas, Confs e Webinars

Veja abaixo os principais eventos para DevOps e ALM (Application Lifecycle Management) em 2018. Além dos eventos no Brasil, tenha a oportunidade de conhecer alguns eventos internacionais e conferências para você conectar.

Janeiro

Fevereiro

Março

Abril

Maio

Junho

Julho

Setembro

Outubro

Dezembro

 


Data a ser definida…

Recommended Webinars…

VSTS – Work Item – Criando Spikes e Acceptance Criteria

Pré-requisito
No último post sobre VSTS Process Templates, explico as principais diferenças entre os templates Agile / Scrum / CMMI no VSTS (Visual Studio Team Services). Certifique-se de que compreendeu bem estes conceitos para dar continuidade ao post abaixo.

Contexto
Ao trabalhar com times de desenvolvimento ágil, utilizando o VSTS, podemos criar o backlog associado a projetos e alocação de times, configurando time box para as Sprints deste projeto, conforme a cadência planejada na sua empresa.

Além de versionar o código-fonte e permitir associar check-in do seu time com os Work Items, o VSTS é uma solução para gerenciar outras etapas do ciclo de vida da aplicação. Neste contexto, a criação e customização de Work Items é necessária para trabalhar em Epics > Features > User Stories e entregar valor ao produto.

Veja que na área de PROCESS (PROCESSO), existem os processos e fields (campos), que são utilizados em níveis de Work Item / Backlog / Projetos.template

Spike
A primeira customização que iremos demonstrar é a criação de Spikes – tempo consumido para explorar melhor as definições de tópicos que apresentam risco para o projeto – e como alocar as horas para tratar estas indefinições, sem impactar nas estimativas do projeto.

Escolha o process template que está trabalhando, no meu caso utilizei o CMMI. Abaixo, veja que há Levels (níveis) de otimizações para incluir campos. Como as Spikes fazem parte do projeto, recomendo criar no nível de Iteration para ser visualizadas no Board junto com as Tasks (destacado em vermelho na figura abaixo – utilize a opção … Editar).process-cmmi

E na tela seguinte, você pode criar “New Work Item Type”, neste caso a Spike.
backlog-level

Veja que na sequência o Work Item do tipo Spike já aparece no Board do VSTS para criação e acompanhamento.

spike

Acceptance Criteria
Outra opção é criar novos campos, ou utilizar campos existentes de outros templates. Por exemplo, no template do CMMI não existe o campo de critério de aceitação da tarefa, mas consegui incluir por já existir em outros templates. Também pode ser incluído qualquer outro campo novo, independente de existir em outros templates.

Para criar um novo campo, acesse na página inicial do Work Item Types, clicando no tipo TASK, conforme abaixo.process-task

Acesse New Field e abrirá uma nova janela para adicionar um campo existente (de outro template) ou simplesmente criar um novo campo. Neste caso, escolhi a opção de criar um campo existente ao Work Item.task-process

Logo após adicionar o campo, você já poderá visualizar dentro da TASK, conforme abaixo.wi-ac

MVP – Produto Mínimo Viável e Canvas MVP

O MVP (Minimum Viable Product) – Produto Mínimo Viável – vai além de construir a versão mais simples de um produto com o mínimo esforço para testar o mercado. Como Eric Ries explica no livro Lean Startup – “it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort… Its goal is to test fundamental business hypotheses.” e assim evitar o lançamento de produtos que as pessoas não irão comprar.

Ou seja, o MVP é atualmente muito utilizado em Startups e empresas que precisam constantemente lançar novos produtos no mercado e validar suas hipóteses, iterativamente aprendendo com feedbacks de clientes e do uso do produto. O fluxo proposto no Lean Startup:

leanstartup-flow

 

Os early adopters, público com maior disposição para comprar produtos em fase inicial de desenvolvimento, geralmente são fundamentais para validar a aceitação do produto neste período. Eles proveem colaborações, compreensão do problema e estão em busca da solução, muitas vezes até pagam por ela.

Três definições que fortalecem o entendimento sobre o MVP:

  • “A learning vehicle” – Eric Ries

  • “You can’t identify one thing and then stop talking to your customers and go build.  Because you’re not really building a product – you’re building an environment that supports increasingly educated guesses.” – Cindy Alvarez

  • “Antes se falava muito em criar os produtos certos para o mercado da melhor maneira possível. Mas isso demanda tempo e, se a ideia de negócio não for boa, perder meses planejando um produto ruim terá sido um grande desperdício. Por isso, acredito que, mais que criar o produto da melhor maneira possível, é preciso ter certeza de que aquele é o produto certo” – Paulo Caroli, consultor da ThoughtWorks e autor do livro “Direto ao Ponto”

As empresas utilizam estratégias para validar o modelo de receita e a proposta de valor do MVP – teste da experiência do usuário, formulários de conversão, landing pages, estabelecer metas, público alvo (personas), etc.  Estes resultados vão provendo direcionamento a concepção do produto e medição de custos.
Canvas MVP
E como definir a estratégia do MVP? O Canvas MVP é uma ferramenta recomendada para agrupar os principais elementos necessários ao MVP:

  • Visão do MVP
  • Funcionalidade
  • Custo e Cronograma
  • Hipóteses de negócios com suas métricas
  • Personas e suas jornadas

canvas-mvpO loop Build-Measure-Learn – citado no livro Lean Startup – direciona a construção, medição dos resultados e aprendizado com o MVP. Os blocos do Canvas MVP – funcionalidades, resultados esperados, e métricas – representam este loop.

Outro loop, fundamentado pelo Design Thinking, que auxilia a construção do MVP é o usuário-jornada-ação. Ele é representado pelos blocos do Canvas MVP – Personas, Jornadas e Funcionalidade e direciona a quem e qual jornada será neste MVP. Também apoia nas ações (funcionalidade) a serem melhoradas no MVP.

 

Referências