PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW

PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW from Matheus Costa

Apresentação - Metodologias Ágeis para Gestão e Planejamento de Projetos

Segue o material de apoio da apresentação do Grupo 4 - EquipeScrum que abordou em sala de aula as metodologias ágeis Scrum, XP e Kanban.
Estamos disponíveis para eventuais dúvidas que não foram sanadas em sala de aula.

Metodologias Ágeis para Gestão e Planejamento de Projetos Scrum - XP - Kanban from Matheus Costa

Scrum, XP ou Kanban ?

Estas três metodologias ágeis serão abordadas na próxima aula pelo grupo 4, responsável pelas postagens deste blog e utilizado na disciplina Gerência de Projetos ministrada pelo Dr. Rogério Patrício Chagas do Nascimento, na Universdidade Federal de Sergipe.

Esta postagem tem como objetivo referenciar uma postagem que sintetiza bem o que vamos apresentar na próxima aula abordando Scrum, XP e Kanban.

O material a seguir é de Dairton Bassi e foi utilizado no evento Agile Brazil 2013:
http://blog.andrefaria.com/agilebr-2013-entendendo-scrum-kanban-e-xp-por-dbassi

Cinco mitos sobre metodologias ágeis

Cultura continua a ser o principal motivo de muitos líderes de TI continuarem indiferentes em relação às metodologias ágeis

Em um artigo no blog "O Mundo depende de Software", da IBM Brasil, Sandra Santos, Gerente de Desenvolvimento da companhia, aponta os cinco principais mitos ainda encontrados nas organizações que estão buscando métodos Ágeis para melhorar sua capacidade de entrega de software e qualidade. São eles:

1. Agile é desenvolvimento bagunçado” “Ágil vai me ajudar a desenvolver mais rápido e “burlar” o processo”

Agile é uma maneira muito disciplinada de entregar software, muitas vezes mais disciplinada que os métodos tradicionais:

• Você tem que testar
• Você tem que obter feedback
• Você tem que enviar software regularmente
• Você tem que mudar e atualizar o plano
• Você tem que dar as más notícias cedo

2. Agile somente serve para desenvolvimentos e times pequenos

Agile pode se adaptar a qualquer tipo e tamanho de projeto:

• A maior parte dos times ágeis está geograficamente distribuída de alguma maneira;
• Organizações têm reportado sucesso em programas ágeis com mais de 500 pessoas;
• Um terço dos times ágeis enfrenta necessidade de atender a requisitos regulatórios;
• 75% das organizações executando projetos ágeis estão trabalhando em projetos com médio nível de complexidade e projetos maiores;
• 78% dos times estão trabalhando em sistemas legado (Source: DDJ November 2009 State of the IT Union Survey).

3. Agile requer muito retrabalho

Ao contrário de um desenvolvimento tradicional, Agile reduz o retrabalho, pois prevê ciclos de entregas mais curtos e coleta de feedback dos usuários mais cedo.

4. Agile é bala de prata

Agile não é a solução para tudo. Você pode falhar em um projeto Agile da mesma forma que pode falhar em um projeto tradicional. Mas você vai falhar mais rápido usando Agile (devido à transparência e visibilidade que a metodologia traz). Iinfelizmente não é uma bala de prata ou uma desculpa para parar de pensar.

5. Agile é anti-documentação

Documentação é necessária principalmente para atender compliance. É um guia valioso para ajudar as pessoas. No entanto, nunca esqueça que o objetivo principal de desenvolvimento de software é a criação de software, não de documentos. Elabore somente a documentação que forneça real valor. Toda informação estará disponível através das ferramentas.

É bom ter em mente também que as metodologias ágeis não são algo que o departamento de desenvolvimento adote simplesmente porque ser uma maneira interessante de escrever código. Elas proporcionam benefícios diretamente relacionados ao negócio.

Uma vantagem inegável do desenvolvimento é a adaptabilidade às mudanças. E ela vem sendo vem sendo a mola propulsora das metodologias de desenvolvimento Ágil em tempos de nuvem e tudo definido por software.

A importância da documentação funcional na Metodologia Ágil

O Problema

Você é chamado para ser o Analista Funcional de um sistema. Este sistema irá controlar um aparelho que emitirá radiação em pessoas que estão fazendo tratamento de câncer. A empresa utiliza a metodologia ágil para o desenvolvimento de software. Neste cenário, você estaria seguro em fazer a documentação do projeto durante o início de cada sprint?

