introdução ao framework - portal.fazenda.sp.gov.br · manifesto para o desenvolvimento Ágil de...

2017

Introdução ao FrameworkSCRUM

Enock Godoy de Souza

Introdução ao Framework SCRUM

Introdução ao Framework

SCRUM

Professor de Gestão de Projetos

O BJ ET I VO D E AP REND I Z AG EM


Apresentar aos alunos uma visão geral do Scrum paraprofissionais que ainda não estejam familiarizados comesse framework.Após o treinamento, é esperado que o público alvo estejafamiliarizado com o framework Scrum e consiga interagircom as equipes de projeto (times de desenvolvimento,Scrum Masters e Product Owners).O curso viabiliza que profissionais da área de negócioatuem como Product Owners, desde que sob a orientaçãode um Scrum Master.


Currículo do ProfessorDoutor em Administração - FEA/USP - 2012.MSc in Analysis, Design and Management of Information Systems , The London School of Economics and Political Science (LSE), University of London - 2003.Pós-Graduado em Gestão Pública - UTFPR - 2014.Pós-Graduado em Administração (CEAG) - EAESP/FGV - 2001.Bacharel em Ciências de Computação - USP/São Carlos - 1996.Certificados: Project Management Professional (PMP®), MoP® Foundation (Management of Portfolios), Prince2® Practitioner, ITIL® Expert v. 3/2011, COBIT® Foundation v. 5 e v. 4.1, Professional Scrum Master I (PSM I®) e Certified Scrum Product Owner (CSPO®).Professor de pós-graduação desde abril de 2005 (FIAP, Mackenzie, FEI, Mauá, FIA e FGV).18 artigos publicados (congressos nacionais e internacionais, revistas nacionais).Agente Fiscal de Rendas na Secretaria da Fazenda-SP desde março de 2010, incluindo um ano de experiência como Diretor Adjunto da área de Desenvolvimento de Sistemas, dois anos como Diretor Adjunto do Escritório de Projetos da área de TI e dois anos como Diretor no Centro de Gerenciamento de Projetos (escritório de projetos corporativo).19 anos de experiência em Informática (FMC do Brasil, Spectrum Engenharia, ABN-AMRO Bank, Banco Santos, BOVESPA e Secretaria da Fazenda-SP).Gerente de equipes e projetos de TI no mercado financeiro e no setor público.Hobbies: correr, andar de bicicleta, treinar Karatê.


Nova Economia InstitucionalComo as pessoas conseguem as coisas? Mercado: você compra de alguém que esteja vendendo. Hierarquia: você organiza uma empresa para produzir

algo que te interesse. Clã ou time: trabalho cooperativo ou em time de

pessoas que formam um grupo coeso (sem hierarquia,autogerenciável) para produzir algo de interesse comum a todos os elementos do grupo.

Mercado, hierarquia e clã são formas diferentes de organizar o trabalho para produzir algo; Quanto mais simples o produto, maior a probabilidade de se conseguir no mercado a um bom preço (exemplo: commodities);Conforme você não encontra no mercado, você é obrigado a montar uma hierarquia/burocracia para construir.


Nova Economia InstitucionalQuando a complexidade e a incerteza aumentam, ocorre uma falha de mercado e se torna mais barato construir pormeio de uma hierarquia;Entretanto, a complexidade e incerteza podem crescer ao ponto de ocasionar também uma falha no mecanismo de hierarquia;Quando o mecanismo de hierarquia/burocracia é insuficientepara coordenar o trabalho, a melhor solução é organizar um clã (equipe autogerenciável não formalmente hierarquizada).A Teoria Econômica por trás desses conceitos é denominada Teoria dos Custos de Transação (parte da Nova Economia Institucional) e rendeu alguns prêmios Nobel de Economia.


Nova Economia InstitucionalRonald Coase, publicou um artigo em 1937 e criou um novo campo de estudos em Economia;Foi agraciado com o prêmio Nobel de Economia em 1991.

Coase (1937) explicou que o mecanismo de mercado contém os chamados custos de transação: tempo e dinheiro para procurar vendedores, custosde negociação da compra e/ou venda, custos relacionados à elaboração do contrato, custos para inspecionar os resultados, custos para fazer o contrato ser cumprido.

