standard-title Scrum https://i2.wp.com/www.scrumportugal.pt/wp-content/uploads/como-funciona-o-scrum.png?fit=1300%2C570

Scrum

Scrum

Scrum é uma framework ágil de desenvolvimento de produtos. Esta abordagem define uma estratégia flexível e holística de desenvolvimento de produtos. Em vez de uma abordagem sequencial, os produtos são  progressivamente desenvolvidos e melhorados de forma iterativa e incremental. Em vez de uma hierarquia top-down, as equipas auto-organizam-se. Em vez de uma comunicação hierárquica, de base escrita e formal, as equipas trabalham co-locadas fisicamente no mesmo espaço físico. A comunicação é diária e cara a cara entre todos os membros da equipa.

Um princípio-chave é o reconhecimento de que os clientes podem, e provavelmente vão, mudar de ideias. Mudar de ideias sobre o que querem, como querem e quando querem. Esta volatilidade significa que os requisitos não podem ser facilmente abordados de forma tradicional preditiva ou planeada. Como tal, esta metodologia adota uma abordagem empírica baseada em evidências – aceitando que o problema não pode ser totalmente compreendido ou definido. A ideia motora é maximizar a capacidade da equipa para entregar rapidamente. Responder às necessidades emergentes e responder de forma rápida às alterações inevitáveis.

O Scrum é baseado nos principios e fundamentos da metodologia Agile. A abordagem é por sua vez baseada num conjunto de valores e princípios que ficaram documentados no manifesto agile, escrito em 2001. Para saber mais sobre desenvolvimento incremental e iterativo, desenvolvimento adaptativo em vez de perspectivo, timeboxing e comunicação presencial em tempo real, leia o nosso post metodologia agile. Para saber mais sobre o conceito de sprint consulte o nosso post sobre sprints.

A origem do nome Scrum

Quando Jeff Sutherland criou o processo de Scrum em 1993, ele empregou o termo “Scrum” depois de ver uma analogia num estudo de 1986 de Takeuchi e Nonaka, publicado na Harvard Business Review. Nesse estudo, Takeuchi e Nonaka comparavam o alto desempenho de equipas multifuncionais com a formação scrum usada por equipas de Rugby.

Para saber mais sobre o que é um scrum master veja o post “Scrum Master“. Saiba também tudo sobre o que é um product owner.

Não se esqueça de ver também os posts sobre alguns termos especificos :

Planning Poker

Planning Poker

Planning Poker Planning Poker, também chamado Scrum Poker, é uma técnica de estimativa baseada na geração de consenso. Esta técnica é usada sobretudo para estimar o esforço ou pontos (esforço relativo) necessários para desenvolver cada requisito. Os membros do grupo fazem estimativas jogando cartas numeradas viradas para baixo para a mesa, em vez de falarem em voz alta. Os cartões são exibidos, e as estimativas são discutidas. Ao exibir os cartões em simultâneo, o grupo minimiza efeitos de enviesamento cognitivo, onde o primeiro número exibido ou falado em voz alta estabelece um referente para as estimativas posteriores. O Planning Poker é uma variação do método Delphi e Wideband Delphi, onde as estimativas são apresentadas de forma anónima. O método foi inicialmente criado por James Grenning em 2002. Mais tarde Mike Cohn popularizou o termo no livro Agile Estimating and Planning. Porquê e o que necessita para usar o Planning Poker A razão A razão para utilizar o planning poker é evitar a influência de uns participantes nos restantes. Se um número foi dito pode influenciar e sugerir um valor aos restantes participantes. Este método pretende forçar que as pessoas pensem de forma independente e proponham um valor segundo o que pensaram não sendo inflenciadas pelos outros. Para isso todos devem mostrar o seu cartão com o valor ao mesmo tempo. Equipamentos Para utilizar este metodo de estimativa cada participante deve ter um conjunto de cartas com valores. Poderá ser necessário um cronometro se for importante limitar o tempo de discussão de cada ponto. As cartas devem representar, por exemplo, a sequência de Fibonacci – 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Esta sequência permite refletir a incerteza das tarefas maiores. Distingir 1 de 2 pode ser facil mas 21 de 22 pode não ser assim tão fácil.

18 April 2017
publicado por admin
Kanban Board

Kanban Board

