A expressão software factory – fábrica de software em inglês – foi usada pela primeira vez na década de 60. Popularizada apenas nos anos 90, define basicamente a ideia de aplicar conceitos da indústria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos, tornando o processo mais independente do fator humano.

Apesar da expressão ‘fábrica’, o processo de criação de uma ferramenta é bem complexo. A fábrica de software cria um produto sob medida para cada cliente e utiliza em suas operações indicadores de qualidade e de produtividade em cada etapa do ciclo de desenvolvimento.

Alguns fatores contribuíram para o crescimento deste serviço, que surgiu para atender novas necessidades do mercado de TI. Entre estes estão a consolidação das técnicas de engenharia de software, o refinamento dos ambientes de desenvolvimento, a alta competitividade do mercado, o aumento da demanda por software e a tendência à terceirização de serviços.

Grandes empresas de TI têm suas próprias fábricas de software, no entanto o mais comum é que este serviço seja terceirizado. Com um mercado consumidor de TI cada vez mais exigente quanto aos aspectos de produtividade, custo e qualidade, as organizações fornecedoras têm procurado se transformar buscando um novo modelo, que supra com eficiência estas necessidades.

Entre os serviços prestados por uma fábrica de software estão o desenvolvimento de sistemas ou módulos, integração de aplicativos, manutenção de programas, incorporação de novas tecnologias, conversão de aplicativos para ambiente web, melhorias de performance e desenvolvimento de web services.

Como é a fábrica que realiza todo o processo, a empresa não precisa se preocupar com infraestrutura, nem de software e nem de hardware, não é necessário disponibilizar espaço e nem profissionais para realizar o serviço, o investimento é pré-definido, portanto não há custos extras ao longo do projeto, e tudo isso com o estabelecimento de um prazo de entrega. Esse é o grande diferencial da fábrica, o cliente não se preocupa com a gestão, apenas solicita o software.

Cada empresa tem uma necessidade específica, mas muitos processos são semelhantes. Por isso, uma fábrica que tenha diversos objetos que possam ser montados de acordo com as particularidades de cada empresa consegue entregar o pedido com maior rapidez. Além disso, como cada componente já foi testado diversas vezes, o resultado é em um produto final com melhor qualidade e custo reduzido.

Para ter um funcionamento adequado, há a necessidade de dividir a fábrica em alguns setores: de atendimento aos clientes, que negocia e especifica as necessidades da área usuária; de planejamento e controle da produção, que faz a alocação dos recursos, estabelece os prazos de desenvolvimento e a definição dos objetos a serem utilizados ou desenvolvidos; de produção, que faz a montagem da aplicação; e de qualidade e garantia, que verifica se o produto final atende as especificações exigidas.

Além de ter esses setores funcionando em conformidade é fundamental para o sucesso de uma fábrica de software é o gerenciamento dos recursos humanos e metodologia de trabalho.

Hoje tive esse erro depois de mudar a hora do servidor do TFS:

TF54000: Cannot update data because the server clock may have been set incorrectly. Contact your Team Foundation Server Administrator.

Aconteceu isso porque ele criou alguns changesets que ficaram com a data depois da data do computador.

Para resolver não foi o mais recomendado(Leia-se:  faça um backup antes) ,mas:
delete from tbl_Changeset where CreationDate > getdate()

O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de “controle”. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de “receita de bolo” do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto.

Planejamento de sprint

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum simplificado

Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível (“stealth”), usando os três passos:

• Agende uma demonstração do software com seu cliente em um mês a partir de agora;
• Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
• Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.

Algumas características de Scrum

• Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
• Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
• Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
• Discussões diárias de status com a equipe;
• A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
  • O que fiz desde ontem?
  • O que estou planejando fazer até amanhã?
  • Existe algo me impedindo de atingir minha meta?
• Transparência no planejamento e desenvolvimento;
• Reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
• Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
• Locais e horas de trabalho devem ser energizadas, no sentido de que “trabalhar horas extras” não necessariamente significa “produzir mais”.

Agendando discussões diárias

Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes estão focadas no trabalho e não em questões pessoais.

Scrum Solo

Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

Para criar um sistema em equipe há a necessidade de realizar controles de versões no código fonte. Para isso a utilização do TFS (Team Foundation Server) é muito útil! Aqui explicarei como realizar a instalção do pluguin para a uitilização dele com o Eclipse (Helios).

Primeiramente é necessário realizar o download do arquivo TFSEclipsePlugin-UpdateSiteArchive-10.0.0 no site do TFS, para isso clique aqui.

Após fazer o download, NÃO descompacte-o. Abra o Eclipse e depois vá no menu Help e depois em Software Updates, conforme figura abaixo:

