Contudo, muitas vezes, dependendo da atividade ou projeto a ser executado, não é interessante pagar para utilizar o software. Assim, utilizamos uma ou outra ferramenta gratuita que possa suprir nossas necessidades. E, acredite, existem muitas! Hoje, portanto, vamos conferir quatro delas!

ProjectLibre

O ProjectLibre é um software de gerenciamento de projetos que foi criado como uma versão de código aberto a partir de um fork do antigo OpenProj. Hoje em dia, muitas grandes empresas utilizam o software que, talvez, seja a melhor alternativa ao MS Project, já que este não possui um preço tão acessível.

O ProjectLibre possui as ferramentas essenciais para a gestão de projetos, além de compatibilidade com arquivos do MS Project, fator este, muito importante para que usuários possam migrar de plataforma caso seja necessário.

Além disso, outro benefício é que o ProjectLibre possui versões para Windows, Linux e Mac OS X, enquanto que o MS Project só funciona em Windows.

Dica: curso gratuito com 8 aulas para dominar a ferramenta.

ProofHub

O ProofHub é uma plataforma para equipes que envolvem muitas pessoas e vários setores. A ideia do software é trazer todos para o mesmo espaço centralizado a fim de manter todos alinhados no projeto.

Dessa forma, o ProofHub disponibiliza aplicações para gestão e colaboração de projetos, ferramentas para gerenciamento de recursos e tarefas, e acompanhamento de progresso. Além disso, através da ferramenta de marcação, é possível revisar e acompanhar feedbacks rápido e facilmente.

Trello

Em março deste ano, meu colega Angelo Santos publicou um artigo bem interessante titulado Trello, a ferramenta que todo engenheiro precisa usar, no qual sucinta sobre os principais recursos da plataforma e os motivos pelo qual vale a pena utilizar.

Como ele aborda no artigo, o Trello é recheado de recursos para usuários de diversas modalidades de gerenciamento de projetos como Kanban, Scrum, PMBOK e, assim, encontra serventia em muitas áreas.

Além disso, por funcionar no esquema Drag and Drop, a ferramenta agiliza muito o trabalho de editar e arquivar as listas em quadros Kanban. Recomendo a leitura do artigo do Angelo caso queira saber mais sobre a plataforma.

LiquidPlanner

O LiquidPlanner é uma ótima ferramenta online para gerenciamento de tarefas, times e projetos. O software funciona bem com um modelo de gestão de projetos preditivo baseado em prioridades e permite que os usuários expressem incertezas em suas estimativas de tarefas usando intervalos.

Assim, se alguém precisar mudar algo, os cronogramas de gerenciamento inteligente automaticamente preveem datas de término confiáveis.

Além disso, o software permite que os gerentes de projeto criem espaços de trabalho e convidem os usuários a integrá-los de uma forma semelhante a uma rede como LinkedIn ou Facebook . O espaço pode conter vários projetos e manter uma narrativa contínua de tarefas, comentários, documentos e outros materiais do projeto.

Estes recursos tornam o software uma boa alternativa ao MS Project e, portanto, vale muito a pena conferir!

Aproveite e siga o Blog da Engenharia no Instagram!

The post Quatro grandes alternativas ao MS Project para gestão de projetos appeared first on Blog da Engenharia.

O conceito, na época denominado iMBOs, do inglês Intel Management by Objectives – Gerenciamento Intel por Objetivos – foi apresentado à John Doerr que nos anos 90 introduziu o modelo de gestão OKR ao Google, a partir dos preceitos e lições do iMBOs.

No livro Avalie o que Importa, de John Doerr, Larry Page, cofundador do Google, menciona

“Os OKRs nos ajudaram a crescer dez vezes mais. Até mais em alguns casos. Eles nos ajudaram a tornar nossa missão louca de ‘organizar as informações do mundo’ viável” – Larry Page

