Arquivo

Posts Tagged ‘Agile’

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

Anúncios

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…

UML como documentação?

01/12/2009 6 comentários

Uma coisa que muitos acabam confundindo é a real função da Unified Modeling Language – UML: UML para documentação ou para entendimento de um problema?

O Craig Larman fala disso no livro “Utilizando UML e Padrões” e cita que diversas pessoas perdem muito tempo modelando com UML no sentido de documentar e atrasam a codificação. Quando vão ver, tudo aquilo que foi modelado em diversos diagramas “bonitos” e que demoram bastante tempo ($$$) para serem produzidos não são soluções que poderiam ser implementadas na realidade.

UML é para modelagem, visando que as pessoas entendam o problema e a solução proposta. Uma vez que a informação foi passada, se quiser registrar o que foi desenhado, tire uma foto e guarde. Pronto!

Exemplo de modelo criado durante reunião com cliente

O Vinicus Teles, no seu livro sobre XP, fala, inclusive, que em sua experiência dificilmente precisou dessas fotos.

Em alguns casos, os modelos são realmente importantes e precisam ser registrados (como modelos de domínio e diagramas de atividade modelando o fluxo do processo, por exemplo). Nestes casos, após modelar, transfira para uma ferramenta case e deixe arquivado (o modelo acima, por exemplo, foi inserido em um documento de visão, criado no início do projeto).

Mas é bom lembrar que de nada adianta se este modelo não for atualizado ao longo do tempo. Documentação desatualizada é pior que não ter documentação!

Agile utiliza UML?

Métodos ágeis podem, sim, utilizar UML. Eu inclusive utilizo bastante, porém temos que ter em mente que o que é importante é saber bastante sobre análise e projeto orientado a objetos, padrões, modelagem e não apenas saber UML.

Os métodos ágeis usam esse tipo de modelagem (visando entendimento de um problema e criação da solução), seja com UML ou o quer que seja. Uma boa referência são os artigos do Scott Ambler (em Agile Modeling) sobre o assunto.

Modele para entender, em um quadro branco, em grupo (e junto com o cliente quando quiser descobrir os conceitos do negócio e modelá-los no sistema), tire foto ou deixe isso fixado na parede da sala de projeto e corra para desenvolver o que modelou, pois é isso que vai dizer se o que desenhou está correto…

Com relação a o que é feito antes de por o software para rodar, devo dizer que não acredito nessa idéia de esperar até que todo o software esteja pronto e documentado com belos diagramas para aí sim validar e colocar em produção! Métodos ágeis trabalham com iterações e o software vai sendo produzido aos poucos (incrementalmente) e a cada novo incremento, temos uma versão funcional do software que já pode ser colocada em produção, gerando valor para o cliente.

Uma grande fase de design ou de modelagem no início, o famoso Big Design Up Front (BDUF) ou Big Modeling Up Front (BMUF), retardando o desenvolvimento, não vai garantir qualidade ao seu projeto do ponto de vista do design. Para isso, existem diversas práticas que podem ser utilizadas durante o processo de desenvolvimento, como programação em par, TDD, etc…

Bom, IMHO, é isso…

PS.: Após escrever e publicar este post, cheguei a esse vídeo do Vinicius: http://vimeo.com/1450383. Sem tirar nenhuma vírgula, é isso!

Tags:, ,

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 🙂