kanban_blambarde

3 razões pra organizar projetos usando um Quadro (kanban)

Lembro quando popularizaram as metodologias ágeis para o desenvolvimento do software, quem olhava de fora tinha a impressão que pra fazer projetos ágeis, eram necessários milhares de Post-Its e muitas paredes ou janelas livres pra organizar os projetos (muita gente divulgava o ágil com uma foto de Post-Its na parede).

os agilistas trataram de afastar esse estereótipo pois, de fato, não são as ferramentas utilizadas que fazem um projeto ágil ou não, mas sim a forma de fazer (Execução), de acordo com o Manifesto Ágil.

Mas quais são os Benefícios de ter, como ferramenta, alguns penduricalhos de papel organizados em uma parede, quadro ou janela?

1. Visibilidade

Eu já falei aqui por que eu prefiro minhas atividades no caderno, pois ele estará sempre ao alcance da mão e dos olhos, pra me lembrar de todas as pendências que tenho pra resolver.

Com o controle das atividades expostos a todos, é como se tivéssemos um grande e coletivo caderno aberto. Todos os envolvidos podem ter uma visão de como as coisas estão, quais são os gargalos do processo, que precisam de atenção para melhorar a qualidade do desenvolvimento.

2. Facilidade de uso

Os cartões podem ser bem simples, de forma que novos integrantes na equipe, gestores ou clientes consigam visualizar e entender sem a necessidade de treinamento, “manual” ou softwares de gerenciamento de projeto.

O próprio quadro, quando bem utilizado e formatado, fornece uma representação gráfica do estado em que está o projeto. Simples assim.

3. Auto-organização e Colaboração

Consequência da visibilidade, a auto-organização deve acabar surgindo naturalmente. Se você tiver problemas do tipo: Gente sobrecarregada Vs. Gente desalocada, e o seu quadro permitir visualizar graficamente a alocação, a própria equipe vai ver essas diferenças e isso pode ajudar a criar uma cultura de colaboração.

Em equipes mais maduras, alguém desalocado pode se oferecer para ajudar alguém atarefado, e vice-versa. Em equipes menos maduras ou problemáticas, essa “exposição” pode facilitar o trabalho do líder em apontar os problemas e buscar soluções em conjunto com o time.

Você lembra de mais alguma vantagem? Compartilhe nos comentários. 😉

Related Posts:

Read More

Espírito Colaborativo

Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software

Houve o tempo em que os desenvolvedores de Software recebiam suas demandas diretamente dos clientes/usuários, e compilavam as regras do negócio para dentro de suas aplicações, sem documentação ou muita possibilidade de transferência de conhecimento.

Anos mais tarde, a falta de documentação destes softwares tornaram as empresas dependentes de seus desenvolvedores, que, caso saíssem, deixariam provavelmente um estado de caos. Assim nasceram as metodologias de software com bases na Engenharia, onde documentações, processos e muito planejamento tomou conta da “indústria”, e passamos à denominação de “Fábrica de Software”, em uma clara alusão ao processo produtivo de uma indústria comum (linhas de produção de software, no caso).

Isso resolveu alguns problemas, mas trouxe muitos outros, dentre eles: o fato do desenvolvimento ser uma atividade intelectual, e não pode ser medida dentro de um conceito de “Fábrica”, de montagem de um veículo, por exemplo; O excesso de planejamento e burocracia, tornou o processo de desenvolvimento muito mais lento, e com o aumento da competitividade o tempo passou a ser fator crítico de sucesso para os projetos, inclusive de Software.

Foi aí que um grupo de grandes profissionais do desenvolvimento de software, como Martin Fowler (pra citar só o mais conhecido), elaborou um Manifesto para o desenvolvimento ágil de Software, em busca do equilíbrio entre estes dois mundos vividos anteriormente.

O que é bastante curioso, a primeira vista, é que o manifesto não trata apenas do desenvolvimento de software da área de TI pra dentro, mas sim de uma mudança cultural que deve atingir todos os envolvidos nestes projetos, valorizando:

Indivíduos e interação entre eles mais que processos e ferramentas;
Colaboração com o cliente mais que negociação de contratos;

Interação entre indivíduos, significa a proximidade (encontros “cara-a-cara” sempre que possíveis), disponibilidade e clareza nas informações. No desenvolvimento do Software, a área Cliente sabe quais são as suas dificuldades e necessidades, e a área de TI sabe como melhor consolidar estas necessidades e transformá-las em Software. A efetiva comunicação entre as duas áreas aumentará a qualidade do produto final.

A colaboração com o cliente é a transparência e confiança na comunicação entre ele e a área de TI, em uma via de duas mãos, comunicando sempre o progresso, informando aquilo que ainda não está claro, trocando experiências e trilhando sempre o caminho da qualidade.