E falando de um projeto mais simples, como um cadastro de cliente. A documentação produzida no início do sprint é a ideal? Tudo o que você documenta ou é produzido pela equipe durante o sprint realmente será utilizado?

“Por que” e “para quem” você cria o Documento?

Existem algumas perguntas sugeridas por Michael Nygard que ajudam a  criar a documentação do projeto: 

1. Quem será o consumidor da documentação?
2. O que eles precisam?
3. Como você vai entregar a eles?
4. Como você vai produzir?
5. De onde você irá tirar as informações para criar a documentação?

Com as respostas em mãos já é possível ter uma ideia mais clara do que é necessário criar.

Processo sugerido

De uma forma simplista, esta é a base do processo sugerido para criação do documento funcional dentro da metodologia ágil:

1. Backlog
   Antes de iniciar o processo de desenvolvimento, o Analista Funcional deve acompanhar o Dono do Produto (PO) ou o Analista de Negócios na criação do backlog do sistema, com todos seus critérios de aceite. A partir daí o Analista Funcional precisa entender o projeto como um todo, documentar este entendimento de uma forma superficial e apresentar ao time de desenvolvimento, tirando todas as dúvidas deste overview e nivelando o conhecimento entre todos. De uma forma resumida seria a apresentação das funcionalidades do sistema sem maiores detalhes. É com essas informações em mente que a base do sistema deveria ser arquitetada.
2. Documentação “Beta” do SprintA mensagem principal deste artigo está presente neste item: Quanto menor for a aceitação do sistema a erros, maior o tempo que deve ser gasto na criação da documentação. O Analista Funcional precisa andar, ao menos, de uma a duas interações a frente da equipe, a fim de criar uma documentação completa, madura, validada e, consequentemente, com menos probabilidade a erros. Quanto mais critico for o projeto mais interações a frente o Analista Funcional deveria ficar.
3. Alinhamento com Líder Técnico
   Após criar a documentação de um sprint, o alinhamento com o Líder Técnico precisa ocorrer com o propósito de antecipar possíveis imprevistos, como por exemplo alguma limitação técnica para o desenvolvimento de uma funcionalidade.
4. Validação da Documentação
   Com a documentação inicial criada e alinhada com o Líder Técnico, é hora de fazer a validação com o Dono do Produto, para que não exista impedimento no que diz respeito a regra de negócio. Feito isso, podemos considerar que temos uma documentação funcional pronta para um sprint.
5. Planning
   Na metodologia ágil, qualquer documentação que precisa ser criada (fora o backlog) deveria ser feita durante o planning. No processo sugerido, dentro desta etapa o time já teria toda documentação funcional em suas mãos e o planning serviria somente para entendimento da documentação entre o time e o PO.

Referência:

http://www.tiespecialistas.com.br/?s=documenta%C3%A7%C3%A3o+funcional

Entrevista sobre a aplicação do XP na LOCAWEB

                          

Olá pessoal, estou trazendo para vocês uma entrevista superinteressante sobre a utilização do método ágil XP na empresa LocaWeb.

A LocaWeb é uma empresa brasileira de hospedagem de sites, serviços de internet e computação em nuvem, líder no Brasil e na América Latina segundo pesquisa da International Data Corporation em 2011. A LocaWeb possui plataformas de lojas virtuais, um shopping online e um sistema de meios de pagamentos. Em novembro de 2012, a empresa adquiriu a Tray e-Commerce, plataforma de comércio eletrônico, a Eventials, plataforma de webinars e em 2013, comprou a All in Mail, empresa que gerencia um sistema de envio de e-mail para fins de marketing.

Quem tiver mais interesse sobre os serviços e produtos que esta empresa disponibiliza é só acessar o portal deles www.locaweb.com.br para mais detalhes.

Finalmente, segue o link da entrevista www.agileandart.com/2010/08/09/9-perguntas-e-respostas-sobre-metodos-ageis-na-locaweb/.

Gostaram ? ? Vlw, até a próxima.

Comparação entre RUP e XP

Metodologias para o desenvolvimento de software independente de seus processos específicos buscam reduzir riscos e aumentar a qualidade do produto gerado. As metodologias RUP e XP têm esse fim, pois apresentam mesmos valores como, envolvimento do cliente, iterações, testes contínuos e flexibilidade. Porém busca-se esses objetivos de forma diferente, através de implementações diferentes.

Segue alguma diferenças entre estas duas metodologias em relação a alocação de tempo e esforços, artefatos, atividades e papeis, ferramentas, responsabilidade do código e, diretivas do projeto:

