Arquivo

Archive for the ‘Idéias’ Category

Agile e PMBoK podem viver juntos em um projeto? Acredito que sim!

04/04/2011 2 comentários

Pessoal,

Publiquei um artigo na MundoJ 46 falando a respeito de um projeto onde apliquei técnicas e idéias de Agile e PMBoK, visando reduzir essa idéia de que são coisas incompatíveis.

Um resumo rápido:

Atualmente temos visto algumas discussões com a tentativa de provar que metodologia (ou base de conhecimento) X é melhor que a Y, etc. Em alguns momentos chegamos a duvidar do sucesso de algumas práticas e ferramentas, quando na verdade deveríamos entender como tirar proveito da melhor forma possível das ferramentas e idéias de cada mindset.

Neste artigo será apresentado um relato de projeto onde foram aplicadas ferramentas e idéias de Agile e do PMBoK, mostrando como é possível unir dois mundos teoricamente heterogêneos para obter melhores resultados.

Tenho recebido alguns feedback´s interessantes e hoje li um post do Rafael Ramos (http://twitter.com/#!/rsouzaramos) onde demonstra seguir a mesma linha de raciocínio em sua estrada.

Segue o link do post: http://www.gestaoetc.com.br/1028/agile-e-pmbok-e-possivel-unir-os-opostos/

Boa leitura e grande abraço!

 

Divisão de tarefas em um time ágil: uma tarefa por desenvolvedor ou vários desenvolvedores por tarefa?

12/02/2011 1 comentário

Em nosso ambiente de desenvolvimento geralmente precisamos tomar algumas decisões com relação ao fluxo de desenvolvimento das atividades de nosso backlog. Trabalho puxado ou empurrado, paralelização de atividades, etc.

Uma escolha importante (que pode ser alterada freqüentemente) é se o time irá atacar um item de cada vez ou se cada desenvolvedor (ou par) ficará responsável por uma única funcionalidade.

Normalmente, prefiro ter mais de um desenvolvedor em uma única tarefa por alguns motivos que considero interessantes. Vou comentá-los abaixo.

Limitação do WIP

Com o crescimento da adoção do método Kanban, muito tem sido falado na comunidade sobre limitar o Work in Progress (WIP). Trata-se de limitar a quantidade de tarefas sendo executadas pelo time, aumentando o foco nas atividades sendo executadas.

Entregas e feedback antecipado

Imaginando 3 atividades de 18 horas cada e um time de 3 desenvolvedores que trabalham 6 horas por dia, se cada um iniciasse uma atividade hoje teríamos as 3 atividades prontas somente no terceiro dia de desenvolvimento (caso não houvesse atraso em nenhuma delas). Até o terceiro dia, não teríamos nada pronto e utilizável para o cliente (apenas aqueles percentuais de conclusão que não servem para nada).

Tarefas sendo executadas em paralelo por três desenvolvedores

Tarefas sendo executadas em paralelo por três desenvolvedores

As três atividades sendo executadas em paralelo aumentam a necessidade de gerência/liderança.

Por outro lado, se tivéssemos os três desenvolvedores atuando na mesma atividade teríamos tal tarefa finalizada ao final do primeiro dia (ou no segundo dia, em caso de atraso).

Tarefas compartilhadas entre 3 desenvolvedores

Tarefas compartilhadas entre 3 desenvolvedores

Assim, teríamos feedback logo no primeiro dia e o cliente já poderia ver algo efetivamente pronto em um tempo menor. Poderíamos nos beneficiar do feedback recebido para melhorar as próximas atividades.

Vale lembrar que feedback nesse caso não é necessariamente do cliente. Podemos ter feedback sobre a qualidade do código (com as análises de código de um servidor de integração contínua, por exemplo), arquitetura, etc…

Claro que nem sempre será possível agir rigorosamente dessa forma. Nem sempre juntar três grávidas irá nos dar o bebê em apenas 3 meses…

Aumento do caos e interação entre a equipe

Quando desenvolvedores compartilham a mesma tarefa é gerado um caos momentâneo  e isso necessariamente aumenta a interação entre os envolvidos. Um começa a reclamar da classe criada pelo outro, da pitaco nos métodos, pacotes, etc.

Isso é bom! Por mais que no início gere um pouco mais de esforço de liderança para controlar os ânimos e ajuda em algumas decisões, com o tempo o próprio time aprende a resolver seus problemas.

O resultado dessa maior interação normalmente é:

  • propriedade coletiva de código
  • maior reaproveitamento de código
  • código mais padronizado
  • peer review
  • integração mais freqüente (já que um depende do código do outro)
  • redução de ilhas de conhecimento e aquela história de “essa funcionalidade é do Fulano e só ele saberá resolver esse problema”

Um arquiteto/líder técnico atento pode tirar bastante proveito dessa situação. Uma revisão técnica após terminar uma funcionalidade pode evoluir a arquitetura da aplicação e mover a estrutura para uma posição melhor, de mais qualidade, ainda na primeira interação, beneficiando a entrega das próximas funcionalidades.

Claro que nem sempre será possível organizar o time dessa forma. Em alguns momentos precisamos respeitar dependências (mesmo que elas raramente existam de fato).

Um outro fator importante a ser analisado é o Custo/Benefício do Atraso (Cost and Benefit of Delay). Quando não há custo em atrasar o início de determinada atividade, postergar o início pode garantir maiores informações no momento certo, por exemplo. O mesmo pode acontecer ao atrasar a entrega de atividades como falado no exemplo anterior.

Por fim, como sabemos, não há bala de prata, mas compartilhar tarefas entre desenvolvedores é, em minha opinião, uma boa idéia e pode trazer vantagens interessantes.

Aqui, tem um post interessante sobre Benefit of Delay e Last Responsible Moment

A história de um projeto (assim como os nossos)

Foi publicado hoje na InfoQ (www.infoq.com) um post de Olivier Mallassi contando a história de um projeto que, segundo ele mesmo, não é “nem mais complexo nem mais simples” que outros.

No entanto é uma história bastante conhecida por qualquer um que já tenha passado por alguns projetos de Software (mesmo que em equipes menores que a mencionada no post).

Há entradas no texto para frases e trabalhos que gosto muito, como:

“Adding manpower to a late software project makes it later”, de Fred Brooks

“Software Engineering: An Idea Whose Time Has Come and Gone?”, de Tom De Marco onde ele fala sobre como a famosa frase “You can’t control what you can’t measure” foi mal interpretada…

O artigo é grande mas é uma excelente leitura! Recomendo!

Segue o link: http://www.infoq.com/articles/mallassi-project-story

Papéis na transição do modelo tradicional para o Scrum

Após acompanhar esta discussão, no grupo scrum-brasil, sobre o papel e as atividades do ScrumMaster (SM), pude perceber algumas opiniões que reforçam o que penso sobre o assunto e tenho visto por aí.

Muitas empresas pecam na transição de modelos tradicionais para metodologias ágeis simplesmente por apenas converter o antigo em novo, sem reservar tempo para estudar e avaliar os conceitos envolvidos e as diferenças nas formas de pensamento. Assim, acabam por evitar mudanças (as vezes propositalmente, visando evitar conflitos) que seriam essenciais para obterem sucesso na reestruturação que desejam.

Leia mais…

Errando logo no início com as famosas RFP´s

14/02/2010 2 comentários

Enquanto curtia a pequena folga de carnaval (trabalharei segunda e quarta-feira – arghhhh)  parei para conferir os e-mails e li este post:

Primeiro passo para um projeto de software falhar: a RFP

A questão levantada pelo autor é bastante interessante e é uma grande realidade em diversas empresas.

– Vamos desenvolver um projeto? Então, escreveremos uma RFP, a entregaremos a algumas empresas e contrataremos a que melhor nos atender (a partir daí, “a que melhor nos atender” pode significar diversas coisas e até, simplesmente, a mais barata).

O problema é que estão negando um princípio muito importante da construção de softwares: Não sabemos o que queremos no início (vide cone da incerteza). Daí, especificamos, no início, algo que pode não ser o mais interessante no final e exigimos que seja feito exatamente daquele jeito.

Em contrapartida, o fornecedor incluirá cláusulas contratuais que bloqueiem (ou ao menos dificultem) qualquer alteração no escopo do projeto, sob pena de multas contratuais. Assim, fazem com que sejam fixados preço, prazo e escopo (logo, a única coisa que pode e vai variar será a QUALIDADE) e, o pior, geralmente não definimos o que será considerado como software de qualidade, no início.

Por exemplo, no que se refere a mudanças no escopo, imagine o impacto que a seguinte frase pode causar no sucesso de um projeto de software (falando de funcionalidades que atendem de forma eficiente e eficaz as necessidades dos usuários e não simplesmente de entregar dentro do prazo e custo definidos – aliás, entregar com prazo e custo dentro do estimado no início é o mais difícil de acontecer):

“Quaisquer alterações no escopo deverão ser apresentadas com no mínimo 30 dias de antecedência e estarão sujeitas a análise do fornecedor”.

Claro que, geralmente, estas alterações serão aceitas pelo fornecedor, desde que o cliente aceite pagar (bem) mais por isso. Afinal, já existem dezenas de documentos definindo o que será feito e tudo deverá ser alterado…

É incrível como, apesar de tanto movimento a favor de melhores práticas e métodos, ainda encontramos diversas empresas com modelos de contratação que não favorecem o sucesso dos projetos de software.

Logo de início, exige-se zilhões de entregáveis que devem ser entregues antes que qualquer linha de código tenha sido escrita. Daí, o que vemos no final são pilhas de documentos mortos desatualizados (ou raramente/precariamente atualizados) e software que não é compatível com o que foi escrito…

De qualquer maneira, alguns pontos que precisamos levantar são:

Estariam os fornecedores preparados/receptíveis para contratos ágeis?

Estariam os clientes e fornecedores preparados para compartilharem os riscos nos projetos de software ao invés de continuarem no “jogo de empurra” onde um quer deixar a culpa para o outro?

É…, sei não viu…

A[]´s e até mais.

A velha história da bala de prata… Continue pensando!

Tenho estudado bastante nos últimos anos e procuro estar alinhado com os assuntos que mais me interessam. Isso envolve gerenciamento de projetos, desenvolvimento, modelagem, liderança e outras coisas.

Para isso tenho livros, revistas, artigos e principalmente blogs e listas de discussões. Atualmente, tenho acompanhado algumas como scrum-brasil, Visão Ágil, XPRio, domain-driven desig, dotNetArchitects, RioJug e Kanban-dev. Claro que não consigo acompanhar e participar ativamente de todas, mas tenho conseguido retirar bastante aprendizado interessante destes meios de comunicação da era digital.

Porém, uma coisa que tem sido recursiva e tem ficado bastante chata é a constante busca pela(o) metogologia/arquitetura/linguagem/framework/batida(rs) perfeita(o). Nestas discussões, inclusive, alguns ativamente atacam outros impondo suas idéias com os mais variados argumentos, ignorando que “cada caso é um caso, salvo alguns casos”.

IMHO, não adianta ficar falando que uma coisa é melhor que a outra ou querer implantar determinada metologia, framework, práticas, etc em todos os projetos como se fosse uma receita de bolo.

Se houvesse uma metodologia perfeita que pudesse ser aplicada como receita para o sucesso, não existiriam tantas outras…

Na minha visão, temos que conhecer (mas conhecer mesmo, não só ler superficialmente e já sair falando como se fosse expert) e identificar o que pode trazer vantagens dada a necessidade, retirarando da caixa de ferramentas as ferramentas que resolvem o problema da melhor maneira.

Já estudei sobre o PMBoK, trabalhei com Rup e hoje estou com Scrum tendendo a seguir com uma abordagem mais Kanban-dev. Se precisar voltar ao Rup (nada de waterfall aqui, ok?), voltarei sem problemas.

Enquanto ficarmos querendo usar a mesma solução para todos os problemas, daremos oportunidade para mais outras centenas de pessoas escreverem artigos, posts, etc com o famoso título “XPTO não é bala de prata!” (seja XPTO CMMI; PMBoK, Scrum, Agile, Crystal, FDD; TDD, BDD, ATDD; Java, dotNet, Ruby e outros milhares de acrônimos e palavrinhas que as vezes nem são mutuamente comparáveis).

Minha opinião é que não devemos parar de PENSAR! Keep Thinking!

Enfim, só um desabafo e vida que segue 🙂