Image Image Image Image Image
Scroll to Top

Topo

scrum

SWX Labs 08 – Equipes de Alto Desempenho

Em 20, out 2014 | Sem Comentários | Em Agile, Blog, Destaques, Empreendedorismo, Scrum, SWX Labs | Por Mike Lopes

capa02

No SWX Labs 08 Mike e Vinicius  conversam com Alércio Bressano sobre Equipes de Alto Desempenho.

Alércio nos mostra o caminho das pedras para criar uma equipe de alto desempenho usando metodologias ágeis, notadamente o Scrum. Dos fracassos iniciais à construção de um time de alto desempenho, passando pela conquista da confiança de sua equipe Alércio mostra que inovar em metodologias de trabalho é um caminho possível e real.

Ouça o podcast clicando no play, se preferir faça o download

Assine o feed do nosso podcast e não perca nenhum episódio: http://feeds.feedburner.com/SWXLabs

Se preferir, também estamos no Itunes Store

Gostou? Não gostou? Erramos algo? Sua opinião é muito importante para nós, por isso deixe seu comentário ou envie email para mike@swx.com.br

Imagem: O termo Scrum se origina de uma jogada de Rugby, por isso homenageamos a competente e divertida seleção neozelandeza de rugby.

Tags | , ,

30

jan
2012

Sem Comentários

Em Blog
Scrum

Por Allison

7 opções para lidar com interrupções em Scrum e outras práticas ágeis

Em 30, jan 2012 | Sem Comentários | Em Blog, Scrum | Por Allison

Fonte: Rafael Buzon/InfoQ

Mishkin Berteig, consultor e coach Agile, publicou recentemente no blog Agile Advice uma revisão de um antigo artigo de sua autoria, acrescentando sete opções para lidar com interrupções nas empresas que utilizam práticas ágeis. Aqui resumimos essas alternativas.

1. Seguir rigorosamente o Scrum

As regras do Scrum são claras, defende Berteig:

Se não faz parte do trabalho planejado para o sprint, então não deve ser feito. Do momento em que a equipe se compromete com o trabalho no início do sprint, na reunião de planejamento, até o final do sprint, na reunião de revisão, é necessário que a equipe seja protegida contra interrupções.

Berteig comenta que ao se rejeitar as interrupções, como resultado de seguir fielmente o Scrum, os obstáculos que impedem as equipes são evidenciados dentro da organização. Desse modo é possível identificar as causas-raiz dos problemas e tratá-las de forma apropriada.

2. Reservar um tempo para interrupções

De acordo com Berteig, em determinadas condições do ambiente de trabalho é possível estimar o tempo médio gasto com interrupções no passado e reservá-lo no sprint para tais ocorrências. A alocação deste tempo poderia acontecer de duas maneiras:

Na reserva de tempo para interrupções, diz Berteig, há duas possibilidades para alocação do tempo:

Todos na equipe dispõem de certa quantidade de tempo diária para lidar com interrupções, OU um ou dois membros da equipe ficam dedicados exclusivamente a lidar com as interrupções durante o sprint.

O autor lembra ainda que o tempo planejado para as interrupções nunca deve ser excedido, pois comprometerá as entregas do sprint. Ele recomenda que o tempo economizado seja sempre usado para analisar as causas-raiz dos problemas.

3. Negociar mudanças de forma visível

Outra abordagem é formalizar o processo de interrupções e mudanças, permitindo às partes interessadas (stakeholders) negociar e conhecer os impactos de suas solicitações imediatamente. Para isso, Berteig recomenda o uso de cartões coloridos para representar a solicitação de cada stakeholder, e que sejam diferentes dos cartões planejados para o sprint.

Após avaliação e estimativa da equipe, os envolvidos podem negociar prioridades e determinar qual trabalho poderia ser deixado de lado para a entrada da nova demanda.