Após clicar no menu, conforme indicado anteriormente, abrirá a tela:

Então, clique em Add Site no lado direito da tela (conforme figura abaixo):

Assim que clicar aparecerá a tela para adicionar o arquivo ou o link. No caso, será o arquivo que baixamos no site do TFS, então o botão ARCHIVE será clicado.

Agora, escolha o arquivo na lista, conforme figura. No caso, coloquei na Área de Trabalho.

Após ter escolhido o arquivo e clicado em Abrir, então aparecerá o plugin do TFS para o Eclipse e pedirá para ser instalado. A figura abaixo mostrará como aparecerá.

Selecione o pluguin na raiz da árvore e depois clique em Install no canto superior direito. Aguarde um pouco e logo em seguida aparecerá a tela abaixo.

Clique em Next e depois aceite os termos e clique em FINISH. A figura abaixo representa como realizar tal procedimento.

Então será necessário reiniciar o Eclipse, assim que clicar em Finish a tela abaixo, pedira para o Eclipse ser reiniciado, então clique em YES.

Ao reiniciar o Eclipse, vamos trocar a Perspectiva do mesmo, para isso siga os passos abaixo:

Então, na próxima tela escolha o Team Foundation Server Exploring e clique em Ok.

Ao clicar em Ok, o Eclipse automaticamente levará a perspectiva para o Team Explorer. Então, vamos configurar para acessar o Servidor TFS. Para isso, na guia do Team Explorer clique no Add Existing Team Project. Conforme figura.

Ao clicar no Add, a tela de configurações será exibida, então faça as configurações adicionando o nome do servidor, porta, usuário e senha, pois o TFS já estará funcionando.

A prototipação evolutiva é utilizada em protótipos que evoluirão até tornarem-se sistemas finais.

Neste método, rapidamente é desenvolvido um protótipo que será modificado até que se obtenha o sistema final. Para que sejam feitas as modificações e o protótipo transforme-se em software, começa-se a construção deste protótipo com os requisitos fundamentais e que estejam bem definidos e é necessário o acompanhamento do usuário, para que juntamente com ele o desenvolvedor possa definir os requisitos do sistema.

Contrastando com a prototipação Throw-Away, um documento de requisitos detalhado não é elaborado, visto que a prototipação evolutiva é um método redutor de custo e de tempo.

Há algumas vantagens e desvantagem ao usar a prototipação evolutiva, que precisam ser conhecidas pelos desenvolvedores antes de adotar este método.

·Vantagens: Rápida entrega do sistema; compromisso do usuário com o sistema; especificação, desenho e implementação interligados; sistema desenvolvido como uma série de incrementos ao usuário;

·Desvantagens: Alguns requisitos não aparecem na especificação; requisitos não funcionais não são testados de forma adequada; documento de requisitos inexistente ou não detalhado; difícil manutenção; em alguns casos difícil gestão;

A longo prazo, podem ocorrer problemas de manutenção e evolução do sistema, por falta de uma estrutura sólida no seu desenvolvimento, isto pode causar o curto tempo de vida do sistema, visto que só os especialistas que o desenvolveram poderão efetuar a manutenção ou a evolução com facilidade.

Quando se utiliza a prototipação evolutiva se torna difícil a elaboração de um contrato entre desenvolvedores e clientes, pois estes contratos geralmente têm por base o documento de requisitos.

Para a obtenção de um bom sistema não se deve basear em protótipos feitos para responder questões especificas, mas desenvolver um protótipo com a finalidade de futuramente transformá-lo em um sistema.

O protótipo evolutivo pode se transformar em um sistema robusto, desde que, seja elaborado um planejamento e um desenvolvimento bem estruturado, com muito cuidado desde o início do projeto.

Este método de prototipação é utilizado para encontrar problemas de requisitos em protótipos, e tem como objetivo consistir uma maior qualidade, por meio da validação e definição no documento de requisitos do software.

Ele tem como base os requisitos que não estão bem definidos, e os que já estão bem definidos dificilmente são utilizados no protótipo. Ao construir um protótipo pelo método Throw-Away, os seguintes passos são seguidos: desenvolve-se um documento de requisitos provisório, obtêm-se opiniões dos usuários e reformula-se o documento de requisitos, repetem-se estes passos, até a obtenção de satisfação dos usuários e, consequentemente, a finalização do documento de requisitos.

Depois da finalização do documento de requisitos, o protótipo já não é mais necessário e então é abandonado, para que se inicie o processo de desenvolvimento do software, o que acarreta em um gasto de tempo um pouco maior e na elevação do custo.