Newton Wagner » projeto

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

Newton Wagner — Tue, 11 Oct 2011 20:28:54 +0000

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.

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

Newton Wagner — Mon, 03 Oct 2011 12:07:31 +0000

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.

Certificação Agile PMI e os PMPs de TI

Newton Wagner — Fri, 25 Feb 2011 17:30:50 +0000

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.

Meu ambiente de trabalho em 7 itens

Newton Wagner — Mon, 14 Feb 2011 10:24:08 +0000

Os memes são como correntes nos blogs. Alguém inicia a corrente e convida outros participantes para comentar sobre o mesmo assunto. Não via/participava disso a muito tempo, mas fui convidado pelo Daniel Costa para um meme do Duodraco e não é legal quebrar a corrente, certo?

As regras do meme são:
1ª – escreva sobre 7 itens de seu ambiente de trabalho – fale sobre qualquer ponto que quiser;
2ª – indique de 3 a 5 pessoas para que possivelmente façam um artigo sobre seu ambiente.

Windows como Sistema Operacional, de preferência o 7, uma grande evolução em comparação ao Vista. Eu até poderia utilizar o Linux, mas muitas ferramentas que utilizo ficariam indisponíveis, e não tenho mais a mesma paciência de antes para me adaptar às novas ferramentas no S.O.
BizAgi Process Modeler para desenhar aquele fluxo do sistema ou de trabalho, sempre quando uma imagem vale mais do que alguns parágrafos.
MindMeister para organizar as idéias em mapas mentais. Não funciona na rede do trabalho, então apelei para o uso do FreeMind.
Lápis e caderno para gerenciamento das tarefas. Já escrevi sobre isso antes.
Celular com Android sincronizado com Google/Exchange, pra não esquecer dos compromissos.
Manifesto Ágil, como guia/filosofia para o gerenciamento de projetos de desenvolvimento de software.
WordPress para os blogs.

É um meme antigo, andei vendo e a maioria dos conhecidos já foram convidados para ele. Vou ficar devendo os convites para o próximo.

Metodologia Tradicional ou Scrum: Foco na Qualidade

Newton Wagner — Tue, 23 Nov 2010 11:30:13 +0000

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.

Utilizando Linha de base (Baseline) no MS Project

Newton Wagner — Thu, 29 Apr 2010 13:59:20 +0000

Um grande recurso do MS Project para o acompanhamento do andamento do projeto é a utilização das Linhas de Base (ou Baselines no termo em inglês), que permite comparar o que foi previsto no projeto com o que está sendo realizado.

Para utilização da Linha de Base, primeiro é preciso entender que ela é uma Foto do seu planejamento, ou seja, como você planejou a execução do seu projeto. Você pode salvar baselines tanto para atividades específicas, como para todo o projeto, mas iremos trabalhar apenas o segundo cenário aqui.

O primeiro passo é criarmos um cronograma do nosso projeto, como neste exemplo:

Uma vez fechado o planejamento, podemos salvar a linha de base do nosso projeto acessando o menu "Ferramentas > Controle > Definir Linha de Base", que irá nos levar até a tela abaixo.

Agora que já salvamos nossa linha de base, podemos visualizar em nosso cronograma no Project a linha de base ao lado do meu cronograma de andamento, através do menu "Exibir > Gantt de Controle", passando a ter a seguinte visualização do gráfico:

Agora que temos a linha de base salva, vamos supor um andamento do nosso projeto, considerando a data atual como 28/04/2010 (linha pontilhada no Gantt). Vamos considerar que a Atividade A foi iniciada e concluída dentro do prazo, a atividade B não foi iniciada no dia, e terá o atraso de 1 dia em seu início, e a atividade C foi iniciada e está com andamento dentro do que foi planejado.

Já vemos agora no Gantt de Controle, uma distorção entre Planejado (barras pretas no Gantt) e o Realizado (barras azuis e vermelhas no Gantt), indicando claramente o atraso nas Atividades B e D:

Linha de Andamento

Outra forma de fazer o acompanhamento com a linha de Base além do Gantt de Controle, é utilizando a Linha de Andamento, acessada através do menu "Ferramentas > Controle > Linhas de Andamento". Iremos configurar uma linha de base simples, em relação ao nosso Planejamento (“Plano da linha de base”), conforme tela abaixo:

