Há alguns anos, quando a internet ainda estava distante, o conhecimento era compartilhado por meio de livros ou de boca-a-boca. Era raro alguém possuir conhecimento aprofundado em vários segmentos e por isso o conhecimento era sinônimo de sucesso, garantia de emprego e prestígio social.
Com o decorrer dos anos e o surgimento da internet, um novo canal de compartilhamento de informações nasceu. Quanto mais popular e acessível a rede mundial de computadores ficava, mais fácil e palpável o conhecimento se tornava. Enquanto o autodidata de outrora era limitado pelos livros disponíveis – muitas vezes caros e em idioma estrangeiro – o autodidata dos tempos atuais tem a sua disposição bilhões de fontes de conteúdo a um clique do mouse. Começava então uma era onde o conhecimento se tornava comum e, consequentemente, deixava de ser considerado como critério de classificação e diferenciação entre as pessoas.
Se o conhecimento se tornou tão ordinário, qual seria então o novo parâmetro para diferenciação? Inteligência? Leia mais…
É difícil descrever todas as responsabilidades de uma equipe de desenvolvimento. Análise, documentação, testes, refatoração e etc. São muitas as competências exigidas, e, se cada uma delas não estiver clara para todo mundo, a chance de algo não sair conforme o esperado é grande. Pensando nisso, me baseei no artigo do Alberto Gutierrez para criar esse checklist com algumas coisas que você deve fazer para ter uma boa equipe.
1. Focar no cliente
O cliente é a razão de tudo. Sem ele não existiria o seu departamento, e, provavelmente, a sua empresa. Por isso, tenha em mente que você deve satisfazer o cliente, entregando coisas que agregam valor para ele. Focar no cliente também inclui abrir a mão de algumas coisas para entregar o que ele precisa. Por exemplo: se aquela refatoração vai atrasar a entrega de uma funcionalidade exigida pelo cliente, abra mão dela por enquanto (faça-a em outro momento mais oportuno).
Leia mais…
Você se considera uma pessoa produtiva no trabalho ou em sua vida pessoal? Quanto tempo consegue se concentrar em uma determinada tarefa antes de ser interrompido ou mudar o foco? A produtividade de uma pessoa está diretamente ligada a capacidade que ela tem de manter o foco. Quanto mais focada for, melhor e mais rápida vai atingir o objetivo, seja no campo profissional ou pessoal.
Porém, nem sempre ‘mais’ significa ‘melhor’. O cérebro humano tem um limite, e não consegue produzir com qualidade satisfatória após um determinado tempo de esforço contínuo. Cada pessoa tem um ritmo e os intervalos regulares são necessários, seja pra ver emails, conversar, fazer uma ligação ou tomar um café. Leia mais…
A fim de ajudar as pessoas a entenderem melhor o desenvolvimento ágil de software, em 2001 os membros da Agile Alliance refinaram o enunciado do Manifesto Ágil, criando doze princípios que as metodologias ágeis devem seguir. Estes princípios são os seguintes:
- Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software funcional.
- Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente.
- Entregue software funcionando com uma freqüência de duas semanas a dois meses, escolhendo sempre a menor escala de tempo possível.
- O pessoal de negócio e os desenvolvedores devem trabalhar juntos no projeto diariamente.
- Construa os projetos com pessoas motivadas. Forneça o ambiente, os equipamentos e as ferramentas de que elas precisam e confie que elas farão o trabalho.
- Uma conversa cara a cara é a melhor forma de transmitir e receber informação do time de desenvolvimento.
- Software funcionando é a principal medida de progresso.
- Processos ágeis promovem um desenvolvimento sustentado. Gerência, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
- A atenção contínua à excelência técnica e a um bom design aumentam a agilidade.
- Simplicidade – a arte de maximizar a quantidade de trabalho desnecessária – é essencial.
- As melhores arquiteturas, designs e requisitos surgem de times auto-gerenciados.
- A intervalos regulares, o time reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo com as reflexões.
Pare por um momento e reflita sobre os princípios acima. Serão tão radicais e impossíveis como algumas pessoas acham ou simplesmente seguem o bom senso? Será tão difícil fazer os projetos funcionarem desta forma? Você realmente acredita que seu cliente prefere uma ótima e farta documentação a um sistema funcionando em um curto prazo? Ou que um e-mail substitua um bom bate-papo? E que tal fazer somente o necessário, sem ficar ‘viajando na maionese’?
Estes princípios formam um senso comum e prático, sobre o qual podemos alicerçar nossos esforços para a construção de um software de sucesso.
(Referência: Agile Modelling – Scott Ambler)
Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.
Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.
Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:
Leia mais…
Como um amigo meu disse certa vez… ‘na internet nada se cria, tudo se copia’. Acabei me rendendo a essa frase, e publicarei uma estorinha já contada em outros blogs. Essa eu peguei do blog do André Dourado (blog muito bom, recomendo). O post original é de Henrik Kniberg, autor do livro ‘Scrum e XP direto das trincheiras’.
É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners. O André fez uma tradução livre para o português. O post original pode ser visto em One Day in Kanban Land.
Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).
Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas. Leia mais…
Quando trabalhamos com equipes mais enxutas, utilizando metodologias ágeis (como o Scrum), temos um considerável poder de decisão e planejamento sobre o que será implementado em cada build. Digo considerável pois existem vários fatores que influenciam o que fará parte do seu sprint (sprint é uma interação que segue o ciclo PDCA e entrega incremento de software pronto), como a priorização do Product Owner (o cliente), tamanho estimado para cada uma das user stories que farão parte da interação, restrições técnicas e outras.
Durante o processo de estimativa, é comum decompormos as user stories em várias tarefas menores, com o objetivo de facilitar a pontuação de cada uma delas. Esse processo é adequado e, se bem feito, aumenta muito a precisão das estimativas, porém, ao quebrar uma solicitação em atividades menores, corremos um sério risco de perdermos de vista o real objetivo de cada uma das tarefas, que é contribuir para a conclusão de um recurso solicitado pelo cliente. Convém não esquecermos que, para o cliente, essas pequenas atividades geralmente não possuem valor por si, a não ser que todas sejam feitas e a feature solicitada seja entregue. Leia mais…
Estimativas de tamanho são diferentes das estimativas de duração. Ao estimar a duração tentamos estabeler quanto tempo será necessário para concluir uma tarefa. Mas, ao estimar pelo tamanho, analisamos quanto esforço (ou quanto trabalho) será necessário dispender para executar a tarefa.
Times ágeis estimam pelo tamanho e separam essa estimativa da estimativa de duração. Utilizarei uma metáfora como exemplo para entendermos melhor essa distinção.
Suponha que, em uma bela manhã de domingo, minha esposa me incumba de recolher uma grande pilha de folhas e lixo de um canto do nosso jardim. Após um café da manhã reforçado, posso olhar aquela enorme pilha, analisar e avaliar minhas ferramentas (uma pá e um carrinho de mão) e estimar imediatamente que levarei 5 horas para terminar o trabalho. Para chegar a esse valor, ignorei qualquer estimativa de tamanho e parti diretamente para uma estimativa de duração.
Agora, imagine que eu olhe para a pilha e estime seu tamanho. Baseando-me nas suas dimensões, estimo que a pilha contem cerca de 10 metros cúbicos de sujeira. Essa é minha estimativa do tamanho da tarefa. Mas, nesse caso, somente uma estimativa de tamanho não é lá muito útil. Como no domingo tem um joguinho de futebol, quero saber quanto tempo vou demorar para limpar toda a sujeira. Ou seja, preciso converter minha estimativa de tamanho em uma estimativa de duração.
Leia mais…
Dual view é a utilização simultânea de 2 monitores no mesmo computador, com a respectiva extensão da área de trabalho disponível. Neste artigo pretendo apresentar argumentos de como uma equipe pode ganhar produtividade utilizando bem não apenas um, mas dois monitores LCD.
O argumento mais óbvio é o ganho de espaço para visualização simultânea de várias janelas, mas somente isso não é suficiente; devemos utilizar esse espaço adicional de forma inteligente. E tudo começa com um conceito que aparentemente não tem relação alguma com monitores: “contexto mental”.
Segundo Andy Hunt, em seu livro “Pragmatic Thinking”, contexto mental é o conjunto de fatos, estados e/ou objetos em que estamos focados em um certo momento. Por exempo, quando participamos de uma reunião, o assunto em pauta, a entonação de voz do interlocutor, sua aparência, a sala, a mesa, a iluminação, até mesmo aquela cadeira desconfortável, tudo se une para formar o contexto. Pense nele como o conjunto de informações para as quais você dedica sua atenção em um certo momento e que estão carregadas na sua memória de curta-duração.
Leia mais…
Comentários recentes