Práticas Ágeis em Projetos que NÃO são de Software

Os métodos que vêm debaixo do chamado guarda-chuva “Agile” incluem abordagens como, por exemplo, o Scrum, o RUP (Rational Unified Process) e o XP (Extreme Programming), todas feitas para projetos de software. 

Apesar disso, muitos seguidores  do “Agile” costumam apresentar essa filosofia de gestão de projetos como uma verdadeira bala de prata para qualquer tipo de projeto, ou seja, o jeito mais moderno de gerenciar um projeto de software ou de qualquer outro tipo, alinhada a filosofia “lean manufacturing”, que faz o projeto acontecer de forma rápida, que corta desperdícios com coisas desnecessárias, que reduz custos e outros benefícios.  

Essa ideia de entender que o “Agile” (ágil em português) seria o mesmo que rápido, esquecendo as premissas que formam a base do conceito do “Agile”, costuma ser explorada por algumas empresas, na ânsia de convencer seus colaboradores que eles (e elas) precisam trabalhar mais depressa, a ao mesmo tempo sem perder a precisão e o foco, para alcançar o sucesso nos projetos que desenvolvem em um tempo menor do que o de costume. A bala de prata, a tal solução para todos os problemas, para evitar o fracasso dos projetos, está na abordagem “Agile”. Todos querem o tiro certo, sem desperdício, e se você não sabe trabalhar com algum método ágil, você não serve mais para a empresa. Trate de se modernizar, ou será chamado de retrógrado e ultrapassado! E isso será usado até que uma nova bala de prata seja descoberta.

Pesquisas apontam que as causas principais de fracasso em projetos se referem a mudança de escopo, falta de comprometimento das equipes, incorreções no business case, falta de recursos, prazos inexequíveis e riscos não gerenciados. Há ainda outras causas como incapacidade gerencial, falta de comprometimento da alta direção, falta de método para gerenciar o projeto e habilidade técnica insuficiente. Mas, a primeira causa de fracasso de um projeto (aproximadamente 70% das causas de fracassos em projetos) está associada as constantes mudanças de escopo. O projeto é iniciado e apesar de não se saber bem o que precisa ser feito, o projeto segue adiante e em algum momento se descobre que alguma coisa está faltando (ou está incorreta, ou imprecisa, ou a mais, ou a menos), sendo necessário acrescentar alguns itens no escopo não considerados no plano original, ou retirar itens inicialmente inclusos e que nesse ponto do projeto se mostram desnecessários. Então, sim, um planejamento mal feito ou apressado, pode ter graves consequências para o projeto. Da mesma forma pode acontecer do cliente - que está pagando pelo resultado que o projeto se propõe a entregar - não saber exatamente do que precisa. Durante a reunião de aprovação do projeto pode surgir a seguinte frase dita pelo cliente: - É o seguinte pessoal, eu quero um resultado bem legal, e assim vocês vão desenvolvendo e eu vejo se vai ficar bom e se eu gostar, seguimos em frente”.  Nossa, o “máximo”! 

Quando se trata de projetos de software não saber exatamente o que será feito no início do projeto não é algo assim tão incomum. Por exemplo, alguém pode ter uma ideia para um aplicativo que pode gerar milhares de dólares e isso ser apresentado de forma geral do ponto de vista técnico e, ao mesmo tempo, algo bastante atrativo ponto de vista financeiro. Em outras palavras, no início não se sabe exatamente como o aplicativo vai rodar, como serão as opções no menu do usuário para que tudo funcione perfeitamente, além de outros detalhes operacionais. Essas coisas serão feitas durante o projeto. Por conta disso, será necessário ter a mente aberta e ser flexível com o escopo do projeto. 

O pessoal que elaborou o Manifesto Ágil, de 2001, estabeleceu princípios que orientam como o trabalho deve fluir nos projetos de software, e consideram quatro aspectos:

