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