Qual a importância da reunião diária no SCRUM?

Quando comecei a estudar a metodologia SCRUM e vi que tinha uma tal de reunião diária algumas perguntas do seguinte tipo surgiram na minha cabeça:

- Essa reunião não é perda de tempo?

- Que diabo de assunto terá para discutir todo dia?

Então fui pesquisar um pouco mais sobre do que realmente é tratada a reunião diária do SCRUM em diversos blogues e qual a sua devida importância. Inclusive os seguintes blogues me ajudaram a escrever esse post:

http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum/

http://www.mountaingoatsoftware.com/blog/weighty-matter-daily-scrum

http://www.effectivemeetings.com/teams/teamwork/scrum.asp

Apresentei para meus colegas de equipe, e resolvemos implementar a diária durante uma fase do projeto que estamos com o prazo apertado e esta técnica realmente nos ajudou a manter o foco e conseguir entregar o software no prazo acordado.

Uma reunião diária deve durar em torno de 15 minutos, portanto não se trata daquelas reuniões prolongadas e se que se arrastam por horas. A ideia principal desta reunião não é solucionar problemas, mas sim identificar se a equipe está no caminho certo, ou caso algum membro do time esteja com problema, este poderá sinalizar para todas pessoas presentes e ‘pedir ajuda’.

As perguntas típicas a serem respondidas numa diária são as seguintes:

“O que você fez ontem?”

“O que você fará hoje?”

“Existe algum impedimento para execução da sua tarefa?”

É recomendado que os participantes fossem os mais breves o possível em suas respostas.  Caso alguém enfrente um impedimento deve sinalizar na diária para que possa ser resolvido fora dela. Típicas assertivas para sinalizar que necessita de ajuda são:

“Eu estou com problemas em debugar o problema com o programa xpto.”

“Eu estou com dificuldades em aprender determinada tecnologia e gostaria de parear com alguém.”

“O departamento VP me pediu para trabalhar em outra coisa por um dia ou dois.”

Apesar de exigir uma equipe com uma certa senioridade em desenvolvimento de softwares, quando feita da maneira correta, a reunião diária pode ajudar qualquer tipo de equipe a manter o foco e aos membros cooperarem entre si para a entrega do software com qualidade e no devido prazo.

Cooperative game manifesto for software development

“Desenvolvimento de software é uma série de jogos cooperativos de invenção e comunicação com recursos limitados e objetivos definidos. O objetivo principal de cada jogo é a produção e entrega de um sistema de software; o resíduo do jogo é uma série de marcadores para ajudar os participantes do próximo jogo. As pessoas usam os marcadores para se lembrarem, inspirarem-se e informar uns aos outros sobre como chegar à próxima etapa do jogo. O próximo jogo é uma alteração do sistema ou a criação de um sistema vizinho. Cada jogo, então, tem um objetivo secundário de criar uma posição vantajosa para o próximo jogo. Dado que os recursos são limitados, o objetivo principal e o secundário competem por recursos.”

Alistair Cockburn : http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development

A palavra ‘jogo’ consiste em uma série de movimentos. Um jogo ‘competitivo’ é aquele que todos os jogadores tem a intenção de ganhar e fazer os outros perder. Por outro lado, um jogo ‘cooperativo’ é aquele que leva os jogadores a ajudarem uns aos outros.

Bons exemplos de jogos cooperativos são grupos de escaladas e bandas de musica. Na música não existe um ponto especifico a se conquistar, mas sim a tocar a musica de maneira mais harmônica possível. Já na escalada, onde existe um ponto que se quer chegar (topo da montanha). Para alguns escaladores chegar ao topo da montanha é algo triste, pois significa que a escalada terminou. Isto acontece com alguns programadores, onde o jogo aqui falado é ajudar uns aos outros a completar a escalada (entregar o sistema funcionando).

No desenvolvimento de softwares nós temos um ‘ponto de chegada’, que é a entrega do software. Não é um jogo competitivo, mas sim cooperativo. O jogo jogado pelo time de desenvolvimento é ajudarem uns aos outros a completarem o software. Podem até haver mais de um time competindo entre si para entregar um software similar em menor tempo, mas dentro de cada time é jogado o jogo cooperativo.