Kanban Board Um Kanban Board é uma ferramenta de organização do trabalho em curso. O trabalho é representado em cartões, post its, placas ou imãs. Cada um desses objetos representa uma componente de trabalho. Os objetos são depois organizados em listas que representam o processo de produção ou desenvolvimento do produto. Um exemplo de organização de listas é “Não iniciado”, “Em progresso” e “Concluído”. Em Scrum, uma organização possível de listas para o Kanban é “Backlog”, “Em Desenvolvimento”, “Concluído”, “Aceite” e “Entregue ao Utilizador”. À medida que o trabalho progride, a equipa vai movendo os objetos entre as diferentes secções. Esta ferramenta também ajuda a melhorar a produtividade. Para isso, é possível definir um limite máximo de trabalho em curso para impedir que a produtividade da equipa seja negativamente influenciada pelo acumular de elementos de trabalho em cada fase de desenvolvimento do produto. Os Kanban boards podem ser usados para organizar muitas áreas de uma organização: Desenvolvimento de software Equipas de venda Equipas comerciais Gestão de tarefas pessoais. Para além de ajudar a manter controlo sobre o projeto e aumentar a produtividade, esta ferramenta ajuda também a criar um sentido de ownership sobre o projeto. A visibilidade sobre o trabalho e sobre o andamento do trabalho ajuda cada elemento da equipa a sentir-se como parte responsável de um todo. Veja também o post sobre a metodologia scrum e sobre a metodologia agile.

18 April 2017
publicado por admin
Agile Manifesto

Agile Manifesto

Agile Manifesto O Agile Manifesto foi um documento criado em 2001 por um conjunto de 17 signatários que estabelece um os valores e princípios fundamentais das metodologias ágeis. Valores do Manifesto Agile O Agile Manifesto estabelece quatro valores orientadores: Os indivíduos e suas interações são mais importantes que os procedimentos e ferramentas; Software a funcionar é mais importante que acima de documentação completa; A colaboração com o cliente é mais importante que a negociação de contratos; A capacidade de responder a alterações é mais importante que seguir um plano; Estes valores não pretendem negar o valor dos procedimentos, ferramentas, documentação, contratos e planos. Em vez disso, pretendem estabelecer um escala de prioridades que introduza flexibilidade nos projetos. Princípios do Manifesto Agile O Agile Manifesto estabelece ainda 12 princípios da metodologia agile: Garantir a satisfação do cliente, através da entrega rápida e continua de software funcional; Até mesmo mudanças tardias ao âmbito do projeto são bem-vindas. Software funcional é entregue frequentemente; Cooperação constante entre as pessoas que entendem do ‘negócio’ e os programadores; Os projetos devem ser criados em torno de indivíduos motivados. Dê-lhes o ambiente e o apoio que necessitam, e confie-os para começar o trabalho feito. O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipa de desenvolvimento é a conversa cara-a-cara. Software funcional é a principal medida de progresso do projeto; Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolprogramadores e utilizadores devem ser capazes de manter um ritmo constante indefinidamente A atenção contínua à excelência técnica e ao bom design aumenta a agilidade. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial. As melhores arquiteturas, requisitos e projetos emergem de equipas auto-organizadas. Em intervalos regulares, a equipa reflete sobre como tornar-se mais eficaz, em seguida, ajusta o seu comportamento em conformidade. O manifesto foi assignado pelos seguintes signatários: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherlands, Dave Thomas

18 April 2017
publicado por admin
Agile Sprint

Agile Sprint

Agile Sprint O Agile sprint também é conhecido por agile iteration. Este é o termo utilizado para referir uma ciclo de trabalho, de duração fixa, onde uma equipa entrega componentes de um produto. Em Scrum, é normalmente usado o termo Sprint em vez de iteração. Cada Sprint inclui uma pequena sessão de planeamento, seguida por um período de desenvolvimento do produto. Cada sprint termina, finalmente, num processo de avaliação e retrospectiva para identificar os ajustamentos necessários ao produto e processo. Diferentes sprints podem ser combinados para formar uma release. Em Scrum, um sprint tem geralmemte a duração entre uma a quatro semanas. Alguns projetos Scrum adoptam uma lógica “Scope driven”, em que o ciclo repete-se até que todos os elementos desejados sejam implementados. Nestes casos, o número de sprints estimados para completar o projeto pode variar. Outros projetos Scrum adoptam uma lógica “Schedule driven”, completando todas os elementos que sejam possíveis em um número pré-definido de ciclos. Nestes casos o número de sprints é definido e fixado desde o início.