Para que esta abordagem seja bem sucedida, Berteig defende que três condições devem ser verdadeiras:

  • Ter um quadro de tarefas visível de forma constante (e não através de ferramentas eletrônicas);
  • Ter uma equipe que seja boa em estimar rapidamente e com bom grau de acurácia;
  • Deixar muito claro, com todos os envolvidos, as mudanças realizadas e seus impactos na iteração atual.

4. Ter uma equipe separada, dedicada a interrupções

Outra abordagem apontada pelo artigo é dedicar uma equipe exclusiva para tratar as interrupções, liberando as demais equipes para a construção dos produtos.

Sobre o perfil desta equipe dedicada a interrupções, diz Berteig:

Quanto mais capacidade técnica tiver esta equipe, e autonomia para que possa realizar mudanças no código, banco de dados etc, mais efetiva será em proteger das interrupções as equipes de produto.

Esta abordagem pode ser especialmente interessante, por tornar mais visíveis os custos associados às interrupções. Funciona, assim, como um indicador da qualidade do código entregue pelas equipes.

Berteig recomenda, ainda dentro desta abordagem, que as equipes não tenham seus integrantes rotacionados, pois isso pode trazer problemas de sinergia entre eles.


5. Realizar iterações extremamente curtas

Realizar iterações extremamente curtas é outra abordagem apontada pelo artigo, que possibilita a realização das interrupções em um tempo médio aceitável, sem contudo comprometer a iteração já planejada e em andamento.

Para tanto, é necessário conhecer historicamente o prazo médio com que as interrupções (novas demandas) precisam ser entregues e realizar iterações menores que este prazo. Berteig cita um exemplo:

Uma equipe na qual trabalhei recebia interrupções que precisavam ser resolvidas dentro de até três dias (interrupções mais urgentes eram raras). Decidiram, então, realizar iterações de dois dias para que na média conseguissem terminar de lidar com uma interrupção em três dias.

A lógica é a seguinte, utilizando o exemplo dado por Berteig: usando iterações de 2 dias a interrupção geralmente ocorrerá entre os dias 1 e 2 da iteração. A equipe, então, ao invés de já iniciar os trabalhos da nova demanda gerada pela interrupção, apenas a prioriza para o próximo ciclo de 2 dias. Dessa forma, a interrupção não atrapalha o ciclo atual e é resolvida dentro de um prazo médio aceitável.


6. Manter o Status Quo

Berteig considera também que as empresas podem optar em manter o status quo e continuar lidando com as interrupções da forma como fazem atualmente. Destaca que em algumas indústrias, a forma atual pode ser estratégica e pode permanecer, mas faz uma ressalva:

Se você escolher manter o status quo é importante que o faça de forma transparente e deixe claro o que está sendo sacrificado. Diga a todos das equipes exatamente porque está optando por essas escolhas e quais os benefícios esperados de se fazer dessa maneira.

7. Estimar com a velocidade de comprometimento

A velocidade de comprometimento (commitment velocity), segundo o autor, é a menor quantidade de pontos entregues em um sprint, medida ao longo do projeto. Utiliza-se essa velocidade como sendo o limite possível para o planejamento dos próximos sprints, permitindo com isso que a equipe se comprometa tanto com as entregas do projeto como com as interrupções.

A equipe pode se sentir tentada a calcular a média das velocidades realizadas e utilizá-la como medida para o planejamento dos sprints, mas Berteig alerta que a média não representa a velocidade de comprometimento e acrescenta:

Com base na lei dos grandes números e no teorema do limite central, usando esta ferramenta da Velocidade de Comprometimento por muitos sprints, sua capacidade de manter compromissos, mesmo com interrupções, se aproximará cada vez mais de 100% de certeza.

Escolhendo a melhor abordagem