Alocação de Tempo e Esforços 

RUP segue 4 fases sequenciais (Inception, Elaboration, Construction e Transition) constituindo um ciclo de desenvolvimento, produzindo uma nova versão de software. Em cada fase há um número de iterações, as quatro fases têm seu foco em diferentes atividades, podendo ocorrer em paralelo. A primeira fase, chamada de início foca o modelamento do negócio e a definição dos requisitos. A fase de elaboração foca em projetar (design), a de construção dá enfoque a implementação e aos testes e por fim a fase de transição onde a implantação e o gerenciamento de modificações são verificados. 

Já o aspecto tempo em XP é diretamente relacionado com código produzido. No começo do projeto o foco é o núcleo do sistema, e após facilidades extras. Porém como as liberações são definidas pelos clientes, os mesmos irão delimitar o tempo do projeto a partir de seu grau de satisfação com o software recebido. 

Artefatos

A comunicação dentro de um processo RUP é baseada em artefatos. Já em XP é baseada em comunicação oral, direta, o que restringe o uso de XP em projetos com grande distribuição geográfica. A pouca evidência de artefatos do XP, com foco em estórias de usuário e código, é visto como um fator que aumenta o risco do projeto, o conhecimento fica vinculado aos desenvolvedores e ao código. 

Atividades e Papéis

Ao compararmos as definições das atividades (disciplinas) e os papéis, temos que o RUP faz uma divisão de tarefas de forma específica, enquanto a divisão de papéis proposta pelo XP tem um caráter de “uso-geral”, sem atribuições específicas dentro das atividades. 

RUP define uma atividade como sendo o trabalho realizado por um papel, usando artefatos de entrada e produzindo artefatos de saída. Os papéis (total de 30) definem o comportamento e as responsabilidades do individuo, estão agrupados em nove disciplinas: Gerência de Projeto, Modelamento de Negócio, Requerimentos, Analise e Desenho, Implementação, Teste, Deployment, Configuração e Controle de Mudanças  e Ambiente. 

 O XP apresenta apenas quatro atividades básicas: produção de código, testes, listening (escutar o cliente), e desenho. E define sete papéis: Programador, Cliente, Testador, Tracker, Técnico, Consultor e  “Big Boss”. 

Ferramentas

O XP não especifica nenhuma ferramenta em específico para o processo, embora haja ferramentas livres como o XPlanner e o Junit. Já o processo no RUP utiliza softwares, como o Rational Rose, que devem ser adquiridos da própria IBM, juntamente com a documentação. 

Responsabilidade do Código 

RUP trata o código (geralmente de sistemas grandes) em subsistemas, e para cada subsistema existem membros responsáveis pelo mesmo. Já o XP trata o código como coletivo, qualquer programador que encontre algum problema, ou algum trecho que possa ser otimizado, tem permissão para fazê-lo. Isso pode agilizar o processo no caso de um programador necessitar corrigir algum módulo para interagir corretamente com o seu. Porém isso pode ser algo prejudicial, pois podem ocorrer casos onde o código aparentemente incorreto teve um motivo para ser estruturado da maneira que foi. 

Diretivas de Projeto

RUP é baseado em casos de uso, as descrições do uso do sistema são continuamente implementadas, integradas e testadas. Já o XP aplica o projeto baseado em teste, casos de teste são implementados antes da escrita do código. XP possui estórias de usuário para guiar o que deve ser implementado. Essas estórias são descrições mais simples se comparadas aos casos de uso do RUP. As duas metodologias indicam que o projeto completo não pode ser planejado em detalhe. RUP indica modificação continua dos planos, enquanto o XP propõe planejar em detalhes somente o futuro próximo. 

Referência: http://www.ppgia.pucpr.br/~alcides/Teaching/mestrado/FundamentosEngenhariaSoftware/artigos/ResumosApresentacoes/RUPvsXP_draft.pdf

Origem do Kanban

Entender a origem do surgimento dos príncipios do Kanban pode contribuir de forma significativa para quem pretende aplicar tal metodologia aplicada ao desenvolvimento de software.

Como descrito na última postagem introdutória, Kanban é uma palavra japonesa que significa “cartões coloridos” e foi criado na década de 1950, na fábrica automobilística da Toyota.

A técnica Kanban tem como premissa básica o conceito Just in time, que, resumidamente, corresponde ao conceito de eliminação de estoques através da requisição de quantidades exatas de materiais no momento exato de sua produção ou execução, conhecida como produção “puxada”. Ou seja, ter somente a quantidade de material necessária para a fabricação do que o cliente necessita. 