Do manifesto, surgiram também alguns princípios, que também indicam como o comportamento colaborativo favorece o bom trabalho dos projetos:

  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Com tudo isso, podemos concluir que de fato um Time de Desenvolvimento de Software, não é composto somente por Gerentes de Projetos, Analistas de Sistemas e Desenvolvedores. É feito também pelos Clientes, Patrocinadores e Usuários. Cada um contribuindo com as informações que possuem para o objetivo final e bem comum: Software de qualidade e Ambiente sustentável.

PS.: Não deixe de ver o Manifesto completo, e todos os 12 princípios do software ágil.

Related Posts:

Read More

Certificação Agile PMI e os PMPs de TI

O PMI anunciou em fevereiro/2011 sua certificação PMI Agile Certification, após um longo “namoro” que incluiu a criação de um grupo de estudo e declarações de pessoas influentes do PMI sobre Agile e Scrum.

O Instituto é reconhecido, principalmente, pela manutenção da Base de Conhecimento em Gerenciamento de Projetos (Guia PMBOK(r)), uma compilação das melhores práticas de mercado, que podem ser utilizadas em projetos desde a Construção Civil até o Desenvolvimento de Software.

Se a Base de Conhecimento é formada a partir das melhores práticas vivenciadas pelos membros do PMI no dia-a-dia de projetos, e os métodos Ágeis estão fazendo parte deste dia-a-dia e contribuindo positivamente para o sucesso dos projetos, nada mais óbvio que eles passam a fazer parte destas melhores práticas.

Das duas certificações existentes hoje, oferecidas pela Scrum Alliance e pela Scrum.org, a primeira é conseguida através da participação de um curso presencial, e a segunda é através da realização de um exame online. Ambos os casos certificam papéis específicos dentro do Scrum: Scrum Master, Product Owner, Scrum Developer e etc. Aparentemente, a certificação do PMI será sobre a filosofia ágil e como colocá-la em prática na visão de projetos.

Alias, um dos possíveis problemas que podem surgir, é justamente que o PMI irá definir “melhores práticas” do ponto de vista de um Gerente de Projetos, o que, para muitos “agilistas”, por si só já é um problema, pois acredita-se que um time não precisa de gerentes de projeto, e que a equipe deve praticar o auto-gerenciamento.

Mesmo assim, consigo ver com bons olhos o fato do PMI ter lançado essa certificação. A área de TI precisa mudar para conseguir acompanhar as necessidades dos mercados, e os métodos Ágeis têm se mostrado bastante poderosos para trilhar este caminho. Ter o apoio de um instituto que é reconhecido por muitos profissionais, inclusive que ocupam cargos importantes nas empresas, pode fazer com que a filosofia Ágil ganhe muitos adeptos importantes para facilitar este processo de mudança cultural.

Temos de torcer (e auxiliar na evangelização) para que a certificação realmente promova esta mudança cultural, e não se torne apenas mais uma certificação obrigatória nos currículos para ocupar cargos de chefia nas instituições.

Related Posts:

Read More

Metodologia Tradicional ou Scrum: Foco na Qualidade

Muitas empresas e profissionais defendem e comprovam sucesso através da utilização das metodologias hoje ditas “tradicionais”, enquanto que, nos últimos anos, vemos uma forte expansão do interesse e uso das metodologias ditas “ágeis”, igualmente defendidas através de casos de sucesso. O que nos faz pensar: Afinal, o que fez esses casos darem certo?

Nos últimos meses estive envolvido em um trabalho de atualização e implantação de uma metodologia de desenvolvimento de software no departamento de informática de um órgão público. A metodologia utilizada, apesar de ter suas origens no RUP, conta com influências da cultura ágil, contemplando um número reduzido de artefatos de projeto.

Por se tratar de uma instituição pública, onde naturalmente é mais difícil de se implantar uma nova cultura, e contar com um grande número de equipes e profissionais envolvidos, temos hoje diferentes níveis de maturidade e de aplicação da metodologia internamente. Há casos em que os processos são seguidos rigorosamente, porém os projetos não obtém sucesso, há casos de “caos” finalizados com sucesso e vice-versa.

O problema é que independente da metodologia, é preciso trabalhar a mentalidade dos profissionais, implantar uma cultura de qualidade, para que, independente de seguir a linha de processos tradicional ou ágil, as pessoas estejam focadas no seu trabalho, afetando diretamente a qualidade dos produtos e satisfação dos clientes.

Metodologias X, Y ou Z poderão ser implantadas de acordo com a realidade de cada caso. Implantar SCRUM sem uma participação ativa do cliente como Product Owner possívelmente levará o projeto ao fracasso. Implantar uma metodologia baseada em casos de uso com Analistas de Requisitos que não se façam entender pelo cliente e/ou pela área técnica, possívelmente levará o projeto ao fracasso.

Não se deixe enganar pela venda de Metodologias de Desenvolvimento: não existe Qualidade sem as pessoas. Antes de implantar uma metodologia, trabalhe com todos os envolvidos esta questão. Afinal, este será um fator de sucesso muito mais importante do que a metodologia implantada.

Related Posts:

Read More