Para que a abordagem escolhida seja bem experimentada, Berteig recomenda que seja feita uma decisão consciente e que seja exercitada por tempo suficiente a fim de entender se funciona ou não para você. E acrescenta algumas considerações:

  • Se você está tentando realizar uma melhoria radical em sua organização, eu recomendaria escolher a opção 1 ( Seguir rigorosamente o Scrum) ou a opção ou 7 (Estimar com a velocidade de compromisso). Ambas as opções colocam pressão na equipe e na organização, em busca de melhoria;
  • Se você não tem um forte apoio executivo para o Agile, então as opções 2 (Reservar um tempo para interrupções), 4 (Ter uma equipe separada, dedicada para interrupções) e 5 (Realizar iterações extremamente curtas), serão as melhores;
  • Se você tem um forte apoio executivo, mas não está desesperado em melhorar sua organização, considere a opção 3 (Negociar mudanças de forma visível);
  • E claro, a opção 6 (Manter o Status Quo) é a mais fácil… Mas não recomendo! A agilidade requer mudanças sistemáticas para encorajar a melhoria contínua, e todas as demais opções ajudam nesse aspecto.

Tags | , , ,

09

jan
2012

Sem Comentários

Em Agile
Blog

Por Allison

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

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

Para os gerentes de projetos de TI seguindo a linha tradicional, não resta muito tempo até que ouçam algo como “Lembra-se daquele projeto? Decidimos usar nele método ágeis”, e na semana seguinte chegar à empresa uma consultoria em Agile e começar a explicar Scrum, XP, User Stories, Sprints, TDD e uma série de outras técnicas e conceitos. Enquanto isso, o gerente provavelmente irá começar a revirar a internet tentando entender o que fazer, e pode se surpreender ao descobrir que gerentes de projetos aparentemente não são indispensáveis nessas metodologias.

Tenho presenciado muitos gerentes nesta situação, alguns chegando a temer seriamente os métodos ágeis. Por isso a inspiração de escrever um artigo que apresente o Agile para os gerentes de projetos que estão usando práticas mais tradicionais.

Benefícios das metodologias ágeis

Metodologias ágeis, nunca é demais lembrar, são um conjunto de práticas baseados em princípios e valores descritos no Manifesto Ágil. Em 2001 um grupo de experientes líderes de TI, insatisfeitos com o gerenciamento tradicional de projetos de software, reuniu-se e compartilhou novas maneiras para se fazer bom software. Entre as várias metodologias consideradas ágeis, o Scrum e o Extreme Programming (XP) são as mais utilizadas.

O Agile pode resolver alguns dos principais problemas encontrados por um gerente de projetos e trazer diversas vantagens; por exemplo:

  • Identificar, com facilidade e clareza, as funcionalidades do software sendo construído e o que ainda falta fazer;
  • Mostrar de forma efetiva os resultados e o progresso real do projeto;
  • Entregar versões funcionais do sistema, ao invés de somente anunciar atrasos e problemas;
  • Lançar o software antes da data final e mostrar aos usuários que podem contar com novas funcionalidades poucas semanas após a requisição, ao invés de meses ou até anos depois.

O objetivo das metodologias ágeis, portanto, é simples mas ao mesmo tempo desafiador: satisfazer o cliente por meio de entregas contínuas e antecipadas de software, com valor agregado. Entre os benefícios podemos citar:

  • Disponibilizar uma nova versão do software regularmente, a cada duas ou quatro semanas;
  • Poder lidar com pedidos de mudanças e replanejar o projeto em poucas horas;
  • Descobrir os principais riscos e problemas de integração durante as primeiras semanas do projeto, enquanto ainda há tempo de lidar com eles;
  • Visualizar o progresso e o resultado efetivo do projeto a partir de versões intermediárias do software;
  • Manter um alto comprometimento da equipe de TI durante todo o projeto;
  • Conseguir um maior grau de satisfação e de comprometimento da equipe do projeto em sua execução;
  • Reduzir a necessidade de microgerenciamento das atividades.

Para potencializar esses benefícios, é preciso uma grande mudança na forma de pensar e de agir, por parte de todos os envolvidos no projeto e na organização.

O escopo do projeto vai mudar