Depois de configurada a linha de andamento, podemos ver no Gantt uma linha vermelha, cortando nosso cronograma na data atual e com marcadores do andamento para cada atividade:

Atividade A: Concluída, sem marcador;
Atividade B: Marcador recuado em relação à linha de andamento e à atividade, indicando atraso em relação ao planejado (Linha de Base);
Atividade C: Marcador sobre a linha de andamento, indicando que a atividade está sendo executada dentro do previsto;
Atividade D: Atividade futura, sem marcador.

Com a linha de andamento, conseguimos ter uma visualização rápida de como está o andamento das atividades em relação ao que foi planejado até a data atual, mas não conseguimos visualizar o impacto nas atividades futuras do projeto (neste caso, Atividade D).

Certificação CAPM vale a pena?

Newton Wagner — Wed, 06 May 2009 15:54:42 +0000

Em meu caminho para direcionar minha carreira para a área de Gestão de Projetos, por ter pouca experiência atuando na área, resolvi procurar por alguma certificação para servir de guia (ou meta) nesse caminho, e me deparei com as certificações oficiais do PMI: CAPM e PMP.

A primeira certificação, é a de PMP, Project Manager Professional, dispensa comentários, pois é extremamente difundida no mercado de trabalho. Já a CAPM, Certified Associate in Project Management, foi criada pelo PMI em 2003 para profissionais envolvidos em projetos e jovens gerentes de projetos que ainda não atingiram os pré-requisitos para a PMP, exigindo apenas 1 ano de experiência de participação em projetos, contra o mínimo 3 anos de atuação como gerente de projetos da certificação PMP.

Nesse momento, como me encaixaria no grupo dos que ainda não possui os pré-requisitos para a certificação PMP, me perguntei se valeria a pena investir na CAPM. Pra responder a essa pergunta, resolvi dar uma olhada no mercado de trabalho.

Realizando uma pesquisa no portal de empregos Catho Online, sem qualquer outro filtro além da palavra chave "PMP" , obtive 107 ofertas como resultado. Ao realizar pesquisa semelhante com a palavra chave "CAPM", nenhum resultado foi encontrado. O mesmo cenário se repetiu em outros dois portais de empregos, CEVIU e EmpregosTI.

Um pouco surpreso com o resultado da pesquisa, aproveitei o contato com uma figura conhecida no mundo de Gerenciamento de Projetos, e fiz para ele a mesma pergunta que havia feito pra mim mesmo: CAPM vale a pena?

A resposta foi positiva, mas com algumas ressalvas.

A ressalva é que o mercado brasileiro ainda não absorveu a certificação CAPM e, por isso, não encontramos vagas específicas para esse tipo de certificado. Então, mesmo com essa certificação você não garante uma vaga para atuação como Gerente de Projetos, tanto quanto um certificado PMP, no mercado de trabalho.

O argumento positivo é, de certa forma, o genérico para certificações: indicativo de interesse pelo assunto; comprometimento e capacidade de aprendizado para aprovação na prova. Isso significa que, se você está atuando como líder técnico, por exemplo, e quer partir para a área de Gestão de Projetos, então uma boa forma de demonstrar isso para seus líderes ou futuro empregador, é tirar uma certificação (CAPM) que demonstra o seu interesse e comprometimento com um modelo reconhecido pelo mercado (no caso o Guia PMBOK).

Estudando Análise de Pontos de Função

Newton Wagner — Mon, 16 Apr 2007 18:05:11 +0000

A bola da vez nos meus estudos é a Análise de Pontos de Função. A APF é uma técnica para medir a quantidade de funcionalidades de um software do ponto de vista do seu usuário. Dessa forma, pode-se estimar o custo do desenvolvimento deste produto.

Perceba que a idéia, e o destaque, são os mesmos da UML, ou seja, foco no usuário do sistema, visão do usuário do sistema, para que ele possa entender o que está sendo feito e interagir.

