Posts Tagged "Software"

Arquitetura de Software: Concorrência

Posted by on Dec 19, 2011 in Software | 0 comments

Acredito que concorrência é um dos tópicos mais básicos de arquitetura de software, e que deve ser conhecido e estudado por todo desenvolvedor de software. Este ano, fiz uma apresentação introdutória sobre o tema na Bluesoft, e gravei um episódio do DeveloperTalk.tv sobre assunto.

Confira os slides e vídeos e aprenda um pouco mais sobre:

  • Locking (Pessimista e Otimista)
  • Leituras (Consistente e Incosistente)
  • Compartilhamento de Recursos
  • Contextos e Escopos de Execução
  • Transações ACID
  • Deadlocks
  • Níveis de Isolamento Transacional

Read More

Mas o que faz um Product Owner?

Posted by on Nov 22, 2011 in Agile | 6 comments

Recentemente recebi uma pergunta no Facebook, sobre o que faz um PO. Gostaria de responder a pergunta e deixar minha opinião registrada através deste post.

A pergunta foi mais ou menos assim:

Onde eu trabalho estou para assumir o desafio de ser PO, e parece que a empresa não tem bem definido o quais são as funções do PO pois alguns dos POs desenham diagramas como um analista de requisitos, isto está correto?

Segundo eles esta é a lista de atividades:

  • Entender, criticar, questionar e mapear processos de negócio do cliente;
  • Levantar requisitos funcionais e não funcionais de sistema;
  • Mapear e descrever atores e casos de usos/user stories de sistema;
  • Definir complexidade dos requisitos de negócio;
  • Elaborar documento de escopo do sistema;
  • Prototipar interfaces de usuário do sistema;
  • Realizar reuniões de licitação de requisitos com cliente;

Vamos então as origens. De acordo com o Scrum Guides:

O Product Owner é responsável por maximizar o valor do trabalho que o Time de Scrum faz, [...] é  a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo.

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar suas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro conjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o contrário. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e  recompensador ao mesmo tempo.

Isso dito, vamos fazer uma analise.

Product Owner (PO) é apenas um Papel do Scrum

Scrum é um  é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software [Wikipedia]. O processo define 3 papéis, entre eles o do Product Owner . Dessa forma em se tratando de Product Owner, podemos afirmar apenas que suas responsabilidades são apenas o que dita o processo:

  1. Maximizar o valor do trabalho que o Time
  2. Gerenciar o Backlog (Manter, Priorizar, etc)
Isso significa que um Product Owner não pode fazer nada além disso? Não. Product Owner  não é um Cargo, é um papel, ou seja, é muito provavel que a pessoa que assumir esse papel tenha outras responsabilidades na sua organização, e isso tem uma relação direta com o contexto (projeto, produto, equipe,  cliente, etc.).
O Product Owner pode ser o próprio cliente, pode ser uma pessoa que faz parte da equipe do cliente (um médico, um advogado, um contador, um CEO), pode ser um gerente de produtos, pode ser um analista de negócios, etc. Se essa pessoa tiver disponibilidade para estar perto do time e estiver capacitada a maximizar o valor do trabalho do time e gerenciar o backlog, do ponto de vista do processo, não há nada de errado com isso.
Em outras palavras, se o PO fizer bem o papel, e tiver outras atividades, não há problema algum, e essas outras atividades que fizer estiverem relacionadas à gestão do Backlog e a Maximizar o trabalho do time, melhor ainda.

Mas então quais são essas atividades?

  • Criar protótipos?
  • Fazer Pesquisas de Mercado?
  • Detalhar Requisitos?
  • Visitar Diferentes Clientes?
  • Pesquisar Produtos Concorrentes?
  • Conversar com Usuários?
  • Desenhar Diagramas?
  • Escrever Testes de Aceitação?
  • Documentar?
  • Manter um Documento de Visão?
  • Servir Café aos Desenvolvedores?
A resposta, na minha opinião, é: Depende do Contexto/Cenário!
Alguns produtos são criados para um único cliente, outros para centenas de milhares, alguns envolvem grande complexidade, outros baixíssima, alguns produtos envolvem diversas áreas de conhecimento, como é o caso de um ERP, por exemplo, alguns produtos são tão grandes, ou tem um prazo tão curto que precisam que diversos times trabalhem simultaneamente para um mesmo target release (Agile Release Train), alguns produtos são construídos em empresas com 20 funcionários, outros em empresas com milhares.

Conclusão

Para todo problema complexo existe sempre uma solução simples, elegante e completamente errada. 

H L Mencken

Podemos concluir que não existe bala de prata! Ou seja não há um conjunto único de atividades (baixo nível) que um PO possa fazer que seja eficiente em todos os projetos e contextos. Você precisará, através de um processo de inspeção e adaptação, encontrar quais são essas atividades que fazem sentido na sua organização.
Read More

Lista com todas as Práticas Ágeis

Posted by on Sep 1, 2011 in Agile, Featured, Software | 5 comments

