Image Image Image Image Image
Scroll to Top

Topo

sprint

16

fev
2012

Sem Comentários

Em Blog
Scrum

Por Allison

Rotação do papel do ScrumMaster: se puder, evite

Em 16, fev 2012 | Sem Comentários | Em Blog, Scrum | Por Allison

Fonte: Rafael Buzon/InfoQ


Algumas equipes ágeis têm tido a iniciativa equivocada, segundo Mike Cohn, de rotacionar o papel do ScrumMaster entre os integrantes da equipe. Em post publicado recentemente em seu blog, Cohn argumenta que está sendo subestimado o papel do ScrumMaster quando se afirma que qualquer um pode exercê-lo e acrescenta:

Não defendo esta abordagem, pois não acho que demonstra o respeito apropriado aos desafios e ao significado do papel de ScrumMaster.

Cohn revela, entretanto, que há situações nas quais se deseja criar oportunidades de aprendizado, e que nesses casos rotacionar o ScrumMaster aumentaria o entendimento na equipe sobre como é estar neste papel.

Outra situação, para Cohn, que permitiria a rotação do ScrumMaster, surge quando se deseja evitar a imagem de um “gerente da equipe”. Com a rotação das responsabilidades, o “poder” fica mais balanceado e a equipe se torna mais autogerenciável.

Cohn não recomenda que o papel do ScrumMaster seja rotacionado sistematicamente, e aponta alguns problemas decorrentes de rotações frequentes:

  • Aqueles que assumiram o papel de ScrumMaster, devido a uma rotação, geralmente têm outras atribuições que terminam ganhando prioridade durante o sprint;
  • É difícil treinar pessoas em número suficiente para fazer bem o papel do ScrumMaster;
  • Algumas pessoas usarão seu tempo como ScrumMaster para forçar mudanças nos processos;
  • Designar alguém como ScrumMaster durante alguns sprints não garante que esta pessoa irá valorizar esse trabalho. Isso pode levar à impressão, da parte de ScrumMasters, de que o Scrum seria um erro.

Rotacionar o papel do ScrumMaster, portanto, não deve ser uma prática permanente. É aceita por Mike Cohn somente por tempo determinado e em situações específicas, que contribuam para o aprendizado da equipe e para a sua capacidade de autogerenciamento.

Quais são suas experiências em rotacionar o papel do ScrumMaster em sua organização?

Tags | , , ,

05

jan
2012

Sem Comentários

Em Agile
Blog

Por Allison

SCRUM, KANBAN e XP – Indo além de Projetos de TI

Em 05, jan 2012 | Sem Comentários | Em Agile, Blog | Por Allison

Três Metodologias Ágeis e como usá-las em Projetos que não sejam de TI

Muitos gerentes de projeto que trabalham com desenvolvimento de software estão bem familiarizados com as entregas rápidas e iterações constantes do desenvolvimento ágil. Mas agora, ágil está ganhando terreno em outras indústrias. Aqui estão três populares metodologias ágeis, e como elas podem trabalhar em projetos que não sejam de desenvolvimento de software.

1. Scrum

Scrum tem encontrado seu caminho dentro de uma variedade de organizações que trabalham com projetos, incluindo escritórios de advocacia e universidades.

Veja como ele funciona, de acordo com a Scrum Alliance:

  • Uma lista de desejos priorizados chamada product backlog é criada.
  • Durante a fase de planejamento, a equipe seleciona um pequeno pedaço do topo da lista de desejos, e chama de sprint backlog, e decide como implementar essas tarefas.
  • A equipe recebe um certo período de tempo, chamado de sprint, para completar o trabalho especificado no sprint backlog e avalia a cada dia o seu progresso.
  • No final do sprint, geralmente de duas a quatro semanas, o trabalho deve estar pronto para entregar a um cliente.
  • O sprint termina com uma revisão de sprint e uma retrospectiva.
  • O próximo sprint, então, começa.

Para Scrum atingir outras indústrias, você teria que: “quebrar os requisitos para um discreto conjunto de itens que poderiam ser trabalhados em um conjunto de iterações”, diz Bob Tarne, PMP, engagement manager para IBM Software Group em Lenexa , Kansas, EUA.

Ele usou o exemplo de trabalhar com um editor e ilustrador em um projeto de publicação.”Nós quebramos o livro em capítulos e começamos a primeira iteração com o capítulo um”, diz ele.”Nós escrevemos, ilustramos e realizamos a edição dentro de um [Sprint]. Nós revisamos no final do [Sprint] e, em seguida, planejamos a iteração dois com o segundo capítulo. ”

2. Kanban