Ao longo dos anos, outras grandes empresas como o LinkedIn, Twitter, Dropbox, Spotify, adotaram o modelo, o que ajudou a consagrar o OKR como o “queridinho das start-ups”.

Hoje, a minha proposta é fazê-lo entender e ajudá-lo a aplicar o modelo de gestão que vem, cada vez mais, ganhando espaço nesse grande universo do gerenciamento de projetos.

O que são os Objetivos e os Resultados Chave?

Um OKR é, essencialmente, composto por duas fases: O Objetivo e os Resultados Chave. O Objetivo é naturalmente delimitado pela pergunta “O que deve ser alcançado?”.

Em seu livro, John Doerr recomenda que os Objetivos sejam significativos, concretos e orientados por ações. Significativo, pois, além da conclusão do Objetivo ser intrinsicamente valiosa para seu Macro Objetivo, o próprio ideal de conclusão será combustível para inflamar o seu anseio pelo alto desempenho. O Objetivo também deve ser concreto, isto é, claro e não deixar espaço para dúvidas se foi alçando ou não ao fim do prazo determinado.

Por fim, deve ser orientado por ações, ou seja, específico, a fim de que seja fácil determinar quais ações devem ser estabelecidas para concluí-lo.

Já os Resultados Chave (KRs) são os indicadores que lhe ajudarão a monitorar se está no caminho certo para alcançar o Objetivo. Se o Objetivo é “O que?”, as KRs são o “Como?”. Pergunte-se “como posso chegar ao Objetivo?”.

Suas KRs devem ser específicas, limitadas dentro de um tempo estabelecido – em Administração de Alta Performance, Grove recomenda um trimestre – sucintos e, principalmente, mensurável por números.

Além disso, é importante ressaltar esta última característica, pois caso contrário, você corre o risco de apenas fazer uma lista de tarefas a serem realizadas ao invés de um OKR. “Aumentar o tráfego orgânico do Blog até fevereiro” é uma tarefa. “Aumentar o tráfego orgânico do Blog de 26% para 34% até fevereiro” é uma KR.

Seja Audacioso 

A Teoria do Estabelecimento de Metas foi proposta pelo renomado psicólogo Edwin A. Looke há mais de seis décadas. Ela sugere que metas árduas de serem alcançadas suscitam em melhor desempenho quando bem aceitas pelos funcionários. De lá pra cá, muitos estudos realizados pela comunidade científica confirmaram a teoria.

Daí, nasce o conceito de Stretch Goals – no português, Metas Alongadas – que são alvos intencionalmente projetados para serem árduos e custosos de serem concluídos.

Ao fazer um OKR, vale a pena utilizar das Stretch Goals de vez em quando, isso porque mesmo que você alcance apenas 60% ou 70% da meta alongada, ainda obterá maior desempenho que um objetivo “normal”. Se você sempre alcança os 100%, talvez suas metas não estejam tão ousadas assim.

Como acompanhar um OKR?

Como qualquer plano de meta, é imprescindível fazer o acompanhamento do seu OKR até o prazo final.  O ideal é realizar Check-ins semanais e, caso o OKR seja de uma equipe, busque não ultrapassar o tempo de 1 hora de reunião.

Os Check-ins o ajudarão a reforçar sua motivação e a cultura do OKR no ambiente de trabalho.

Nas reuniões, sempre foque em aperfeiçoar o resultado e não justificar os motivos dos resultados ruins. Mensure os números, compare os resultados obtidos com a expectativa definida anteriormente. Busque entender o que você fez que deu certo e o que não deu, além de possíveis Impedimentos Externos que podem ter comprometido a evolução do seu OKR.

Portanto, revise as Iniciativas, isto é, o que você pode fazer para retomar os bons resultados obtidos e evoluir.  Com isso, a cada Check-in, suas ações se tornarão mais afiadas, o que lhe permitirá alcançar seu objetivo de forma mais prazerosa e bem sucedida!