18 April 2017
publicado por admin
Metodologia Agile

Metodologia Agile

Metodologia Agile A metodologia Scrum é a mais reconhecida e utilizada metodologia agile para desenvolvimento de produtos e serviços. A metodologia Agile descreve um conjunto de valores e princípios pelos quais os produtos são desenvolvidos. Entre esses princípios destacam-se o desenvolvimento incremental e iterativo; desenvolvimento adaptativo em vez de perspectivo; timeboxing e comunicação presencial em tempo real.  Vamos ver mais em detalhe cada um destes princípios. Desenvolvimento iterativo e incremental A ideia básica por trás do desenvolvimento iterativo e incremental é desenvolver um produto através de ciclos repetidos (iterativos) e em pequenas porções de cada vez (incremental). Aproveitando o que foi aprendido no passado, o cliente e a equipa melhoram iterativamente o produto até que este esteja completo. Em cada iteração, são feitas modificações a componentes (desenvolvimento iterativo) e novas capacidades funcionais são adicionadas (desenvolvimento incremental). Desenvolvimento adaptativo em vez de prescritivo Os métodos tradicionais de desenvolvimento de produtos baseia-se num pressuposto nem sempre realista. O pressuposto é que um esforço inicial significativo de planeamento evita problemas de desempenho e más decisões. Paralelamente, uma definição detalhada de requisitos, procedimentos e desenhos, evitam inconsistências e defeitos. Ao longo da história da gestão de projetos, este pressuposto, aparentemente lógico, foi sistematicamente contrariado. A incerteza e volatilidade do contexto interno e externo do projecto, podem tornar inútil esse trabalho antecipado. Alterações nos requisitos, soluções, tecnologia ou prioridades, não só implicam alterações ao trabalho futuro como implicam reformulações no trabalho realizado. Os métodos adaptativos focam-se em reduzir o esforço up front de planeamento e desenho. O esforço é colocado em prever o que irá ocorrer no curto prazo, mantendo apenas uma visão de alto nível do longo prazo. Quanto mais longe for o horizonte de planeamento, mais vago é o Agile sobre o que ocorrerá nesse perído. Ao mesmo tempo, o agile incentiva as alterações, criando momentos onde o cliente pode alterar e avaliar o produto. Em vez disso, o enfase é colocado em facilitar a adaptação ao longo do projeto, criando momentos onde o produto, plano, estimativas e abordagens podem ser melhoradas. Timeboxing Timeboxing é usado como uma técnica de planeamento de projeto. A maioria dos métodos de desenvolvimento ágil quebram o trabalho de desenvolvimento de produtos em pequenos incrementos que minimizam a quantidade de planeamento e design antecipado. As iterações são períodos de tempo curtos (timeboxes) que normalmente duram de uma a oito semanas. O cliente e a equipa seleccionarão requisitos que possam ser “encaixados” nessa iteração. Caso seja necessário optar entre cumprir a duração da iteração ou completar o prazo da iteração, o tempo será sempre a restrição mais rígida. Comunicação presencial em tempo real A framework Agile dá preferência à comunicação presencial, cara a cara, como forma de manter uma ligação próxima entre a equipa, cliente e outros stakeholders relevantes. Ao contrário da comunicação escrita, a comunicação verbal em tempo real facilita a rápida e não constrangida troca de ideias, ajudando às boas relações e a criar um sentido de propriedade comum sobre o projeto. O Agile fomenta ainda que os membros da equipa e cliente estejam fisicamente agrupados numa sala. O agrupamento físico, facilita a comunicação, a integração entre o trabalho e o sentido de responsabilidade comum.

18 April 2017
publicado por admin
Metodologia Scrum

Metodologia Scrum