Calma, calma, eu sei que o título está um pouco, ou melhor, muito ambicioso, mas em 2009, Jurgen Appelo fez um post chamado “A grande lista de práticas ágeis“, sabendo desde o inicio que o post seria odiado e amado por muitos, visto que já muita gente encara metodologias de modos mais partidários ou religiosos. Com este aqui não será diferente.

Eu gosto de encarar essas práticas como uma caixa de ferramentas, e nessa linha, podemos encarara que cada ferramenta certa para o problema certo, ou seja, dependendo de cada realidade ou contexto, ferramentas diferentes serão ou não úteis. Tomei como base a lista do Jurgen e incluí algumas outras práticas.

Requisitos (Requirements)

Design

Desenvolvimento (Construction)

Testes (Testing)

Processo (Process)

Organização (Organization)

Aprendizado

  • Coding Dojos
  • Clubes de Livro (Book Clubs)
  • Palestras da Equipe para a Equipe (Brown Bag Seminars)
  • Biblioteca Rica à Disposição (Livros, Screencasts, Áudio-livros, Contas no SafariBooks)
  • Participação em Eventos (Alta cobertura de eventos)

Gestão Ágil

Referências

Agradecimentos Especiais à Jurgen Appelo, Daniel Cukier, e Fábio Aguiar pela colaboração.
Sentiu falta de alguma prática na lista? Deixe seu comentário.
Read More

Artigo de Kanban na JavaMagazine

Posted by on Oct 30, 2010 in Agile | 1 comment


JM 84

JM 84

É com grande satisfação que anuncio que o artigo que escrevi sobre Kanban finalmente foi publicado na Java Magazine 84.

Este artigo apresenta uma introdução ao método Kanban. Para isso, descreve os passos para implantá-lo em uma equipe de desenvolvimento de software, aborda a criação de um card wall que represente o processo e cartões que representem itens de trabalho, além da definição da cadência de reuniões e outros eventos importantes para o ciclo de desenvolvimento.

Kanban permite que um processo seja otimizado de acordo com um contexto específico, aderindo a diferentes tipos de equipes e projetos. Geralmente causa pouca resistência a mudanças por parte das pessoas e da organização, ao passo que ajuda a equipe a manter um ritmo sustentável e previsível através de um fluxo contínuo de trabalho, conquistado em virtude da definição do limite de trabalho em progresso.

Para quem tiver mais interesse, há também uma apresentação sobre o tema que fiz no Bluesoft Labs:

Espero que gostem. Aguardo feedback de todos.
Read More

Uncle Bob Martin, um grande exemplo para nós Desenvolvedores

Posted by on Jun 17, 2010 in Agile | 5 comments

Fábio Akita, recentemente publicou uma entrevista com o famoso Uncle Bob Martin, grande personalidade da comunidade de desenvolvimento de software, métodos ágeis e software craftsmanship.

Uncle Bob é, sem dúvida, um grande exemplo para todos nós desenvolvedores de software, apesar de seus 46 anos de experiência com desenvolvimento de software, ele nunca parou de aprender. Programadores não devem nunca pensar que a linguagem que aprendem na faculdade ou que utilizam agora são A linguagem, ao invés disso, devem abrir suas mentes e estar sempre aprendendo uma nova linguagem de programação, disse ele.

What I'm reading and re-reading por Earl

What I'm reading and re-reading por Earl

Se você programar somente em Java, por exemplo, e não for além disso, você será um programador muito fraco, porém se for em busca de aprender novas linguagens e aprender novos paradigmas você voltará para o seu Java com muito mais conhecimento e será ainda mais eficiente, afirmou Bob. “Eu, por exemplo, estava aprendendo Ruby e agora estou estudando Clojure”, disse.

Depois de ter escrito o livro Clean Code (Código Limpo), Bob está escrevendo um outro livro agora, chamado Clean Coder (Codificador Limpo), falando sobre como gerenciar o tempo, como lidar com pressões, como estimar, como lidar com chefes, etc. Estamos aguardando ansiosos pela nova publicação.

Bob disse que toda boa idéia que fica popular, tornar-se um hype, muita gente usa isso para seus próprios interesses, muitas vezes invertendo os propósitos. Cuidado! Escolha bem quem o ajudará a aprender métodos ágeis. Volte as fontes, busque os livros de quem estava lá no inicio. Martin Fowler e Kent Beck, são ótimas referências.

Muita gente está agora em ágil, defendo ágil, alerta Bob, mas está apenas pela corrida do ouro, ou seja, não conhecem e nem acreditam nos princípios e valores dos métodos ágeis, apenas estão ensinando ou utilizando ágil para manter-se lucrativos em virtude do movimento do mercado que está sendo impulsionado pelo hype.

Veja o vídeo da entrevista, que foi gentilmente disponibilizado sob a licença Creative Commons pelo Akita.

http://blip.tv/play/AYHm7HIC

Siga os conselhos de Uncle Bob Martin, aprenda como um louco, leia, leia, leia.

Para maiores informações, visite o blog do Akita.
Read More