O documentário a seguir conta de forma bem completa como surgiu o conceito Just in time e Kanban. 

Tendo como base grande parte dos princípios do Manifesto para Desenvolvimento Ágil de Software, bem como a filosofia Lean do Sistema Toyota de Produção (TPS – Toyota Production System), surgiu o Kanban para Desenvolvimento de Software, que veremos com mais detalhes nas próximas postagens!

Referências: 

Kanban no desenvolvimento de projetos de software. Acessado em: 25 de fevereiro de 2016. Disponível em: <http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf> 

Como o Kanban pode ajudar sua empresa a reduzir custo. Acessado em: 25 de fevereiro de 2016. Disponível em: <http://www.sobreadministracao.com/como-o-kanban-pode-ajudar-sua-empresa-a-reduzir-custos/> 

Scrum, uma solução viável à sua empresa

O Scrum é um framework que faz parte do desenvolvimento ágil de projetos, possibilitando às empresas um retorno de investimento, muitas vezes, mais rápido do que nas metodologias convencionais. Isso o torna, à primeira vista, atrativo para as organizações que buscam alternativas rápidas e eficazes para atender tendências de mercado e ter a capacidade de responder às mudanças.

Um Time Scrum é formado por três papéis. O primeiro é o Product Owner (Dono do Produto), que define os itens que devem ser desenvolvidos para um projeto e tem autoridade, inclusive, em relação à alta gerência. O segundo papel é do Scrum Master, este age como mentor do Dono do Produto facilitando a priorização dos itens que serão desenvolvidos em um projeto auxiliando o Time de Desenvolvimento e difundindo o Scrum na empresa. Como terceiro papel, tem-se o Time de Desenvolvimento, composto de três a nove pessoas, também chamados de desenvolvedores, os quais possuem habilidades suficientes para completar o trabalho a eles destinado em um período, geralmente, de duas a quatro semanas, chamado de Sprint.

Mas afinal, quais os benefícios que uma equipe Scrum pode trazer para sua organização? Essa pergunta tem várias respostas, já que o Scrum pode ser aplicado em projetos dos mais variados tipos e tamanhos. Como exemplo, citamos uma empresa cujo foco é realizar uma campanha para acompanhar as tendências do mercado, ou, então, uma empresa com a necessidade de criar um produto de forma rápida e eficaz para seus clientes.

No framework Scrum, em cada Sprint, ou seja, em cada ciclo de trabalho, o serviço deve estar completo e pronto para ser implementado no mercado. No caso da primeira empresa, uma equipe de três a nove pessoas pode desenvolver uma campanha publicitária em poucas semanas, comprometendo-se com o trabalho e entregando ao solicitante a campanha desejada, sem romper, é claro, a interação com seu patrocinador (sponsor).

Já para a segunda empresa, tem-se a criação de um novo produto, a qual requer mais que quatro semanas de trabalho para a sua finalização. Neste caso, a empresa pode, a cada ciclo, entregar parte do produto a seus patrocinadores e ter dentro de poucos meses um produto completo e comercializável.

Apesar dos exemplos acima, cabe ressaltar que a abordagem deste artigo não é explicar detalhadamente o Scrum, mas sim apresentar duas possibilidades de trabalho para sua aplicação, através de equipes de trabalho auto- organizadas e auto- gerenciadas, de forma a propiciar, assim, um resultado de alto valor agregado para a empresa.

Neste framework, são envolvidos todos os stakeholders do projeto, ou seja, os executivos, a gerência e também o Time Scrum, o qual conta com o Dono do Produto (responsável pelos itens do produto), com o Scrum Master (responsável por facilitar a implantação do Scrum) e com a Equipe de Desenvolvimento (responsável pelo desenvolvimento do produto por completo).

Para a aplicação do Scrum, é importante que se tenha uma avaliação e um estudo de sua implantação em cada caso particular, já que há uma mudança cultural na forma de trabalho, o que exige adaptação dos colaboradores. Independe do tipo de projeto elaborado, o Scrum pode ser uma ferramenta extremamente útil à sua empresa, por trazer resultados completos e com alto valor agregado em um curto espaço de tempo.

Artigo publicado originalmente em TI Especialista 

Referência

http://www.tiespecialistas.com.br/2015/10/scrum-uma-solucao-viavel-a-sua-empresa/