Aproveite e siga o Blog da Engenharia no Instagram!

The post OKR: Entenda a metodologia de gestão do Google appeared first on Blog da Engenharia.

Portanto, se você já leu a PARTE 1, podemos começar segunda parte.

Neste artigo, daremos início ao framework propriamente dito, assim, abordaremos os papéis, os eventos e os principais artefatos do SCRUM e como se relacionam dentro do desenvolvimento de um projeto.

Basicamente, existem 3 papéis importantes na equipe que implementam o SCRUM. São eles:

• Product Owner (Dono do Produto).
• Scrum Master.
• Development Team (Time de Desenvolvimento).

Em alguns materiais são informados outros dois, os Stakeholders (Partes Interessadas) e os Gerentes.

Porém, embora sejam muito importantes, não tratarei desses papéis nesta série, pois a relação destes dois papéis são auxiliares e eles não se envolvem integral e frequentemente com os processos do SCRUM.

Product Owner

Todo projeto possui por excelência stakeholders, sejam os clientes, os fornecedores, investidores, a comunidade, os parceiros, o governo ou qualquer outro órgão que possa estar envolvido no projeto.

Portanto, dentro de uma equipe SCRUM é fundamental a presença de um Product Owner. Ele é o principal responsável por ser a ponte entre a equipe e os stakeholders, podendo assim gerar valor ao projeto.

Além disso, o Product Owner é o membro responsável por escrever as Product Backlogs  – artefato abordado mais abaixo.

É importante ressaltar que cada equipe SCRUM possui apenas um Product Owner.

Scrum Master

O Scrum Master é o líder facilitador do time SCRUM, cuja as principais funções são remover os impedimentos que possam vim a atrapalhar a execução das Sprints, ajudar o Time de Desenvolvimento a entender e praticar corretamente o framework, assim como garantir sua implementação dentro da organização.

Além disso, o Scrum Master também é o responsável por guiar o Time de Desenvolvimento em suas tarefas diárias, auxiliar os Daily Meetings (Reuniões Diárias) e servir como ponte entre o Time e o Product Owner.

Development Team

Por fim, temos o Time de Desenvolvimento, o time de pessoas responsável por executar as Sprints determinadas pelo Product Owner da equipe e entregar o produto.

O Time de Desenvolvimento é, geralmente, composto por 5 pessoas, no máximo nove, sendo a equipe constituída de profissionais multidisciplinares e auto gerenciáveis, no qual seu principal objetivo é entregar algum tipo de incremento funcional em cada Sprint.

O que é um SPRINT?

No esporte, um Sprint é quando um atleta se esforça para dar o máximo de si a fim atingir sua velocidade máxima, seja correndo, pedalando ou nadando. Por conta da fisiologia humana, as pessoas não conseguem se manter neste estado por muito tempo, então os sprints são rápidos, algo de 30 a 35 segundos.

Os Sprints do SCRUM seguem o mesmo preceito, isto é, são pequenos períodos de tempo, no qual o Time de Desenvolvimento se esforça para desenvolver e entregar alguma parte do trabalho. Assim como no esporte, os sprints do SCRUM duram pouco tempo, geralmente, entre 1 semana a 1 mês.

A ideia é que dividindo o trabalho em pequenas partes, a equipe possa entregar parte do projeto ao cliente e, assim, receber um feedback do trabalho realizado. Na primeira parte desta série, isto foi citado nos Princípios do AGILE, nos tópicos 1, 3, 7 e 12.

Eventos do SCRUM

Os Eventos do SCRUM são, basicamente, as tarefas que giram em torno dos Sprints. O framework apresenta 4, que são os:

• Daily Meeting (Reunião Diária)
• Planning Meeting (Reunião de Planejamento)
• Sprint Review (Revisão do Sprint)
• Sprint Retrospective (Retrospectiva do Sprint)

Daily Meeting

