Scrum é uma metodologia incompleta? Ou: Agile precisa de UML?

Scrum não é uma metodologia para desenvolvimento de software e sim um framework que nasceu com o intuito de ser aplicado em gerenciamento de projetos de desenvolvimento de produtos.

Segundo o Scrum.org (tradução livre)

Scrum é uma estrutura para desenvolver, entregar e sustentar produtos complexos. Esta definição consiste nas funções, eventos, artefatos do Scrum e as regras que os unem.

Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas.O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de produto e técnicas de trabalho, de modo que você possac ontinuamente melhorar o produto, o time e o ambiente de trabalho.

Aqui você pode baixar uma versão em português do Scrum Guide.

É possível assistir a esta vídeo aula que descreve o que é o Scrum e seus valores, pilares, eventos, papéis e artefatos.

Por quê então confunde-se Scrum com metodologias Ágeis de Desenvolvimento de Software? Simples, primeiro por quê as pessoas simplesmente não procuram estudar os conceitos (ironia), mas principalmente, justamente por ele entregar regras e ferramentas que casam com os conceitos e diretrizes de metodologias e processos ágeis, e portanto é usado em conjunto com, por exemplo: XP ou RUP, as pessoas o confundem.

Também por quê metodologias como RUP, a princípio, não definem todas ferramentas para gestão de projeto mas im artefatos e fases de um processo de desenvolvimento de software - eu já disse que desenvolver software é complexo? Olha o Scrum dando suporte aqui

Quando você diz:

No caso de Scrum eu vejo melhoria contínua (retrospective meetings), proximidade com os stakeholders (a ação do product owner), desenvolvimento iterativo (sprints), priorização de requisitos (planning poker e backlog) e resposta rápida a mudanças (entregas frequentes, daily meetings e o próprio backlog). Também o time autossuficiente.

Você está citando justa a possibilidade de incorporar estas ferramentas de gestão de equipe ao processo. Por isso quando você afirma

Mas para um desenvolvimento de software isso está incompleto.

está correto, e por isso mescla-se um metodologia ágil com Scrum.

Onde estão os casos de uso? Scrum tem as user stories, mas elas precisam de refinamento.

Por experiência eu entendo que toda metodologia e processo deve ser adaptado ao contexto (equipe, cultura, empresa, complexidade de projeto etc). Quando falo em adaptação posso citar a possibilidade de que uma história de usuário possa ser escrita como um caso de uso, sem demérito. Ou que uma história épica seja um caso de uso complexo que exploda em documentos de requisito por iteração, que resolvem partes do caso de uso. No meu entendimento: história de usuário é "o que", caso de uso e suas regras é o "como" as descrever. Podemos expandir isso para muitos outros artefatos.

Onde está a modelagem de domínio? Onde está o design (projeto)?

No Scrum? Acho que já deu pra entender que não cita isso, cada produto complexo (motor de avião, por exemplo) tem suas especificidades e deve usar as ferramentas do processo adequado (modelagem de domínio quando Scrum aplicado a desenvolvimento de software)

Onde está a arquitetura?

Estou apenas pontuando, mesmo contexto da resposta acima, se estivesse desenvolvendo um produto complexo como uma roupa inteligente que ofereça segurança e resistência a fogo, com certeza poderia aplicar scrum, para gerenciar a equipe e as entregas em várias interações, mas o scrum não sabe o que são as entregas, neste caso, talvez: estudos de literatura científica, protótipo de tecidos, análise de resultados, avaliação de danos, protótipos funcionais do produto, testes em situações reais.

No caso de software: estudo da arquitetura, protótipo dos componentes de segurança, modelagem de dados para cada módulo, etc.

Já nos dois pontos onde afirma

Implementação e design ad hoc qualquer um faz.

Vejo o pessoal se preocupando muito com o Agile e pouco com essas coisas.

Eu concordo principalmente por já ter visto muito do que citei acima, falta de aprofundamento em conhecimento. Eu vi e ainda vejo muitos, principalmente iniciantes, usar o o jargão "Ágil" como desculpa para não ter documentação, não fazer análise, não se preocupar com qualidade, não definir processo. Então esse pessoal pega o Scrum, que não descreve, como você mesmo já afirmou, processos e ferramentas para o desenvolvimento de software, e aplica de forma vazia.

Já, engenheiros e arquitetos de software mais experientes e "estudados", aplicam de acordo com seus contextos, as ferramentas e os processos ágeis necessários ao desenvolvimento de software, conjuntamente com as ferramentas e preceitos Scrum (alguns preceitos inclusive podem ser relacionados a preceitos do manifesto ágil).

Por fim,

De onde devem partir essas disciplinas? O que serve para complementar o Scrum hoje em dia? O pessoal se preocupa com isso?

e ainda

Ágile precisa de UML?

UML especificamente é uma linguagem, como, quanto e quando usar fica a critério da equipe. Usar UML com metodologias Ágeis? Sem problemas. Escrever todos os diagramas UML para cada caso de uso de todo o sistema? Não, isso é burocracia, não é nem análise, nem planejamento nem se encaixa nos preceitos ágeis. Mas posso usar todos os diagramas UML e Scrum? Sim, desde que faça daily meetings, em sprints e registre em backlogs, está usando Scrum, mas não está sendo ágil ;-).

É um erro bastante comum confundir o Scrum com um processo de desenvolvimento de software quando na verdade ele é um framework com o qual você pode utilizar vários processos ou diferentes técnicas para desenvolver, entregar e manter produtos complexos.

Segundo o Guia do Scrum escrito pelos seus criadores, a definição de Scrum é:

Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Resumidamente, o Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos, mas ele não define quais processos, técnicas, ferramentas ou tecnologias devem ser utilizados.

O que acontece é que alguns processos, técnicas e ferramentas acabaram se popularizando a ponto das pessoas acharem que elas fazem parte do Scrum, como por exemplo: Histórias de Usuários, Quandro Kanban e o Planning Poker.

O Scrum é composto por papéis, eventos, artefatos e regras. As regras intregram os papéis, eventos e artefatos, administrando as relações e interações entre eles. Sendo que os papéis definidos pelo scrum são: O Product Owner, O Time de Desenvolvimento e O Scrum Master. Os eventos são: A Sprint, O Planejamento da Sprint, Reunião Diária, Revisão da Sprint e Retrospectiva da Sprint. Os artefatos são: Backlog do Produto, Backlog da Sprint, Incremento.

Dessa forma, para implementar o Scrum, cabe ao time de desenvolvimento definir junto com os stakeholders do produto um processo de desenvolvimento de acordo com as suas necessidades. É por isso que você não vai encontrar respostas definitivas sobre como fazer levantamento de requisitos, modelagem de domínio, arquitetura e design no Scrum.

Para mais informações, recomendo a leitura do Guia do Scrum.