Disseminando conhecimento e inovação em desenvolvimento de software corporativo
Um dos principais desafios ao se elaborar a arquitetura de um software está em considerar seus atributos de qualidade e, principalmente, a correta especificação destes atributos. Muitos dos problemas, não por acaso, estão diretamente relacionados a essa dificuldade na especificação, como acontece no tratamento de segurança e desempenho. Veja como lidar com esses desafios de forma equilibrada.
Integração Contínua não se resume a disponibilizar um servidor que continuamente obtenha e compile uma cópia do projeto. Ela é uma virtude a ser cultivada pelos desenvolvedores, independente de um servidor e, para tanto, é preciso seguir uma série de práticas que tornam possível integrar o trabalho dos diversos membros do projeto, mantendo sua integridade e realizando o menor esforço possível.
É comum em equipes ágeis que haja dificuldades em estimar e especificar requisitos não-funcionais, como escalabilidade, interoperabilidade, facilidade de manutenção, desempenho, portabilidade e segurança. Em posts e artigos recentes, especialistas apresentam recomendações e boas práticas para lidar com esses requisitos em projetos ágeis.
Sempre houve um grande dilema entre a estimativa de prazo e de dinheiro que envolve um projeto de TI, reclamações por ambas as partes cliente/desenvolvedores justificando que tal análise ou estimativa não era exata(bem, uma estimativa já não é exata por definição) também é algo frequente. Porém será que métodos como APF não podem ajudar quando o assunto é gerar uma estimativa?
No Scrum, os requisitos são normalmente chamados de user stories. Mas seria CERTO utilizar casos de uso com Scrum? E, em caso afirmativo, sob que circunstância você deveria fazer esse uso?
Em algumas user stories podemos definir facilmente que são os beneficiados. Mas como cumprir o modelo padrão "Como ... Eu quero ..." se não podemos expressar quem quer aquela tarefa pronta?
Em uma discussão recente na lista do Scrum Development, Tri Nguyen perguntou se os products owners devem participar da reunião de planning poker. Existe um consenso geral sobre isso?
Em seu site, Alistair Cockburn propôs a criação de uma extensão para o Manifesto Ágil, voltada para o usuário / cliente, a partir de um discussão na cidade de Salt Lake junto com Jeff Patton, que em conjunto com outras pessoas iniciaram este trabalho. O trabalho é ainda preliminar, mas já foram criadas quatro opções, que são basicamente as mesmas, mas dispostas de maneira diferente.
Requisitos não-funcionais descrevem qualidades do sistema ao invés de seus comportamentos. Scott Ambler causou muita discussão quando ele recentemente declarou "O conceito de product backlog do Scrum funciona bem para requisitos funcionais simples, mas... se torna insuficiente para requisitos não-funcionais e restrições de arquitetura." em um artigo no Dr. Dobb's Portal.
