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.

14 PRINCÍPIOS DA TOYOTA

Porto Alegre, 04 de junho de 2014

UNIRITTER – Pós-Gradua​cão em Tecnologia​s Aplicadas a Sistemas de Informação com Métodos Ágeis

PROF. DANIEL WILDT (Metodologias Ágeis)

ALUNOS: Gustavo R. Emmel, Marcus M. da Silva

Abaixo estão relacionados os 14 princípios da Toyota, dentre estes escolhemos três que julgamos que atenderá de forma mais imediata às necessidades mais latentes do nosso dia a dia.

Princípios da Toyota:

1.       Tome decisões pensando sempre no longo-prazo, mesmo que no início os custos sejam maiores;

2.       Crie fluxo contínuo p/ todos os processos, pois assim aparecerão os reais desperdícios a serem continuamente eliminados;

3.       Utilize sistemas de produção puxados pela demanda, como o Kanban, para evitar a superprodução;

Mudando a cultura das pessoas envolvidas no processo para utilizar o kanban como uma ferramenta de gestão
1.	WHAT – O que será feito.
	Disseminação da importância da utilização do quadro kaban entre os colaboradores.
2.	WHY – Por que será feito
	Aumentar a qualidade dos resultados de cada processo, em um menor tempo possível, tornando o trabalho das pessoas em equipe. Responsabilizando a equipe (Ônus/bônus do grupo nunca individual). Identificação dos gargalos do processo para solução dos mesmos.
3.	WHERE – Onde será feito
	Em cada área da empresa (TI, Comercial, Suporte, Administração).
4.	WHEN – Quando será feito
	O processo na realidade já começou, no momento que definimos o quadro kanban para desenvolvimento das rotinas (TI), (Maio/2014).
5.	WHO – Por quem será feito
	No início a responsabilidade da divulgação/convencimento dos colaboradores será do Marcus / Gustavo. Porém o objetivo é que à medida que forem aderindo à ideia, os próprios colaboradores terão esta responsabilidade.
6.	HOW – Como será feito
	a)      Mostrando / treinando aos colaboradores a utilização do kanban; b)      Pequenas reuniões de acompanhamento para esclarecimentos do processo.
7.	HOW MUCH – Quanto custará fazer
	Basicamente o custo será o tempo de treinamento dos colaboradores envolvidos no processo.

4.       Nivele os volumes de produção produzindo sempre próximo a uma quantidade média, para que se evitem assim os desperdícios e a sobrecarga de trabalho quando as demandas oscilaram;

5.       Construa uma cultura de parar e resolver a raiz do problema no exato momento da sua ocorrência, para que se tenha qualidade desde o início de cada etapa/operação do processo produtivo;

Trazer o testador para o processo de definição das funcionalidades do projeto, juntando analista, desenvolvedor e testador.
1.	WHAT – O que será feito.
	No momento de definição das funcionalidades do projeto, juntar o testador para a mesma.
2.	WHY – Por que será feito
	Diminuir o tempo gasto com teste e eventuais duvida que o testador possa vir a ter, bem como entregar o software de acordo com as especificações definidas pelo solicitante.
3.	WHERE – Onde será feito
	No departamento de TI.
4.	WHEN – Quando será feito
	A partir de Junho de 2014, conforme do novo contrato de desenvolvimento de sistema de gestão.
5.	WHO – Por quem será feito
	Pela equipe envolvida, TI e Suporte.
6.	HOW – Como será feito
	O testador (suporte) participará desde o principio da analise e definição do sistema, esclarecendo eventuais dúvidas e dando novas sugestões.
7.	HOW MUCH – Quanto custará fazer
	O custo será o tempo gasto do participante do teste.

6.       Padronize processos e tarefas, aumentando a segurança e autonomia dos colaboradores durante o dia-a-dia, constituindo assim a base para a sua melhoria contínua;

7.       Pratique os 5Ss e utilize controles visuais para que “Tudo” seja facilmente visualizado e compreendido por qualquer pessoa, sem que haja a necessidade de se fazer perguntas;

8.       Use somente tecnologias confiáveis e certamente eficazes em seus processos; A tecnologia dever ser puxada pela produção, e não empurrada pra ela;

Na área de TI estamos definindo ferramentas para administração do desenvolvimento projetos, controle de versão, testes confiáveis a serem utilizadas pelos desenvolvedores com propósito de qualificar os códigos, testes, agilizando o desenvolvimento, com qualidade.
1.	WHAT – O que será feito.
	Utilização de ferramentas padronizadas para todos os desenvolvedores (IDE, Framework e Controle de Versão).
2.	WHY – Por que será feito
	Diminuir o tempo de desenvolvimento dos projetos, de forma segura e com qualidade. Padronização dos códigos de forma que torne sua manutenção mais eficaz. Código fonte mais limpo e claro.
3.	WHERE – Onde será feito
	No Departamento de TI.
4.	WHEN – Quando será feito
	Este processo será iniciado a partir do mês de junho, utilizando o desenvolvimento do sistema (Gestão) conforme último contrato assinado pela empresa.
5.	WHO – Por quem será feito
	O processo será encabeçado pelo responsável da TI, junto com a sua equipe de desenvolvimento.
6.	HOW – Como será feito
	a)      Escolhendo ferramentas padrão; b)      Preparando novo ambiente de desenvolvimento; c)       Treinando os colaboradores envolvidos.
7.	HOW MUCH – Quanto custará fazer
	Será o tempo de treinamento dos colaboradores envolvidos no processo, bem como a compra de um novo servidor, e das licenças e das ferramentas utilizadas (caso haja necessidade).

9.       Faça com que seus líderes conheçam, compreendam e vivam essa filosofia ensinando e servindo de exemplo aos demais, pois só assim tais princípios se transformarão em cultura;

10.   Invista no desenvolvimento de seus colaboradores e forme pequenas equipes em todos os níveis, pois o sucesso é baseado no conjunto e não no indivíduo;

11.   Zele pelo relacionamento com seus fornecedores e parceiros como se fossem seus próprios colaboradores, oferecendo desafios e auxiliando-os no seu desenvolvimento;

12.   Vá e veja você mesmo para compreender por completo como funcionam os processos, pois só assim é possível mensurar o que deve ser melhorado;

13.   Tome decisões sem pressa, por consenso, considerando todas as opções possíveis e, assim feito, implemente-as rapidamente;

14.   Aprenda coisas novas todos os dias e faça auto-reflexões sobre suas dificuldades e falhas, buscando sempre fazer melhor e melhor sempre.