Utilizando Canvas para entender melhor seu produto

Dando uma pausa..pngJá é uma prática de mercado utilizar canvas para obtenção de dados para o que quer que seja, já vi scrum team canvas, machine learning canvas… Tem Canvas para todos os gostos. O canvas acabou caindo no gosto dos analistas, product owners e demais profissionais do mercado porque facilita o entendimento de todas as partes e direciona um brainstorm, por exemplo.

Uma das estratégias comuns para entendimento do produto (e da visão da empresa), são os Business Model Canvas e o Product Vision Board.  Vou focar, hoje, nestes dois canvas.

Continue lendo “Utilizando Canvas para entender melhor seu produto”

PO Proxy – PO Linha

 

BusinessAnalystAsProxyProductOwner

“O Product Owner é aquele que determina as metas e conduz o time na entrega constante de valor” (Cohn, 2009, Succeeding with Agile)

Recentemente assumi um projeto (iniciado a 3 meses por um fornecedor em metodologia tradicional), e projeto apresentava a cada status report a dependência/premissa de ter declarado o PRODUCT OWNER, mas neste caso leia-se dono do projeto, a pessoa que aprova ou não as entregas.

Para o fornecedor essa pessoa deveria ser alguém da área de negócios, e por isto foi apontado um gerente de uma área de negocio, que além de todas as suas atividades diárias ele deveria também tocar as atividades deste projeto (o profissional atribuído a este papel deveria estudar o produto, testar conceitos e construir o produto).

Scrum Guide , uma das referências do assunto, descreve o PO como:

“É o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. (…)

Sendo o “Product Owner uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.”

Cerejinha do bolo, este projeto possui duas áreas de negócios envolvidas (Limão e Laranja e por este motivo não será possível UM Product Owner.

Qual a probabilidade destes DOIS gerentes quererem assumir mais uma função, com uma parte da atividade que eles desconhecem, de um projeto já iniciado e que ele não tinha conhecimento do escopo que foi fechado?

O PO neste cenário é o que chamamos de “cliente”, ele tem noção do que o produto precisa solucionar, mas não tem conhecimentos técnicos para realizar testes, cuidar da evolução do produto e dar diretrizes para o time (pensando na questão técnica), principalmente, sendo dois clientes com objetivos distintos dentro do produto.

Quando me coloquei a par do projeto sugeri trazer uma “nova” função/papel para o projeto, um PO LINHA (tem quem conheça essa função como PO Proxy), essa pessoa tem o perfil de um analista de negócios/requisitos que prepara todo o material (escreve user stories (traduz as necessidades do cliente – E ELE É TIME!), deixa as estórias em critério de ready para inicio da Sprint, declara os critérios de aceite das histórias, faz a ponte com o time) tudo isto em conjunto com os Product Owners do projeto, neste caso os gerentes das áreas de negócio.

Esse caso que estou contanto é recente e tem 10 dias que se iniciaram as atividades e venho contar aqui as evoluções de 2 semanas:

                – O Product Owner consegue tocar todas as suas atividades diárias e o projeto não é considerado um peso (declaração do próprio PO)

                – O PO linha já apresentou as regras de negócio para a primeira Sprint para que o Product Owner valide e dê o seu de acordo (DOR/DOD) e já estamos trabalhando nas histórias de 2 Sprints a frente.

Organize. (3)

Comentando os doze princípios do manifesto ágil

Em algumas discussões com amigos, recebi algumas referências na internet sobre o Manifesto Ágil. O manifesto ágil é a intenção de melhorar o desenvolvimento e entrega de software ao cliente, fazendo com que a área de TI agregue mais valor, ao invés de ser uma área cara e burocrática. Abaixo, os doze princípios do desenvolvimento ágil de software:

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

Tem coisa melhor e mais motivadora do que receber elogios do cliente?

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

Com agilidade é possível entregar o software que o cliente verdadeiramente precisa. Uma empresa é feita de pessoas, estas pessoas mudam de opinião a todo momento. Uma empresa não pode parar simplesmente porque “o sistema não permite”.

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.

Com todos os stakeholders* envolvidos, fica mais fácil alinhar as expectativas de negócio com o software que está sendo construído. Vamos levantar essa bandeira?

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

Pedir relatórios e status de hora em hora não parece uma boa idéia quando você precisa trabalhar concentrado. Se não confia no trabalho, existe um problema: ou com o membro da equipe ou com você, que não consegue deixar as coisas fluirem.

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Acredito que desenhos em lousas também costumam funcionar bem. Milhares de páginas em documentação?  Acho difícil.

Software funcional é a medida primária de progresso.

Aprovar um software funcionando é bem melhor que aprovar um desenho, não?

Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Continuidade é a chave do sucesso.

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Entregando o que é necessário para o negócio naquele momento, poupamos o esforço desnecessário com aquilo que não agrega valor ou que provavelmente entraria “no bolo” num projeto que entrará daqui 1 ano ou mais.

As melhores arquiteturas, requisitor e designs emergem de times auto-organizáveis.

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Preciso explicar esses? Acho que não. São princípios, que se a gente parar pra pensar, fazem todo o sentido. Então, porque não adotá-los simplesmente?

Parece que o mundo todo não acha isso lá muito fácil.

*diz-se stakeholder toda parte interessada em um projeto.

Uma nova realidade em TI

E eis que cai no meu colo, algo que eu achei que nunca fosse existir. Destino? Prefiro acreditar que buscamos as oportunidades.

Oportunidade de aprender e entender como tudo isso funciona, e concluir que toda aquela paixão não está sozinha no mundo.

Por mais que isso seja algo muito além da minha realidade, estou motivada.

O vídeo mostra a comparação das metodologias Agile e Waterfall, comparando as duas. Não espero converter ninguém com isso, nem comparar as duas metodologias.

Mas acredito que a metodologia Agile vai muito mais de encontro aos meus ideais.

Engenharia de Software: Engenharia, mesmo?

Vamos supor que você, sentadinho aí, lendo esse post. Suponha que você precise construir um prédio e contrate uma empresa para isso.

A empresa pergunta a você o que você precisa e você dá uma breve idéia. Eles te trazem muitos documentos para que eles tenham certeza que vão fazer o que você quer. E uma condição: Você só pode ver o prédio depois de pronto  (e depois de pronto, você precisa aprovar a construção). O prazo para construção é de 1 ano. Você topa.

Acontece que, depois de 6 meses, você precisa de uma alteração: Quer que, no último andar, uma das salas do seu prédio possua teto solar. A empresa topa e promete entregar.  Porém, existem impeditivos (e custos) que não foram informados, e você tem uma bela surpresa na entrega: O teto solar não está como você pensava, e sequer atende as suas necessidades – e pior – o prédio não está como você imaginava . Você aprovaria a construção? Voltaria a fazer negócio com essa empresa?

Assim é o desenvolvimento de software hoje, com uma diferença: Não é necessário derrubar o prédio para construí-lo novamente. Basta aplicar as alterações e pronto: o software passa a atender a necessidade. Porém, a maneira como funcionam os projetos de software, na maioria das vezes, são como projetos de construções – só depois que a construção é feita, o cliente pode saber o que está sendo entregue. E acontecem problemas, como o desse vídeo aí em cima.