Oliver E. Williamson, autor de diversos textos acerca dos Custos de Transação, foi agraciado com o prêmio Nobel de Economia em 2009.


Teoria dos Custos de Transação


Teoria dos Custos de TransaçãoMecanismos de Controle:


Teoria dos Custos de TransaçãoRelacionada com o comportamento humano;Como obter informação;Como processar informação;Assimetria da Informação.

O Modelo dos Custos de Transação contém quatro dimensões:


Teoria dos Custos de TransaçãoCaso não exista confiança, é necessário processar mais informação:

Nível de padronização:


Teoria dos Custos de TransaçãoExemplos de clãs: Células de manufatura (Toyota); Máfia Italiana; PCC, CV, ADA; Equipes SCRUM e DEVOPS.


Teoria dos Custos de Transação


Teoria dos Custos de TransaçãoNossa equipe têm os conhecimentos, habilidades e motivação para executar as tarefas?

Dinâmica “Trabalhando juntos como uma equipe” (Dinâmica da Bola).


Manifesto para o Desenvolvimento Ágil de SoftwareEstamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratosResponder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Princípios por trás do Manifesto ÁgilNossa maior prioridade é satisfazer o cliente,através da entrega adiantada e contínua de software de valor.Aceitar mudanças de requisitos, mesmono fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.


Princípios por trás do Manifesto ÁgilSoftware funcional é a medida primária de progresso.Processos ágeis promovem um ambientesustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.Contínua atenção à excelência técnica e bom design, aumenta a agilidade.Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.


Leitura Complementar

Guia do Scrum:http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf


SCRUM

Framework de desenvolvimentode sistemas baseado em conceitosmais modernos de produçãoenxuta e autogestão;

Definição oficial: Um framework a partir do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Scrum é:

Leve;

Simples de entender;

Extremamente difícil de dominar.


O que é o Scrum?

Scrum é um framework estrutural, queestá sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990;

Scrum não é um processo ou uma técnica para construir produtos. 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 das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las.


Pilares do ScrumTransparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos

definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a

própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por

inspetores especializados no trabalho a se verificar.


Pilares do Scrum

Adaptação: se um inspetor determinaque um ou mais aspectos de um processo desviou para fora dos limitesaceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o

mais breve possível para minimizarmais desvios.


Valores do Scrum


A Equipe (Time) do ScrumO Time Scrum é composto pelo ProductOwner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveise multifuncionais.Times auto-organizáveis escolhemqual a melhor forma para completaremseu trabalho, em vez de serem dirigidospor outros de fora do Time.Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.


A Equipe (Time) do Scrum (continuação)Equipes Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versãopotencialmente funcional do produtodo trabalho esteja sempre disponível.

Coloque o título da apresentação no slide mestre


Product OwnerO Product Owner (PO), ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento.O PO é a única pessoa responsável por gerenciaro Backlog do Produto. O gerenciamento do Backlog do Produto inclui: Expressar claramente os itens do Backlog do Produto; Ordenar os itens do Backlog do Produto para alcançar melhor as metas

e missões; Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; Garantir que o Backlog do Produto seja visível, transparente, claro para

todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, Garantir que o Time de Desenvolvimento entenda os itens do Backlog

do Produto no nível necessário.


Product Owner (continuação)O Product Owner é uma pessoa e não um comitê. O PO pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dositens de Backlog devem convencer o PO.Para que o PO tenha sucesso, toda a organização deve respeitar as suas decisões. As decisões do PO são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém, além do PO, tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir a partir do que outras pessoas disserem.


Ferramentas normalmente usadasProduct Vision Box É baseado no conceito de visualizar como ficará a

caixa do produto final, buscando aglutinar o time para agir na direção correta e tornar a visão do POem realidade;

É usada geralmente no início do projeto para alinharos conhecimentos sobre o negócio (construídausando a linguagem do cliente);

Construída pelo time de desenvolvimento para assegurar que a visão do que deve ser o produto foi compreendida.


Ferramentas normalmente usadasElevator Speech (elevator pitch) É um resumo usado para definir de forma rápida e simples um