Assim como aconteceu com BPMN, estou só estudando, mas acho que dessa vez, em breve, vou praticar um pouco mais a aplicação da APF, e aí vejo a possibilidade de passar algumas informações mais relevantes sobre o assunto. Por enquanto, seguem alguns links para estudos:

IFPUG - International Function Points User Group;
BFPUG - Brazilian Function Points User Group;
Fatto Consultoria e Sistemas: Este site contém um FAQ e outras informações sobre APF;
Compare Preços do Livro: Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software, ISBN 8571948992;

Palestra do grupo BrasilDotNet na Unieuro

Newton Wagner — Wed, 21 Mar 2007 13:59:43 +0000

Ontem tive a oportunidade de assistir palestras sobre o Windows Vista, Imagine Cup, Microsoft .NET, ASP.NET e também um overview de Arquitetura de Software.

Porém, a motivação de escrever este post não veio do evento em si, mas sim de algumas das impressões sobre o evento do Daniel Costa.

A primeira é o fato da apresentação da codificação em ASP.NET 2.0 no Visual Studio. Concordo com o Daniel quando ele diz que este tipo de programa não garante qualidade de código. Porém, o mercado hoje está em busca de produtividade, afinal de contas, o usuário não se importa se você fez uma série de IFs aninhados, ou se separou a lógica do programa em métodos e etc. E aí o Visual Studio aparece como uma poderosa ferramenta de apoio ao desenvolvimento, assim como o Delphi para PHP, anunciado pela Borland, pode se tornar uma.

A segunda foi a leve crítica feita ao PHP-DF, que segundo ele está demorando pra sair. Não, não vou defender o grupo nem a posição do Daniel, mas é interessante notar que esse tipo de coisa a Microsoft e a Sun sempre saem na frente, até mesmo na produção de ferramentas de qualidade, que é o investimento. Os próprios integrantes do BrasilDotNet revelaram ter algum, pequeno, apoio da Microsoft, enquanto isso dezenas de empresas são parceiras da Sun pra divulgar o Java, mas a Zend não oferece nenhum tipo de incentivo pra eventos relacionados ao PHP.

Pra terminar, achei interessante as palestras, apesar de terem sido muito corridas. Os próximos eventos que pretendo ir é o 1º PHPDF Pocket e o CodeGear Delphi Tour 2007, onde será apresentado o Delphi for PHP dia 27.

Introdução ao BPMN (Business Process Modeling Notation)

Newton Wagner — Mon, 12 Mar 2007 18:30:11 +0000

O BPMN, Business Process Modeling Notation, como diz o nome, é uma notação de modelagem de Processos de Negócios, parecida com a UML que é uma linguagem de modelagem.

Extensão do Visio para BPMN

A diferença entre as duas é que a primeira foi feita exclusivamente para relatar os Processos de Negócio, deixando de lado alguns (poucos) tecnicismos que encontramos na segunda, como os Includes e Extends, que podem dificultar o entendimento do fluxo de um processo.

Pelo que li até agora, não existem segredos na notação, mas não sei dizer o quão difundida ela esta no mercado. Essa semana vou receber um treinamento sobre isso, e se pintar alguma coisa realmente interessante eu conto por aqui.

ATUALIZAÇÃO: Vi no Submarino o livro BPM & BPMS: Business Process Management & Business Process Management Systems, de Tadeu Cruz. Pode ser uma boa leitura para quem está interessado no assunto e procura por mais informações.

Newton Wagner » projeto

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

1. Visibilidade

2. Facilidade de uso

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

Artigos Relacionados:

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

Artigos Relacionados:

Certificação Agile PMI e os PMPs de TI

Artigos Relacionados:

Meu ambiente de trabalho em 7 itens

Artigos Relacionados:

Metodologia Tradicional ou Scrum: Foco na Qualidade

Artigos Relacionados:

Utilizando Linha de base (Baseline) no MS Project

Linha de Andamento

Artigos Relacionados:

Certificação CAPM vale a pena?

Artigos Relacionados:

Estudando Análise de Pontos de Função

Artigos Relacionados:

Palestra do grupo BrasilDotNet na Unieuro

Artigos Relacionados:

Introdução ao BPMN (Business Process Modeling Notation)

Artigos Relacionados: