Meus caros, finalmente chegamos a terceira e última parte do nosso Café com Agile. Se você, caro leitor ficar com alguma dúvida, envie para o Sandro ou para mim, que oportunamente iremos responder.
Tanto eu, como o Sandro já conheciamos tanto Scrum como PMI, com a diferença que o Sandro é um especialista em Gerência de Projetos e eu sou um grande entusiasta e estudioso de Scrum e Agile em geral. No início da conversa, o único objetivo era um poder aprender com o outro, eu queria conhecer mais sobre os conceitos de PMI e ele conhecer um pouco mais sobre Scrum, e nesse ponto tenho certeza que atingimos o nosso objetivo e de quebra, o papo foi até surpreendente.
Gostei muito dessa experiência, e espero que aqueles que lerem também gostem. E agora, deixando a parte "sentimental" de lado, vamos ao derradeiro final do papo.
Sandro: Em nossa última conversa, entendi que a idéia no scrum é fazer entregas constantes, mas a minha dúvida é, como é decidido a ordem em que as coisas serão desenvolvidas?
Milton: Tendo o “Product Backlog” em mãos, o “Product Owner” define o que deve ser entregue primeiro para que o projeto tenha um maior retorno financeiro
Milton: Ai, a equipe de desenvolvimento se reúne, verifica quais itens eles podem entregar no prazo combinado e começam o desenvolvimento destes itens
Milton: Nesse ponto, surge o conceito de time-box, ou seja, em scrum o prazo é fixo, a equipe trabalha em ciclos/iterações que duram de 2 a 4 semanas. Ao final de cada iteração é entregue um incremento do produto
Milton: Cada ciclo ou iteração é o que chamamos de “sprint”.
Milton: Com o incremento entregue, o “Product Owner” pode decidir por utilizar o produto em produção ou aguardar pelos próximos incrementos
Sandro: E já é apresentando ao cliente?
Milton: Sim, em alguns casos o “Product Owner” é o próprio cliente. Inclusive, é uma prática recomendável que, quando o projeto for específico para um único cliente o “Product Owner” seja uma pessoa de negócios do Cliente.
Sandro: Sim, ele seria o gerente de TI ou um analista sênior que esteja a par das regras de negócio e estratégias da empresa
Milton: Não necessariamente, pode ser até um cara de negócio mesmo
Milton: Tem uma coisa q falamos, mas não dei nome, q é o “Sprint Backlog”
Milton: O “Sprint Backlog” é a porção de coisas do “Product Backlog” que a equipe seleciona para desenvolver
Sandro: Hummm esse eu conheço, é o incremento planejado para o próximo Sprint.
Milton: Isso mesmo
Milton: Com isso observamos uma coisa muito interessante, o cliente não precisa esperar uma vida pra ver algum resultado do projeto
Milton: E o fornecedor não precisa ficar uma vida amarrando escopo, nem fazendo planejamentos de projetos enormes, com milhares de documentos e assinaturas de aprovação de escopo e mudanças
Milton: Isso porque o fornecedor foca apenas nas tarefas do “Sprint”, e o “Product Owner” foca em organizar continuamente o “Product Backlog”, medindo o quanto o projeto está dando de retorno financeiro
Sandro: Sim, isso eu visualizei , é sensacional, jogo aberto e de ajustes rápidos!
Milton: Exato
Milton: Além dessa questão sobre o "como tratar o escopo", acredito que temos mais uma diferença marcante, quer dar um palpite? hehe
Sandro: Bom, o que eu gostei muito no scrum foi que possui praticas muito democráticas. Ele permite que o especialista opine, se expresse, participe do processo. Isso muda até mesmo o pique do cara em vir trabalhar
Sandro: Além disso, ele não vê que tem que trabalhar 2000 horas em entregáveis que nem imagina ainda (em finais de semanas e feriados), mas sim 2 semanas (de segunda a sexta) em assuntos já discutidos e planejados para essas 2 semanas
Sandro: Seria isso?
Milton: Sim, você foi na veia do negócio
Milton: A primeira parte é a questão dos papéis, não existe o Gerente de Projeto Super Poderoso, cada papel tem um poder específico, de acordo com a sua função e cada papel deve contribuir com os demais para atingir os objetivos do projeto
Milton: - o Product Owner define os objetivos do produto, e o que será feito primeiro para atingir este objetivo
- o Time define o que é capaz de entregar em cada sprint, bota a mão na massa e procura melhorar o processo sempre para produzir mais
- o Scrum Master, que nem foi citado até agora e é muito importante, isola o time de interferências, remove impedimentos e faz um papel de facilitador entre o Product Owner e o Time
Milton: O segundo ponto é a questão do "tamanho" do projeto. Você deixa de trabalhar com um projeto titânico, e passa a trabalhar com vários mini-projetos, em seqüência, com isso o produto vai crescendo a cada entrega.
Milton: E acho que qualquer Gerente de Projeto concorda que é muito melhor trabalhar com um projeto de 200 horas, do que com um projeto de 20.000 horas
Sandro: Claro, muito melhor
Sandro: E a questão dos poderes de um sobre o outro? No caso do Scrum Master x Product Owner?
Sandro: Existe braço de ferro entre os dois?
Milton: Depende, pode existir, mas por questões políticas. E isso pode acontecer com qualquer tipo de função
Milton: Se os dois fizerem o seu papel e se mantiverem focados no objetivo do projeto não devem ocorrer quedas de braço no sentido político da coisa
Milton: Claro que ocorrerão conflitos, mas são conflitos saudáveis, buscando o melhor para o projeto e não benefícios individuais
Milton: É diferente de você ter, por exemplo, dois Gerentes de Projeto brigando por aquele "Recurso" que é o cara em java, que programa tudo rapidinho
Sandro: Sim, mas ai seriam 2 GPs em uma mesma empresa, se existissem 2 Scrum Master na mesma empresa poderia ter o atrito também?
Milton: Não, porque em scrum a idéia é q a equipe seja fixa. Não vai ter aquela dança de pessoas entre as equipes, porque manter as pessoas trabalhando juntas contribui para o desenvolvimento profissional delas
Milton: Ainda mais quando você possui uma equipe bem heterogenia, onde você tem pessoas com várias funções e com diferentes níveis de experiência. Em uma equipe assim todos aprendem com todos, e se tornam profissionais melhores, aumentando a maturidade e capacidade da equipe
Sandro: entendi
Milton: Bom, acho q estamos chegando ao fim do papo por hoje, mais alguma consideração?
Sandro: Acho que não, clareou pra mim ainda mais as práticas e personagens do scrum, foi show de bola
Tanto eu, como o Sandro já conheciamos tanto Scrum como PMI, com a diferença que o Sandro é um especialista em Gerência de Projetos e eu sou um grande entusiasta e estudioso de Scrum e Agile em geral. No início da conversa, o único objetivo era um poder aprender com o outro, eu queria conhecer mais sobre os conceitos de PMI e ele conhecer um pouco mais sobre Scrum, e nesse ponto tenho certeza que atingimos o nosso objetivo e de quebra, o papo foi até surpreendente.
Gostei muito dessa experiência, e espero que aqueles que lerem também gostem. E agora, deixando a parte "sentimental" de lado, vamos ao derradeiro final do papo.
Sandro: Em nossa última conversa, entendi que a idéia no scrum é fazer entregas constantes, mas a minha dúvida é, como é decidido a ordem em que as coisas serão desenvolvidas?
Milton: Tendo o “Product Backlog” em mãos, o “Product Owner” define o que deve ser entregue primeiro para que o projeto tenha um maior retorno financeiro
Milton: Ai, a equipe de desenvolvimento se reúne, verifica quais itens eles podem entregar no prazo combinado e começam o desenvolvimento destes itens
Milton: Nesse ponto, surge o conceito de time-box, ou seja, em scrum o prazo é fixo, a equipe trabalha em ciclos/iterações que duram de 2 a 4 semanas. Ao final de cada iteração é entregue um incremento do produto
Milton: Cada ciclo ou iteração é o que chamamos de “sprint”.
Milton: Com o incremento entregue, o “Product Owner” pode decidir por utilizar o produto em produção ou aguardar pelos próximos incrementos
Sandro: E já é apresentando ao cliente?
Milton: Sim, em alguns casos o “Product Owner” é o próprio cliente. Inclusive, é uma prática recomendável que, quando o projeto for específico para um único cliente o “Product Owner” seja uma pessoa de negócios do Cliente.
Sandro: Sim, ele seria o gerente de TI ou um analista sênior que esteja a par das regras de negócio e estratégias da empresa
Milton: Não necessariamente, pode ser até um cara de negócio mesmo
Milton: Tem uma coisa q falamos, mas não dei nome, q é o “Sprint Backlog”
Milton: O “Sprint Backlog” é a porção de coisas do “Product Backlog” que a equipe seleciona para desenvolver
Sandro: Hummm esse eu conheço, é o incremento planejado para o próximo Sprint.
Milton: Isso mesmo
Milton: Com isso observamos uma coisa muito interessante, o cliente não precisa esperar uma vida pra ver algum resultado do projeto
Milton: E o fornecedor não precisa ficar uma vida amarrando escopo, nem fazendo planejamentos de projetos enormes, com milhares de documentos e assinaturas de aprovação de escopo e mudanças
Milton: Isso porque o fornecedor foca apenas nas tarefas do “Sprint”, e o “Product Owner” foca em organizar continuamente o “Product Backlog”, medindo o quanto o projeto está dando de retorno financeiro
Sandro: Sim, isso eu visualizei , é sensacional, jogo aberto e de ajustes rápidos!
Milton: Exato
Milton: Além dessa questão sobre o "como tratar o escopo", acredito que temos mais uma diferença marcante, quer dar um palpite? hehe
Sandro: Bom, o que eu gostei muito no scrum foi que possui praticas muito democráticas. Ele permite que o especialista opine, se expresse, participe do processo. Isso muda até mesmo o pique do cara em vir trabalhar
Sandro: Além disso, ele não vê que tem que trabalhar 2000 horas em entregáveis que nem imagina ainda (em finais de semanas e feriados), mas sim 2 semanas (de segunda a sexta) em assuntos já discutidos e planejados para essas 2 semanas
Sandro: Seria isso?
Milton: Sim, você foi na veia do negócio
Milton: A primeira parte é a questão dos papéis, não existe o Gerente de Projeto Super Poderoso, cada papel tem um poder específico, de acordo com a sua função e cada papel deve contribuir com os demais para atingir os objetivos do projeto
Milton: - o Product Owner define os objetivos do produto, e o que será feito primeiro para atingir este objetivo
- o Time define o que é capaz de entregar em cada sprint, bota a mão na massa e procura melhorar o processo sempre para produzir mais
- o Scrum Master, que nem foi citado até agora e é muito importante, isola o time de interferências, remove impedimentos e faz um papel de facilitador entre o Product Owner e o Time
Milton: O segundo ponto é a questão do "tamanho" do projeto. Você deixa de trabalhar com um projeto titânico, e passa a trabalhar com vários mini-projetos, em seqüência, com isso o produto vai crescendo a cada entrega.
Milton: E acho que qualquer Gerente de Projeto concorda que é muito melhor trabalhar com um projeto de 200 horas, do que com um projeto de 20.000 horas
Sandro: Claro, muito melhor
Sandro: E a questão dos poderes de um sobre o outro? No caso do Scrum Master x Product Owner?
Sandro: Existe braço de ferro entre os dois?
Milton: Depende, pode existir, mas por questões políticas. E isso pode acontecer com qualquer tipo de função
Milton: Se os dois fizerem o seu papel e se mantiverem focados no objetivo do projeto não devem ocorrer quedas de braço no sentido político da coisa
Milton: Claro que ocorrerão conflitos, mas são conflitos saudáveis, buscando o melhor para o projeto e não benefícios individuais
Milton: É diferente de você ter, por exemplo, dois Gerentes de Projeto brigando por aquele "Recurso" que é o cara em java, que programa tudo rapidinho
Sandro: Sim, mas ai seriam 2 GPs em uma mesma empresa, se existissem 2 Scrum Master na mesma empresa poderia ter o atrito também?
Milton: Não, porque em scrum a idéia é q a equipe seja fixa. Não vai ter aquela dança de pessoas entre as equipes, porque manter as pessoas trabalhando juntas contribui para o desenvolvimento profissional delas
Milton: Ainda mais quando você possui uma equipe bem heterogenia, onde você tem pessoas com várias funções e com diferentes níveis de experiência. Em uma equipe assim todos aprendem com todos, e se tornam profissionais melhores, aumentando a maturidade e capacidade da equipe
Sandro: entendi
Milton: Bom, acho q estamos chegando ao fim do papo por hoje, mais alguma consideração?
Sandro: Acho que não, clareou pra mim ainda mais as práticas e personagens do scrum, foi show de bola
link para a Parte 1
link para a Parte 2
Um comentário:
You fucker! Não li tudo, mas lerei. Abração e parabéns pela iniciativa.
Postar um comentário