Embed Size (px)
Citation preview
Desenvolvimento ágil e práticas Lean
Renan Daré1, Marcos Abreu2
1Gerenciamento de projetos de T.I - Pontifícia Universidade Católica (PUCPR)
Caixa Postal 17.315 - 80.215-901 - Curitiba - PR - Brasil
2Professor orientador - Pontifícia Universidade Católica (PUCPR)
Caixa Postal 17.315 - 80.215-901 - Curitiba - PR - Brasil
[email protected], [email protected]
Resumo. Este artigo tem como objetivo comparar as diferentes técnicas
utilizadas no desenvolvimento ágil e práticas Lean, a fim de levantar os desafios
na implantação, os benefícios obtidos com as técnicas e elaborar um plano de
ação com base nesta pesquisa, para implantação em uma equipe de quatro
desenvolvedores de software de uma empresa brasileira de tecnologia.
1. Metodologias de desenvolvimento de software
Dentre as diversas metodologias utilizadas em desenvolvimento de software, podemos
destacar entre elas:
1.1. Modelo em cascata
Descrito pela primeira vez em 1970 por Winston W. Royce, um cientista da computação,
em seu artigo “Managing the development of large software systems”, este modelo tem
como objetivo seguir uma sequência linear de desenvolvimento, ou seja, uma sequência
cronológica, é composta por sete passos, sendo eles: requerimentos do sistema,
requerimentos do software, análise, design, codificação, testes e manutenção, conforme
mostra a figura 1. Em seu artigo, Royce faz críticas a este modelo principalmente quanto
a dificuldade de validação dos resultados gerados a cada fase, dificultando ao cliente saber
exatamente o que esperar do software até as últimas fases do projeto, dificultando também
o controle do tamanho, custo e cronograma do projeto. Royce propõe ajustar o modelo
através da inclusão de iterações e na elaboração de documentação para suportar estas
iterações. Seus principais pontos negativos são: 1. Alto impacto no produto caso um erro
de requisito for encontrado, ou uma mudança precisar ser feita, fazendo com que projeto
volte ao ciclo desde o início. 2. O produto só é testado no final do ciclo, e uma vez que
uma etapa for concluída os desenvolvedores não podem voltar a um estágio anterior para
fazer alterações.
Figura 1. Representação gráfica do fluxo do modelo em cascata, criado por Winston W. Royce - Managing the development of large software systems.
1.2. RUP (Rational Unified Process)
Segundo Philippe Kruchten criador do livro “The Rational Unified Process An
Introduction – Third Edition” em 2003, RUP é: “Um processo de engenharia de software
que captura muitas das melhores práticas em desenvolvimento de softwares modernos e
apresenta-os em uma forma adequada para uma ampla gama de projetos e organizações.”.
O ciclo de vida do RUP está baseado no modelo Espiral proposto por Boehm. RUP é
documentado utilizando a UML (Unified Modeling Language) para ilustrar os processos
em ação, e é composto por quatro fases, e nove disciplinas, sendo suas fases: Iniciação,
que tem como objetivo definir o escopo do projeto e sua motivação comercial; elaboração
tem como objetivo analisar as necessidades em detalhes; construção, onde se dá início
efetivamente a produção de design e código-fonte do software; e transição, onde o sistema
é entregue aos usuários. Suas disciplinas são: Modelagem de negócios, Requisitos, análise
e design, Implementação, Teste, Implantação, Gerenciamento de configuração e
mudanças, Gerenciamento de projetos e ambiente, ver figura 2. Dentre as vantagens na
sua utilização estão: 1. Uso de um ciclo de vida iterativo e incremental; 2. Uso de artefatos
como resultados das etapas e iterações definidos através de uma especificação formal
(UML); 3. Suporte à gestão de riscos através da fase de Elaboração. Como principal
desvantagem está o alto nível de complexidade para projetos de pequeno porte e quando
aplicado em algumas áreas exige certo nível de experiência da equipe.
Figura 2. Representação gráfica das fases do modelo RUP. Fonte: Wikipédia.
1.3. Práticas Lean
Criada no início da segunda guerra mundial, foi idealizada e implementada na Toyota,
por Taiichi Ohmo, e utilizada na linha de produção para guiar processos industriais, por
esta razão também recebe o nome de “toyotismo”. O Lean tem seus princípios voltados
para a eliminação de desperdícios, excelência na qualidade, criação de conhecimentos,
adiar decisões e comprometimentos, entregas antecipadas, respeitar pessoas e equipes, e
otimizar o todo. O método Lean propõe em seu fluxo sempre, construir, mensurar e
aprender (figura 4). Dentre os pontos positivos de se utilizar Lean estão: 1. Máximo
envolvimento das pessoas no processo de desenvolvimento; 2. Evitar desperdícios e
ampliar o valor agregado entregue ao cliente. 3. Trabalho em equipe com objetivo de
ganhar tempo e eliminar o tempo ocioso. Sua maior desvantagem está na necessidade de
mudanças nos hábitos culturais da organização, há quem considere também o aumento da
concorrência entre os funcionários causados pela disputa de melhores resultados entre si,
sacrificando o trabalhador com intuído de aumentar sua produtividade.
Muitas das propostas dos métodos chamados ágeis, como por exemplo XP e Scrum, são
propostas de trazer para o desenvolvimento de software as práticas de eliminação de
desperdício desenvolvidas na indústria de transformação.
1.4.XP (Extreme Programming)
Criado em 1996 por Kent Beck (1999) um engenheiro americano de software com intuito
de evitar especificações formais e rígidas, para um processo de projeto colaborativo e
interativo. É definido por Vinícius Teles no livro “Extreme Programming” como: “Um
processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor
de cada dia de trabalho da equipe de desenvolvimento.” Além disso, o XP se baseia em
cinco valores principais: o feedback, a comunicação, a simplicidade a coragem, e o
respeito. Possui treze práticas (Cliente Presente, Planejamento, Reuniões em pé,
Programação em Par, Desenvolvimento Guiado pelos Testes, Refatoração, Código
Coletivo, Código Padronizado, Design Simples, Metáfora, Ritmo Sustentável, Integração
Contínua e Releases Curtos). No XP quando o cliente aprende com o sistema e reavalia
suas necessidades, ele gera feedback para a equipe. Dentre as principais vantagens da
utilização do XP estão: 1. O ganho de eficiência no desenvolvimento uma vez que os
desenvolvedores têm grande foco neste processo; 2. Aceitar mudanças contínuas; 3. Foco
na qualidade pois, ao utilizar desenvolvimento em pares, permite que o código seja
revisado constantemente enquanto é criado. Como desvantagens no uso têm-se: 1.
Limitação no tamanho da equipe, uma vez que se recomenda utilizar em equipes de até
doze membros; 2. Exige maturidade da alta direção para implantação. No artigo "The
Costs and Benefits of Pair Programming" de Laurie Williams (2001), o autor relata que
em relação a programação em pares, existe ainda uma perda em tempo gasto na solução
de problemas, em relação a utilização da programação individual, porém, segundo o
levantamento feito pelo próprio Williams, equipes que utilizam programação em pares
produzem códigos com 15% menos erros devido as validações constantes. Na figura 3 é
possível ver o fluxo do XP.
Figura 3. Representação gráfica do fluxo do processo Extreme Programming. Fonte: Google.
Figura 4. Representação gráfica do fluxo utilizado pelas práticas Lean. Fonte: www.manualdastartup.com.br.
1.5. SCRUM
Criado em 1995 por Ken Schwaber e Jeff Sutherland com o propósito de ser um conjunto
de práticas que auxiliam na gestão de um projeto, segue a teoria de que só conhecemos
algo de fato através da experiência. Scrum possui três papeis principais: o Scrum Master,
que tem como função manter os processos, o Product Owner representando os
stakeholders e o negócio como um todo, e a equipe responsável pela codificação, testes e
implementação. Scrum segue um conjunto de práticas denominadas: Product Backlog:
uma lista ordenada de trabalhos a serem realizados mantida pelo Product Owner; Daily
Scrum: reuniões diárias em pé com duração de 15 minutos no máximo e tem o propósito
de manter toda a equipe integrada e atualizada; Sprint: conjunto de histórias, que devem
ser entregues em um período que não ultrapasse um mês; Sprint Planning Meeting:
reunião regida pelo Product Owner com a intenção de informar a equipe sobre as histórias
do próximo Sprint; Sprint Backlog: uma lista de tarefas que o time se compromete a fazer
em um Sprint; Sprint Review Meeting: reunião feita ao final de cada Sprint, onde o time
mostra o que foi alcançado durante o Sprint; Sprint retrospective: reunião feita com o
time ao final de cada Sprint, tem como objetivo identificar o que funcionou bem, o que
pode ser melhorado, e que ações serão tomadas para melhorar o processo. Dentre as
vantagens desta metodologia estão: 1. Promover a melhoria contínua através de ações
tomadas após reuniões de Sprint retrospective, 2. Satisfação do cliente obtida através da
entrega contínua de pequenos pedaços de software. As principais desvantagens são: 1.
Em alguns casos existe a ausência de documentação uma vez que a metodologia prima
por entregar versões do software ao invés de grandes documentações; 2. Exige certa
maturidade e dedicação de todos os membros para se conseguir manter níveis elevados
de comunicação.
Figura 5. Representação gráfica do fluxo utilizado nas práticas SCRUM. Fonte: www.desenvolvimentoagil.com.br.
2. O desenvolvimento ágil
Segundo Jeff Patton publicou em seu artigo “Kanban Development Oversimplified” em
2009, ágil é: “Uma mistura de uma variedade de boas ideias, de uma variedade de
fontes”.
O termo ágil surgiu em 2001 quando Ken Schwaber e Jeff Sutherland, fundadores dos
métodos SCRUM, Kent Beck (1999) representando o Extreme Programming (XP), entre
outros, se reuniram em Utah EUA, e criaram os princípios comuns entre os diferentes
métodos, dando origem a aliança ágil, e posteriormente a criação do “Manifesto Ágil”
[Agile Manifesto (2004)].
Este manifesto tem como objetivo descobrir e reunir maneiras melhores de desenvolver
softwares, que estão separadas em quatro características principais, visando:
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 contratos;
Responder a mudanças mais que seguir um plano;
2.1. Diferenças entre métodos tradicionais e métodos ágeis
Em metodologias tradicionais como o modelo em cascata por exemplo, existe grande foco
em documentação, levantamento de requisitos onde somente após cumpridas estas etapas
dá-se início a codificação, este modelo geralmente segue um fluxo linear de trabalho, ou
seja, somente pode-se passar para a próxima etapa após finalizar a anterior, e tem seu foco
voltado no produto final. Outro ponto importante está relacionado ao fato deste modelo
não estar suscetível a mudanças a qualquer momento, o que causa certa desvantagem em
relação a metodologias ágeis, uma vez que uma mudança seja necessária, é preciso
documentar e aprovar novamente, reiniciando todo o ciclo. Desta forma não há a sensação
de sucesso progressivo existente nas metodologias ágeis obtida após cada entrega do
software, e sim, somente quando o software é entregue por completo.
Os processos ágeis promovem desenvolvimento sustentável, atenção a excelência técnica
e bom design, dão maior agilidade ao desenvolvimento, e tem a simplicidade como fator
essencial. Além disso, em processos ágeis acredita-se que, as melhores arquiteturas,
requisitos e designs nascem de equipes auto organizáveis, e, refletir sobre como se tornar
mais eficaz, realizar os ajustes necessários, estão entre os princípios comuns nos
processos ágeis. Em metodologias ágeis parte-se do princípio que entregar pequenas
parcelas do software gera valor agregado ao cliente, e tem-se o foco voltado as pessoas
ao invés de processos.
Dentre as principais técnicas adotadas por Ryan Polk como ágil, em seu artigo “Agile &
Kanban In Coordination” em 2011, estão:
User Stories: Definições de alto nível de um requisito contendo informações suficientes
para que os desenvolvedores possam produzir uma estimativa do esforço para
implementá-lo.
Acceptance tests: Descrição formal do comportamento de um produto de software,
geralmente expressa como um exemplo ou uma situação de uso.
Iterative Development: Estratégia de desenvolvimento onde partes diferentes do
software são desenvolvidas em paralelo e integradas quando finalizadas.
Burn-Down Charts: Gráfico que demonstra a evolução do esforço versus o tempo sobre
as User’s Stories.
Project Boards: Quadro que contém os backlogs do Sprint corrente. Tem o objetivo de
tornar as informações visíveis a toda a equipe.
Daily Stand Ups: Reuniões diárias em pé de no máximo 15 minutos tem como intuito
manter toda a equipe informada sobre o andamento das tarefas.
TDD (Test-driven development): Prática onde se desenvolve primeiro o caso de teste,
depois se codifica.
Continuous Integration: Prática que tem como objetivo minimizar a duração e o esforço
de cada item e entregar a partes do produto ao cliente a qualquer momento.
Já Kazuhiro Matsuo, professor no Instituto de tecnologia de Kanazawa, e Shota Anzawa,
aluno de graduação do mesmo instituto, revelaram em seu artigo “Work in Progress -
Project Pratices of Agile Software Development for Undergraduate Students“ (2010) que
utilizaram outras técnicas, são elas:
TiDD (Ticket-Driven Development): Gestão de tarefas no ciclo de vida de
desenvolvimento de software usando ferramentas de relatório de erro, geralmente utiliza-
se JIRA;
Pair Programming: Os membros do projeto fazem suas tarefas de programação em
pares;
Automated Testing: Criar rotinas de testes automatizadas capaz de praticar testes em um
software automaticamente;
Code Coverage: Rotina de testes utilizada para descrever o grau em que o código-fonte
de um programa é testado, tem o intuito de evitar bugs e geralmente utiliza-se a ferramenta
EMMA.
Além destas técnicas citadas, existem outras três técnicas de grande importância quando
se utiliza metodologia ágil em desenvolvimento de software, são elas:
Sprint Review: Reunião realizada ao final de cada sprint incluindo o time, Product
Owner, Scrum Master, Stakeholders, gerência e clientes, a fim de avaliar se os objetivos
do Sprint encerrado foram atingidos.
Sprint Retrospective: Reunião que ocorre ao final de cada sprint contendo somente o
time, com o propósito de identificar o que funcionou bem no sprint que se encerra, o que
pode ser melhorado e que ações serão tomadas para melhorar nos próximos sprints.
Quadro Kanban: Consiste em um sistema representado por um quadro, onde cartões que
representam o trabalho seguem um fluxo pré-estabelecido de estágios geralmente
separados em colunas. Na medida em que o trabalho vai evoluindo, os cartões vão
mudando de estágio, e sempre que um novo trabalho é identificado, um novo cartão é
criado e adicionado ao quadro.
3. Desafios na implementação ágil
Ryan (2011) mostra como muitas equipes implementam erradamente as práticas ágeis.
Dentre os principais equívocos encontramos:
3.1. Reuniões diárias sem propósito
Fazer reuniões diárias de 15 minutos não é suficiente. A reunião diária é o momento onde
cada membro da equipe informa o que fez, o que pretende fazer e quais impedimentos
encontrou desde a reunião anterior. O objetivo desta reunião é manter a equipe sempre
atualizada sobre as tarefas, tomar decisão em casos de impedimentos ou problemas e
também para que seja criado um plano de ação para as próximas 24 horas. Estas reuniões
perdem seu propósito em alguns casos bastante comuns, ou seja, quando o assunto se
torna extremamente técnico, quando são usadas para planejamento, quando somente o
Scrum Master fala, quando a conversa é direcionada somente ao Scrum Master, e por fim,
obviamente quando as reuniões são canceladas. Ryan relata em seu artigo que alguns
membros da sua equipe passaram a faltar regularmente das reuniões diárias em pé, e
percebeu que muitos deles não conseguiam finalizar seus trabalhos dentro das iterações,
criou-se então uma equipe com menor número de membros e maior estrutura imaginando
que estes membros seriam capazes de se auto organizar e executar seus trabalhos, Ryan
começa então a utilizar o método Kanban para controlar o ambiente e gerenciar o trabalho.
3.2. Uso de ferramenta de controle de bugs para coordenar a equipe
Ferramentas de controle de bugs são muito boas para registrar as pendências, visualizar
as demandas e até mesmo para auxiliar no processo de qualidade, mas não ajudam a dar
uma direção e propósito bem definido para o trabalho. Ryan (2011) percebeu isso quando
cita que os trabalhos eram distribuídos pelo Product Owner e conforme a demanda
chegava, o próprio Product Owner definia para qual equipe ia o trabalho, tentavam-se
quebrar as tarefas por trabalho individual e/ou características de cada equipe, mas no final
estes acabavam abrangendo todas as equipes.
3.3. Ausência de um processo de estimativa
Segundo Hazan (2008), a estimativa em softwares é uma atividade que pode ser aplicada
em todas as fases do ciclo de vida de um projeto, e com ela é possível chegar a métricas
para prever custos e prazos necessários para se desenvolver um software. Uma das
principais dificuldades encontradas no processo de estimativa é a falta de base para
comparação, é preciso antes formar esta base para depois conseguir estimar. Uma das
formas de se conseguir formar esta base é quebrando as estórias em tarefas e estimando
estas tarefas em horas, por outro lado, este tipo de estimativa pode se tornar uma meta,
fazendo com que a equipe se force a cumpri-la, comprometendo a qualidade e o grau
assertividade das estimativas. James Grenning (2002) criou uma técnica de estimativa
chamada “Planning Poker” que consiste em um jogo de cartas feito com a equipe onde
cada membro tem 13 cartas contendo os tamanhos de 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100,
além de uma carta contendo uma interrogação, cada membro da equipe utiliza uma carta
para dar peso a uma estória ou tarefa a desenvolver, e ao final chega-se a um consenso
comum entre a equipe com relação aos valores obtidos. Dentre os benefícios da utilização
desta técnica está o entendimento do escopo, pois como cada participante estima de forma
individual, o mesmo é forçado a entender todas as funcionalidades de cada tarefa para
conseguir estimar, e consegue-se dar início a criação da base de conhecimento.
3.4. Ausência de reuniões de aprendizagem
Muitas equipes que tentam implementar metodologia ágil em seu dia-a-dia, acabam
tentando implantar ágil como uma técnica “mecânica” e pronta, e esquecem das
interações entre as equipes e a troca de experiências entre eles, tais como Sprint Planning
e Sprint Retrospective.
3.5. Estruturar a equipe é mais do que dividir por produto ou processo
A estrutura da equipe é um tema delicado pois a mesma pode influenciar na estrutura final
da aplicação: em 1968 por Melvin E. Conway publicou artigo no Simpósio Nacional de
Programação Modular mostrando haver uma forte correlação entre a estrutura das equipes
e as estruturas dos softwares produzidos pelas mesmas: "Organizações que desenvolvem
sistemas de software tendem a produzir sistemas que são cópias das estruturas de
comunicação dessas organizações." Isso demonstra o quanto o processo de estruturação
de equipes é importante para garantir um software de qualidade, uma vez que estruturar
uma equipe exige que seus membros possuam certo grau de maturidade.
4. Proposta para implantação de Práticas Ágeis em uma equipe – ação
incremental
Considerando as técnicas discutidas, e as diversas citações de experiências obtidas por
vários autores neste artigo, tomou-se a decisão de descrever uma proposta estratégica para
implantação de metodologia ágil, em uma empresa com as mesmas características da
empresa onde o autor trabalha. Fundada em 1989 atua em diversas áreas do mercado,
focada em tecnologia e educação, líder na produção de computadores no país, na parte
educacional possui aproximadamente 300 funcionários, e está presente em mais de 40
países, 14 mil escolas e atende mais de 1,4 milhões de usuários em seus sistemas. Nos
últimos doze meses sofreu diversas mudanças tanto em relação a produtos, quanto a
estrutura. Há seis meses houve a necessidade de mudança no produto e foi então decidido
desenvolver a partir desta data os sistemas em linguagem de programação C# .NET,
deixando o legado em ASP clássico aos cuidados de uma nova equipe, denominada
equipe de manutenção.
A equipe de desenvolvimento conta com nove desenvolvedores em seu quadro, que estão
subdivididos em outras duas equipes uma com cinco e outra com quatro desenvolvedores,
e cada uma destas equipes possui um coordenador técnico, responsável por retirar
impedimentos, organizar as demandas, e fazer o primeiro contato técnico com os
criadores dos projetos, acima destas duas equipes existe ainda o gerente de projetos. O
foco deste estudo é a equipe com quatro desenvolvedores denominada Equipe de Projetos.
Suas demandas, são passadas pela equipe de criação de projetos formada em sua maioria
por pedagogas, para o coordenador da equipe, que tem a função de quebrar e repassar as
tarefas aos desenvolvedores, utilizando ferramenta, Microsoft TFS (Team Foundation
Server), onde cada desenvolvedor é responsável por garantir a entrega de seus backlogs
durante o Sprint corrente. Um dos principais problemas encontrados na metodologia de
trabalho atual é a alta demanda da equipe de desenvolvimento, uma vez que os prazos de
entrega, são criados pela equipe de criação de projetos e não pelo time, desta forma o
coordenador não consegue alcançar o limite máximo do WIP para a equipe. Outro ponto
importante é a comunicação, não há formalidade nas solicitações de desenvolvimento
entre as equipes, causando inúmeras reuniões de concepção de projetos sem sucesso e
objetividade, e alto índice de bugs. São feitas reuniões em pé diariamente com a equipe
de desenvolvimento, a fim de manter atualizado o andamento de cada backlog a todos os
integrantes da equipe. Ao final de cada backlog existe um processo de testes realizados
pela própria equipe de desenvolvimento a fim de garantir a inexistência de bugs, e validar
seu funcionamento em diferentes plataformas tais como tablets e browsers diversos, após
esta validação o coordenador da equipe é responsável por aprovar o pacote que está sendo
entregue, após esta aprovação, a equipe de design e a equipe de criação do projeto também
fazem seu teste a fim de garantir que o que está sendo entregue condiz com o que foi
solicitado. Este processo de validação torna-se muito burocrático e pouco eficaz, pois é
efetuado em três ambientes diferentes, sendo um deles o ambiente de produção. Com base
neste cenário, propõe-se um plano de ação a fim de garantir a melhoria no ambiente de
desenvolvimento, e maior agilidade, com auxílio das seguintes técnicas:
Adoção da metodologia ágil SCRUM:
Propõe-se a adoção da metodologia ágil SCRUM dentre as diversas existentes atualmente
e citadas neste artigo, a fim de se obter maior desempenho da equipe e qualidade nos
softwares entregues. Escolheu-se SCRUM por ser uma das metodologias mais difundidas
atualmente, por não requerer grandes mudanças culturais na organização, também, por já
ser utilizada em outros times de desenvolvimento da mesma empresa, a fim de conseguir
comparar futuramente os ganhos obtidos em cada time com esta metodologia.
Utilização de Quadro Kanban:
Assim como Ryan (2011) utilizou este quadro para gerir e controlar a demanda de sua
equipe com sucesso, este mesmo quadro é utilizado por muitas empresas, em paralelo
com a utilização de alguma metodologia ágil, propõe-se então a utilização do quadro
Kanban juntamente com a metodologia ágil SCRUM com foco em gerir e controlar as
demandas diárias da equipe e conseguir também, encontrar o limite do WIP da equipe.
Adoção de Sprint Planning Meeting
Propõe-se realizar reuniões de Sprint Planning Meeting para dar início a cada Sprint
conforme determina as práticas ágeis, e engajar cada vez mais o Product Owner hoje
distante da equipe de desenvolvimento, a cada novo Sprint, e conseguir diminuir o fluxo
demasiadamente alto de trabalho existente sobre a equipe de desenvolvimento.
Adoção de Sprint Retrospective
Assim como Ryan (2011) também utilizava esta técnica, porém semanalmente, propõe-
se a realização de reuniões de Sprint Retrospective com todo o time de desenvolvimento,
ao final de cada Sprint, a fim de promover a melhoria contínua conforme característica
principal da técnica, e ajudar no processo de construção de uma equipe auto gerenciável.
5. Conclusão
Como pôde ser observado nas seções anteriores, seja qual for o método ágil que adotar,
eles sempre tendem a estar relacionados ao comportamento e ao relacionamento entre
pessoas de uma equipe, a participação dos clientes no desenvolvimento, e adaptação a
mudanças no decorrer do desenvolvimento. Pode-se dizer que metodologia ágil foca em
pessoas e não somente em processos, considera também a necessidade de produzir mais,
com o mesmo espaço de tempo, e, além disso, consegue-se aumentar a satisfação do
cliente com múltiplas entregas de pedaços de software. Com base neste cenário viu-se a
necessidade de implantar algumas práticas de metodologia ágil citadas acima, na equipe
de desenvolvimento denominada equipe de projetos, a fim de mitigar os problemas
encontrados atualmente por falta de gestão. Escolheram-se as quatro técnicas citadas
acima para que seja possível atingir principalmente os problemas relacionados a
comunicação e fluxo de trabalho demasiadamente alto. Com a utilização do quadro
Kanban, busca-se alcançar o limite do WIP da equipe e conseguir promover melhora no
ambiente de desenvolvimento. Também se pretende eleger um Product Owner oriundo
da equipe de criação de projetos, com o intuito de estreitar o relacionamento entre as
equipes.
Referências
Ryan Polk. (2011) “Agile & Kanban in Coordination”,
http://www.agilemethod.csie.ncu.edu.tw/agileMethod/download/2011papers/2011%20
Agile_Kanban_In_Coordination/Agile_Kanban_In_Coordination.pdf
Jeff Patton. (2009) “Kanban Development Oversimplified”,
http://jpattonassociates.com/kanban_oversimplified/
Kazuhiro Matsuo, Shota Anzawa (2010) "Work in progress - Project practices of agile
software development for undergraduate students", http://www.fie-
conference.org/fie2010/papers/1074.pdf
Laurie Williams (2001) "The Costs and Benefits of Pair Programming",
http://collaboration.csc.ncsu1.edu/laurie/Papers/XPSardinia.PDF
Melvin E. Conway (1968) "Lei de conway",
http://www.melconway.com/research/committees.html
Vinicius Manhães Teles (2004) “Extreme Programming”,
http://www.novateceditora.com.br/livros/extreme/ p.21
"Agile Manifesto" (2004), http://agilemanifesto.org/
Ken Schwaber, Jeff Sutherland (1995) "SCRUM", http://www.scrum.org/