• Comunicação: indivíduos e interação entre eles mais que processos e ferramentas;
• Praticidade: Software em funcionamento mais que documentação abrangente;
• Alinhamento de expectativas e colaboração: colaboração com o cliente e membros do projeto mais que negociação de contratos;
• Adaptabilidade e flexibilidade: responder a mudanças mais que seguir um plano.

A boa comunicação interna e externa (entre os membros da equipe e com o cliente) é ressaltada. Através dessa boa comunicação e constante alinhamento de expectativas o software é produzido de forma prática (mais software funcionando e menos documentação). A equipe do projeto deve estar aberta as mudanças de escopo, ao invés de ficar protegendo o escopo original inicialmente considerado. Essa flexibilidade – diretamente ligada à forma como o projeto trata as mudanças de escopo - é vital para que o resultado seja realmente alinhado aos desejos e anseios do cliente. No Scrum, por exemplo, o método ágil mais utilizado, o projeto é desenvolvido em rodadas de curta duração chamados de sprints. Cada sprint tem, tipicamente, entre 2 a 4 semanas. Um escopo inteiro do projeto - que produz o software completo - é dividido em partes. Digamos, apenas para ilustrar, que para desenvolver o software completo do nosso exemplo, sejam necessários 10 sprints. Durante cada sprint são realizadas reuniões diárias de andamento do projeto e partes do software são desenvolvidas para serem entregues ao cliente. A estratégia aqui é a mesma inventada pelos Romanos: Dividir e vencer. O fato de trabalhar criando partes menores em um curto espaço de tempo (de 2 a 4 semanas) é um facilitador importante para discutir/negociar/fazer modificações no software em função de eventuais solicitações de mudança pelo cliente. Apenas para comparar, seria muito mais difícil responder as mudanças se o projeto estivesse sendo gerenciado considerando fases longas de um cronograma.

Os projetos de software têm suas características próprias e, evidentemente, têm várias diferenças em relação a outros tipos de projetos. Apesar dessa questão óbvia, vale a pena fazer uma comparação com os projetos de construção civil, que costumam usar o método cascata (gerenciamento de projetos tradicional que adota as melhores práticas do guia PMBOK do PMI). Aqui vamos tratar de apenas um aspecto bastante simples, mas que mostra não ser tão fácil ser flexível com o escopo do projeto. Digamos que, por exemplo, o cliente que está comprando um prédio de dez andares decide, depois de concluídas as fundações da edificação e parte das paredes dos primeiros andares, que esse prédio deve ter quinze andares. É óbvio que acrescentar cinco andares à essa edificação causaria problemas ao projeto, uma vez que tudo no prédio foi calculado para um total de dez andares. Na prática, para aceitar essa mudança seria necessário derrubar o que foi feito e reiniciar a construção. Ser flexível com a mudança de escopo aqui não é uma opção. Uma mudança de escopo que geraria impactos negativos (atraso no cronograma, estouro no orçamento, etc). Portanto, essa solicitação de mudança não seria aprovada!  Como o exemplo do prédio de dez andares do ramo da construção civil, há muitos tipos de projetos que necessitam ser muito bem definidos desde o seu início. Esses projetos precisam ser muito bem planejados e seus escopos muito bem definidos, e se isso não é contemplado o risco do projeto fracassar é bem real.

Sim, mas não há nada que possa ser aproveitado dos métodos ágeis em outros tipos de projeto que não sejam de software? Me parece que a resposta é sim. Então, vejamos algumas ideias que, sempre que possível, podemos usar:

Criar uma lista de itens prioritários (similar ao “backlog”do Scrum) – isso ajuda a decidir o que será feito. 

Escrever descrições resumidas sobre o que será feito (similar as “user stories”do Scrum) – isso facilita o planejamento e a discussão sobre o que será feito.

Mostrar em um quadro ou mesmo na parede, para a equipe e as partes interessadas, o progresso do projeto (similar ao Kanban) – isso permite ter uma visão geral do trabalho que está sendo feito. 