processo, produto, serviço, organização ou evento e sua proposição de valor;

O termo reflete a ideia de que deve ser possível entregar uma mensagem suficientemente adequada (apesar de resumida) no tempo de um passeio de elevador, ou seja, entre trinta segundos e dois minutos.


PersonaArquétipo de um usuário do sistema (uma visão sobre o que seria o usuáriopadrão do sistema);Dicas para desenvolver personas: Comece com personas provisórias; Mantenha suas personas concisas; Separe as personas do cliente e do usuário; Escolha uma pessoa primária; Faça com que suas personas sejam críveis; Identifique o principal benefício ou problema; Teste suas personas; Conecte as personas com as histórias de usuário; Visualize suas personas; Reconheça quando o uso de personas não é a solução mais adequada.


Persona: exemplo fictício de um usuário do Waze


História de UsuárioUma ou mais sentenças em linguagem de negócio ou cotidiana do usuário final ou usuário do sistema, descrevendo o que um usuário faz ou necessita fazer como parte desua função de trabalho;São definições em alto nível dos requisitos que incluem apenas informações suficientes para que os desenvolvedores possam produzir estimativas razoáveis do esforço necessário para implementá-las.

Seguem o modelo: Como um <papel>, eu quero <alguma coisa>, para <benefício>.


História de Usuário (continuação)Exemplos: Busca por clientes: Como um usuário, eu quero procurar

por meus clientes pelos seus primeirose últimos nomes.

Modificar agendas: Como um usuário não-administrativo,

eu quero modificar minhas próprias agendas mas não as agendas dos outros usuários.

Fechar aplicação: Como um usuário fechando a aplicação, eu quero ser perguntado para

salvar se eu tiver feito qualquer alteração em meus dados desde a última gravação.


GroomingRefinamento do backlog do produto, às vezeschamado de grooming, em referência a mantero backlog limpo e organizado;Esta atividade ocorre regularmente e pode ser uma reunião oficialmente agendada ou uma atividade contínua. Algumas das atividades que ocorrem durante este aperfeiçoamento do backlogincluem: Remover histórias de usuário que não sejam mais relevantes; Criar novas histórias de usuário, em resposta a novas necessidades descobertas; Reavaliação da prioridade relativa das histórias; Atribuir estimativas a histórias que ainda não tenham sido estimadas; Corrigir estimativas à luz das informações recentemente descobertas; Dividir histórias de usuário que sejam de alta prioridade, mas estejam

estimadas de forma superficial (grosseira) para caber em uma próxima iteração.


Equipe (Time) de DesenvolvimentoO Time de Desenvolvimento consistede profissionais que realizam o trabalhode entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.