Como o próprio nome sugere, os Daily Meetings são as famosas Reuniões Diárias do SCRUM que ocorrem todos os dias durante um Sprint.

O objetivo destas reuniões é alinhar os participantes com o que foi feito, o que deve ser realizado no dia, além de ajudar o Scrum Master a identificar os possíveis impedimentos e, por isso, cada membro deve fazer as seguintes perguntas:

• O que você tem feito desde ontem em direção à meta?
• O que você planeja fazer hoje em direção à meta?
• Há algo que pode te impedir de realizar seu objetivo em direção à meta?

As Reuniões Diárias do SCRUM não ultrapassam o tempo de 15 minutos, além de serem realizadas em pé – por isso às vezes também são chamadas de Stand up Meeting. O objetivo disso é gerar um ambiente levemente desconfortável, assim as reuniões são mais práticas e eficazes.

Planning Meeting

As Planning Meeting, ou Reuniões de Planejamento, são as reuniões que ocorrem com toda a equipe SCRUM, no início de cada Sprint, a fim de definir qual o objetivo do Sprint e ajudar o Product Owner a gerar o Sprint Backlog.

É importante a presença de todos os membros, pois a Equipe precisa definir o “Que” deve ser feito, “Como” e também” Quem” fará o que. Planejar bem é muito importante, pois além de ajudar a concluir o processo com mais eficiência, ajudará a motivar a equipe conforme as etapas são finalizadas.

Review Sprints

As Revisões de Sprints são as reuniões que a equipe SCRUM organizam no final de cada Sprint com o objetivo de rever o trabalho que foi executado, as tarefas que deixaram de ser feitas e apresentar as novas funcionalidades para os Stakeholders.

Além disso, durante esta reunião é importante que o projeto seja avaliado em relação ao objetivo da Sprint que foi previamente definido na Reunião de Planejamento.

Nesta reunião, participam o Time de Desenvolvimento, o Product Owner, o Scrum Master, além dos gerentes, engenheiros, clientes e qualquer outra Parte Interessada no projeto.

Sprint Retrospective

 Os Sprint Retrospectives são reuniões que ocorrem no final de cada Sprint. São, geralmente, a última atividade dentro de um Sprint, pois seu objetivo é, principalmente, procedural.

Nestas reuniões a equipe SCRUM avaliará o andamento dos Sprints a fim de buscar possíveis melhorias no processo. Perceba a diferença entre a Retrospectiva do Sprint e as Revisões de Sprint, no qual esta se preocupa com o que a equipe está construindo, enquanto aquela trata de como o processo está sendo executado.

Artefatos do SCRUM

Por fim, temos os dois artefatos oficiais do SCRUM. O Scrum Guide, o manual oficial do SCRUM, os definem como:

• Product Backlog [Backlog do Produto]
• Sprint Backlogs

Product Backlog

Como vimos anteriormente, na parte de papéis do SCRUM, uma das funções do Product Owner é gerar os Product Backlogs.

Em inglês um Backlog é “um acúmulo de algo, especialmente um trabalho incompleto ou questões que precisam ser tratadas” (Dicionário de Oxford). Seguindo esta linha de raciocínio, um Product Backlog – ou Backlog do Produto – nada mais é do que uma lista que contém os requisitos do cliente em uma ordem prioritária.

Portanto, os Product Backlogs são extremamente necessários na execução da Sprint, uma vez que ditará o que deve ser realizado.

Porém, caso o Product Owner sinta necessidade de alterações, ele – como o responsável pelo Backlog do Produto – pode mudar durante a Sprint.

Sprint Backlog

Já a Sprint Backlog é uma lista de tarefas extraída a partir do Product backlog. Estas tarefas deverão ser executadas durante a Sprint.

Os Sprints Backlogs são criados durante a Reunião de Planejamento, onde a equipe SCRUM seleciona um número de itens da Product Backlog, além de estimar a quantidade de horas necessárias para realiza-los.