Definir períodos curtos de tempo para executar partes do trabalho do projeto (similar aos sprints do Scrum) – isso facilita o planejamento/controle do trabalho da equipe do projeto para executar o que será feito.

Adotar reuniões rápidas e diárias de acompanhamento do progresso do projeto com o pessoal da equipe de pé, e com duração máxima de 10 minutos (similar as standup meetings do Scrum) – isso facilita a comunicação através de reuniões objetivas e focalizadas no trabalho que está sendo feito.

Organizar reuniões de retrospectiva ao final de cada período de trabalho (similar as retrospective meetings do Scrum) – isso possibilita discutir o que funcionou e deu certo e o que não deu certo no projeto e precisa ser melhorado ou mesmo descartado do ambiente do projeto.

Bem, é isso aí! Até a próxima!

O Arduino na Educação

O mundo atravessa grandes transformações com impactos na forma como as pessoas vivem e trabalham. Estamos falando da digitalização na indústria, da inteligência artificial, da impressão 3D, da Internet das coisas, dos carros autônomos e da robótica em larga escala. Assim, cada vez mais a tecnologia se mostra como algo vital e torna os seres humanos dela dependentes.

Consequentemente, o ensino de disciplinas relacionadas a ciência, tecnologia, engenharia e matemática (STEM = Science, Technology, Engineering and Mathmatics) ganha enorme importância, e essa tendência pode ser facilmente comprovada observando o que está ocorrendo em diversos países, inclusive no Brasil.

Veja em:

Escolas apostam em aulas de robótica e programação para alunos do ensino médio 

Aulas de robótica transformam reforço em apoio a criatividade

Já a algum tempo as antigas classes de informática, em várias escolas de ensino médio, foram substituídas por aulas de robótica, com ênfase no ensino de alguma linguagem de programação. Sim, porque saber ligar os fios que conectam módulos e componentes eletrônicos através de um protoboard é apenas parte do desafio, sendo importantíssimo saber como fazer tudo isso funcionar através de um código específico, ou seja, por meio de um programa.

Se o mundo do futuro vai usar ainda mais a tecnologia, então os empregos do futuro demandarão mais profissionais com essa competência. Isso reforça a ideia que o ensino de ciência, tecnologia, engenharia e matemática é cada vez mais importante. Consequentemente, os que se destacarem nesses assuntos construirão e programarão as máquinas que automatizarão todos os outros trabalhos, e aqui devemos lembrar o básico: para escrever um programa usa-se uma linguagem de programação. 

Uma breve pesquisa na Internet mostra que existem muitas linguagens de programação como, por exemplo, o Java, o Ruby, o C++, o Python e o PHP, apenas para lembrar algumas das mais populares.  Nos empregos do futuro é bem provável que existam novas linguagens e que talvez ainda tenhamos algumas das linguagens de programação de hoje rodando a pleno vapor. Nós não sabemos, pois não temos bola de cristal. Mas podemos lembrar que muitos anos atrás o Fortran e o Cobol eram largamente utilizadas e hoje são apenas peças exóticas do nosso museu tecnológico. O fato é que a experiência humana mostra que o novo sempre vem. Como ninguém que vive nesse tempo presente pode aprender uma linguagem que só existirá no futuro, o jeito é aprender uma linguagem de programação existente e tirar proveito do valioso conhecimento que esse aprendizado trará do ponto de vista do raciocínio lógico. Quem aprende uma linguagem de programação poderá aprender outras linguagens.  Aprender a programar é um exercício que incentiva a criatividade e motiva o aluno a querer mais, a aprender mais! 

Mas qual seria a melhor primeira linguagem de programação para um aluno do ensino médio aprender? Para responder a essa pergunta vamos dar mais um passo considerando o uso de uma ferramenta educacional no ensino de robótica para alunos do ensino médio. É algo relevante – por instrumentalizar e facilitar – trabalhar com uma ferramenta educacional que permita aos alunos investigar seu interesse em cursos de ciência e tecnologia de uma maneira única. Eu considero que o Arduino é essa ferramenta. 

O Arduino é uma plataforma para desenvolvimento com inúmeras possibilidades que permite o uso da criatividade, na hora de aprender ou ensinar, desperta o interesse e a curiosidade! 

Na escola tradicional as matérias são ensinadas separadamente e de forma segmentada. Em outras palavras, os alunos têm aulas de matemática, física, química, biologia e assim por diante. Não é incomum que muitos, diante disso, tenham a percepção de que existe uma distância grande entre a teoria e a prática e que – no limite do exagêro - estão estudando coisas que “não servem para nada” e que não serão usadas no dia a  dia de seus trabalhos futuros. Por outro lado, quando uma ferramenta – como o microcontrolador Arduino - é utilizada, é imediatamente criada a oportunidade do aluno observar o modo como conceitos de diferentes matérias trabalham juntos, através de uma abordagem prática, na qual o aluno participa de atividades e desenvolve projetos.

 

O Arduino usa o C / C++, que são linguagens de programação de alto nível, com as quais é possível escrever um programa com comandos que podem ser compreendidos pelo estudante/programador. Entretanto, o Arduino é um microcontrolador que entende a chamada linguagem de máquina.  Usando a plataforma IDE (Integrated Development Environment ou ambiente de desenvolvimento integrado), um software totalmente gratuito que é baixado da Internet, o programa desenvolvido pelo estudante/programador – chamado de sketch - pode ser compilado, transformando a linguagem de alto nível em linguagem de máquina, e carregado no Arduino. Dessa forma, em pouco tempo, uma ideia pode ser transformada em algo real, palpável e que funcione na prática. É evidente que junto com o programa (software) deverão ser montados todos os componentes (hardware) – microcontrolador, módulos, componentes, etc - que estão representados nas instruções desse programa. Afinal de contas, uma coisa não funciona sem a outra, e vice-versa.  

Aprendizado de forma lúdica e ativa

Os alunos investigam situações problema e desenvolvem projetos com soluções

São incentivados a trabalhar em equipe e de forma colaborativa

Adquirem conhecimentos de programação de computadores

Relacionam conhecimentos de diferentes naturezas e áreas numa perspectiva interdisciplinar

O professor tem um importante papel nesse processo de formação do aluno, pois cabe a ele (ou a ela) apresentar aos alunos as várias tecnologias e conceitos que podem ser usados e assim promover a educação e o interesse nas áreas de ciência, tecnologia, engenharia e matemática. Esta abordagem integrada mostrará aos alunos como os vários campos e conhecimentos nessas áreas trabalham juntos para fornecer as soluções do mundo real. Bem, é isso aí. Até a próxima!

Transformação Digital e Gestão de Projetos

Entendendo a transformação digital ...

Você não pode simplesmente ler um livro ou seguir um blog sobre transformação digital e esperar aprender tudo o que precisa saber. 

O impacto irá variar dependendo da sua indústria, especialidade e ambiente. A transformação digital é um termo genérico para o impacto tecnológico de uma ampla gama de tecnologias disruptivas, juntamente com a reinvenção fundamental de como os negócios são feitos como resultado dessas tecnologias. Você precisa entender quais tecnologias são especificamente relevantes para sua área de trabalho e como essas tecnologias estão afetando a maneira como o trabalho é realizado nessa área.

Supondo que você deseje permanecer na mesma indústria, esse deve ser seu primeiro alvo de educação. Quer se trate de robótica ou veículos autônomos, da Internet das Coisas ou da IA (Inteligência Artificial), ou qualquer outro grupo de disrupções, você precisa entender como seu setor está sendo afetado - e o que os líderes desse setor estão fazendo para abraçar as oportunidades e responder aos desafios. Este é um momento para aproveitar sua rede de contatos, engajar-se em associações do setor e escritórios locais de associações profissionais como, por exemplo, o PMI ou o IPMA, dentre outros. Você precisa entender as possibilidades e como o trabalho está evoluindo em resposta a essas oportunidades.

