Páginas

29 fevereiro 2008

Simpósio Brasileiro de Qualidade de Código 2008









Saudacoes!!
Bem, aos interessados em seguir nesta área, ai vai a dica:
Em Florianópolis haverá o evento nacional de qualidade de software... e existe inclusive uma chamada de trabalhos para M
etodos, experiências e Modelos Ágeis! (será que vou arriscar??)

Apenas dos preços salgados para quem não é aluno nem do meio, pode ser uma ótima oportunidade para observar o que está acontecendo na comunidade acadêmica de desenvolvimento de software (onde até pouco tempo, existia uma aversão imensa sobre qualquer coisa que fosse referente à palavra "Ágil")...


é estamos melhorando...

[]s

I want more porn...

Momento distração... já que estamos em plena sexta feira!


26 fevereiro 2008

Technical debt -- Introdução ao Débito Técnico

Conceito



O termo descreve a obrigação que uma empresa adiciona a um projeto de software quando escolhe uma abordagem de desenvolvimento que permita um resultado rápido que aumentará a complexidade do software e que custará muito mais caro a longo prazo.

Inserido acidentalmente

Uma abordagem tecnológica não adequada ou o código inserido por um programador inexperiente. Este é o resultado não estratégico de um trabalho mal desempenhado. Pode ser criado, ironicamente, na tentativa de refatorar algum setor de código problemático sem o auxílio de mecanismos de verificações/validações.

Inserido intencionalmente



Ocorre com a decisão da empresa em favorecer conscientemente o resultado presente em detrimento dos ganhos futuros. Entre os exemplos mais comuns e mais preocupantes: “Se não entregarmos esta release no prazo, não haverá outra entrega”, ou ainda “se não esta features não for implementada, perderemos N clientes”. A escolha em deixar para o futuro a preocupação com a qualidade do código produzido é o principal motivo para a ampliação dos custos de manutenção.



Identificar o Débito Técnico

  • Existe um único desenvolvedor capaz de tocar em “certas partes do código”

  • Desenvolvedores não possuem confiança em estimar o esforço em realizar atividades

  • A falta de validação/testes dificulda a confiabilidade no sistema. Desenvolvedores dificilmente garantem o funcionamento do sistema

  • Inserções no sistema são feitas e entregues rapidamente, mas levam muito mais tempo para realmente estarem utilizáveis no sistema (retrabalho)



Aprofunde Conhecimento

25 fevereiro 2008

Cockburn e Use Cases



Lendo o blog do Tyner Blain me deparei com post comentando sobre a posição do Alistar Cockburn sobre Casos de Uso e desenvolvimento Ágil.

Entre as principais motivações para utilização de Casos de Uso:

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have throught through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)


Mas o mais importante desta leitura está a apresentação abaixo. Realmente me fez pensar um pouco sobre a forma que tratamos User Stories, e de que maneira, mudando-se o foco, poderíamos utilizar Casos de Uso para ampliar a visibilidade e o conhecimento de todos da equipe sobre o domínio da aplicação, e mais do que isso, de que maneira esta abordagem se encaixa ao Desenvolvjmento Ágil

Leitura Obrigatória número 4300

Download do Arquivo: Agile Use Cases

22 fevereiro 2008

Willian Demin



Frase da Semana

"Não existe necessidade de mudanças. Sobrevivência é fundamental"

[]s