A definição de sucesso pode variar de projeto a projeto. Em alguns casos o tempo de entrega do começo ao fim pode ser o medidor do sucesso do time. Em outros casos o sucesso pode estar atrelado a entrega de um software sem defeitos, e ainda em outros levam em conta a usabilidade do sistema, bem como aceitação pelo cliente e o seu desempenho. O que vai ser usado para medir o sucesso da equipe não interfere na ideia de que estamos jogando um jogo cooperativo, mas sim interfere nas estratégias que o time vai usar para alcançar a entrega.

Cinco “S” (Kaizen) aplicados no desenvolvimento de software

Cinco “S” (Kaizen) aplicados no desenvolvimento de software

Seiri: separar;

Seiton: organizar;

Seiso: limpar;

Seiketsu: padronizar;

Shitsuke: manter;

Assim como a metodologia Lean de desenvolvimento de software e Kanban, o Kaizen também ‘nasceu’ no Japão, como parte da metodologia de trabalho da Toyota, conhecida também por Just in Time. O 5S foi e continua sendo muito usado para dar suporte a metodologias como Kanban para ajudar no processo de melhoria continua.

O conceito do 5S é para ser um método que visa organizar o local de trabalho ou um fluxo de trabalho. Uma que vez que aplicamos o Kaizen no local de trabalho, o time de colaboradores irá ter um local de trabalho mais limpo e organizado. Quando aplicado em um fluxo, qualquer colaborador poderá cumprir as etapas do mesmo e rapidamente identificar se alguma delas está faltando ou foi ‘pulada’.

Um time de desenvolvimento pode se beneficiar da pratica do Kaizen em sua rotina de trabalho, vamos olhar passo a passo como podemos aplicar em nossos projetos:

   Seiri: separar;

Revisar nosso código antigo para remover quaisquer funções obsoletas e não mais utilizadas, bem como muitas funções que acabam não sendo mais usada e deixamos comentadas dentro do código. Muitas vezes utilizamos ferramentas de controle de versão (git), e a mesma guardará as mudanças para nós, não precisamos deixar o código comentado para ver o que se passou. Vale lembrar aqui o conceito do YAGNI (You Ain't Gonna Need It)

   Seiton: organizar;

Muitas vezes no desenvolvimento de software, acabamos fazendo uma força tarefa para agilizar a conclusão de determinado programa. Com essa força tarefa, acabamos fazendo certas ‘gambiarras’ para entregar o software no prazo. Devemos ter a preocupação para separar um tempo e destrinchar o código, separar bem as classes e utilizar o conceito de OO.

   Seiso: limpar;

Importante que reservemos tempo para refatorar nosso código. Sempre que tivermos oportunidade devemos procurar melhorar e limpar um programa já desenvolvido. Mas devemos sempre nos lembrar de rodar as rotinas testes após a refatoração. Ter utilizado o TDD pode ser tornar muito útil quando for refatorar seu código.

   Seiketsu: padronizar;

Devemos manter um padrão de codificação. Nosso código deve estar legível e de rápida compreensão. Uma ótima técnica do Extreme Programming para criar um padrão nos times de desenvolvimento é o Pair Programming.

   Shitsuke: manter;

Uma vez que os padrões de desenvolvimento foram estabelecidos e o código foi revisado para garantir a melhor técnica e desempenho, devemos manter em alto nível tanto de nossas habilidades como desenvolvedores quanto o código desenvolvido.

TDD - Test-driven development

TDD - Test-driven development

O processo de realizar desenvolvimento de sistemas a partir a testes apareceu inicialmente em meados dos anos 2000 junto a pratica do extreme programming, com a ideia de começar o desenvolvimento pela rotina de testes.

Com manifesto ágil, que trouxe a cultura LEAN para desenvolvimento de software e pratica do extreme programming, vínhamos a tomar uma nova mentalidade para realização do nosso trabalho como desenvolvedores. Viemos a absorver os 5 princípios da mentalidade LEAN:

1.    VALOR;

2.    FLUXO DE VALOR;

3.    FLUXO CONTÍNUO;

4.    PRODUÇÃO PUXADA;

5.    PERFEIÇÃO.

Mary Poppendieck, que aperfeiçoou a metodologia LEAN para o desenvolvimento de software nos trouxe 8 princípios:

1.    Eliminar desperdício;

2.    Amplificar conhecimento;

3.    Desenvolver com qualidade;

4.    Postergar decisões;

5.    Entregas rápidas

6.    Respeitar as pessoas

7.    Melhoria continua;

8.    Otimizar como um todo.

Se formos analisar, tanto o pensamento LEAN, quando as praticas do XP, veremos que eles buscam a perfeição do software e entregar um produto de qualidade para o cliente.Sempre se focando na prevenção de falhas, por isso a utilização do TDD.

Ainda temos a metodologia SQA – Software quality assurance, que consiste em monitorar os processos de engenharia de software e desenvolvimento. Este princípio se baseia buscar uma forte definição de requerimentos, codificação, refatoração de código, testes, gerenciamento de versões, dentre outros.

Está clara a ideia de que SQA está diretamente ligada com as ideias de comprometimento de Desempenho e Qualidade. Sendo estes mesmo ideais que o TDD busca atingir, estando diretamente ligados segundo minha opinião.

A utilização do TDD visa justamente desenvolver um software com uma codificação limpa, se baseando na pratica do YAGNI (você não vai precisar disto) e um sistema sem erros, baseado na metodologia LEAN, para entregar um produto de qualidade para o cliente.

Uma boa maneira de se preparar para realizar o TDD, através do assert, é adicionar um critério de aceite nas User Story que dará origem ao código. Ex.

COMO UM ... EU QUERO ... PARA QUE SEJA POSSIVEL ...

Os ... finais da US irão te ajudar a entender o que deve ser escrito no assert do teu teste, para que a partir dele tu comece a codificar e por fim chegar no resultado esperado.

Algumas dicas para Desenvolvedores JUNIOR

Algumas dicas para Desenvolvedores JUNIOR:

Outro dia eu estava lendo um artigo em inglês de um site de TI sobre dicas para quem está iniciando em Desenvolvimento de softwares (< 2 anos de experiência na área de programação).

Achei as dicas muito interessantes e resolvi traduzir o texto com as minhas palavras (de uma maneira mais interpretativa ou até mesmo no Sentido figurado).

O texto original ON BEING A JUNIOR DEVELOPER pode ser encontrado aqui:

http://mattsencenbaugh.com/on-being-a-junior-developer/

 

1	LEIA O CODIGO DE OUTROS PROGRAMADORES:
	Talvez a melhor maneira melhorar suas habilidades técnicas é lendo o código de outras pessoas. O Github é um dos melhores lugares para você encontrar códigos. Melhor ainda se você já tiver um programador experiente e capacitado no seu local de trabalho, em que possa se espelhar no código dele e poder ainda tirar quaisquer duvidas de sintaxe. Neste quesito existe duas coisas muito importantes: a)      Definir bem o nome de métodos e variáveis. Bons programadores deixam o código legível e entendível para qualquer pessoa de fora do projeto. b)      Consiga visualizar o sistema como um todo dentro de sua cabeça e entenda-o. Uma boa pratica para escrever o código e saber o que está fazendo e aonde se quer chegar.
2	PLANEJE O QUE IRÁ FAZER
	Antes de começar a escrever o seu código, pegue um papel e caneta e desenhe seu código. Estes desenhos não precisam ser muito complexos, mas devem proporcionar uma visão holística de como os componentes de seu código irão funcionar e interagir entre si. Neste momento você poderá explorar diferentes maneiras de resolver seu problema, e qualquer coisa poderá apagar tudo e começar do zero. Desta maneira você verá que perderá menos tempo do que se tiver que refatorar o código após uma semana de desenvolvimento por falta de planejamento.
3	TENHA UMA OPINIÃO
	Mesmo sendo novato, você deve ter uma opinião e deve saber as razões pelas quais formou aquela opinião. Perguntar a si mesmo por que formou determinada opinião é uma boa pratica para começar a formar respostas consistentes de suas opiniões quando elas lhe forem questionadas.
4	FAÇA PERGUNTAS
	Após estar integrado com o sistema que está desenvolvimento, faça perguntas relativas ao funcionamento do sistema e a escolha das tecnologias que estão sendo aplicadas no sistema. Bem como a base de dados escolhida. Assim ficará mais de fácil de entender o sistema como um todo e poder contribuir pela melhora do sistema.
5	EXPLORE NOVAS TECNOLOGICAS
	Muitas vezes os desenvolvedores ficam presos a uma tecnologia e acabam tendo medo de experimentar algo novo. Acabamos ficando presos dentro de uma caixa por medo de não conseguir aprender ou falhar. Entretanto é crucial lutar contra esses instintos e aprender novas tecnologias. Cada linguagem nova que aprendemos nos expõe a novos paradigmas e diferentes maneiras de resolver os problemas, consequentemente expandindo a nossa visão universal do mundo da programação.
6	ABRAÇE OS TESTES UNITÁRIOS
	Teste unitário é uma nova pratica de desenvolvimento e devemos cultivar essa cultura. Ela, além de dar maior confiança que o código funciona como realmente deveria, ela nos ajuda a melhorar os protótipos de função antes mesmo de construí-los.
7	REFATORE
	O trabalho de um desenvolvedor não é tão somente escrever código, também é função do desenvolvedor dar manutenção / atualização em um sistema já existente que está rodando no cliente. Muitas vezes encontramos códigos tão porcamente escritos que acabam se tornando impossíveis de manter. Outras vezes ao alterar uma função acabamos prejudicando o funcionamento de outra parte do sistema. A realidade é que ao longo do tempo, vamos pegando experiência como desenvolvedores, aumentando nosso conhecimento e a maneira como desenvolvemos um sistema. O que desenvolvemos a um ano atrás com certeza não funciona tão bem quanto o que estamos desenvolvendo hoje, e isso torna o código de um ano atrás mal escrito? Devemos começar o sistema do zero e refazer tudo? A decisão de refazer todo o sistema geralmente é uma perda de tempo e dinheiro, e normalmente ela demora mais tempo do que imaginamos e planejamos. A melhor solução é a medicina preventiva. Devemos estar constantemente reescrevendo e refatorando nossos códigos. Uma boa regra dos métodos ágeis e sempre deixar o código de uma maneira melhor do que quando encontramos ele.

SCRUM

SCRUM

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.

fonte: desenvolvimentoagil.com.br/

POMODORO TECHNIQUE

POMODORO TECHNIQUE

Nas aulas do pós de metodologias ágeis que eu ouvi falar desta técnica, fiquei um pouco curioso, pesquisei e resolvi por em prática. Venho então a dividir minhas opiniões a respeito desta técnica.

A Técnica Pomodoro consiste basicamente em dividir seu tempo de trabalho em períodos de 25 minutos e após esse período fazer pausas curtas. Esta técnica tem por finalidade aumentar a concentração e diminuir eventual cansaço.

Existem vários sites que explicam como essa técnica funciona, mas basicamente seus princípios são os seguintes:

1.   Escolher a tarefa a ser executada

2.   Ajustar o pomodoro (alarme) para 25 minutos

3.   Trabalhar na tarefa até que o alarme toque; registrar com um "x"

4.   Fazer uma pausa curta (3 a 5 minutos)

5.   A cada quatro "pomodoros" fazer uma pausa mais longa (15-30 minutos)

O grande segredo é não deixar ser interrompido de sua tarefa durante o seu pomodoro, nem por você ou por outras pessoas. Ficar focado os 25 minutos na tarefa, e só após esse período que você irá se desligar da tarefa e atender as outras necessidades.

Na web vocês encontraram vários gadgets para controlar o tempo, tanto de 25 minutos quanto dos intervalos.

Eu utilizei a técnica e realmente funcionou para mim. Fiquei bem focado em um projeto que tinha prazo de entrega e estava receoso que não iria conseguir. Entretanto, o gadget que conta tempo, não funcionou pra mim. Funcionei melhor com um relógio de parede, sendo que eu sabia mais ou menos meus 25 minutos de trabalho e que deveria trabalhar sem ser interrompido.

Essa técnica funciona para qualquer tipo de trabalho ou tarefa a ser executa, apesar de render bons resultados no desenvolvimento de sistemas.