Tradicionalmente, para garantir um bom projeto o gerente gasta muito tempo reunindo todos os possíveis requisitos que os usuários possam ter em suas mentes. Com o intuito de evitar surpresas, é feito um grande esforço para se construir o plano perfeito. O trabalho é planejado para que tudo possa ser controlado rigorosamente, sem mudanças.

Mas isso quase sempre é impossível. No entanto, este tipo de pensamento tem se tornado comum em grandes empresas, onde planejar, especialmente em conjunto com outras equipes e áreas, é algo muito difícil.

Em um projeto ágil, por outro lado, podemos:

  • Lançar o software regularmente e em datas marcadas (pelo menos em um ambiente de testes), para que os usuários possam verificar rapidamente o trabalho realizado;
  • Permitir aos usuários finais que solicitem mudanças e novas funcionalidades, desde que deixem as menos importantes para depois;
  • Disponibilizar versões intermediárias com frequência, para que os usuários possam utilizar antecipadamente as primeiras funcionalidades do sistema.

Além disso, surpresas são bem-vindas, pois podem criar ideias e favorecer a inovação.

Em projetos ágeis, para controlar o projeto e comunicar o progresso, são contabilizadas as funcionalidades implementadas e não a porcentagem de realização das tarefas, o que é muito mais fácil de entender. Em um projeto tradicional o gerente de projetos diria algo como, “consumimos 45% do orçamento e estamos duas semanas atrasados”. Em um projeto ágil, poderia dizer: “com 45% do orçamento temos hoje uma aplicação capaz de executar estas 12 funcionalidades das 20 previstas”.


A adoção de uma metodologia ágil é um verdadeiro projeto de mudanças

Os métodos ágeis, entretanto, podem ser difíceis de implementar em grandes empresas. Normalmente a gestão de TI acredita que os métodos ágeis dizem respeito apenas aos desenvolvedores e à equipe técnica. Isto é um grande erro, pois elas também envolvem as equipes de gestão e de negócios.

O uso de práticas ágeis apenas no âmbito dos desenvolvedores não vai necessariamente reduzir os prazos globais dos projetos. Os ganhos de produtividade podem ser desperdiçados por outras equipes em outras funções. Se as atividades de testes de integração, por exemplo, durarem muito tempo, os desenvolvedores terão que fazer vários merges das diferentes versões de testes realizadas.

Em muitos casos, o primeiro projeto na adoção de uma metodologia ágil falha devido à falta de envolvimento do patrocinador, à falta de capacitação e treinamento, ou a uma má atuação de alguns “falsas consultorias” em Agile. (Existem consultores que simplesmente rotulam suas ofertas de serviços com a palavra “ágil” sem ter o conhecimento apropriado.)

Negociação do escopo

A negociação de um contrato em Agile é talvez o ponto mais complexo na adoção de práticas ágeis em uma empresa. Isso porque em Agile as mudanças no escopo são bem vindas e constantes. Mas os gerentes de projetos têm muitas dúvidas e resistência ao trabalhar com um escopo variável, principalmente quando não existe uma relação de confiança com o fornecedor.

Há no entanto novos modelos de contratos que procuram criar uma relação de confiança. Entre os pontos abordados nesses contratos, podem estar a definição de escopo fechado por iteração; medidas precisas para controlar a qualidade das entregas; e a possibilidade de o cliente cancelar o projeto ao final de qualquer iteração, sem multas ou penalidades.

A adoção de uma metodologia ágil é na verdade um “projeto de gestão de mudanças”, que requer um forte comprometimento dos patrocinadores e gestores. Esse processo de mudanças pode ser feito gradualmente, implementando-se primeiro as práticas ágeis para desenvolvimento de software, e depois seguindo com práticas mais avançadas e focadas em planejamento, organização e gestão.

O papel do gerente de projetos

O gerente de projetos ganha novas atribuições em um contexto ágil, pois a filosofia do time e os novos papéis exigem uma nova postura e uma nova forma de lidar com as atividades do dia a dia.