Com raízes na indústria automobilística, Kanban é adaptável a projetos que não sejam de desenvolvimento de software, especialmente de recursos humanos e legal, porque os seus princípios não estão associadas a qualquer prática específica, afirma Abdiel Ledesma, PMP, proprietário do Grupo Equation no Panamá e presidente da PMI Capítulo Panamá.Esses princípios são:

  • Visualize o fluxo de trabalho: Isto pode ser feito usando um cartão de parede, com as colunas representando os estados ou etapas do fluxo de trabalho e as cartas que representam os itens de trabalho
  • Limite o andamento do projeto: “Se a sua equipe estava trabalhando em cinco itens de uma vez e não a fez progressos, reduza esse número para dois ou três”, diz Sliger. “Selecione o mais importante, os itens de trabalho mais valiosos. Trabalhe sempre na próxima coisa mais importante.”
  • Gerencie o fluxo: O fluxo de trabalho através de cada estado ou etapa deve ser ativamente monitorado, medido e relatado, a fim de avaliar os efeitos positivos ou negativos de mudanças incrementais e evolutiva.
  • Tornar explícito as políticas dos processos: Garantir uma compreensão explícita do mecanismo de um processo para alcançar uma discussão racional e objetiva dos problemas e facilitar o consenso em torno de sugestões de melhoria.
  • Melhore de forma colaborativa: Kanban para realmente funcionar, as equipes devem colaborar. “Kanban é bom como qualquer outro método ágil, em que a equipe tem que se reunir para planejar, diariamente preferencialmente em pé, e pode optar por fazer retrospectivas para inspecionar e adaptar o seu processo”, diz a Sra. Sliger. “Todos esses itens, e mais envolver a colaboração e melhoria contínua.”

Para se adaptar a um projeto de recursos humanos, por exemplo, visualizar o processo de contratação através de uma placa de Kanban. Categorias na placa seriam incluir uma coluna para os candidatos que enviaram currículos, uma coluna para os candidatos que estão qualificados para a posição e uma coluna para os candidatos que se mudaram após o processo de entrevista por telefone. Apoio que fluxo de trabalho com um documento que define quem é responsável por esses diferentes papéis e processo de kickoff o com uma pequena reunião com a participação de todas as partes interessadas.

O nome por si só pode desligar-se muitas equipes de projetos trabalhando em projetos fora desenvolvimento de software e eles podem estar certos.

3. Extreme Programming

XP se concentra em desenvolvimento orientado a testes, lançamentos de pequenas “releases”, e uma estrutura de equipe que inclui o cliente, enquanto que as abordagens tradicionais de gerenciamento de projeto, geralmente adotam, diz Mr. Tarne.

Muitas das regras para esta metodologia ágil são projetadas especificamente para tratar de codificação, projetar e testar. Ter planejamento, por exemplo: Um projeto tradicional faz planejamento na frente; XP diz para planejar o lançamento a um nível elevado, mas o plano de cada iteração em seu início (ou a cada duas semanas).

Mas XP oferece algumas lições aprendidas para projetos além de TI.

“O mais poderoso das práticas ágeis é o reconhecimento das pessoas como o ativo mais valioso de projeto e a liderança como catalisador”, disse Ledesma diz.

“XP tem cinco valores que podem ser enfatizado em muitos tipos de projetos (além desenvolvimento de software) : Simplicidade, comunicação, feedback, respeito e coragem”. Esses valores podem, e devem ser aplicados a todos os projetos em todos os setores, o Sr. Tarne diz. “Comunicação é um grande exemplo”, diz ele. “Eu vi uma série de projetos que descarrilou por causa das comunicações pobres”.

Traduzido de http://www.pmi.org/passport/dec11/agile-non-it-projects.htm

Fonte: PMI.org

Tags | , , , , , ,

13

nov
2011

Sem Comentários

Em Blog

Por Allison

Scrum

Em 13, nov 2011 | Sem Comentários | Em Blog | Por Allison

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Onde os projetos são dividos em 4 ciclos como mostra abaixo:

  • Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é priorizada para refletir a necessidade dos clientes ou demandas do mercado. Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.
  • Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser entregues são agora tratados no Sprint Backlog. As tarefas agora são responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas.
  • Reuniões Diárias: o Scrum Master se reune diariamente com a Equipe num mesmo horário, para que se reporte:
  • O que foi feito ontem?
  • O que se pretende fazer hoje?
  • Quais são os impedimentos que estão atrapalhando a execução das tarefas?
  • Revisões: no final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint.

Algumas pessoas que trabalham diretamente no dia-a-dia do Scrum:

  • Equipe: responsável por entregar soluções, geralmente é formada por um grupo pequeno (entre 5 e 9 pessoas) e que trabalha de forma auto-gerenciada;
  • Product Owner: responsável pela visão de negócios do projeto, é ele quem define e prioriza o Product Backlog. Geralmente é o papel desempenhado pelo cliente;
  • Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência.

Fonte: Alex/BitMasters

Tags | , , ,