Na Reuniões Diárias, o Time de Desenvolvimento poderá realizar alguma mudança no Sprint Backlog, caso seja necessário. Por exemplo, se as tarefas estiverem quantitativamente menor que a capacidade da equipe ou muito difíceis de serem executadas em uma única Sprint.

Por fim, espero que tenha ficado claro quais são os Papéis, os Artefatos e Eventos do SCRUM. Atente-se às palavras em negritos, pois tratam-se de conceitos importantes para o framework. Espero você na PARTE 3 da série, até logo!

Aproveite e siga o Blog da Engenharia no Instagram!

Já me segue no Instagram?

The post Destrinchando o SCRUM [Parte 2/4] appeared first on Blog da Engenharia.

Isso porque o SCRUM tem se tornado muito popular nos últimos anos e seus adeptos ao redor do mundo só tendem a aumentar.

Mas, se você não sabe ou nunca utilizou o SCRUM, talvez esteja se perguntando “por que será que este termo anda tão em voga?”, “da onde surgiu esse tal de SCRUM” ou mesmo “como posso utilizar o SCRUM?”.

Assim, se você pretende começar a vislumbrar este framework ou se já conhece, mas pretende aprender um pouco mais – afinal conhecimento nunca é demais – você está no lugar certo.

Nesta série DESTRINCHANDO O SCRUM, dividida em 4 partes, veremos:

1. O que é o SCRUM e como ele surgiu. [PARTE 1/4]
2. SCRUM e o Movimento Ágil. [PARTE 1/4]
3. Quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos. [PARTE 2/4]
4. Como implementar e acompanhar o SCRUM com sucesso! [PARTE 3/4]
5. Quando não se deve implementar o SCRUM. [PARTE 3/4]
6. Por fim, algumas DICAS especiais que preparei junto ao Antonio Santos,  Scrum Master e atual supervisor de implantação de projetos da Modular Mining System, para leitores que pretendem se aprofundar. [PARTE 4/4]

Sem mais delongas, vamos juntos destrinchar o SCRUM.

Afinal, o que é o SCRUM?

O SCRUM é um framework – não uma metodologia – de projetos com etapas bem definidas que, inicialmente, buscava auxiliar equipes no desenvolvimento de softwares.

Porém, sua implementação não se restringiu a este campo e, atualmente, pelo menos 60% dos projetos ágeis em todo mundo, de diferentes áreas, setores e níveis organizacionais o utilizam.

O grande destaque do SCRUM está no fato dele ter sido criado, especialmente, para lidar com alguns dos principais problemas que decorrem ao longo do desenvolvimento de um projeto, isto é, a imprevisibilidade, prazos curtos, burocracias, complexidade de problemas iminentes, hierarquias mal elaboradas, comunicação, dentre muitos outros.

Logo, dentre os principias benefícios de aplicar o SCRUM podemos citar alguns, como:

• Simplicidade
• Maior velocidade
• Mais flexibilidade
• Comunicação aprimorada
• Transparência
• Adaptabilidade
• Eficiência na execução
• Engajamento do time

Uma breve história do SCRUM

A história do SCRUM inicia-se em 1986. Em janeiro deste ano, Takeuchi e Nonaka, publicam o artigo intitulado The New Product Development Game – O novo Jogo de Desenvolvimento de Produtos – no qual destacava empresas no Japão e nos Estados Unidos que adotaram uma nova abordagem para gerenciar o processo de desenvolvimento de produtos.

Além disso, o nome SCRUM – derivado do jogo de Rugby – foi sugerido, depois que Takeuchi e Nonaka observaram que algumas equipes, pequenas, multidisciplinares e auto gerenciáveis, recorrentemente obtinham melhores resultados comparado às equipes grandes do modelo cascata de gerenciamento de projetos.