Equipe (Time) de Desenvolvimento (continuação)São auto-organizados. Ninguém (nemmesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa (não há exceções para esta regra).


Equipe (Time) de Desenvolvimento (continuação)Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento comoum todo; Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios.


Scrum MasterO Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que oTime Scrum adere à teoria, práticas e regrasdo Scrum. O Scrum Master é um líder-servidor para o Time Scrum.O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais de suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem essas interações para maximizar o valor criado pelo Time Scrum.


SprintO coração do Scrum é a Sprint, um períododelimitado de tempo (time-box) de um mês ou menos, durante o qual um produto “Pronto”,versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.


Sprint (continuação)Durante a Sprint: Não são feitas mudanças que possam por

em perigo o objetivo da Sprint; As metas de qualidade não diminuem; O escopo pode ser esclarecido e

renegociado entre o Product Owner e o Time de Desenvolvimento, quanto mais for aprendido.

Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.


EventosO Scrum prescreve quatro eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação: Reunião de planejamento da Sprint; Reunião diária; Reunião de revisão da Sprint; Retrospectiva da Sprint.


Reunião de Planejamento da SprintO trabalho a ser realizado na Sprint éplanejado na reunião de planejamentoda Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.Reunião de planejamento da Sprintpossui um time-box com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box.


Reunião de Planejamento da Sprint (continuação)A reunião de planejamento da Sprintresponde as seguintes questões: O que pode ser entregue como

resultado do incremento da próxima Sprint?

Como o trabalho necessário para entregar o incremento será realizado?

A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. A meta da Sprint fornece uma direção para o Time de

Desenvolvimento sobre o porquê de estar construindo o incremento.


Planning Poker

Os membros da equipe (Scrum Team)estimam o tamanho de cada item doBacklog do Produto por meio da técnica denominada Planning Poker;Os pontos são uma medida arbitrária e, após cada Sprint, a equipe mede a velocidade(pontos que cabem em cada Sprint), paraestabelecer o ritmo do projeto;Das histórias do Backlog do Produto, a equipe seleciona a que julga ser a mais simples de todas, isto é, a que demandará menos esforço para implementação. Para essa história a estimativa será de 2 pontos, que é o menor ponto do baralho selecionado para esse primeiro Planning Poker;


Planning Poker (continuação)

Após as cartas serem mostradas, os membros da equipe que estimaram omenor e o maior valor precisam defender seu ponto de vista;As rodadas continuam até que a equipe chegue a um valor de consenso acerca do tamanho do item do Sprint Backlog.

Vale ressaltar que o processo pode ser demorado no início. Usualmente, com o tempo, a equipe aprimora o processo e começa a chegar ao consenso mais rapidamente.


Reunião Diária

A Reunião Diária do Scrum é um evento com prazo delimitado (time-boxed)de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas;Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária,e prever o trabalho que deverá ser feitoantes da próxima Reunião Diária;A Reunião Diária é mantida no mesmohorário e local todo dia para reduzir a complexidade;Para agilizar o tempo e reforçar o cumprimento do time-box, essa reunião costuma ser feita em pé (standup meeting).


Reunião Diária (continuação)

Durante a reunião os membros do Time de Desenvolvimento esclarecem: O que eu fiz ontem que ajudou o

Time de Desenvolvimento a atendera meta da Sprint?

O que eu farei hoje para ajudar o Time de Desenvolvimento atendera meta da Sprint?

Eu vejo algum obstáculo que impeçaa mim ou o Time de Desenvolvimentono atendimento da meta da Sprint?


Burn Down Chart


Reunião de Revisão da Sprint

A Revisão da Sprint é executada no final daSprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint , oTime Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar, obter comentários e promover a colaboração.Esta é uma reunião com prazo delimitado de 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor.


Reunião de Retrospectiva da Sprint

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar umplano para melhorias a serem aplicadas na próxima Sprint(lições aprendidas);A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antesda reunião de planejamento da próxima Sprint;Esta é uma reunião com prazo delimitado de 3 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor.


Backlog do Produto (artefato)

O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto. O Backlog do Produto é a origem única dos requisitos para qualquer mudança a ser feitano produto;O Product Owner é responsável pelo Backlogdo Produto, incluindo seu conteúdo, disponibilidade e ordenação;Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e mais bem entendidos;O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem;


Backlog do Produto (continuação)

O Backlog do Produto é dinâmico, mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil;O Backlog do Produto existirá enquanto o produto também existir.


Backlog da Sprint (artefato)

O Backlog da Sprint é um conjunto de itensdo Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint;O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”;O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint.


KANBAN

Em japonês, significa literalmentesinal visual;A metodologia Kanban se baseia em transparência total e comunicação em tempo realsobre capacidade;Dessa forma, o quadro doKanban é visto como a única fonte da verdade (source of truth) doque está ocorrendo com o trabalho da equipe.Observação: o Kanban não é parte do SCRUM, mas é muito usado atualmente em times de desenvolvimento, de forma integrada ao Scrum ou isoladamente.


KANBAN: Exemplo


KANBAN: Cartões


Modelo de KANBAN do RH-Folha


Scrum x Kanban


SCRUM

Pontos fortes: Por ser adaptativo, lida muito bem com as

mudanças no escopo; As equipes de desenvolvimento trabalham de

forma mais motivada com esse modelo (em geral, as pessoas se sentem “mais satisfeitas com o trabalho”, “mais felizes”).

Pontos fracos: Foco em projetos de desenvolvimento; Geralmente não aborda outros aspectos do projeto (projetos não estão

restritos apenas ao desenvolvimento); Como o planejamento detalhado é restrito a 2 sprints (em geral, 2

meses), os executivos se sentem inseguros quanto ao prazo; Exige uma mudança cultural para a qual nem todas as empresas estão

preparadas.


Qual Metodologia/Framework Usar?

Qual é a metodologia mais adequadapara cada cenário?Em quais casos podemos aplicar SCRUM?Em quais casos é mais adequado usarmetodologias tradicionais (Prince2TM ou alguma metodologia baseada nas melhores práticas do PMI®)?


Complexidade x Incerteza

Ref: Burns; Dennis (1985)


Complexidade x Incerteza

Ref: Hartman (2000)


Tamanho x Complexidade

Ref: Goodyear; Nelson (2007, p. 310)


Consenso x Certeza

Ref: Schwaber (2004, p. 5)


Princípio do Reducionismo Limitado

Fonte: Mathiassen & Stage (1992)


Princípio do Reducionismo Limitado

Fonte: Mathiassen & Stage (1992)

Quando adotamos especificações e aumentamos a incerteza, é necessário usar contramedidas experimentais;Quando adotamos prototipação e aumentamos a complexidade, é necessário usar contramedidas analíticas.Solução: métodos híbridos.


Dinâmica: Fábrica de Aviões

Desenvolver aviões conforme solicitado pelo Product Owner (professor).


Referências

BURNS, R. N.; DENNIS, A. R. Selecting the Appropriate Application DevelopmentMethodology. Data Base. (19–23), Fall/1985.

CIBORRA, Claudio. Teams, Markets and Systems: Business Innovation and Information Technology. Cambridge, UK: Cambridge University Press, 1993.

DE SOUZA, Enock Godoy; REINHARD, Nicolau. Escalation Risk Factors in e-GovernmentProjects: A Multiple Case Study. In: Electronic Government and Electronic Participation, 2012, Kristiansand, Norway. Joint Proceedings of Ongoing Research and Projects of IFIP EGOV and IFIP ePart. Österreich/Austria: Trauner Verlag, 2012. p. 127-138.

GOODYEAR, Marilu; NELSON, Mark R. Leadership Strategies for Large-scale IT Implementations in Government. In: MORSE, Ricardo S.; BUSS, Terry F.; KINGHORN, C. Morgan (Orgs.). Transforming Public Leadership for the 21st Century. Armonk, New York: M.E. Sharpe, 2007, p. 308-324. (Transformational Trends in Governance & DemocracySeries).


Referências

HARTMAN, Francis T. 2000. Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value With Smart Management. 1st ed. Newtown Square, PA: Project Management Institute.

Manifesto Ágil. Site Institucional. 2001. Disponível em: <http://www.manifestoagil.com.br/>Acesso em: 09/12/2016.

MATHIASSEN, Lars; STAGE, Jan. The Principle of Limited Reduction in Software Design. Information, Technology and People, Vol. 6, No. 2, 1992.

PROJECT MANAGEMENT INSTITUTE - PMI. A Guide to the Project Management Body of Knowledge - PMBOK® Guide. 6 ed. Sylva, NC: 2017.

PICOT, A.; C. BORTENLÄNGER; RÉ HRL H. Organization of Electronic Markets: Contributions from the New Institutional Economics, The Information Society, v. 13, p. 107-123, 1997.

PILCHER, Roman. Agile Product Management with Scrum: Creating products that customers love. Upper Saddle River, NJ: Addison-Wesley Professional, 2010. (The Addison-Wesley Signature Series).


Referências

SCHWABER, Ken. Agile Project Management with Scrum. Redmond, Washington: Microsoft Press, 2004.

______. The Enterprise and Scrum. Redmond, Washington: Microsoft Press, 2007.

SUTHERLAND, Jeff; SCHWABER, Ken. The Scrum Guide. 07/2016. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf>. Acesso em: 05/11/2016.

WILLIAMSON, Oliver E. Markets and Hierarchies: Analysis and Antitrust Implications. New York: The Free Press, 1975.

realização:

2017

introdução ao framework - portal.fazenda.sp.gov.br · manifesto para o desenvolvimento Ágil de...

Documents