SPRINT PLANNING MEETING

O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem aoSprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.

Referências

<http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm>

<http://www.desenvolvimentoagil.com.br/scrum/sprint_planning_meeting>

Práticas em XP

     O objetivo principal do XP é levar ao extremo as práticas que são ditas como boas na engenharia de software. Estas práticas estão diretamente ligadas aos valores (comunicação, simplicidade, feedback e coragem) da metodologia. Estarei trazendo agora para vocês estas práticas e uma breve explicação de cada uma.

Versões Pequenas: Release é algo que é implantado no cliente, ou seja, está pronto para ser utilizado. As Releases normalmente são pequenas e frequentes (a cada 2-3 meses) sendo que funcionalidades prioritárias são desenvolvidas mais cedo para serem entregues mais rapidamente ao cliente, pois prioriza-se o que ele mais precisa no momento. Obviamente que algumas organizações não querem essas entregas frequentes e pequenas, pois precisam dar treinamentos antes do sistema ser entregue e isso leva um certo tempo ou então não faz parte da cultura organizacional. Nesse caso, se a organização não seguir isso não está seguindo realmente o que mandam as metodologias ágeis como o XP.

Jogo do Planejamento: Seu objetivo é determinar rapidamente o escopo da próxima Release, combinando prioridades do negócio e estimativas técnicas. Portanto no XP planejamos o tempo todo, diferente do que alguns pensam. Com um cliente presente ele define o escopo para a próxima Release. Dessa forma, define-se as features, prioridades e o escopo da release

Teste: A prática de teste no XP é bastante técnica, e envolve a presença do cliente no desenvolvimento e na validação de testes. O cliente compartilha com o desenvolvedor sobre o funcionamento do sistema. Os testes também se tornam as especificações da programação, visto que o teste diz o que deve estar de acordo e o que não deve estar de acordo, é como uma especificação.Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas. Dessa forma, o teste impõem também confiança ao sistema e dão coragem para altera-lo, pois podemos saber imediatamente se algo introduziu um bug no sistema.

Programação em pares: Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica, e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.

Projeto Simples: Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.

O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.

Refatoração: A refatoração significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos.

Propriedade Coletiva: Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.

Integração Contínua: Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.

Cliente presente: Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações.

Semana de 40 horas: O XP preconiza que não se pode trabalhar horas extras por mais de uma semana, pois trabalho extra é sintoma de que algo está errado. Devemos manter um ritmo sustentável.

Padrões de Codificação: Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no início dos projetos.

Referências: http://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

Kanban: INTRODUÇÃO

Metodologias ágeis mais populares como Scrum e XP, surgiram com a proposta de melhorar e agilizar os processos envolvidos no desenvolvimento de software. Porém, no mundo real fica claro que os processos ainda não estão “perfeitos”. Mas o que fazer então, sendo que essas ferramentas estão, teoricamente, maduras e eficientes no que se propõe? Como identificar onde estão os “gargalos” que fazem as equipes falharem nos seus sprints? Podemos dizer com que o Kanban pode ajudar a identificar essas falhas e solucioná-las.

O método Kanban para desenvolvimento de software e processos ágeis tem como ênfase não sobrecarregar os membros que compõe a equipe de criação do produto e tem princípios básicos como: a equipe ou membro deve iniciar uma nova tarefa quando é capaz de realizá-la agora, a equipe deve aceitar mudanças incrementais e evolutivas estimuladas pelo método Kanban e respeitar os atuais processos, papéis e responsabilidades.

O Kanban não é um processo e nem descreve papeis e faces para serem seguidos. Podemos dizer que o Kanban é uma abordagem para mudança gerencial do projeto, um conceito para introduzir alterações em um ciclo de desenvolvimento de software ou gerenciamento de projetos.

O nome Kanban é de origem japonesa e sua tradução seria como “sinal” ou “cartão”. Portanto, vamos chamar de sinalizador ou melhor “registro visual”. O nome Kanban surgiu dos sistemas de cartão usados nas indústrias de produção, que tinham como finalidade o gerenciamento do fluxo de trabalho através da organização de desenvolvimento.

O Kanban, com seu mecanismo de sinalização, tem como objetivo apresentar uma atividade de trabalho em processo, ou seja, o número de atividades ou cartões em circulação é equivalente à capacidade do sistema.

A implementação do modelo Kanban se resume em três etapas que são:

• Visualizar os processos;
• Limitar o trabalho em processo do inglês WIP (work in progress);
• Gerenciamento do lead-time, ou seja, tempo que a atividade leva para passar por todas as fases até a sua entrega.

