Priscila Chagas

Tag: agile

  • 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.

    (mais…)

  • 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).

    O 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.