Já em 1993, Jeff Sutherland e Jeff McKenna, insatisfeitos com os recorrentes atrasos em seus projetos de desenvolvimento de softwares, orçamentos estourados, além do estresse gerado pela utilização dos modelos tradicionais de gestão de projetos, abraçaram o estudo de Takeuchi e Nonaka e arquitetaram o framework para utilizá-lo pela primeira vez na Easel Corporation.

“Na Easel, não tínhamos nada a perder, por isso decidimos tentar, embora o artigo se concentrasse na fabricação de produtos e não no desenvolvimento de softwares. Pensei que a ideia deles abordava algo fundamental, um processo descritivo de como os seres humanos trabalhavam melhor juntos em qualquer empreendimento” – Jeff Sutherland

Depois de dois anos de sucesso implementado o SCRUM, em 1995, Jeff Sutherland e Jeff McKenna apresentaram o artigo titulado SCRUM Development Process – Processo de desenvolvimento SCRUM – no qual, objetivavam a sistematização das práticas do SCRUM na conferência de pesquisa da Association for Computing Machinery (ACM), a primeira e maior sociedade de computação científica e educacional do mundo.

Desde então, o SCRUM vem se adaptando e evoluindo, mas o núcleo apresentado na conferência continua praticamente o mesmo.

SCRUM e o Manifesto Ágil

O Manifesto Ágil – também conhecido como Agile – é um documento que foi, inicialmente, elaborado entre os dias 11 a 13 de fevereiro de 2001, em uma reunião em Utah, EUA.

Na época, grandes gestores de projetos e profissionais influentes da computação se reuniram para discutir os fatores que realmente importavam no desenvolvimento de software.  Na reunião, acabou sendo compilada uma série de 4 valores e 12 princípios que deveriam nortear a gestão, tomada de decisões e ações das equipes durante a execução de projetos ágeis, assim, otimizando os resultados.

Além disso, vale ressaltar que entre os participantes da reunião se encontravam nossos caros Jeff Sutherland e McKenna. Por isso – e por outro motivos – o SCRUM também é consistente com os valores e princípios do Agile.

Enfim, confira abaixo os 4 Valores e os 12 Princípios do Manifesto Ágil, traduzidos diretamente do site oficial do agilemanifesto.org, onde se encontra o documento.

4 Valores do AGILE

• Os indivíduos e suas interações acima de procedimentos e ferramentas.
• O funcionamento do software acima de documentação abrangente.
• A colaboração com o cliente acima da negociação e contrato.
• A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

12 Princípios do AGILE

1. Satisfação do cliente – Nossa maior prioridade é satisfazer o cliente por meio de entrega antecipada e contínua de software valioso.
2. Adaptabilidade –  mudanças de requisitos são bem-vindas, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Frequência de entrega – Entrega de software funcional com frequência, de algumas semanas a alguns meses, com preferência à escala de tempo mais curta.
4. Cooperação – Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.
5. Motivação – Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para fazer o trabalho.
6. Face-to-Face – O método mais eficiente e eficaz de transmitir informações para dentro de uma equipe de desenvolvimento é a conversa ‘cara-a-cara’.
7. Softwares Funcionais – O software funcional é a principal medida de progresso.
8. Ritmo Constante – Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante, indefinidamente.
9. Bons Designs – Atenção contínua à excelência técnica e um bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
11. Auto-organização – As melhores arquiteturas, requisitos e projetos emergem de equipes auto organizáveis.
12. Feedbacks – Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, em seguida, sintoniza e ajusta seu comportamento de acordo.

Além disso, na PARTE 2 desta série abordaremos quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos.

Continue atento aos próximos artigos e não deixe de acompanhar o conteúdo que trazemos diariamente aqui no Blog, pois sempre tem muita coisa interessante.

Aproveite e siga o Blog da Engenharia no Instagram!

The post Destrinchando o SCRUM [Parte 1/4] appeared first on Blog da Engenharia.