O que tivemos de mais interesse em 2012? Quais foram melhores artigos, as opiniões que geraram maiores discussões? Isso é o que você vai encontrar nessa seleção de artigos que fizemos especialmente para você: os melhores conteúdos de 2012. Já que final e início de ano é sempre um tempo propício para fazer um balanço do que passou e o planejamento para o que ainda virá, esperamos que os artigos publicados aqui te ajudem nisso!
Boas festas e feliz 2013! Um abraço da equipe de Redação do iMasters!
Já esbarrei com vários desenvolvedores que estranharam o fato de utilizarmos, na empresa onde trabalho, a Qualidata, metodologias ágeis e ao mesmo tempo termos atividades de elicitação de requisitos, descrições de casos de uso e modelagem de domínio antes de um sprint de construção propriamente. Para eles, a leveza do Agile parece pedir sempre a leveza das “User Stories” e da comunicação face-a-face preconizadas pelo eXtreme Programming. Mas nem sempre é assim.
Por que descrevemos casos de uso na Qualidata?
Bom, primeiramente não quero em nenhum momento dizer que use-case é melhor ou pior que user-story. São coisas totalmente distintas e servem para propósitos distintos. Discutir o que é melhor só faz sentido dentro do contexto de um projeto ou uma realidade específica. A nossa realidade na Qualidata, em geral, é o desenvolvimento de sistemas corporativos com muitas regras de negócio – e você deve manter este contexto em mente ao ler o restante deste artigo.
Nós acreditamos realmente que “software em funcionamento mais que documentação abrangente” (do manifesto ágil) seja algo muito importante. É óbvio que no manifesto ágil a parte da direita não é necessariamente banida, mas apenas a parte da esquerda é mais valorizada. Ainda assim, essa frase do manifesto pede uma discussão muito mais fundamental e que talvez seja a causa de muita das confusões em torno do assunto. Descrição de caso de uso é documentação? Parece óbvio que sim, mas depende do que entendemos por documentação.
Em geral, quando as pessoas falam de documentação de um componente de software (e de outras coisas diferentes de software), elas estão se referindo a uma representação, textual ou não, do comportamento desse componente, visando facilitar seu entendimento quando alguém precisar lidar com ele no futuro. Em outras palavras, documentação em geral é vista como uma ferramenta de comunicação e um registro para uso futuro, para facilitar a vida de quem for lidar com isso mais pra frente.