Para ganhar em rapidez, as metodologias ágeis dão grande importância à equipe de projetos e à forma como ela pode colaborar de modo eficiente para a resposta às mudanças. Busca-se desenvolver equipes autônomas, capazes de lidar com todas as questões sob sua alçada. Além disso, as equipes têm a liberdade de tratar diretamente com os usuários e alguns patrocinadores.

Outro papel que cresce e ganha importância, a medida que cresce o Scrum, é o de Product Owner (PO), que é responsável pelo produto sendo construído e pelos benefícios e o valor que serão proporcionados ao negócio e aos usuários finais. O Product Owner pode complementar o trabalho do gerente de projetos focando nas funcionalidades já entregues e analisando os benefícios do lançamento do produto em cada iteração.

Mas com equipes autônomas e a presença do Product Owner, quais seriam as responsabilidades de um gerente de projetos? O gerente de projetos continua responsável por várias áreas da gestão, como integração, gestão do tempo, orçamento, qualidade, recursos humanos, comunicação, risco e contratos. E aparecem outras atividades importantes em um contexto ágil; por exemplo:

  • Integrar o projeto ágil com outros projetos da empresa: Em empresas grandes e complexas como bancos e operadoras de telecomunicações, projetos ágeis terão sempre alguma dependência com projetos ditos mais tradicionais.Se você precisa que uma equipe “não-ágil” crie um novo serviço na web, terá que entregar a especificação do projeto com meses de antecedência. O gerente de projetos ágil precisa buscar, nesse contexto, envolver e “evangelizar” outros gerentes, buscando disseminar a filosofia e o funcionamento das equipes ágeis, além de coordenar atividades entre diversas áreas.
  • Proteger a equipe na empresa: Departamentos externos e outros funcionários certamente demandarão suporte e manutenção de sua equipe em outros projetos. Muitas vezes questões urgentes podem levar dias, e gerar atrasos e quebras no ritmo da equipe. Conseguir “blindar” o time de interferências externas e criar mecanismos para tratar estas questões é outro papel importante do gerente de projetos.
  • Aperfeiçoar o processo e as práticas: Metodologias ágeis estimulam o aperfeiçoamento das práticas, técnicas e ferramentas de forma continuada. O gerente de projetos é convidado a criar iniciativas que aprimorem os processos que vão além da sua equipe, e podem buscar otimizar até práticas e processos mais estratégicos. (Em Scrum, o Scrum Master assume esta última responsabilidade.)

Voltando ao Scrum, um gerente de projetos pode assumir o papel do Scrum Master desde que esteja disposto a trabalhar perto da equipe, e a auxiliá-la a aperfeiçoar processos e práticas e a desenvolver suas habilidades. (Veja definições em português de Product Owner e Scrum Master)

Em grandes projetos, um gerente pode assumir o papel de Scrum Master, mas atuando em nível mais estratégico. Em um projeto simples (por exemplo, com uma equipe interna de quatro a oito pessoas), o gerente pode até assumir o papel do Product Owner também. Mas isso somente se conseguir ao mesmo tempo pensar no projeto e no produto em construção.

Comece com um projeto piloto

Como todo projeto de mudanças, a adoção das metodologias ágeis deve ser planejada e ter patrocinadores importantes dentro da organização. É recomendável que o primeiro passo seja um projeto piloto, que permita aos patrocinadores entender melhor as metodologias envolvidas, e identificar possíveis benefícios e dificuldades na sua implementação em larga escala na empresa.