O segundo elemento é entender o que a transformação digital significa para o gerenciamento de projetos. É mais do que apenas entregar os projetos que aproveitam as oportunidades do seu setor, mas também reconhecer que o próprio gerenciamento de projetos está sendo afetado. Isso abrange duas grandes áreas:

·        - O que muda nas ferramentas e técnicas de gerenciar projetos

·        - Como trabalhamos para entregar os projetos ao negócio

Ferramentas e técnicas que usamos ...

O primeiro deles é o mais fácil de entender: é o uso do “learning machine”, da IA e de disciplinas relacionadas para mudar o trabalho de um gerente de projeto. Em termos gerais, o gerenciamento de projetos se tornará menos gerencial (de comando e controle) e mais um trabalho de líder, à medida que a mecânica da administração de projetos se torna automatizada e as decisões básicas são tomadas por software. Isso faz com que o gerente de projetos se concentre em formar uma equipe e liderar um ambiente em que os membros da equipe sejam capazes de dar o melhor de si, tornando-se mais auto-organizados e autônomos (e se espera isso mesmo em ambientes de entrega em cascata).

Como trabalhamos ...

A segunda área é um pouco mais difícil de entender. Isso é o reconhecimento de que a transformação digital não está apenas mudando nossa indústria e nossa disciplina de gerenciamento de projetos, mas também está mudando a forma como o trabalho está sendo entregue (em função dessa e para se alinhar a essa transformação). Isso abrange tudo, desde treinamento e desenvolvimento de habilidades até a prontidão para mudança organizacional. É um aspecto da transformação digital que muitas vezes não é reconhecido, mas pode ser a diferença entre transformar com sucesso ou simplesmente interromper o negócio.

Do ponto de vista do gerente de projeto, pode ser a diferença entre o bom e o excelente - o gerente de projetos que souber não apenas entregar projetos transformadores usando técnicas transformadoras, mas que também souber como operacionalizar essas soluções com o mínimo de disrupção, realmente agregará valor ao seu empregador.

Conduzindo a transformação digital ...

A transformação digital não é algo que um gerente de projetos possa simplesmente ignorar. O gerenciamento de projetos deve assumir o papel de verdadeira força motriz por trás dessa transformação, uma vez que oferece uma enorme oportunidade de obtenção de melhorias significativas. Em outras palavras, os gerentes de projeto têm a capacidade de não apenas fazer parte da transformação digital, mas também de impulsioná-la.

A tecnologia afeta a sociedade e provoca mudanças. Esse é um fato da vida. Há muitos exemplos de empresas que fracassaram por não acreditar nessa afirmação. A Kodak quando não viu o potencial da fotografia digital que substituiu a revelação dos filmes. A Sony quando achou que nunca perderia o mercado do Walkman. A Nokia que achou que permaneceria a vanguarda da telefonia celular. A Blockbuster que achava ter um modelo de negócios sustentável até o surgimento do streaming de video. Isso apenas para mencionar casos recentes. Mas, há muitos outros!!!

Mesmo com tantos exemplos, ainda existem organizações e indivíduos que acreditam estar imunes ao impacto desta última - e maior - onda de perturbação impulsionada pela tecnologia. A verdade é que a transformação digital está mudando fundamentalmente a forma como os negócios são feitos, e as organizações mais progressistas já estão aproveitando os benefícios de adotar os conceitos e de oferecer maneiras novas, mais eficientes e eficazes de trabalhar. Os gerentes de projeto devem compreender o que a transformação digital significa e tentar alavancar as oportunidades de gerar sucesso para si e suas organizações. Bem, é isso aí. Até a próxima.