RESUMO
O sucesso das metodologias ágeis em lidar com ambientes extremamente complexos
(exemplo: ambiente de desenvolviment...
SUMÁRIO
1. INTRODUÇÃO 1
2. UMA VISÃO GERAL SOBRE AS METODOLOGIAS ÁGEIS 1
CAPÍTULO 1. INTRODUÇÃO
A ideia para esse projeto, inicialmente nasceu da vontade e necessidade de criação de
um processo d...
CAPÍTULO 2. UMA VISÃO SOBRE AS MÉTODOLOGIAS ÁGEIS
2.1. Metodologias Tradicionais
A “Crise do Software” (1970), ocasionada ...
Programming (XP) e outros, cada um com as suas particularidades, todos concordavam
que, em suas experiências prévias, um p...
de hoje.
2.2.3. 12 Princípios Ágeis
Para melhor compreensão a Agile Alliance descreveu 12 princípios:
● Nossa maior priori...
metodologia ágil para equipes pequenas e médias e que irão desenvolver software com
requisitos vagos e em constante mudanç...
CAPÍTULO 3. PROCESSO DE DOCUMENTAÇÃO DE SOFTWARE
3.1. Porque documentar?
Antes de discutirmos sobre documentação ágil, sob...
de documentação. Mas, devemos analisar: para documentar, as pessoas gastam tempo;
e, consequentemente dinheiro. Não sabemo...
Formato digital ou impresso? Padrão fechado ou aberto? Manutenção centralizada ou
compartilhada? O que levar e consideraçã...
encontrar um equilíbrio nos comentários e permitir que de alguma forma estes
comentários possam ser ancorados a documentaç...
Não vou discutir sobre se devemos ou não documentar, pois no capitulo anterior vimos
a importância e o que levar em consid...
Mais uma vez reforço, cada projeto é um projeto distinto, a ideia é apenas nos fazer
pensar em o que vamos levar em consid...
que os leitores possam tentender;
● Tornar o documento compreensível, fornecendo exemplos do cotidiano dos
próprios leitor...
● A necessidade de documentação para um próximo estágio (Ex.: uma
manutenção futura);
● A necessidade de documentação para...
4.2.5. Evite informação perecível
Sabemos que principalmente em um projeto de software, tudo é muito dinâmico, a
tecnologi...
É importante documentar o design que está sendo adotado e utilizado pelo projeto de
software, pois este documento servirá ...
4.2.10. Utilize exemplos reais
Muitas pessoas tem dificuldade em entender material técnico, até porque em sua
maioria eles...
4.3.1. Apresente a informação de maneira estruturada
A documentação pode ser para diversos propósitos, dependendo do leito...
módulos, lista de funcionalidades, lista de erros etc. Essa informação sistemática são
frequentes em documentação, entreta...
espécie de sumário ou resumo; ou Você pode escolher alguns parágrafos de cada seção,
não necessariamente do inicio, e usa-...
Não me estenderei, apenas as citarei e caso sintam a necessidade de aprofundar, o livro
do Andreas é uma excelente leitura...
com menos de 2 linhas e quebra de página dentro de células de uma tabela.
4.4.2. Infraestrutura e organização técnica
● Do...
separado, para facilitar mudanças e reutilização do layout.
● Utilize sempre uma única fonte para múltiplos documentos, qu...
CAPÍTULO 5. CONCLUSÃO
Como dito no inicio deste trabalho, a ideia, em momento nenhum é apresentar um
receita de bolo para ...
BECK, Kent. Programação Extrema (XP) explicada. Porto Alegre: Bookman, 2004.
COCKBURN, Alistair. Crystal Clear: A Human-Po...
Próximos SlideShares
Carregando em…5
×

Rascunho TCC

315 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
315
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Rascunho TCC

  1. 1. RESUMO O sucesso das metodologias ágeis em lidar com ambientes extremamente complexos (exemplo: ambiente de desenvolvimento de software), ou seja, projetos dinâmicos, de constantes de mudanças e sem requisitos claros, ou até mesmo desconhecidos. Tem atraído muitas empresas e suas respectivas equipes a buscarem nestas metodologias um padrão para seu processo. Porém as metodologias se baseiam em uma manifesto, manifesto esse que não prescreve um processo ou o uso de ferramentas, mas sim um conjunto de ideias do que é realmente importante e traz valor no processo desenvolvimento. Em outras palavras o que realmente merece nossa atenção. E por não ser prescritivo não diz o que, nem como fazer, permitindo assim, a empresa/equipe contextualizar e aplicar as ideias de acordo com a sua cultura e seu processo. Uma dessas ideias, ideia da qual eu gostaria de trazer à discussão é de que “software em funcionamento tem mais importância que documentação abrangente”. Talvez esta seja a ideia mais controversa e menos debatida nos grupos de discussões ágeis, até pela força de vontade na interpretação do conceito por traz da ideia. O processo documentação não perdeu espaço, a documentação não perdeu seu valor, mas de que adianta uma pilha de papéis se meu software não funciona, se minha equipe não lê e se ele não está atualizado e sequer o cliente sabe que existe. Então a questão não é deixar de documentar, mas sim descobrir por quê, o quê e como documentamos. Para otimizar os recursos, agregar valor ao projeto e da suporte a todos que necessitam precisamos primeiro responder a estas perguntas, e pretendo fazer isto durante este trabalho.
  2. 2. SUMÁRIO 1. INTRODUÇÃO 1 2. UMA VISÃO GERAL SOBRE AS METODOLOGIAS ÁGEIS 1
  3. 3. CAPÍTULO 1. INTRODUÇÃO A ideia para esse projeto, inicialmente nasceu da vontade e necessidade de criação de um processo de documentação, hoje inexistente, na empresa do qual hoje sou coordenador, mas a pergunta por que, o que e como documentar são sempre perguntas que surgem e acabam sempre no “limbo” não permitindo o avanço do projeto. Em busca de resposta percebi que assim como eu, muitos se perguntam a mesma coisa, e pouco tem se discutido, se debatido e se documentado. Sendo assim resolvi trazer este assunto à discussão para ajudar na busca de muitos por um processo de documentação realmente ágil. Cada pessoa da empresa e do time tem uma perspectiva sobre por que, o que e como documentar; e isso atrapalha na hora de saber se realmente determinada informação é importante e/ou traz valor para o projeto. Com isso muitos projetos exageram e acabam pecando pela falta ou o excesso de documentação. O principal objetivo deste estudo é responder a estas três perguntas e ajudar a quem precisa desenvolver um processo de documentação realmente ágil, visando sempre uma documentação clara e objetiva, focando sempre nos leitores alvo e usando as ferramentas necessárias para otimizar e distribuir a informação, para assim evitar uma sobrecarga de informação desnecessária e que não traz valor nenhum ao projeto. Cada projeto é um projeto, sendo assim, as necessidades, requisitos e variáveis também mudam. Portanto não tenho a pretensão de desenhar um processo e muito menos achar que o mesmo servirá para todo tipo de projeto. Meu desejo é simplesmente dar algumas respostas que realmente acho importantes, trazer alguns pontos que devem e precisam ser observados e dar algumas dicas de ferramentas que podem auxilia-lo na elaboração e desenvolvimento de um processo de documentação específico para seu projeto. Espero que as informações pesquisadas, estudadas e dispostas aqui possam trazer uma nova maneira de enxergar o processo de documentação. Não como algo desnecessário, custoso e sem valor, mas sim como algo que pode agregar valor ao projeto, melhorar a comunicação da equipe e também poupar a todos de muitos problemas futuros causados por falta de informação documentada no projeto. Vamos entender um pouco sobre as métodologias ágeis, seus princípios, vamos buscar saber por que documentamos, para só então, tentar chegar numa conclusão do que seria uma documentação ágil e traçar algumas características que descrevem este tipo de documentação.
  4. 4. CAPÍTULO 2. UMA VISÃO SOBRE AS MÉTODOLOGIAS ÁGEIS 2.1. Metodologias Tradicionais A “Crise do Software” (1970), ocasionada pelo exponencial crescimento da demanda, da complexidade do software e total inexistência de técnicas e padrões de desenvolvimento, forçou as empresas desenvolvedoras de software buscarem realizar, muitas metodologias surgiram, linguagens foram criadas para modelar e facilitar o entendimento do produto pelo cliente e pela própria empresa desenvolvedora. Algumas destas metodologias que surgiram desta “crise”, metodologias estas cunhadas como tradicionais, são: Modelo Cascata (uma das mais utilizadas até duas década atras), Modelo Espiral e o Modelo Interativo e Incremental (a mais utilizada nos dias de hoje) etc.. O Modelo Cascata, bastante inflexível, era sequencial e não permitia alterações durante o projeto, o que em projetos de longa duração, fazia com que projetos já nascecem obsoletos e diferentes do planejado pelo cliente. O Modelo Espiral que apesar de sequencial, e diferente do Modelo Cascata, era dividido em versões chamadas de incrementos, assim torna mais fácil lidar com as mudanças e as validações do que está sendo desenvolvido é melhor para o cliente. Mas assim como no desenvolvimento em cascata não permitia desenvolvimento paralelo e a comunicação entre todas as etapas do projeto. Já o Modelo Iterativo e Incremental, o mais parecido com os Métodos Ágeis, apresenta um ciclo de vida iterativo baseado no aumento e no refinamento sucessivo de um sistema através de múltiplos ciclos de desenvolvimento de análise, de projeto, de implementação e de teste (LARMAN, 2000). Apresenta alguns benefícios como: ● A redução de riscos com os custos e prazos planejados; ● A equipe fica focada com os objetivos de cada incremento, trabalhando de maneira mais eficiente; 2.2 Metodologias Ágeis 2.2.1. História Com o passar dos anos as organizações passaram a focar resultados rápidos e precisos, e principalmente flexível a mudanças, foi então nesse contexto, que as Metodologias ageis ganharam força e estão crescendo vertiginosamente em todo o mundo. O termo “Metodologias Ágeis” tornou-se popular em 2001 quando um grupo de dezessete especialistas em processos de desenvolvimento de software decidiu se reunir nos EUA, para discutir maneiras de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, utilizando métodos como Scrum, Extreme
  5. 5. Programming (XP) e outros, cada um com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Foi então criada a Aliança Ágil e estabelecido o Manifesto Ágil contento os conceitos e princípios comuns compartilhados por todos esses métodos. Desde então o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes conceitos: ● Indivíduos e interação mais que processos e ferramentas; ● Software em funcionamento mais que documentação abrangente; ● Colaboração com o cliente mais que negociação de contratos; ● Responder a mudanças mais que seguir um plano. O Manifesto Ágil não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, ele coloca que: “mesmo havendo valor nos itens da direita, eles valorizam mais os itens a esquerda”. 2.2.2. Manifesto Ágil É importante observar que o Manifesto Ágil, não impõe, mas apenas define preferências e encoraja a focar certos conceitos sem deixar esquecer os outros. Assim sendo, se desejamos seguir os conceitos ágeis, precisamos entender e valorizar mais algumas coisas dos que outras. ● Indivíduos e interação mais que processos e ferramentas; ○ Precisamos priorizar quem é realmente responsável pelo desenvolvimento do projeto. Priorizar a interação para que os erros sejam minimizados e todos tenham o completo entendimento do objetivo do projeto e objetivo de cada um que compõe a equipe. A comunição é fundamental em uma EQUIPE. ● Software em funcionamento mais que documentação abrangente; ○ A documentação é importante, ajuda a entender um projeto durante sua execução, além de ajudar nas futuras manutenções, mas de que adianta te-la se seu software não funciona. De que adianta o manual de um equipamento que não é utilizado. ● Colaboração com o cliente mais que negociação de contratos; ○ O contrato é importante, principalmente para definir direitos e deveres de ambas as partes, mas de que adianta seguir a risca um contrato e no final do projeto ter a instisfação do cliente e entregar um software que não atende as expectativas e anceios daquele que patrocinou todo o projeto. ● Responder a mudanças mais que seguir um plano. ○ Vivemos em um mundo que muda o tempo todo. A todo tempo, leis são criadas e modificadas, novas descobertas são realizadas e novos concorrentes surgem. Estar atento a estas mudanças, se preparar para elas e responde-las num tempo curto é primordial para sobrevivência nos dias
  6. 6. de hoje. 2.2.3. 12 Princípios Ágeis Para melhor compreensão a Agile Alliance descreveu 12 princípios: ● Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. ● Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. ● Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos. ● Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto. ● Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. ● O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. ● Software funcional é a medida primária de progresso. ● Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. ● Contínua atenção à excelência técnica e bom design, aumenta a agilidade. ● Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. ● As melhores arquiteturas, requisitos e designs emergem de times auto- organizáveis. ● Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. 2.2.4. Exemplos de Métodologias Ágeis Os métodos ágeis caracterizam-se pelo seu caráter adaptativo e orientado para pessoas. São várias as metodologias que são classificadas como ágeis, em que se destacam o XP (Extreme Programming) e Scrum. 2.2.4.1 XP - eXtreme Programming Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma
  7. 7. metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. 2.2.4.1 Scrum Scrum possui seu foco no gerenciamento de projeto da organização onde é dificil planejar à frente. Mecanismos do Controle de Processo Empírico, onde ciclos de feedback constituem o núcleo da técnica de gerenciamento que são usadas em oposição ao tradicional gerenciamento de comando e controle. É uma forma de planejar e gerenciar projetos trazendo a autoridade da tomada de decisão a níveis de propriedade de operação e certeza. Entender os princípios e o valor que o manifesto está querendo nos passar é importântissímos, quando o assunto é agilidade. Entender o conceito é o primeiro passo para tornar qualquer processo ágil, e como este estudo visa entender e aplicar um pouco deste conceito no processo de documentação. Nada como saber o que é agilidade para tornar algo ágil.
  8. 8. CAPÍTULO 3. PROCESSO DE DOCUMENTAÇÃO DE SOFTWARE 3.1. Porque documentar? Antes de discutirmos sobre documentação ágil, sobre como e o que vamos documentar, precisamos nos perguntar por que documentamos. Por que necessitamos registrar algumas informações, sejam elas do projeto, do software ou até mesmo do ambiente que está acontecendo o desenvolvimento do software. Muitos ligam a documentação a qualidade do projeto e consequentemente a qualidade do produto, ou seja, uma documentação completa e detalhada reflete um software de alta qualidade. Mas acredito que essa não é uma verdade absoluta, na verdade acredito que nem mesmo seja verdade essa afirmação. Acredito que um software de alta qualidade se completa com uma documentação clara e objetiva, pelo simples motivo de que tendo informação sobre determinado produto, além de você utiliza-lo de maneira correta, você ainda pode aproveitar melhor todos os seus recursos. Observo que documentamos principalmente pela própria natureza do software, que tem como caracteristicas predominantes: ● Alta complexidade, envolve diversas tecnologias; ● Envolvimento de diversas pessoas no desenvolvimento; ● Poder atender a necessidades distintas; ● Constante evolução, sempre se atualizando as novas necessidade; ● Utilizado por diversos tipos de pessoas, pessoas que não necessariamente são especialistas em tecnologia; etc. E quando documentamos, fazemos para: ● Registrar informação do projeto e produto; ● Comunicar mudanças e alterações; ● Mostrar a maneira correta de instalar, utilizar e manter o sistema. Segundo Michelazzo (2006), a documentação pode ser dividida em dois grandes grupos, a documentação Técnica, voltada para os desenvolvedores, para aqueles que estão ligados diretamente a o desenvolvimento do produto; e a documentação de Uso voltada para o usuário final e os responsáveis por administrar o produto. Analisando estes dois grandes grupos afirmo que documentamos para garantir duas coisas principais: ● O futuro do sistema (Documentação Técnica): ou seja, para que ele possa ser ampliado e mantido com segurança; ● O uso do sistema (Documentação de Uso): ou seja, para que os usuários tenham suporte para a sua utilização. Assim, fica fácil perceber que há um motivo muito forte e justo para existir o processo
  9. 9. de documentação. Mas, devemos analisar: para documentar, as pessoas gastam tempo; e, consequentemente dinheiro. Não sabemos o custo de documentação, mas o bom senso e a experiência indicam que, se os documentos exigidos forem extensos e com alto grau de detalhamento, eles absorverão uma boa parcela do orçamento do projeto. E por isso cabe o bom senso na hora de documentar e, logo aparece outra pergunta: o que documentar? 3.2. O que documentar? Como já dito no inicio deste trabalho, cada projeto e cada sistema são únicos e cada um possui seus requisitos, ou seja, necessidades. Por isso, para saber o que vamos documentar não há receita de bolo, mas sabemos de acordo com cada projeto o que precisará ser registrado para que futuramente possa ser dado manutenção ao software e que os usuários do sistema precisarão saber para utilizar o software que está sendo desenvolvido. Mas não esqueça, documentar apenas o que é necessário para não gerar uma documentação extensa e desnecessária. Lembre-se que documentação é tempo e esse tempo tem valor dentro do orçamento do seu projeto. Pensando no futuro, ou seja, na manutenção que posteriormente será dada ao produto é necessario que se registre, ou se documente coisas como: ● Os requisistos funcionais e não funcionais, inclusive os que forem se encontrando e os serão modificados ao longo do projeto. Ou seja, o problema que o software se propõe a estar solucionando; ● Mapeamento das principais funcionalidade/processos do software; ● Descritivo básico das funcionalidades. Ex: Javadoc, PHPdoc etc; ● A infra-estrutura (hardware e software) necessária para que o software tenha um bom e correto funcionamento; ● A tecnologia e a estratégia adotada durante o desenvolvimento; ● Os bugs conhecidos e desconhecidos e suas possíveis solução; E pensado nos usuários, ou seja, aqueles que de certa forma irão utilizar e manter o sistema é necessário que se documente coisas como: ● A infra-estrutura (hardware e software) necessária para que o software tenha um bom e correto funcionamento; ● A instalação, configuração e manutenção do software; ● O uso de todas as funcionalidade do software; ● Bugs conhecidos; Esses são apenas alguns pontos que devemos levar em consideração quando estamos documentando, são informações extremamente necessária para o correto uso do software que está sendo desenvolvido e para futuras manutenções, haja visto que a equipe que dará a manutenção não é a mesma que desenvolveu, assim é necessário que as informações do projeto que seram necessária para a manutenção estejam disponível para está equipe. 3.3. Como documentar?
  10. 10. Formato digital ou impresso? Padrão fechado ou aberto? Manutenção centralizada ou compartilhada? O que levar e consideração quando vamos escolher a formar que vamos registrar a informação? Qual estratégia adotar quando formos escolher o meio de documentarmos o nosso projeto e nosso software? Muitos defendem padrões para a documentação de software, porém devemos lembrar que cada projeto é único e, portanto, deve considerar um conjunto específico de ferramentas de gestão, desenvolvimento e, também, de registro de informações. Quando estamos falando em como os documentos vão ser criados e como eles estarão disponivel, é importante levar duas palavrinhas em consideração: acessibilidade e usabilidade. Não devemos esquecer que documentamos para compartilhar informação, e quando o assunto é compartilhamento, o meio pelo qual compartilhamos é de extrema importância. Pois, do que adianta criarmos a melhor documentação do mundo, se a mesma, não está disposta da melhor maneira possível, se na hora de darmos a manutenção, perderemos mais horas procurando a documentação, do que reescrevendo o software. Por isso, cada projeto, deve buscar sim a melhor ferramenta que se adapte ao seu orçamento e equipe, mas não pode deixar de analisar como ela vai impactar no compartilhamento desta informação. Concordo que devam ser criadas convenções para escrever documentos dentro de uma empresa, para que haja uma linguagem uniforme e que todos entendam o que está sendo descrito. Porém, estabelecer padrões fechados de tipos de documentos e formatos que devem ser seguidos à risca para todo e qualquer projeto, como acontece em alguns lugares, já é um pouco demais. Devemos tomar cuidado com a armadilha do excesso de padrões, principalmente quando o assunto é servir uma gama variada de pessoas, devemos procurar padrões amplamente difundidos e largamente utilizados, principalmente nos dias de hoje, onde temos as nossas mãos inúmeros meios para chegar a estas informações, ou seja, computadores, notebooks, netbooks, tablets, smartphones, entre outros e cada um operando um sistema diferente. Limitar por o meio por onde a informação será acessada torna a documentação ineficiente e ineficaz. Considerando a questão da singularidade de cada projeto, é importante que durante o processo de definição de documentos sejam analisados critérios ligados principalmente ao seu uso futuro e aos custos para a sua produção. Não devemos esquecer que a documentação é algo realizado por uma equipe e acessada por diversas outras equipes, então é necessário que a ferramenta, ou as ferramentas venham permitir a criação colaborativa dos documentos, assim como ancorar artigos de um mesmo tópico, e permitir que determinada informação que se repete ao longo da documentação possa ser mantida de forma centralizada para que se evite, um espalhamento de informações de modo que atrapalhe ou deixe muito custosa a manutenção da documentação, ou seja, eu escrevo uma vez e incorporo aquele texto onde eu quiser e quantas vezes eu quiser durante o processo de documentação. Sabemos a importância de se comentar um código, mas também sabemos como o exagero dos comentários pode tornar poluído e extenso as linhas de código. Então
  11. 11. encontrar um equilíbrio nos comentários e permitir que de alguma forma estes comentários possam ser ancorados a documentação é primordial para que haja dialogo entre o código e a documentação e vice-versa. Agora que entendemos um pouco melhor o processo de documentação, podemos prosseguir no nosso estudo, este capitulo nos ajudou a enxergar como processo de documentação é importante para o nosso projeto e como ele é fundamental para a manutenção e o uso do nosso software. O objetivo principal é entender o processo, saber da sua importância, para que possamos enxergar um meio de torna-la ágil. CAPÍTULO 4. PROCESSO DE DOCUMENTAÇÃO ÁGIL DE SOFTWARE 4.1. Documentação em Processos Ágeis Documentação em projeto de software que utiliza metodologias ágeis sempre gera uma boa e longa discussão. Isso por que muitos interpretam ao seu gosto o manifesto, quando o mesmo diz: “Software em funcionamento mais que documentação abrangente”. Há quem defenda que inclusive ela não exista, ou seja, basta um código bem documentado e uma interface bastante amigável e pronto.
  12. 12. Não vou discutir sobre se devemos ou não documentar, pois no capitulo anterior vimos a importância e o que levar em consideração no processo de documentação, e como ele é necessário para o futuro e a boa e correta utilização do software. Quanto a interpretação do manifesto, muitos esquecem de analisar o contexto de quando o mesmo foi criado, esquecem que naquele período (e ainda hoje), o desenvolvimento foi marcado por processos pesados e burocráticos de software (ex.: RUP). As funcionalidades dos software eram todas documentadas no inicio, a documentação acontecia antes e não durante o desenvolvimento e muitas das vezes, no papel o software estava completo, ou seja, com todas as funcionalidades documentadas, mas na prática algumas funcionalidades estavam parcialmente desenvolvidas e muitas nem haviam saído do papel. O manifesto ataca justamente isto, para que gastar tempo e dinheiro com uma documentação completa se o software não funciona, em outras palavras, para que documentar funcionalidade que ainda não foram completamente desenvolvidas, ou até mesmo nem foram desenvolvidas. E em nenhum momento eles dizem que não há valor na documentação, apenas dizem: “Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”. Ora se até eles entendem que há valor na documentação, quem sou eu para dizer que em um projeto ágil a documentação não tem valor. A verdade é que a documentação necessita de uma atenção especial, nem sempre há a necessidade de tudo ser documentado, muito menos impresso e entregue a todos. A documentação precisa ser dirigida, precisamos saber quem serão os leitores, para que a documentação seja objetiva e completa, e principalmente de fácil leitura e entendimento. O grande problema é que tem faltado equilíbrio, ou se documenta demais, ou não se documenta. O “x” da questão está em encontrar o que precisa e deve ser documentado e faze-lo de maneira eficiente e eficaz, devemos sempre nos preocupar em documentar o presente, ou seja o que está sendo desenvolvido, levando em consideração, como já vimos o futuro (manutenção) e o uso do software, pensando sempre numa documentação enxuta, porém completa, para que a manutenção não seja tão custosa. A manutenção da documentação é outro fator que deve ser levado em consideração. Apesar de não ter sido citada no capitulo anterior, a manutenção da documentação é o que mantém a documentação “viva”, ou seja, é o que a mantém funcional. Para que serve uma documentação desatualizada? Quem consulta uma documentação que não condiz com a realidade do software? A manutenção é responsável pela eficiência e eficácia da documentação. Ou seja, a estratégia usada no processo de documentação tem que levar em consideração o ”fator” manutenção. As ferramentas que forem utilizadas devem permitir e ajudar na atualização da documentação sempre que necessário. Por fim mas não menos importantes as ferramentas além de proverem uma fácil manutenção, deve prover um meio fácil de compartilhamento e acesso a informação. Ou seja, a documentação como dita anteriormente, deve estar acessível e deve ser facilmente compartilhada. Creio que este é o caminho para se conseguir um documentação ágil. Coletei algumas dicas preciosas que encontrei no livro do Andreas Ruping (Agile Documentation) e que compartilharei com minhas palavras a vocês neste trabalho.
  13. 13. Mais uma vez reforço, cada projeto é um projeto distinto, a ideia é apenas nos fazer pensar em o que vamos levar em consideração, o seja, quando estivermos desenhando nosso processo de documentação, devemos e precisamos pensar nisso para que possamos otimizar a documentação gerada ao longo do projeto. 4.2. Como escolher o que vai ser documentado … ... 4.2.1 Concentre-se nos leitores do documento Em um contexto ágil, não documentamos por que foi prescrito, documentamos por que esse documento cumpre uma finalidade para o leitor a quem ele se destina. Entendendo que um documento possui uma finalidade para alguém, faz todo sentido, saber quem é este aguém, para que possamos tornar o documento mais preciso e objetivo. E uma vez claro quem são os leitores, para o documento é necessário: ● Tornar claro a quem serão os leitores (ou seja, a quem se destina o documento), inclusive tornando isso explícito; ● Explicar o contexto e o conhecimento necessário para entender o documento; ● Evitar usar conteúdo fora do contexto e conhecimento dos leitores; ● Restringir o escopo do documento à expectativa dos leitores. Isto ajuda a manter o documento pequeno e preciso, como também restringe o nível de detalhe para
  14. 14. que os leitores possam tentender; ● Tornar o documento compreensível, fornecendo exemplos do cotidiano dos próprios leitores. Quando você prepara seu trabalho, considerando-o como um serviço para leitores, então você passa a se perguntar: “Quem são meus leitores?”, “Que informação meus leitores precisam” e “Será que meus leitores são capazes de entender?”. Se ao criar um documento, você perceber que não consegue descobrir que são seus leitores e o por que eles gostariam de ler seu documento, existe uma alta probabilidade deste documento ser desnecessário. 4.2.2 Mantenha o foco e a relevância no documento Um foco claro e identificável sobre um determinado tema, torna o documento conciso e objetivo. O documento objetivo fornece a nformação relevante para este tema, mas não mais que isso. Alguns sinais que um documento tem um foco claro: ● Um documento dever ser adequadamente intitulado, um titulo claro sugere que o foco do documento também é claro; ● A diferença de escopo entre dois documentos relacionados deve estar clara em cada titulo; ● Um resumo ou sumário no inicio do documento pode explicar o foco do documento; ● Todas as seções do documento devem ser composta por material relevante ao assunto do documento. Você pode conseguir documentos simples, se você lembrar-se de verificar que tudo o que você está dizendo realmente contribui para o assunto do documento. Se você achar que este não é o caso, volte e se pergunte qual objetivo do documento, e o que você pretende transmitir aos seus leitores. Isto não se aplica apenas ao se criar um novo documento. Documentos são atualizados, e sempre que adicionar informações, garanta que a informação vai para o lugar certo, para que todos os documentos do projeto mantenham seu foco. 4.2.3. Levante as necessidades de documentação individualmente A quantidade e o tipo de documentação dependem de uma série de fatores, como: tamanho do projeto, situação da equipe, criticidade, entre outras coisas. Mas todo cuidado deve ser tomado para se evitar documentação desnecessária, para isso observe separadamente: ● A necessidade de documentação para as partes interessadas no projeto; ● A necessidade de documentação para comunicação da equipe; ● A necessidade de documentação para cada membro da equipe (principalmente em equipes heterogêneas);
  15. 15. ● A necessidade de documentação para um próximo estágio (Ex.: uma manutenção futura); ● A necessidade de documentação para follow-up do projeto. É necessário definir quais documentos e quais materias serão cobertos no processo de documentação. A necessidade de documentação pode mudar, mais documentação pode ser necessária. O importante é de tempos em tempo re-avaliar a necessidade mantendo a documentação num nível adequado de volume e detalhamento. 4.2.4. Mantenha um portfolio de documentos (possíveis documentos de projeto) Crie um portfolio de documentos com os documentos que podem ser necessário para os projetos de software e seu escopo. Assim os projetos podem escolher os documentos que eles precisam e checar a necessidade de cada documento individualmente. A criação do portfolio auxilia a equipe na hora de saber quais documentos eles precisam, o portfolio tem uma série de sugestões para o time considerar. A figura abaixo mostra um exemplo de portifolio de documentos: Os documentos listados acima são apenas exemplos, uma idéia, de como categorizar e apresentar os documentos. Cabe a equipe dicidir quais documentos são necessários, levando em consideração as necessidades aprentadas acima (4.2.3).
  16. 16. 4.2.5. Evite informação perecível Sabemos que principalmente em um projeto de software, tudo é muito dinâmico, a tecnologia está em constante atualização e tudo muda de maneira muito rápido. Com isso a chance de documentarmos coisas que rapidamente perderão seu valor é muito grande e não podemos nos permitir gastar o tempo e consequentemente o dinheiro em documentação deste tipo. Encontramos mais valor em uma documentação com foco em questões futuras, que irão auxiliar-nos em uma próxima fase, ou em um futuro projeto. Não podemos esquecer que documentamos para suportar o produto após o seu desenvolvimento, seja na manutenção, ou em atualizações futuras. Baseado nisso, ao documentarmos precisamos sempre levar esta informação em consideração. Evitando assim, um disperdício em registro de informações perecíveis. 4.2.6. Especifique em conjunto Creio que o “calcanhar de aquiles” de todo projeto de software seja a especificação dos requisitos levantados. É muita prepotência achar que algumas entrevistas e uma série de perguntas é o suficiente para levantar os reais requisitos de um sistema. E mais prepotência ainda achar que se terá uma boa especificação baseando-se em requisitos incertos. Cria-se um verdadeiro telefone sem fio, muito perigoso, para qualquer projeto. O cliente diz o que acha que quer, o analista anota o que acha que o cliente precisa e o especialista especifica da melhor forma o que acha que entendeu. Porque não se colocar o cliente, os interessados e o time de desenvolvimento em uma mesma sala e todos juntos chegarem em uma conclusão sobre os requisitos e a especificação de cada um. A melhor forma de saber se todos estão enxergando o mesmo horizonte é colocando todos no mesmo lugar, eliminando todo ruído. Existe forma melhor de saber o que o cliente quer, ouvindo da boca do próprio? E existe forma melhor da especificação atender ao cliente de forma melhor sendo o mesmo participante da especificação? Não existe forma mais eficiente e eficaz de se especificar e se manter no horizonte correto se não houver uma integração entre cliente e time de desenvolvimento. O envolvimento do cliente e das partes interessadas é primordial para o sucesso da especificação e consequentemente o resultado final do desenvolvimento. O documento de especificação deve conter um registro desta reunião cara-a-cara dos requisitos, das discussões e do entendimento de todos os participantes. Casos de uso, estórias e cenários são um excelente input para o documento de especificação. Além deste documento auxiliar em discussões futuras, para inclusive melhorar ainda mais a especificação. O refinamento da especificação é muito importante para manter a clareza e dar a correta visão para o time de desenvolvimento. 4.2.7. Justifique o design escolhido para o projeto
  17. 17. É importante documentar o design que está sendo adotado e utilizado pelo projeto de software, pois este documento servirá para futuras mudanças de design. Um documento padrão sobre o design, descreve a interface do sistema, bem como suas funcionalidades internas, seja de aspectos estruturais, ou comportamentais. Este documento é importante para transmitir o design do sistema a outras equipes, clientes ou projetos futuros. A descrição do design é o suficiente durante a manutenção do sistema, mas quando o sistema sofre alterações, um mero registro do design atual pode não ser o suficiente. Como o design evolui é importante que o time saiba o por que da sua escolha e as outras opções de design que existem. No entanto detalhes de implementação mudam, assim como, o software muda, o que o torna estes detalhes precíveis. Documentos sobre o design do projeto tem valor, quando eles não só se restringem a atual descrição do design, mas também justifica e explica o por que que um design particular foi escolhido. 4.2.8. “Big picture” introduz melhor que muitos detalhes técnico Imaginemos que um novo colaborador se junta ao time e para ele é entregue uma pilha de papel, repleta de detalhes tecnicos muito importante para o projeto. Como todo esse dilúvio de informação seria recebido por ele? Será que realmente a melhor maneira de introduzir alguém a um projeto é bombardeando de detalhes técnicos? Será que conhecer todos os detalhes técnicos é realmente util para alguém que só quer ter uma ideia sobre o sistema e seu funcionamento? A melhor maneira de passar uma ideia sobre o projeto, talvez seja a descrição de uma “Big Picture” do que está sendo construido. A “big picture” prover um entendimento global, descrevendo a arquitetura geral, mostrando os módulos e as sua interações, bem como uma visão geral dos seus comportamentos e funcionalidades. Ela explica os principios, motivações e decisões por tras do projeto. Nomeia a tecnologia fundamental para construção do software e intencionalmente asbtrai detalhes tecnicos e irrelevantes para uma visão geral. 4.2.9. Saiba separar descrição de avaliação Uma boa descrição pode e deve contar com fatos, observações, análises, dados e estatísticas e dá base e sustentação para uma boa avaliação, ou seja, julgamentos, opinião, recomendação, validação ou interpretação. Tanto a descrição, quanto a avaliação são extremamente úteis e ajudam na tomada de decisão, dando um norte, para quem necessita. Mas é importante que elas estejam separadas, claras, para que o leitor de certa forma, saiba o que é a descrição e o que é a avaliação. Essa separação ajuda para o objetivo geral de apresentar uma informação focada. A separação pode estar refletida na estrutura do documento, ou seja, separando em seções específicas, ou usando tecnicas de layout, como caixas de texto especiais, colunas adicionais ou variando as fontes.
  18. 18. 4.2.10. Utilize exemplos reais Muitas pessoas tem dificuldade em entender material técnico, até porque em sua maioria eles são muito abstratos. Além do que, nem todos os leitores do projeto são necessariamente especialistas na área. A documentação é geralmente apresentada com maior sucesso quando acompanhada de exemplos reais. Assim como exemplos bobos e fora do contexto do projeto podem ter efeito contrário, a documentação se torna mais convincente quando ela inclui exemplos realísticos dentro do contexto do projeto. Exemplos realista servem com input para a especificação, principalmente para ajudar as pessoas sem conhecimento técnico a entender como se comportará a funcionalidade, além de ajudar a explicar na justificativa do design escolhido para o projeto. 4.3. Dicas para saber como documentar … ...
  19. 19. 4.3.1. Apresente a informação de maneira estruturada A documentação pode ser para diversos propósitos, dependendo do leitor, a documentação ela tem que se permitir ser lida não apenas de maneira sequencial, ou seja, do inicio ao fim, mas precisa permitir que uma informação seja retirada de maneira rápida, para que assim possa atender a todos os leitores. Uma documentação não estruturada, não organizada, não atende a leitores que buscam informações rápidas e objetivas, apesar deles estarem disposto a perder tempo folheando o documento, quando suas buscas não apresentam resultado, eles assumem que a informação não está disponível. Isso presume que devemos utilizar hypertexto e hyperlinks em documentos de projeto, para que os leitores possam ser levados através de sua busca à informações que consideram relevantes, mas não podemos permitir que isto atrapalhe a leitura sequencial do documento. Temos sempre que encontrar o bom senso, de modo que, a documentação não esteja “over-estruturada”, o que poderia atrapalhar aos leitores senquenciais, nem esteja desestruturada que inviabilize a leitura por aqueles que querem recuperar uma determinada informação de maneira rápida. A escolha do capitulos, seções e sub-seções são essenciais para a construção de textos bem estruturados, mas a utilização de blocos de construção textual é bem vindo e pode auxiliar na estruturação do documento. A utilização de diagramas e tabelas na estruturação do documento torna-o mais visivel e ajuda aos leitores a perceberem o conteúdo do documento. 4.3.2. Diagramas são uma ótima forma de apresentar estruturas e processos Estruturas e processos possuem papel importante em engenharia de software, as estruturas descrevem como o sistema está organizado e como está composta suas pequenas partes, e os processos descrevem a parte dinâmica do software. Não é surpresa perceber que muitas tecnicas de modelagem usam diagramas para descreverem estruturas e processos, como sabemos uma imagem, vale mais que mil palavras. Diagramas falam com a nossa intuição. Textos técnico são muito monótonos e os diagramas ajudam na dificil tarefa de entreter e atrair leitores. Diagramas são excelentes complementos, eles providenciam uma excelente visão geral, quando acompanhado de texto explicando detalhes se necessário. Diagramas são excelentes quando necessários, os melhores são claros e simples, não possuem muitos elementos gráficos e se necessário podem sem explicados em uma legenda. Uma simples foto de um desenho de uma reunião pode ser um execelente diagrama. 4.3.3. Apresente a informação sistematica usando tabelas Em projetos de software é comum ter informação sistemática, alguns exemplos: lista de
  20. 20. módulos, lista de funcionalidades, lista de erros etc. Essa informação sistemática são frequentes em documentação, entretanto, membros do time não estão interessados em um loga leitura quando tudo poderia ser facilmente apresentado em uma lista. Usar tabela para apresentar informação sistemática é uma escolha óbvia já que as tabelas oferecem um formato compacto para apresentação de informação de maneira concisa e clara. Como os diagramas, as tabelas ajudam a diminuir a monotonia dos textos técnicos e ajudam a atrair a atenção dos leitores. Também como os diagramas as tabelas podem carecer de informação mais detalhada por isso, em alguns caso o uso apenas de uma tabela pode não ser suficiente e poder ser necessário ela vir acompanhada de texto com mais detalhes. 4.3.4. Oriente seus leitores Existe diferente tipos de pessoas que executam diferentes papeis e possuem diferente áreas de conhecimentos em um projeto de software e isso tem que estar previsto em sua documentação, um documento pode ser importante para uns e completamente irrelevante para outros. As pessoas podem ler a documentação com diferente intenções. Alguns podem buscar uma visão geral, outros buscam um detalhe especifico e ainda existem outros que buscam ler a documentação por completo. Uma breve orientação no inicio de cada documento pode informar aos leitores a que propósito serve o documento e explica como diferentes grupos podem aproveitar o documento. Nesta breve orientação é importantes responder a perguntas como: Quem poderia ler o documento, qual contexto do documento, ou seja, o que está contemplado e o que não está no seu escopo, como o documento está organizado, qual a dependencia entre os diferente capitulos e qual a ordem de leitura dos mesmos, qual a relação entre os documentos e o que precisa ser lido antes, como pode se ter uma rápida visão geral do conteudo e se o documento está completo ou em andamento, se atualizações são necessárias e quais partes serão atualizadas. Essa breve orientação auxilia os leitores evianto perda de tempo e otimizando a leitura da documentação. 4.3.5. Faça um breve esboço descrevendo as seções Criar um esboço das seções do documento é uma excelente maneira de dar uma visão geral do documento como todo, um esboço deve conter o objetivo geral e a ideia principal da seção. Um documento que contém estes esboços permitem uma leitura sequencial em diferentes níveis, os leitores podem decidir se aprofundar e ler a seção com mais detalhes ou passar para a próxima seção. Há duas formas de se trabalhar com os esboços: Você pode iniciar cada seção com uma
  21. 21. espécie de sumário ou resumo; ou Você pode escolher alguns parágrafos de cada seção, não necessariamente do inicio, e usa-los como esboço. Ambas as técnicas preservam a ordem sequencial do texto, então as pessoas podem ler o documento do inicio ao fim se eles quiserem, enquanto outros leitores podem focar nos esboços para uma rápida verificação. 4.3.6. Apenas inclua referencia (links) se as mesma estão disponível Documentos são criados focando um assunto. Entretanto, nenhum documento pode estar isolado. Sempre existe assuntos relacionados que precisam ser entendidos antecipadamente ou documentos relacionados que providenciam informação adicional. Como consequência, quase todos os documentos precisam incluir referencias para outros documentos. Referenciar documentos que não estão disponíveis, não vale muito a pena, não agrega valor a documentação e poderia muito bem ser deixado de fora. Devemos levar em consideração que há uma perda de credibilidade se mantermos referencias a documentos indisponíveis. 4.3.7. Crie um glossário para auxiliar no entendimento do vocabulário Termos técnicos ocorrem com frequência em projetos de software. Documentos sobre o design particularmente não podem ser feitos sem termos especificos da tecnologia utilizada. 4.3.8. Mantenha um histórico do documento É comum a documentação evoluir, ou até mesmo, receber atualizações a medida que o projeto evolui, muitas informações só são descobertas durante a execução do projeto, além de que, as necessidades podem mudar e o software também. Com essas mudanças e novas informações descobertas a documentação fica desatualizada, sendo necessária a revisão e atualização da documentação. O leitor ele precisa saber quando está lendo um documento desatualizado e é bom que haja um registro histórico destas alterações, uma espécie de log de mudanças contendo: autor, as alterações e se ela refere-se a um software, deve indicar a versão dele. Deste modo os leitores podem entender como aquele documento esteve envolvido durante o desenvolvimento do projeto. 4.4. Outras dicas Apesar do foco deste trabalho está em nos auxiliar em entender o que e como documentar, e para isso apresento os padrões que li no livro de Andreas Ruping. Acredito ser de grande valia outras dicas encontradas no livro e que merecem ser citadas, pois acrescenta mais ainda na qualidade da documentação. São dicas de layout, tipografia e organização estrutural para a documentação.
  22. 22. Não me estenderei, apenas as citarei e caso sintam a necessidade de aprofundar, o livro do Andreas é uma excelente leitura. 4.4.1. Layout e Tipografia ● Use apenas 50% da página para o texto, deixe o restante para cabeçalhos, rodapés e margem. A maioria dos leitores preferem páginas com margens amplas do que uma página lotada de texto. ● 2 alfabetos minúsculos por linha, esse seria uma boa largura para o texto. Em casos que ultrapassem os 2 alfabetos, você pode, aumentar a fonte, aumentar a margem ou criar colunas. ● Altura da linha 120% da altura da fonte, para auxiliar na legibilidade do documento. Desta forma você garante que as palavras não estejam tão próximas uma das outras e atrapalhem a leitura. ● Se limite a 2 tipos de fonte, assim evitamos de tornar o texto caótico. O excesso no uso de fontes em um documento pode tornar o documento menos simpático a primeira vista. ● Moderação no uso das variações das fontes, usar variações de fonte para dar ênfase a determinadas palavras é permitida, mas sempre procure usar com cuidado. O uso sem cuidado pode atrapalhar a legibilidade do documento. ● Utilize sombreamento e bordas ao separar as células de uma tabela, assim as tabelas se tornam mais legível e fica mais fácil diferenciar as linhas titulos das demais. ● Procure localizar as tabelas e diagramas abaixo do texto que as faz referência, pois é o primeiro lugar onde os leitores irão procurar. ● Mantenha coerência entre as páginas, a coerência auxilia no fluxo de informação. Evitar títulos no final da página, parágrafo em quebra de página
  23. 23. com menos de 2 linhas e quebra de página dentro de células de uma tabela. 4.4.2. Infraestrutura e organização técnica ● Documento paisagem, o projeto de documentação pode estar representado como um tipo de paisagem que os membros podem usar como um mapa mental quando eles recuperam ou adicionam informação. O documento paisagem em forma de árvore se aproxima melhor da intuição humana. ● Arquive os documentos, o arquivamento de documento nos fornece como vantagem poder recuperar determinadas versões quando necessário. ● Wiki, uma wiki fornece acesso a documentação via servidor interno, além de possibilitar troca de mensagem e inclusão de notas dos membros do projeto. ● Proximidade com o comentário do código, Documentação sobre o código, deve estar como comentário no código. Documentos separados, podem ser utilizados para tratar de problemas de alto nível, como visão geral, requisitos, design e arquitetura. ● Meio mais adequado, para a leitura o meio impresso é mais adequado, já para uma busca o meio on-line se mostra a melhor opção. ● Separe conteúdo do layout, layout e conteúdo devem estar devidamente
  24. 24. separado, para facilitar mudanças e reutilização do layout. ● Utilize sempre uma única fonte para múltiplos documentos, quando determinado conteúdo é encontrado em diversas fontes, o esforço para manutenção é maior, além de permitir problemas de sincronicidade. Devemos sempre procurar mecanismo que nos permite de uma única fonte gerar diversas visões. ● Use referência ao incluir artefatos comuns, Artefatos que aparecem em diversos contextos, devem ser importados por referências para dentro do documento que os inclui, para que haven alterção no artefato, todos os documentos que o referenciam sejam igualmente atualizados. ● Disponibilize documentos independente da plataforma, optar por escolher disponibilizar a documentação por um meio amplamente disponível, faz com que a documentação alcance um maior número de leitores. ● Crie e utilize modelos de documento, uma vez o modelo definido, todos os documentos o seguirão, mantendo um padrão e coerência no projeto de documentação. ● Utilize ferramentas para auxiliar na documentação, A maioria dos projetos podem ser geridos com um pequeno conjunto de ferramentas que auxilia no projeto de documentação. ● Marque as mudanças durante o desenvolvimento da documentação, isso permite identificar de maneira rápida as partes dos documentos que tiveram alterações recentemente. ● Notifique as atualizações aos leitores em potencial, sempre que uma mudança significativa ocorrer em um documento, os leitores em potencial deveriam ser notificados, esta notificação poderia explicar o que foi alterado, mas não deve incluir a atualização em si. ● Reorganize quando necessário, reorganização frequente tornam as coisas piores, não melhores. Reorganize apenas quando necessário, ou melhor, quando é ativamente solicitada pelos membros do projeto.
  25. 25. CAPÍTULO 5. CONCLUSÃO Como dito no inicio deste trabalho, a ideia, em momento nenhum é apresentar um receita de bolo para o processo de documentação. Sabemos que cada projeto possui um requisito e devemos sempre estar atento a eles. O que foi apresentado são algumas dicas, alguns tópicos, que devem ser levados em consideração antes, durante e depois em um projeto de documentação. Acredito que se cada ponto apresentado for devidamente explorado, teremos como resultado uma documentação mais eficiente e eficaz no que se diz respeito a informar e auxiliar em qualquer tipo de projeto, sejam os membros da equipe, sejam os usuários ou os stakeholders do projeto. Espero ter contribuido e ajudado aqueles que assim como eu tinham dificuldade em enxergar e desenvolver um projeto de documentação que realmente atendesse a necessidade e não apenas servisse como disperdicio de tempo. Assim como espero ter clarificado o conceito de documentação dentro de projetos ágeis, eliminando a idéia de que não se deve ter documentação nesse tipo de projeto. REFERÊNCIAS BIBLIOGRÁFICAS RUPING, Andreas. Agile Documentation
  26. 26. BECK, Kent. Programação Extrema (XP) explicada. Porto Alegre: Bookman, 2004. COCKBURN, Alistair. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Professional, 2004. PUNTER, Mike. “Programming for Maintenance” in Techniques of Program and System Maintenance. QED Information Sciences, 1988, pg. 116. SEI - Software Engineering Institute. Concept of Operations for the CMMI. Carnegie Mellon University, 2001. Disponível em: <http://www.sei.cmu.edu/cmmi/background/conops.html>. SOMMERVILLE, I. Engenharia de Software. 6ª edição. Pearson. 2003.

×