A seguir é apresentada uma lista de ações que podem ajudar o gerente de projetos a organizar um primeiro projeto piloto com metodologias ágeis. São incluídas também algumas dicas gerais que podem ajudar os projetos ágeis a serem bem-sucedidos.

  • Defina o projeto piloto com o objetivo de testar o uso de métodos ágeis. Deixe claro que um dos objetivos é experimentar uma nova metodologia. Custos, cronogramas e riscos devem ser avaliados neste contexto.
  • Explicite os motivos para utilizar o Agile. Evite metodologias ágeis, se não houver um real motivo no momento. As dificuldades em adotá-las podem desencorajar a equipe e a gestão. Documente os motivos e analise, junto aos usuários finais e patrocinadores, quais benefícios são possíveis com a entrega do projeto, meses antes.
  • Garanta o comprometimento dos patrocinadores. Envolva-os em revisões regulares do projeto e em reuniões de duas a quatro horas por semana. Com esse grau de envolvimento, os patrocinadores poderão ajudar a obter apoio de outros departamentos mais rapidamente, entre outras vantagens. Também é importante que os patrocinadores avaliem junto com você os passos seguintes ao projeto piloto.
  • Faça treinamentos em Agile, com empresas com experiência comprovada. O Agile parece simples, mas leva algum tempo para dominar práticas reais. Uma opção complementar é o Coaching: existem empresas com profissionais experientes que podem ajudar na condução de projetos seguindo práticas ágeis. Verifique a experiência destas empresas e considere adquirir seus serviços para um primeiro projeto piloto.
  • Avalie a experiência em métodos ágeis reais dos fornecedores que contratar. Algumas empresas de serviços de TI utilizam o termo Agile com propósitos comerciais, mas suas equipes não possuem conhecimento ou capacidade para trabalhar efetivamente com as práticas ágeis. Para reduzir o risco de cair nessas armadilhas, é importante entender os principais conceitos e acompanhar as decisões sobre a metodologia ágil a ser utilizada, além de ter uma noção geral das práticas de planejamento, desenvolvimento e testes mais adequados à realidade da empresa.
  • Construa uma equipe com pessoas orientadas a resultados e dispostas a tentar coisas novas.

Conclusões

As metodologias ágeis continuam ganhando popularidade e aceitação. A pergunta não é mais se funcionam ou não, e sim se podem ajudar sua empresa a realizar mais e melhores projetos de TI. A melhor maneira de testar estas metodologias é realizando um projeto piloto para identificar os potencias benefícios e as prováveis dificuldades na sua implementação.

A adoção do Agile é um verdadeiro projeto de mudanças para o departamento de TI e para as áreas de negócio. Nesse processo, o gerente de projetos pode cumprir um papel fundamental, assumindo a liderança das mudanças e ajudando as equipes técnicas a entregar software de maior qualidade em menor tempo, e com funcionalidades de maior valor para a empresa.

Fonte: Ignacio Lizarralde/InfoQ

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 | , , , , , ,

20

dez
2011

Sem Comentários

Em Agile
Blog

Por Allison

Scrum o que realmente é

Em 20, dez 2011 | Sem Comentários | Em Agile, Blog | Por Allison

O Scrum é um processo de gestão e desenvolvimento ágil que se desenvolveu como uma abordagem iterativa e incremental para otimizar a previsibilidade e controle de riscos, fortemente sustentado por três pilares:

  • Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
  • Inspeção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
  • Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras. Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

  • o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
  • o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
  • o Time: são os desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

  • Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
  • Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
  • Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
  • Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis a partir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
  • Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
  • Daily Scrum: o Time se encontra diariamente para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
    • O que ele realizou desde a última reunião;
    • O que ele vai fazer antes da próxima reunião;
    • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint. Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

  • Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
  • Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente integrável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Fonte: Elton Kuzniewski

Tags | , ,

13

nov
2011

Sem Comentários

Em Blog

Por Allison

O desenvolvimento ágil funciona em projetos de hardware?

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

Vários profissionais de TI tem trazido à tona recentemente a questão da aplicação das práticas ágeis no desenvolvimento de hardware. Nil Johnson escreveu um artigo na Electronic Engineering Times (EETimes): Desenvolvimento ágil de hardware – sem sentido ou necessidade?

Ele colocou a questão:

Deve haver um debate quando se trata de aplicar o Agile no desenvolvimento de hardware? Deveriam os valores e princípios que guiam as equipes ágeis de software também guiar os times que desenvolvem para sistema operacional (System on Chip teams) ; ou as diferenças entre estas duas disciplinas seria muito grande?