Continua no próximo post!

Referência:http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf  . Acessado em 16 de fevereiro de 2016.

O XP sendo aplicado

Olá pessoal, encontrei esse vídeo super legal sobre o XP. Nele vocês poderão perceber, por meio de uma peça teatral, como este método é aplicado nas empresas desenvolvedoras de softwares.

Os Valores e Princípios do Extreme Programming

    Como citado a alguns posts atrás, o Extreme Programming (XP) é um processo de desenvolvimento de software que adota os valores e princípios. Irei agora trazer agora o detalhamento de cada valor e principio deste método ágil.

VALORES

Comunicação: XP foca em construir um entendimento pessoa-a-pessoa do problema, com o uso mínimo de documentação formal e com o uso máximo de interação “cara -a-cara” entre as pessoas envolvidas no projeto. As práticas de XP como programação em pares, testes e comunicação com o cliente têm o objetivo de estimular a comunicação entre gerentes, programadores e clientes. 

Simplicidade: XP sugere que cada membro da equipe adote a solução mais fácil que possa funcionar. O objetivo é fazer aquilo que é mais simples hoje e criar um ambiente em que o custo de mudanças no futuro seja baixo. O objetivo dessa abordagem adotada por XP é evitar a construção antecipada de funcionalidades, como é feita em muitas metodologias tradicionais, que acabam muitas vezes nem sendo usadas. 

Feedback: Os programadores obtêm feedback sobre a lógica dos programas escrevendo e executando casos de teste. Os clientes obtêm feedback através dos testes funcionais criados para todas as estórias (casos de uso simplificados). O feedback é importante, pois possibilita que as pessoas aprendam cada vez mais sobre o sistema e assim corrijam os erros e melhorem o sistema. 

Coragem: Ela é necessária para que realmente se aplique XP como deve ser aplicado. Exemplos de atitude que exigem coragem são: alterar código já escrito e que está funcionando; jogar código fora e reescrever tudo de novo; e permitir código compartilhado por todos. Estes exemplos de atitudes podem ser necessários para trazer melhorias ao projeto e não devem ser evitadas simplesmente devido ao medo de tentá- las. 

PRINCÍPIOS

Feedback rápido: A idéia de XP é que os participantes de um projeto como clientes, programadores e gerentes devem estar sempre se comunicando para facilitar o aprendizado coletivo sobre o projeto que está sendo desenvolvido e de alertar rapidamente sobre dúvidas, riscos e problemas para facilitar eventuais ações de contingência. 

Assumir simplicidade: Todo problema deve ser tratado para ser resolvido da forma mais simples possível. XP afirma que se deve fazer um bom trabalho (testes, refactoring, comunicação) para resolver hoje os problemas de hoje e confiar na sua habilidade de adicionar complexidade no futuro quando for necessário. 

Mudança incremental: Quando muitas mudanças são realizadas todas de uma vez, não se obtém um bom resultado. Em vez disso, esse princípio de XP diz que as mudanças devem ser incrementais e feitas aos poucos. Os programadores têm a liberdade para estar sempre fazendo alterações de melhoria no código e as mudanças de requisitos são incorporadas de forma incremental. 

Abraçando mudanças (Embracing Change): XP procura facilitar o ato de incluir alterações através do uso de vários princípios e práticas. A idéia de XP é a de que mudanças devem ser sempre bem vindas independentemente do estágio de evolução do projeto. Isso é muito benéfico em projetos cujos requisitos são bastante voláteis devido aos clientes não saberem o que querem. 

Trabalho de qualidade: Em XP, qualidade não é um critério opcional, mas sim obrigatório. Embora a definição de qualidade possa variar de pessoa para pessoa, XP trata qualidade no sentido de se ter um sistema que atenda aos requisitos do cliente, que rode 100% dos casos de teste e que agregue o maior valor possível para o negócio do cliente.

Referências

http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf

O que é o Product Backlog?

Product Backlog

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

Referências:

<http://www.desenvolvimentoagil.com.br/scrum/product_backlog>

<http://scrumex.com.br/blog/?p=1091>

Scrum - Aprenda Scrum em 9 minutos

Reuniões Diárias - Daily Scrum

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

• O que você fez ontem?
• O que você fará hoje?
• Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.

O que é o Scrum Master?

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

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador nas reuniões diárias e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.

No Scrum, os projetos são divididos 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.

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. Veja a ilustração abaixo: