Scrum Solo

Processo de software para desenvolvimento individual

Scrum solo
Software process for individual development

Tiago Pagotto José Augusto Fabri, Alexandre L´Erario e José

Laboratório de Inovação - LABINOV Antonio Gonçalves
Universidade Tecnológica Federal do Paraná - UTFPR Laboratório de Inovação - LABINOV
Cornélio Procópio, Brasil Universidade Tecnológica Federal do Paraná - UTFPR
[email protected] Cornélio Procópio, Brasil
{fabri,alerario}@utfpr.edu.br

Resumo – No Brasil existem muitas microempresas de software representam cerca de 10% da força produtiva do setor de
com um único desenvolvedor (desenvolvedor solo). Em pesquisa software (fonte: ministério do planejamento do Brasil). Aliado
realizada pela Secretaria de Política de Informática do Ministério a este número, o Brasil forma anualmente cerca de 40 mil
de Ciência e Tecnologia foi apontado que cerca de 60% das profissionais na área de Tencologia da Informação (fonte:
empresas de software consolidadas no mercado, iniciaram suas ministério da educação do Brasil), estes profissionais carecem
atividades com somente um desenvolvedor. Em sua maioria, estes de um processo de produção para o desenvolvimento de seus
desenvolvedores individuais não utilizam, formalmente, um trabalhos de conclusão de curso.
processo de software. Neste ponto, este trabalho tem como
objetivo apresentar um processo que possa ser usado de maneira O Scrum Solo, criado em 2012 pelos autores deste trabalho,
formal por estes desenvolvedores solo – o Scrum Solo. se caracteriza como um processo iterativo e incremental que
Inicialmente, o procedimento definido foi experimentado no une as boas práticas delineadas pelo Personal Software Process
desenvolvimento de software para o Laboratório de Inovação da (PSP) e pelo Scrum. O processo proposto neste trabalho vem
Universidade Tecnológica Federal do Paraná. Posteriormente, suprir a ausência de um processo para desenvolvedores solo,
vários alunos desfrutaram do Scrum Solo para a elaboração de fato este apontado no parágrafo anterior.
seus trabalhos de conclusão de curso. Atualmente, muitas
empresas que trabalham com o desenvolvimento individual se O objetivo deste artigo é justamente descrever o processo e
beneficiam do processo retratado neste documento. apresentar sua aplicação no desenvolvimento de parte de um
pequeno projeto de software.
Palavras Chave – Metodologia Ágil; Scrum; Personal Software
Process (PSP); Scrum Solo. Adicionalmente, o processo proposto neste trabalho é
amplamente utilizando pelos alunos dos cursos de Engenharia
Abstract— In Brazil there are several small software companies da Computação e Tecnologia em Análise e Desenvolvimento
with only one developer (solo developer). In a survey conducted de Sistemas da UTFPR - campus Cornélio Procópio. Além
by Secretaria de Política de Informática of Ministério de Ciência destes, no Paraná, muitas empresas que possuem um único
e Tecnologia has been indicated that about 60% of market desenvolvedor também utilizam o Scrum Solo.
consolidated software companies started their activities with a
single developer. The majority of these developers does not Para atingir o objetivo traçado, o trabalho foi segmentado
formally make use of a software process. At this point, this work da seguinte maneira: as seções II e III apresentam uma visão
aims to present a formal software process for solo developers – geral do Scrum e do PSP; já a IV descreve o Scrum Solo; na V
the Scrum Solo. Initially, the defined procedure was experienced é retratada uma aplicação do Scrum Solo em parte de um
in software development for the Laboratório de Inovação of pequeno projeto de software; e, por fim, as seções VI e VII
Universidade Tecnológica Federal do Paraná. Afterwards, abordam, respectivamente, os resultados e as considerações
several students made use of Scrum Solo to elaborate their finais.
completion of course works. Nowadays, plenty software
companies working with individual development benefit from the II. SCRUM
process described in this document.
O Scrum é um framework ágil (vide Figura 1) para
Keywords: Agile; Scrum; Personal Software Process (PSP); gerenciamento de projetos que se destaca por sua abordagem
Scrum Solo. enxuta (lean) de desenvolvimento [2]. Inicialmente, ele foi
utilizado em empresas de fabricação de automóveis e produtos
I. INTRODUÇÃO de consumo. Essas empresas notaram que projetos usando
No Brasil, atualmente existem muitos desenvolvedores de equipes pequenas e multidisciplinares (crossfunctional)
software que trabalham individualmente (solo). Estes produziram os melhores resultados, e associaram estas equipes
altamente eficazes a formação Scrum Rugby (utilizada para
reinicio do jogo em certos casos). Jeff Sutherland, John B. Projeto de alto nível: são desenvolvidas especificações
Scumniotales e Jeff MacKenna documentaram, criaram e externas para cada requisito a ser construído. Protótipos são
implementaram o Scrum na empresa Easel Corporation em construídos quando existe incerteza. Todo tempo e esforço para
1993, incorporando estilos de gerenciamento observados por a construção do projeto em alto nível devem ser registrados e
Takeuchi e Nonaka [3]. Em 1995, Ken Schwaber formalizou a monitorados;
definição de Scrum e ajudou a implantá-lo no
desenvolvimento de software em todo mundo [4]. C. Revisão do projeto de alto nível: métodos de verificação
formal são aplicados para descobrir possíveis erros no projeto.
Por ser um modelo iterativo e incremental, o Scrum divide Vale ressaltar novamente, que todo tempo e esforço para a
o projeto em vários sprints (ciclos curtos de desenvolvimento) construção da revisão do projeto devem ser registrados e
consecutivos que ocorrerão de acordo com a prioridade do monitorados;
product owner (proprietário do produto). Cada período de
sprint é definido, geralmente, entre duas e quatro semanas. D. Desenvolvimento: o projeto é refinado e reavaliado. O
Durante esse tempo, o scrum team (analista e programadores) código é gerado, revisado, compilado e testado. As métricas de
se dedica ao máximo para ter um pequeno conjunto de registro e monitoramento do tempo e esforço também são
funcionalidades codificadas e testadas [4]. mantidas no desenvolvimento;

A primeira atividade de cada sprint é uma reunião de E. Pós conclusão: usando as medidas e as métricas coletadas
planejamento (daily scrum meetings) do mesmo, na qual em todas as atividades anteriores, a efetividade do processo é
product owner e scrum team conversam sobre as prioridades determinada por meio de uma análise estatística. Essas medidas
do product backlog (lista de requisitos ou funcionalidades a e métricas devem fornecer diretrizes para a modificação do
serem desenvolvidas no software) e, assim, definem o sprint processo de modo a aperfeiçoar sua efetividade.
backlog (lista de requisitos ou funcionalidades que serão Adicionalmente, deve-se ressaltar que o PSP é o resultado
implementadas na sprint). Ao finalizar um sprint, é realizada de uma adaptação do CMMI (Capability Maturity Model –
outra reunião na qual ocorre a revisão e a demonstração das Integration) para o nível individual e é dividido em sete níveis
funcionalidades produzidas; com isso, obtem-se um feedback de maturidade, sendo estes [7]:
do product owner, o que pode levar a alterações nas
funcionalidades recém-entregues e incrementações no product  Nível 0 (PSP0): o desenvolvedor irá institucionalizar o
backlog [4]. seu processo de produção de software e registrar o tempo
de desenvolvimento dos artefatos gerados.
 Nível 0.1 (PSP0.1): o desenvolvedor adota um padrão de
código e estabelece uma métrica de software.
 Nível 1 (PSP1): o desenvolvedor utiliza as métricas para
estimar o tamanho e a complexidade do projeto.
 Nível 1.1 (PSP1.1): o desenvolvedor irá planejar e
Figura 1. Fluxo do Scrum executar o teste utilizando o seu relatório utilizando, para
isso, métricas e a base de experiência.
Esta seção apresentou uma visão geral do Scrum, a próxima
irá caracterizar as boas práticas do Personal Software Process.  Nível 2 (PSP2): o desenvolvedor tem a possibilidade de
promover a revisão do código e do design.
III. PERSONAL SOFTWARE PROCESS (PSP)
 Nível 2.1 (PSP2.1): o desenvolvedor tem condições de
O PSP é um processo de melhoria projetado para ajudar os construir seus guias e templates.
desenvolvedores a controlar, administrar e aperfeiçoar sua
competência para produzir software de qualidade. O propósito  Nível 3 (PSP3): possibilita o refinamento cíclico do
do PSP é ajudar o desenvolvedor a melhorar a sua forma de processo.
trabalho, entendendo sua própria performance e sabendo onde e
Feita a formalização do Scrum e do PSP, a seção seguinte
como melhorá-la. A filosofia por trás do PSP é que a
trata a temática deste artigo, o framework Scrum aplicado à um
competência de uma organização para construir softwares de
único desenvolvedor.
determinado tamanho e grau de complexidade decorre, em
parte, da habilidade individual de seus engenheiros. O PSP se IV. SCRUM SOLO
baseia no princípio do conhecimento, avaliação e melhorias
contínuas do processo individual [3]. Como não é possível produzir softwares de maneira ad-
hoc, o Scrum Solo 1 surge como uma customização do
Este processo define cinco atividades distintas, são elas [6] processo Scrum voltada para o desenvolvimento individual de
[7]: software.
A. Planejamento: isolamento dos requisitos e, baseando-se
neles, os desenvolvedores estimam o tamanho, o tempo e os
recursos necessários. Toda a métrica é registrada em planilhas
ou gabaritos. Finalmente, as tarefas de desenvolvimento são 1
O processo Scrum Solo pode ser visualizado na íntegra no seguinte
identificadas e um cronograma de projeto é criado; endereço: http://scrumsolo.wordpress.com.
 Figura 2. Fluxo do processo Scrum Solo
Figura 4. Atividade de Requisitos do Scrum Solo
Ao analisar a Figura 2, é possível perceber que o Scrum
Solo possui características semelhantes ao Scrum  Sprint: objetiva desenvolver o conjunto de itens
propriamente dito . O product backlog e o sprint backlog selecionados a partir da product backlog em duração
máxima de uma semana. O product backlog e o
ocorrem de maneira idêntica em ambos os frameworks. No
protótipo do software são usados como entrada e, os
Scrum Solo, é proposto que os sprints tenham durações
artefatos gerados nessa atividade são: sprint backlog,
reduzidas a uma semana e não existam reuniões diárias; ao produto, ata e planta de desenvolvimento (vide Figura
final de cada sprint, de forma equivalente ao Scrum, deve ser 5). Nota-se que o sprint e a ata dessa atividade estão
entregue, pelo desenvolvedor, um protótipo do software com diretamente ligados ao desenvolvimento (atividade do
novas funcionalidades e, podem existir, quando necessário, PSP – item D).
reuniões de orientação entre o grupo de validação (clientes e
usuários finais) e o desenvolvedor [1].
É importante evidenciar também que o fato do Scrum Solo
integrar as boas práticas do framework Scrum com as
prerrogativas delineadas pelo PSP garante qualidade e
agilidade na produção do software (vide figura 3) [6].

Figura 5. Atividade de Sprint do Scrum Solo

 Deployment: objetiva disponibilizar o produto

para uso do cliente. A planta de desenvolvimento é
Figura 3. Escopo do Scrum Solo usada como entrada e, os artefatos gerados nessa
atividade são: produto e ata de validação (vide
A seguir, será descrita a especificação do Scrum Solo Figura 6).
relacionando as atividades, atores e artefatos:
A. Atividades do processo [1] [6]
 Requeriment: objetiva definir o escopo do produto,
caracterizar o cliente do produto e definir a product
backlog. As informações coletadas com o cliente e
orientador (pessoa que possui grande conhecimento
sobre o processo de software) são usadas como
entradas e, os artefatos gerados nessa atividade são:
escopo, product backlog e protótipo do software (vide
Figura 4). Percebe-se que todos os artefatos gerados
são armazenados em um repositório de dados. É
interessante que este repositório permaneça em uma
nuvem. Nota-se que o protótipo do software e o Figura 6. Atividade de Entrega do Scrum Solo
product backlog dessa atividade estão diretamente
ligados ao projeto de alto nível (atividade do PSP –  Management: objetiva planejar, monitorar e
item B). controlar o desenvolvimento do produto. O
product backlog é usado como entrada e, os
artefatos gerados nessa atividade são: estrutura
 analítica do projeto (EAP), cronograma, planilha diretamente com a atividade B do PSP – projeto de alto
de custo e planilha de controle (vide Figura 7). nível.
 Product backlog: caracterizado como uma lista de
funcionalidades que devem ser implementadas no
software. Deve ser limitada ao código da funcionalidade,
a descrição, a data da inserção e a data de seleção para a
sprint backlog. Nota-se que a data da inserção só será
preenchida quando a funcionalidade for selecionada –
vide artefato na nuvem do processo.
 Repositório do processo: caracterizado como um serviço
de armazenamento de arquivos na nuvem, este objetiva
armazenar todos os artefatos gerados durante a execução
do processo. Este repositório deve ser organizado em
Figura 7. Atividade de Gestão do Scrum Solo diretórios e o conjunto de regras para a organização dos
diretórios é de responsabilidade do desenvolvedor.
Nota-se que o cronograma e a planilha de custo dessa
 Sprint backlog: armazena o conjunto de funcionalidades
atividade estão diretamente ligados ao planejamento, à revisão
que devem ser implementadas durante aquele sprint. O
do projeto de alto nível e à pós-conclusão (atividades do PSP – sprint backlog armazena o código da funcionalidade
itens A, C e E, respectivamente). (mesmo da product backlog) e o link para acesso a planta
B. Atores do processo [1] de especificação daquela funcionalidade. Esta planta é
caracterizada pelos diagramas de: casos de uso,
 Product owner: caracterizado como proprietário do sequência, classes e entidade e relacionamento. É válido
produto. Ele irá interagir diretamente com o produto e destacar que todos os diagramas devem ser armazenados
pode ser caracterizado como uma única pessoa, por no repositório do processo. O referido artefato possui data
exemplo: gerente, contador, secretária; ou, como um de inserção da funcionalidade no sprint backlog, tempo de
grupo de usuários, por exemplo: pessoas que necessitam construção (orçado ou previsto e realizado ou real), data
de um aplicativo para verificar a disponibilidade de de validação e, por fim, se a funcionalidade é fruto de um
ônibus em todo o país. retrabalho – vide artefato na nuvem do processo.
 Desenvolvedor individual: responsável por executar o  Produto ou parte dele em funcionamento: versão do
processo e construir o produto. produto que possibilite ao cliente obter um retorno sobre
 Orientador: caracterizado como um consultor que o investimento feito na compra do software.
conhece a fundo o processo. Este possui uma visão ampla  Ata: objetiva registrar a validação da implantação de uma
da tecnologia utilizada para o desenvolvimento do funcionalidade. É utilizada no sprint e na entrega. No
produto e do escopo do projeto. sprint, a funcionalidade é validada pelo orientador; já na
 Grupo de Validação: possíveis usuários do produto entrega, a mesma é validada pelo cliente – vide artefato
gerado. Este deve participar da validação do produto, a na nuvem do processo. Este artefato se relaciona
qual deve constar na ata (artefato do processo). diretametne com a atividade E do PSP – pós conclusão.
C. Artefatos do processo  Planta de desenvolvimento: objetiva aglutinar os
artefatos que foram utilizados na especificação das
 Escopo: caracteriza o escopo do processo e os aspectos
funcionalidades. O Scrum Solo sugere que sejam
inerentes ao mapeamento dos problemas do product
utilizados os diagramas de: casos de uso, sequência,
owner. Descreve os principais pontos do software
classes e entidade e relacionamento. Porém, de acordo
(aplicados na solução de problemas), o perfil do cliente e
com a especificidade do projeto, esta planta pode ser
os itens da product backlog (requisitos funcionais) – vide
customizada. Uma ferramenta que possibilita a construção
artefato na nuvem do processo2.
dos referidos diagramas é o Astah.
 Protótipo de Software: coleciona as telas para acesso e
 Estrutura Analítica do Projeto (EAP): organograma
manipulação de dados do software, além das interfaces
que objetiva apresentar o escopo do projeto. No topo
dos relatórios. Deve-se ressaltar que todos os arquivos
deste organograma é encontrado o nome do projeto, logo
inseridos devem estar no formato .PNG e que é
abaixo, as atividades e, posteriormente os pacotes de
importante apontar o nome do item da product backlog
trabalho. Estes últimos caracterizam formalmente todo o
que representa a tela ou a interface de relatório – vide
trabalho que será feito durante a execução do projeto –
artefato na nuvem do processo. Este artefato se relaciona
vide modelo na nuvem do processo. Este artefato se
relaciona com a atividade A do PSP – planejamento.
2
A nuvem que contém os artefatos do processo pode ser acessada através do
endereço: https://goo.gl/pf7NU2. A partir deste ponto, todos os artefatos
 Cronograma: organiza sequencialmente os pacotes de
apresentados e referenciados neste item podem ser encontrados na subpasta trabalho dentro de um espaço de tempo determinado.
“TEMPLATES” com seus respectivos indicadores. Nele, pode-se apontar o responsável pela execução de
 cada atividade. O Scrum Solo sugere que se utilize o sugerida a utilização do artefato “Protótipo do Software”
cronograma no formato de diagrama de Gantt – vide mapeado anteriormente na nuvem e uma caneta comum para
exemplo na nuvem do processo. Este artefato se relaciona compor a primeira versão do documento. Através de um vídeo5
com a atividade A do PSP – planejamento. pode ser visualizado como os autores deste trabalho realizaram
a composição da interface do primeiro item da product backlog
 Planilha de custo: mapea o custo efetivo gerado durante – Cadastrar Empresas.
a execução do projeto. Ao final, tem-se, de forma
consistente, a visão de uma comparação entre o Após a execução da atividade Requeriment, o Scrum Solo
orçamento realizado previamente e os custos e tempos prevê que uma Sprint seja configurada. Paralelamente, deve-se
reais gastos no projeto – vide artefato na nuvem do iniciar a gestão do projeto por meio da execução da atividade
processo. Este artefato se relaciona com a atividade A do de Management. Pode-se perceber esse paralelismo na Figura
PSP – planejamento. 2.

V. APLICAÇÃO DO SCRUM SOLO A execução da atividade Management irá delinear os

seguintes artefatos: Estrutura Análitica do Projeto (EAP),
Nesta seção iremos aplicar o Scrum Solo no Cronograma Inicial e Planilha de Custo. É indispensável que
desenvolvimento de parte de um pequeno projeto de software. todos estes artefatos também sejam validados pelo cliente.
O principal cliente deste projeto é Laboratório de Inovação3 da
Universidade Tecnológica Federal do Paraná – campus A Estrutura Analítica deste projeto também pode ser
Cornélio Procópio. visualizada na nuvem. Nota-se que a EAP possui cinco
pacotes de trabalho: cadastrar clientes; agendar atendimento;
O software a ser construído com o apoio do Scrum Solo realizar atendimentos; relatar atendimentos realizados; e,
tem como objetivo criar um mecanismo de agendamento que relatar atendimentos a realizar. Estes pacotes são os mesmos
pode ser feito a partir de qualquer dispositivo. O referido documentados na product backlog.
agendamento é feito por empresas constantemente atendidas
pelo laboratório. De posse da EAP é necessário construir o cronograma de
trabalho, para isto, como apresentado anteriormente, o Scrum
Inicia-se a construção do software pela atividade Solo propõe ao desenvolvedor que ele utilize um diagrama de
Requeriments. Conforme relatado, essa atividade requer a Gantt para representá-lo. O cronograma de trabalho também
construção dos seguintes artefatos: Escopo, Product Backlog e pode ser visualizado no repositório deste projeto.
Protótipo de Software (vide Figura 4). Estão envolvidos
diretamente nesta atividade: desenvolvedor, orientador e Vale salientar que o cronograma desenvolvido deve ser
product owner. consistente com a EAP (todos os pacotes de trabalho definidos
no cronograma devem constar também na EAP). Observa-se
A execução da atividade de Requeriment requer uma também, que os pacotes de trabalho “cadastrar empresas” e
interação direta entre desenvolvedor e cliente. O primeiro “agendar atendimentos” serão desenvolvidos durante a
artefato gerado desta interação é o escopo do projeto. Ambos primeira sprint, ou seja, na primeira semana. Este fato
os itens, interação e escopo, podem ser visualizados na nuvem demonstra a consistência entre o cronograma e o Scrum Solo
que contém o repositório do projeto4 (local de armazenamento que prevê que as sprints devem durar uma semana.
de todos os artefatos).
O último artefato a ser construído na atividade Management
Ao analisar o artefato gerado é possível perceber (vide Figura 7) é a planilha de custo, a qual também deve
claramente algumas funcionalidades ou requisitos do software retratar todos os itens que foram inseridos na product backlog,
(no Scrum Solo estes requisitos também são chamados de na EAP e no cronograma. A planilha de custo, apresentada no
itens): cadastrar empresas; agendar atendimentos; realizar repositório deste projeto, possui o tempo e o custo orçado (em
atendimentos; relatar atendimentos realizados; e, relatar minutos) para os itens da primeira sprint. Ao final da sprint,
atendimentos a realizar. Estes itens irão compor a product após a reunião de orientação (realizada na presença do
backlog, que pode ser visualizada no repositório deste projeto. orientador), é necessário informar o tempo real destinado ao
A product backlog possui os campos: ID do item; descrição desenvolvimento do item da product backlog. Deve-se destacar
(caracteriza o nome do item); data da inserção do requisito na que a unidade de tempo (minutos) configurada no Scrum Solo
Product Backlog; e, data da seleção deste requisito para pode ser alterada de acordo com a necessidade do
compor a sprint backlog. desenvolvedor.
Após o preenchimento da primeira versão da product É importante enfatizar que o Scrum Solo caracteriza-se pela
backlog, é necessário delinear o primeiro protótipo do produto. iteratividade e incrementalidade, dentro deste contexto, os
Para realizá-lo é preciso interagir diretamente com o cliente. É artefatos gerados pelas atividades Requeriment (executada
sistematicamente ao longo do desenvolvimento do produto) e
3
O Laboratório de Inovação (LABINOV) da Universidade Tecnológica Management serão incrementados ou alterados constantemente.
Federal do Paraná, campus Cornélio Procópio, surgiu em 2014 com a missão Estes devem ser atualizados e versionados no Repositório do
de oportunizar o crescimento de empresas e projetos inovadores. Projeto.
4
A nuvem que contém o repositório do projeto pode ser acessada através do
endereço: https://goo.gl/pf7NU2. A partir deste ponto, todos os artefatos
produzidos e referenciados nesta aplicação podem ser encontrados e
visualizados na subpasta “EXEMPLO DE APLICAÇÃO” com seus 5
Vídeo disponível na nuvem do processo na subpasta “EXEMPLO DE
respectivos indicadores. APLICAÇÃO” e também no endereço: https://youtu.be/N8xmN25vDO0.
 Após a execução da atividade de Managment, será expectativas inerentes a gestão de projetos do cliente e do
executada a sprint (vide Figura 5). Para o software desenvolvedor.
caracterizado neste trabalho foram gerados o seguintes
artefatos: Sprint Backlog, Planta de Desenvolvimento, Produto VII. CONSIDERAÇÕES FINAIS
ou parte dele em funcionamento e Ata de Validação. A maior O processo descrito neste trabalho une algumas práticas do
parte destes artefatos referidos anteriormente podem ser Personal Software Process (PSP) ao Scrum. O PSP se
encontrados na nuvem do projeto. caracteriza como um processo de software que apresenta o que
Ao analisar a sprint backlog é possivel verificar a presença deve ser feito para se ter um produto de qualidade. O Scrum se
dos seguintes itens: Cadastrar Empresas e Agendar apresenta como um processo iterativo e incremental que tem
Atendimentos. Estes itens fazem parte do cronograma como objetivo sistematizar o desenvolvimento de um sofware
apresentado na atividade de Management, provendo assim uma por meio da execução de uma série de sprints. A união destes
consistência entre os artefatos gerados. “Cadastrar Empresas” dois processos geraram o Scrum Solo e, este último une as boas
também foi especificado por meio da planta de práticas apresentadas pelo PSP à sistematização produtiva
desenvolvimento, o link desta especificação também está garantida através do Scrum. O Scrum Solo transpõe a barreira
presente na sprint backlog. A data de inserção e o tempo de do que deve ser feito e apresenta como fazer, fato este
construção (em minutos) orçado também fazem parte do abordado na seção V.
escopo. Observa-se que os tempos orçados para os itens Na seção V é perceptivel que os artefatos gerados com o
equivalem com os da planilha de custo gerada na atividade de Scrum Solo são armazenados em um repositório na nuvem. É
Management. Precisa-se relevar que a data de validação do crucial que estes itens armazenados sejam colecionados em
produto e o tempo realizado devem ser inseridos no artefato ao uma página acessível ao cliente, permitindo sua visualização.
final da sprint (neste caso o tempo realizado é de 250 minutos e
data de validação ocorreu no dia 06/01/2016). O campo O Scrum Solo apresenta formalmente o Astah para
“retrabalho” tem como objetivo denotar se o item gerado automatizar a construção da planta do software. Os autores
durante a sprint não foi validado e deve sofrer alguma deste trabalho julgam que esta ferramenta reune todos os
alteração. diagramas e artefatos necessários para a construção de um
software..
O Scrum Solo prevê que a planta de desenvolvimento do
software seja desenvolvida com a ferramenta Astah 6 , Por fim, é importante realçar que o Scrum Solo encontra-se
amplamente utilizada neste trabalho. em constante evolução. Esta pode ser feita por qualquer
desenvolvedor e reportada aos autores deste trabalho.
A Ata de Validação demonstra formalmente se o item foi
aceito pelo orientador no final da sprint. AGRADECIMENTOS
Por fim, a atividade de Deployment (vide Figura 6) tem Os autores deste trabalho agradecem ao apoio,
como objetivo validar todo trabalho de desenvolvimento junto delineado para apresentação deste trabalho, da Fundação
ao Grupo de Validação. Esta atividade é de suma importância, Araucária, da Secretaria de Estado da Ciência, Tecnologia e
pois é por meio dela que o software entra em funcionamento. Ensino Superior do Paraná (SETI).

VI. RESULTADOS REFERÊNCIAS BIBLIOGRÁFICAS

Conforme relatado na introdução deste trabalho, o Scrum [1] J. A. Fabri, A. L´Erario e T. Pagotto, “SCRUM SOLO”, disponível em:
Solo foi criado em 2012. Vários desenvolvedores solo vêm https://www.scrumsolo.wordpress.com/, acessado em: 18 de fevereiro de
utilizando o referido processo com êxito. Os resultados 2016.
quantitativos e qualitativos do sucesso deste modelo são [2] M. Cohn , “MOUNTAIN GOAT SOFTWARE”, disponível em:
https://www.mountaingoatsoftware.com/agile/scrum, acessado em: 24
apresentados nos itens a seguir: de fevereiro de 2016.
 55 alunos dos cursos de Engenharia da Computação e [3] J. Sutherland, A. Viktorov, J. Blount e N. Puntikov, “Distributed
SCRUM: Agile Project Management with Outsourced Development
Análise e Desenvolvimento de Sistemas da Universidade
Teams”, Hawaii International Conference on Software Systems
Tecnológica Federal do Paraná utilizaram o Scrum Solo (HICSS’40), 2007.
nos anos de 2012, 2013 e 2014 e obtiveram sucesso no [4] K. Schwaber, “Agile Project Development with SCRUM”, capítulos 1-2,
desenvolvimento de seus produtos. Microsoft Press, 2004.
[5] W. S. Humphrey, “PSP: a Self-Improvement Process for Software”,
 Um mapeamento efetuado pelos autores deste trabalho Addison-Wesley Professional, 2005.
detectou 8 alunos e ex-alunos dos cursos de Análise e [6] R. Guoping, D. Shao e H. Zhang, “SCRUM-PSP: Embracing Process
Desenvolvimento de Sistemas da Universidade Agility and Discipline”, 17th Asia Pacific Software Engineering
Tecnológica Federal do Paraná que utilizam o Scrum Solo Conference (APSEC’10), 2010.
no desenvolvimento de produtos caracterizados como [7] W. S. Humphrey, “The Personal Software Process (PSP)”, Carnegie
software. Estes alunos relatam que o processo apresentado Mellon University, 2000.
neste artigo supre as necessidades eminentes na produção
de software. Segundo os ex-alunos, o processo atende as

6
A ferramenta Astah está disponível no endereço: http://www.astah.net/.