Ele continua com uma discussão sobre os valores do Manifesto Ágil e como estes valores formam a base da abordagem ágil no desenvolvimento de software. Ele coloca a questão – Poderia o mesmo funcionar para o desenvolvimento de hardware? – e comenta:

Para qualquer um que vê o desenvolvimento de hardware como um processo criativo, é difícil negar que os valores do manifesto são diretamente aplicados. Mas apenas considerar um conjunto de valores não é suficiente. De certo modo, valores abstratos precisam se traduzir na prática. Felizmente, times de software têm criado práticas que abordam os valores ágeis e muitas delas podem ser aplicadas diretamente também no desenvolvimento de hardware.

Ele reconhece as diferenças entre as abordagens do desenvolvimento de software e de hardware encorajando os times de hardware a abraçarem as práticas ágeis. Ele usa a prática do continuous delivery (entrega contínua) como um exemplo:

Uma prática de destaque é aquela de implantação rápida e contínua aos clientes. Para muitos times ágeis de software, implantação contínua é absolutamente crítico para o sucesso. Infelizmente, sua aplicabilidade no desenvolvimento de hardware – ou a falta dela – tende a ser usado para desacreditar o Agile totalmente. Para desenvolvimento ASIC em particular, implantação contínua não é realista; mas uma prática não ser realista não deve ser motivo de descrédito do conjunto de práticas. Nenhum time ágil de software realiza todas as práticas ao pé da letra; logo não se pode esperar o mesmo de um time de desenvolvimento de hardware.

Ele conclui com um pedido de mudança no foco das organizações de hardware:

Mudanças acontecem no desenvolvimento de hardware. Independentemente se são mudanças nas especificações, na rotatividade de funcionários, na dinânica do time ou novas tecnologias. Não há como evitar isso. As equipes que deixarem de lado os conceitos de Dilbert e as políticas internas para uma forma mais apurada e uma visão mais humana do desenvolvimento de hardware, retratada pelo manifesto, vai fazer desta mudança uma vantagem. Aos times que não se abrirem a esta mudança, irá restar o exercício fútil de tentar encaixar o “quadrado” dos tradicionais processos bem definidos no “buraco redondo” que é o desenvolvimento de hardware atual.

Larry Maccherone escreveu recentemente algo similar sobre as As 10 questões principais sobre quando usar Agile em projetos de hardware.

Ele elenca uma lista de questões e respostas a fim de auxiliar nas decisões sobre a aplicação de abordagens ágeis em projetos de hardware:

  1. As práticas e processos ágeis são efetivos na condução de projetos que não são de software (firmware, eletrônicos, mecânicos, etc.)?
  2. Quais ajustes são necessários no framework de processo Scrum para funcionar bem para estes projetos?
  3. Quais ajustes são necessários em nossas expectativas sobre funcionalidades comerciais mínimas, design emergente e definição de Scrum?
  4. Quais ajustes em nossas expectativas são necessárias acerca de histórias?
  5. Como fica a questão de priorizar histórias estritamente pelo valor gerado ao usuário final?
  6. Deveriam as histórias de usuário ser nossa única ferramenta de gerenciamento de requisitos?
  7. Se histórias de usuário não são nem requisitos oficiais do Scrum, então porque não devemos usar somente nossas práticas tradicionais de requisitos?
  8. O que fazer quando precisamos enviar um protótipo ao fornecedor e não é possível ser feito dentro de uma iteração?
  9. O que fazer com dependências e analise do caminho crítico?
  10. Talvez não precisemos da analise contínua do caminho crítico, mas ainda temos especialistas que não são dedicados permanentemente ao time. Como lidar com isso?

Para cada questão que ele lista uma resposta curta é dada seguida de uma discussão de abordagens práticas para resolver as potenciais incompatibilidades e como endereçá-las.

As práticas ágeis poderiam ser usadas no desenvolvimento de hardware? Quais mudanças seriam necessárias fazê-las funcionar neste contexto?

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 | , , ,