Arquivo

Archive for the ‘Scrum’ Category

Spotify engineering culture

Muito legal para tirar umas idéias de como implantar processos na sua empresa. Analíse que nem tudo encaixa na sua estratégia. Mas vale muito a pena ver… mais de uma vez.

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/


https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Categorias:Scrum, Videos

Pivotal Tracker

22/03/2012 1 comentário

A algum tempo escrevi sobre o scrummy.com. Atualmente aqui na empresa estamos utilizando o Pivotal Tracker e achei muito mais interessante. Nele é possível controlar o projeto seguindo a metodologia Scrum e modelos ágeis.

Assim como na outra ferramenta, os projetos públicos podem utilizar o Pivotal Tracker sem qualquer custo. Já para projetos privados, é necessário pagar uma mensalidade dependendo da quantidade de usuários.

Para um entendimento inicial mais interessante, existe um “Getting Stared” no link https://www.pivotaltracker.com/help/gettingstarted que é muito bom. Dá uma boa noção sobre a abrangência da ferramenta.

Os principais pontos positivos na minha visão são:

  • Controle de usuários aos projetos
  • Configuração do projeto
    • Time Zone
    • Tamanho da iteração (em semanas)
    • Ponto de escala (power, linear, Fibonacci ou Custom). Em alguns projetos utilizamos o Custom e colocamos em horas.
    • Configuração inicial da velocidade, ou seja, quantidade de pontos da escala possíveis de entregar em cada iteração (Sprint)
    • Estratégia de velocidade: A cada “n” iterações o software analisa a sua média de entregas e recalcula sua velocidade
    • Projeto
      • Criação de Histórias (Feature, Bug, Chore, Release)
      • Pontuação
      • State (Started, Finished, Delivered, Accepted, Rejected)
      • Requester (quem criou a histíoria)
      • Owner (responsável por entregar a tarefa)
      • Labels (bom para filtrar grupo de histórias.
      • Criação de Tasks
      • Histórico de alterações da história
      • Anexar arquivos
      • Workflow de tarefas
      • Configuração de envio de e-mail sempre que alguma tarefa é alterada
      • Icebox track
      • Report de progresso/histórico.

O que pode melhorar:

  • Controle de impedimentos: hoje não existe uma fila para impedimentos. A melhor forma de contornar isso é utilizando um label, ou colocando na track “icebox”.
  • Normalmente no Scrum existe um PBI (Story) que contém várias tarefas. O tempo é calculado em cima de cada tarefa. O Pivotal Tracker trabalha diferente, aonde existe o peso da “story” e as tasks apenas para controle do que deve ser feito.

Existe a versão para IPhone e IPad (https://www.pivotaltracker.com/tracker-for-iphone-and-ipad)

Como conclusão, é uma ferramenta muito boa e está melhorando nosso controle de projetos e comunicação com o cliente.

Categorias:Ferramentas, Scrum

Priorizando o desenvolvimento de funcionalidades utilizando ROI

05/07/2011 7 comentários

Continuo estudando o livro “Professional SCRUM with Microsoft Visual Studio 2010” e me deparei com um conteúdo muito interessante sobre priorização de tarefas (PBIs ou Product Backlog Item).

Apenas como explicação, no SCRUM um PBI é uma funcionalidade (em inglês “feature”) à ser implementada que deve ser criada pelo “product owner”. Em um projeto temos o momento inicial aonde o product owner escreve todos os PBIs necessário para o projeto funcionar. Mas durante o andamento do projeto os PBIs podem diminuir (a partir do momento que vão sendo entregues) ou aumentar (quando surgem novas funcionalidades a serem implementadas).

O mais complicado de tudo isso é como priorizar o desenvolvimento de todos os PBIs. Nem todos os PBIs tem o mesmo benefício para o negócio. Algumas são imprescindíveis, outas necessárias, e outras “seria interessante ter” (nice to have). Por outro lado, existe a complexidade e o esforço necessário para entregar aquela funcionalidade. Um PBI pode ser imprescindíveis e de fácil desenvolvimento ou “nive to have” e de difícil implementação. Abaixo segue técnicas de como medir numericamente o que é mais prioritário em um projeto através do ROI (Return of Investiment).

ROI é uma medida que indica o valor que aquele PBI tem para o projeto. Na maioria dos projetos ele é medida em valor monetário (dólar, real, …) . Você divide o retorno (preço de venda – preço de compra) pelo investimento (preço de compra) para chegar no valor do ROI. Um valor alto de ROI é um bom investimento, enquanto um baixo valor, é um mal investimento. Controlando o valor de retorno e o valor de custo, chega-se ao ROI ideal. Se você não controlar os dois valores, nunca saberá se o valor gasto em um projeto está lhe trazendo retornos reais de dinheiro.

Na utilização de SCRUM, o product owner é responsável por definir o “business value” e a equipe técnica mede o esforço. Nessa metodologia não utilizamos dólar para medir “business value” e nem horas para medir esforço (A metodologia de medida de esforço será comentada mais abaixo). Mas é possível utilizar o ROI para mensurar relativamente o custo de cada um utilizando as métricas abaixo.

Supondo que estamos desenvolvendo um site de ecommerce e temos dois PBIs.

  • Pagamento do pedido utilizando mais de 1 forma de pagamento
    Business Value: 80
    Esforço: 13Utilizando a escala de 1 a 100 o product owner diz que esse backlog será de grande valia, pois pesquisas feitas indicam que muitos pedidos de valor alto não são fechados devido ao limite dos cartões de crédito. Disponibilizando mais de 1 forma de pagamento no mesmo pedido, as vendas aumentariam.
    Por outro lado, a sistemática para controlar o pagamento e liberar o pedido é muito complexa. A equipe de desenvolvimento coloca um valor de esforço alto para esse backlog. Dessa forma, calculamos:ROI = 80 / 13 = 6,15
  • Integrar redes sociais com o ecommece para incentivar a propaganda.
    Business Value: 30
    Esforço: 😯 Product owner acha a tarefa interessante, mas acredita que o retorno não será muito grande, e não é uma funcionalidade imprescindível para o projeto. O Business Value dele é indicado como 30.
    A equipe de desenvolvimento considera a dificuldade de integrar várias redes sociais distintas e como será arquitetado o sistema. É indicado um esforço de 8 pontos.ROI = 30 / 8 = 3,75

No exemplo acima fica claro que o primeiro PBI tem um ROI muito maior do que o segundo. Logo, tem uma  prioridade maior e será desenvolvido primeiro.

O trabalho do product owner de listar todos os PBIs e indicar o “business value” é mais simples. Apenas lendo o título das funcionalidades é possível colocar analisar quais tem um peso maior ou menor. Mas para a equipe técnica, não é tão simples. Como no exemplo acima, como chegar nos valores 13 e 8? Abaixo algumas metodologias:

Plannig Poker
Criado por Mike Cohn, a metodologia é simples e divertida de se implementar.  Parte-se do pressuposto que muitas equipes tem problemas em medir o esforço que será gasto (em horas, dias, …) para cada tarefa. Mais complicado ainda é quando existem tarefas com índices de esforço muito próximos (Ex: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, …). Como medir o esforço gasto entre os pesos 7 e 9, sendo que os dois são muito próximos. Lembrando que muitas vezes a própria equipe não sabe quanto tempo vai demorar para desenvolver uma tarefa.

Então utilizasse a um conjunto de cartas (valores) pré-definidos. Cada carta tem um valor e deve ser associado com o conjunto de tarefas que será entregue em um sprint. A maioria dos Planning Pokers utiliza a sequência de Fibonacci (1, 2, 3, 5, 8, 13, …).  Dessa forma um ítem de difícil implementação pode ter o peso 55, enquanto que um item de dificuldade parecida que deve ser entregue no mesmo sprint, só pode ter os valores intermediários (34 ou 89).

No decorrer do projeto, e com um controle do projeto, é possível medir quanto “esforço” é entregue em cada sprint e prever quais tarefas podem ser entregues nos próximos de acordo com o seu peso.

scrumy.com

27/06/2011 4 comentários

Para quem não conhece o SCRUM, existe uma forma muito prática de controlar o andamento de um projeto, através do chamado “Dashboard”. Nada mais é do que você colocar as fases de um projeto em colunas (To Do, In Progress, Verify and Done) e escrever em “post-its” todas as tarefas (PBIs ou Product Backlog Itens)  desse projeto. A medida que o trabalho vai sendo desenvolvido, os “post-its” vão mudando de fases.

Já baixei vários DashBoards interessantes na internet, mas agora que comecei a trabalhar com o scumy.com, minha vida mudou… hehehe… Você pode criar User Stories, Tasks, PBIs, Bugs, Sprints, etc. Não é nenhum software sensacional, mas muito bom para controlar o andamento de um projeto, ainda mais quando as equipes trabalham fisicamente separadas. Vale a dica!!!

Categorias:Dicas, Ferramentas, Scrum

Organizing a Scrum Team

O segundo capítulo do livro “Professional Scrum with Team Foundation 2010” trata de como organizar e qual o papel de cada profissional dentro de a equipe.  São eles:

    • Product owner – responsável por determinar as características / módulos do sistema e como deve funcionar
    • ScrumMaster – gerente de projeto, coordenador, responsável pela produtividade, entregas, comunicação.
      As duas principais tarefas dele é certificar-se da produtividade da equipe e dar feedback através dos release.
      Tarefas: fazer as reuniões diárias, envolver as pessoas necessárias, forçar a comunicação, determinar o tamanho do time.
    • TeamMembers – responsáveis por desenvolver/testar o sistema

    O capítulo comenta bastante sobre com coordenar o “Daily Scrum” todos os dias. A reunião diária deve ser para aquecer a equipe e forçar todos a lembrar o que está sendo desenvolvido, porque, e para que. Nesse momento cada profissional do time deve falar. Isso força o próprio desenvolvedor a se concentrar no que está fazendo e quais as suas atividades para aquele dia. O ScrumMaster deve organizar qualquer trabalho que esteja travando o desenvolvimento de alguma tarefa. Questões técnicas podem ser resolvidas na própria reunião ou durante o dia em conversar com os desenvolvedores. Questões de escopo, dúvidas de regras de negócio devem ser tratadas pelo ScrumMaster. Não que ele tenha que saber responder todas as questões, mas é responsável por correr atrás da solução, procurar o Product owner para discussões, etc.

Especificar e priorizar características a serem desenvolvidas são um trabalho do product owner. Ele escreve o que é chamado de “User Stories”, que são pequenas descrições das funcionalidades que o produto precisa ter. Internamente a equipe cria os products backlog itens (PBIs) que são pequenas tarefas a serem desenvolvidas.
Fala-se sobre a “Prioridade das tarefas” vs “Valor de negócio (Business Value) vs Esforço”. A prioridade das tarefas é diferente do valor de negócio. Uma tarefa pode ser imprescindível, mas só pode ser desenvolvida nos últimos sprints pois depende de outras tarefas. E também é diferente da dificuldade e esforço necessário para entregar cada uma das tarefas.

Uma coisa que achei bem interessante e que gera bastante discussão é como é organizada uma equipe com Scrum. Normalmente são equipes pequenas, com poucos desenvolvedores, 1 ScrumMaster e 1 Product Owner. Mas isso não é uma regra. Podem existir mais de 1 Product Owner na equipe, cada um com uma responsabilidade. Por exemplo, um responsável pela área de Marketing e outro na área Comercial.
Em grandes projetos, pode-se criar várias pequenas equipes (que contém 1 ScrumMaster, 1 Prodcut Owner e os membros da equipe). A melhor forma de separar em várias equipes segue a seguintes prioridades:

    • Separar por característica
      • Vantagem: Reduz a dependência entre outros times, foca em desenvolver as características do projeto, promove aceitação de testes.
      • Desvantagens: Solução da arquitetura e design podem se perder durante o processo, aumentando o custo de suporte e cada time precisa “reinventar a roda”
    • Separar por preocupações transversais(Ex: um time cuida do desenvolvimento do cache de objetos, outro da segurança do sistema):
      • Vantagens: Reduz o custo e aumenta a qualidade técnica do projeto, promove arquitetura consistente das features.
      • Desvantagens: Não é uma divisão boa para o cliente, time não consegue visualizar o escopo geral do projeto, necessita definir a interface primeiro, mudanças são custosas.
    • Separar por tecnologia
      • Vantagens: Maximiza habilidade do especialista/desenvolvedor, promove testes unitários dentro de cada tecnologia.
      • Desvantagens: Aumenta a dependência entre as equipes, ninguém é responsável pelas entregas de funcionalidades, cada equipe está focada em entregar a sua parte, mas não presta atenção na complexidade técnica do produto.

Depois de toda essa separação em várias equipes, é necessário organizar a comunicação entre elas na “Scrum of Scrum Meeting”. É uma reunião aonde podem participar um membro de cada equipe que tenha capacidade de dar o feedback sobre o andamento das atividades. Não necessariamente precisa ser o ScrumMaster.

Quando existem várias equipes, cada uma delas tem seus próprios sprints. Mas lembrando que normalmente ela depende de trabalhos e entregas de outras equipes, então o trabalho precisa ser muito bem coordenado. Uma coisa que o capítulo não comentou é como organizar para que isso ocorra sem maiores problemas. E o mais importante… como gerar Releases entregáveis para o Product Owner??? Essa é uma boa discussão, não!?

Então existe uma grande comparação entre os papéis/responsabilidades entre SCRUM e MSF. Em resumo, como é possível perceber, o SCRUM tem equipes menores e existe mais responsabilidade. Ou seja, é necessária uma equipe com mais conhecimento. O MSF tem responsabilidades bem definidas e separadas, aonde existe uma equipe de testes/QA, o papel do Gerente de Projeto se compara ao PMI. Não vou entrar em detalhes, mas as comparações no livro são muito bem organizadas.

Trechos do livro que grifei:

“The ScrumMaster has two primary responsibilities: ensure team productivity and tracking  Project status through release. These are not easy task, but when treated as top-line job  responsibilities, they are quite achievable.”

“The product owner is responsible for ensuring that product features meet customer expectations. The product owner can be a leader in the user community, someone from marketing, a business analyst with the IT arena, or any other individual who can effectively communicated business needs.”

“The primary responsibility of the team members is to build the product. They determines the architecture, component design, and user experience. They work within boundaries of time and coast and are empowered to make trade-offs to build the best possible product within those limits. Both development and testing occur within the team. Because is no separate QA group, the team members are both empowered and responsible for their own testing.”

“Four resources are required to ship great software: time, money, people an technology.”

“The architect role, regardless of project management methodology , is to manage the complexity of component parts of the system. Developers write the code, but the architect must be able to see the forest for the trees. ”

 Abaixo achei uma charge sobre equipes de SCRUM… hehehe..

Categorias:Scrum

Scrum – Shipping Software

Como primeiro resumo do capítulo 1, “Shipping Software” do livro “Professional Scrum with Team Foundation Server 2010”, os autores falam sobre o projeto como um todo e como organizar o desenvolvimento com Scrum. Como sou leigo no assunto, acabei discutindo algumas questões com a equipe que atualmente coordeno na empresa.

Scrum é uma metodologia de desenvolvimento de software com processo iterativo, aonde existe um escopo inicial do que deve ser desenvolvido e as entregas são divididas em “sprints” que consequentemente são compostas de novos módulos, melhorias, correção de bugs. Scrum prevê que sempre haverá alterações no escopo do projeto (como acontece na maioria das vezes), e que o projeto vai criando valor no decorrer do seu desenvolvimento.

Scrum é baseado em desenvolvimento Agil (Agile) aonde o objetivo é entregar a maior quantidade de “features” sem perder tanto tempo documentando. A idéia é planejar e executar.

As metodologias MSF (Microsoft Solution FrameWork) e WaterFall são comparadas com Scrum.

Microsoft Solution FrameWork

O MSF é uma metodologia parecida com Scrum, aonde existe iteratividade no desenvolvimento. Ele prega que o projeto pode mudar seu escopo, profissionais, tecnologia depois de iniciado. A ideia é desenvolver vários releases, sendo que cada um deles passa por um processo de visão/escopo, aprovação do plano de projeto, desenvolvimento, validação do release e entrega.

Diferente do Scrum, teoricamente um release não pode ser entregue com Bugs, ou seja, dentro de uma entrega existem várias iterações para que o produto seja entregue com a qualidade esperada.

WaterFall

É o método que vejo ser mais utilizado dentro das empresas e que foi uma das primeiras metodologias a serem especificadas. Acredito até que os profissionais ficam “preso” nessa forma de trabalho.

Essa metodologia prega a necessidade de um grande trabalho de planejamento e documentação (algumas  vezes chamado de blueprint). Prazos são especificados, cronogramas (característica para o Gráfico de Gantt) são desenvolvidos e então se inicia o desenvolvimento. Qualquer alteração de escopo implica em um grande trabalho de gerenciamento de mudança, aonde é necessário analisar documentação, escopo, prazo, custo, risco, comunicação. Dependendo do tamanho do projeto, existe um comitê de mudanças para avaliar a viabilidade das tarefas.

Essa metodologia é indicada para projetos que tem um escopo bem definido, aonde o cliente sabe exatamente como deve ser desenvolvido. Será que existe algum cliente assim? Eu não conheço! 🙂

Vejo que o PMI prega muito essa metodologia, procurando controlar todas as suas áreas para que nada saia do controle

Citações

Sublinhei no livro conceitos que achei importante nesse capítulo e repasso para fortificar esse post.

“The fundamental concept is to put customer value at the center of everything you do. While maximizing customer value, you also maximize your team´s productivity and predictability with each release, create a sustainable team environment for shipping great software.”

“It´s one thing you have great vision; it´s quite another to turn that vision into a great product.”

“The product owner, who fills the product management role in Scrum, is embedded in the Scum team and is counted on to know the user intimately. This person must know the user´s likes and dislikes, tolerances, and aspirations. The product owner  must know what the users love, what they don´t like, and what they don´t care about. Essentially, the product owner´s insight into user needs is essential.”

“Iterative nature – The product features are defined iteratively and frequently. They come in and out of scope based on product owner decisions, whish directly impact the value of the product.”

“For instance, planning a project using a traditional software development methodology involves allocating time for requirement definition, design, development, testing, user acceptance, release management, and support.”

“Because of these unknowns and the fixes constraints in the triangle, you simply cannot offer a fixed-cost commitment for a fixed-feature product. You therefore have two alternatives: Vary the cost or vary the features. If you must deliver a fixed budget, then the answer is simple: Vary de features.”

“The geometry of the project management triangle, with constant angles, dictates the fact that you cannot change just one side of the triangle without adjusting the others. If you increase de features, then you´ll in increase the time and coast lines. If you increase time, then you´ll get more features, but it will cost more. If you want to decrease cost, you´ll spend less time and get fewer features.”

“Scrum is a iterative software development process. In a iterative process, a product undergoes many release, some major and some minor, with each release adding more value to the product. This type of process enable a team do delivery value to the customer early and to get feedback that can be quickly incorporated into future product development.”

Conclusão

Com essa definição do Scrum, eu entrei em um conflito pessoal ( 🙂 ) pois sempre trabalhei fortemente com escopo e prazo. Discutindo com minha equipe a respeito da metodologia, e com profissionais experientes que já trabalharam em vários projetos de muitas empresas eles comentaram:

– Vejo que o Scrum é muito bem aplicado em uma fábrica de software aonde a demanda é pela entrega de um produto específico, melhorias, correção de bugs. O Scrum Master é responsável por visualizar o andamento do projeto e se reportar para o cliente/chefe.

– Scrum não é aplicável, por exemplo, dentro de uma empresa financeira como bancos. Essas empresas tem o perfil de documentar e deixar claro o que deve ser desenvolvido e entregue. Qualquer alteração deve ser documentada e discutida.

Scrum with Team Foundation Server 2010

27/05/2011 2 comentários

Nem acredito que o livro chegou tão rápido no Brasil. Eu comprei pela Amazon e paguei $ 39,16 com frete. Se encomendasse em lojas no Brasil, o prazo era de 10 semanas e teria que desembolsar R$ 100,00… um absurdo.

Mas voltando um pouco no tempo… Atualmente coordeno uma equipe de desenvolvimento de aplicações WEB em .Net. Nossos trabalhos normalmente são entregues no prazo e com uma qualidade que satisfaz nosso cliente interno, mas nunca realmente medimos como está o andamento do projeto dentro do departamento, se as tarefas geram bugs, se realmente são entregues com qualidade, quanto tempo falta para entregar o projeto, se os profissionais da equipe estão melhorando seu conhecimento/trabalho, etc.

Comecei a pesquisar como poderia entregar relatórios gerenciais consistentes. Então encontramos uma apresentação do Aaron Bjork que tem grande experiência com VSTS e SCRUM (caso queiram a apresentação me enviem um email ou comentem esse post). A apresentação exemplifica a metodologia SCRUM e como utilizá-la com VSTS 2010. Unindo o útil ao agradável, estamos com o projeto de atualizar a versão do VSTS para 2010 e implantar a metodologia dentro do departamento. Prometo que sempre que tiver novidades a respeito, postarei a respeito.