Metodologia Scrum Uma descrição resumida da metodologia Scrum é apresentada em seguida: O cliente, denominado no Scrum por product owner, cria uma lista prioritizada de requisitos chamada de product backlog. Estes requisitos são organizados por temas, épicos e histórias. Temas como agregação de requisitos. Épicos como grandes requisitos que ainda não foram detalhados. Histórias como requisitos detalhados vistos pela perspectiva do utilizador do produto. Esses requisitos são então estimados pela equipa usando técnicas como o planning poker. Durante o planeamento do sprint, o product owner descreve os requisitos prioritários à equipa. Essa descrição permite um planeamento mais detalhado das actividades necessárias para desenvolver os requisitos prioritários. Com base nesse planeaamento detalhado, a equipa de desenvolvimento confirma os requisitos a realizar nesse sprint. Quando não é possível realizar esses requisitos no tempo disponível, a equipa e o product owner negoceiam os requisitos que podem ser entregues de acordo com a sua complexidade e prioridade. A equipa decide como implementar esses requisitos e actualiza o sprint backlog A equipa tem uma certa quantidade de tempo – um sprint normalmente de 1 a 8 semanas – para completar o seu trabalho A equipa reúne-se todos os dias para avaliar o seu progresso (daily Scrum) Durante o período, o Scrum Master mantém a equipa focada nos seus objetivos O período termina com uma revisão do produto do sprint em conjunto com o cliente e stakeholders (Sprint review) A equipa reúne para realizar uma retrospectiva do sprint. A aprendizagem com o passado permite melhorar o processo no futuro. No final do Sprint, o trabalho deve estar pronto para entregar ao cliente e ser integrado no produto previamente existente. Quando começa um novo sprint, o cliente e equipa voltam a escolher alguns pontos da lista do product backlog e começa a trabalhar novamente.

18 April 2017
publicado por admin
Porque se chama Scrum?

Porque se chama Scrum?

Quando Jeff Sutherland criou o processo de Scrum em 1993, ele empregou o termo “Scrum” depois de ver uma analogia num estudo de 1986 de Takeuchi e Nonaka, publicado na Harvard Business Review. Nesse estudo, Takeuchi e Nonaka comparavam o alto desempenho de equipas multifuncionais com a formação scrum usada por equipas de Rugby.

18 April 2017
publicado por admin
Product Owner

Product Owner

Product Owner O Product Owner é um dos três papéis definidos dentro da metodologia Scrum. Ele é geralmente alguém com uma sólida compreensão do negócio, organização e mercado, que representa os utilizadores e outros stakeholders no projeto. A sua responsabilidade é ter uma visão das funcionalidades do produto que adicionam valor à organização e transmitir essa visão para a equipa scrum. Esta responsabilidade é realizada mantendo um product backlog, que é uma lista de requisitos priorizados para o produto. O product owner trabalha diretamente com o gestor de produto para poder aferir os requisitos para o product backlog. Depois o product owner leva  o product backlog para a equipa scrum. A equipa Scrum olha para o Product Backlog prioritizado, selecciona os itens mais prioritários. Estes são os itens que a equipa compromete-se a entregá-los no final do Sprint (iteração). Depois de escolherem os itens constrói-se um Sprint Backlog. A equipa compromete-se a executar um conjunto de atividades no Sprint e o Product Owner compromete-se a não trazer novos requisitos para a equipa durante o Sprint. Os requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipa comece a trabalhar num Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceites. O product owner também é responsável por aceitar as entregas do sprint, confirmar se estão de acordo com os requisitos definidos no sprint backlog definido para o sprint. As suas principais responsabilidades incluem: Desenvolver uma visão clara do produto Definir objectivos para cada sprint Produzir e manter um product backlog priorizado Clarificar os requisitos do produto Trabalhar com a equipa na definição dos requisitos a elaborar em cada sprint Comprometer-se com a equipa em não lançar novos requisitos para a equipa durante o sprint Especificar os requisitos do produto Estar disponível para a equipa durante o sprint

18 April 2017
publicado por admin

Scrum Master

Scrum Master

Scrum Master O Scrum Master é um dos três papéis definidos dentro da metodologia Scrum. A sua principal responsabilidade é ajudar a equipa a seguir o processo Scrum. Ele é parte da Scrum Team e atua como um servant leader. Ao contrário de um gestor de projetos numa abordagem waterfall, o Scrum Master não é responsável pelo planeamento, isso é feito pelo product owner e pela equipa. Também não gere os elementos da equipa, nem é responsável pela qualidade do produto, isso é feito pela equipa. Qual é então o seu papel? Ele é responsável por assegurar que a equipa segue o processo bem como ser um facilitador que remove obstáculos da equipa. Estas responsabilidades traduzem-se em: Facilitar a

18 April 2017 | publicado por admin