Toda empresa em que eu já tenha trabalhado, atendido como fornecedor ou prestei consultoria até hoje tem o mesmo discurso: esse negócio de [qualquer novidade] é legal mas aqui dentro não funciona. Pode até funcionar nas empresas certinhas, mas aqui nosso negócio é muito específico, nossa tecnologia é muito específica, nossos banheiros são muitos específicos…. Tenho uma notícia para quem pensa assim: não existe empresa certinha. Todo mundo acha que é diferente dos demais.
Ainda bem que no meu trabalho as coisas não são assim. Todo mercado é dinâmico mas o de Internet chega ao ridículo, da noite para o dia todos os paradigmas mudam. Ao mesmo tempo nós somos o braço de Internet de um dos maiores grupos de mídia do mundo e temos que seguir os mesmos critérios de qualidade, agilidade e inovação dos nossos “irmãos” nos canais de TV, Jornais e Rádios.
Quando fui contratado um dos requisitos era exatamente trabalhar o processo de desenvolvimento da empresa. Não somos diferentes de ninguém, temos um processo que foi criado e adaptado por sete anos e está longe de ser perfeito, como em qualquer lugar padrão. Após algum tempo observando como as coisas funcionam começamos a introduzir mudanças.
Somos uma equipe grande (incluindo alguns colegas blogueiros) que tem como trabalho cuidar de diversos sistemas entre sites, ferramentas de edição e produção de conteúdos e utilitários diversos.
Antes da mudança que introduzimos nosso fluxo de trabalho era o mais caótico possível: alguém enviava um e-mail com algo que estava errado ou precisava ser feito. Este e-mail originava uma tarefa num Gantt Chart. Uma das minhas tarefas diárias era correr atrás da equipe com o cronograma na mão perguntando o que estavam fazendo, depois sentar na minha mesa e atualizar o cronograma. Cada desenvolvedor pegava uma tarefa, ocasionalmente dois dividiam uma mais complexa. Ao terminar o desenvolvedor enviava um pacote para a equipe de testes (nenhum teste além do eventual feito pelo desenvolvedor era feito por aqui) que testava e homologava. Eventualmente o pacote voltava e ia para produção.
A primeira providência foi acabar com o cronograma. Nós temos uma licença do Jira, que apesar dos seus problemas funcionais é um dos melhores issue trackers disponíveis. O fluxo mudou: agora o cliente enviava um e-mail, este entrava no Jira e era designado para a pessoa que dava um prazo para a solução.
Dentro os diversos problemas que ainda tínhamos era colocar coisas em produção. Para homologar, agendar para subir em uma janela, acompanhar a janela, etc etc perde-se muito tempo e a cada tarefa concluída o ciclo era repetido. Solução? Só subir software a cada 15 dias. Em vez de mandarmos 5 ou 7 pacotes por todo o processo mandávamos apenas um e desta forma economizamos muito tempo. Eventualmente conseguíamos fazer mais coisas por parar menos com distrações do processo.
O próximo problema era no mundo das prioridades. Antes alguém mandava um e-mail e olhávamos para ele. Se fosse algo muito grave no nosso ponto de vista (ou se o cliente ligasse reclamando) nós colocávamos a alteração no topo da lista, caso contrário ia para quando “tivéssemos tempo” (i.e. nunca). Obviamente o cliente não ficava satisfeito com essa priorização e nós perdíamos muito tempo trabalhando no que era importante para nós sem saber se era importante (ou mesmo útil!) para o cliente ou não.
Solução? Jogo do Planejamento. Temos diversos clientes internos (e alguns milhões de externos) então elegemos o grupo que realmente representa nossos clientes. Em reuniões semanais de uma hora nós passávamos todas as issues abertas (depois da primeira reunião isso foi rápido) e agendamos possíveis subidas para estas. O cliente pode alterar qualquer iteração, menos a que está em execução. Quando o sistema vai para o ar o cliente recebe uma lista com todas as modificações que subiram para testar e mandar o feedback.
Estava melhor mas ainda não era o ideal. Nossos projetos ainda eram planejados em extensos Microsoft Projects que em algumas semanas perdiam sua sincronia com… o mundo real. A visão era de que o esquema de Jira/Jogo do Planejamento/Release de 15 dias funcionava bem para a manutenção mas não para projetos.
Então mudamos algumas coisas. Após quatro membros da equipe participarmos do curso de Scrum da Teamware nós resolvemos colocar em prática alguns conceitos, melhorando o processo utilizado para manutenção de maneira que servisse para nossos projetos.
Colocar em prática? Como assim?!? O projeto já possui cronograma definido, equipe definida, o escopo vêm sendo discutido há meses! Por que não esperar uma boa oportunidade, com tudo calmo? Simples: porque ela não vai acontecer. Qualquer empresa que queira se manter competitiva vai estar sempre bolando algo novo e mantendo suas pessoas ocupadas com isso. Oportunidade não se espera, se cria.
Para minimizarmos o risco da adoção nós introduzimos as coisas aos poucos. O foco não era implantar o processo X ou o processo Y mas sim coisas que nos ajudassem. O Scrum é um bom molde, um bom guideline. Vamos tentar implantar o molde, se virmos algo melhor ou ruim no caminho adaptamos. Vamos seguir, devagar quando necessário, mas movendo para frente.
Primeiro precisamos diminuir a importância do Jira em favor de post-its. Issue trackes são ferramentas bem interessantes, com o passar dos releases fizemos os usuários aprenderem a abrir issues no jira e acompanhar o andamento por ele (muito menos telefonemas de ’status report’!). Um dos problemas da ferramenta era presença. Para termos o Jira numa reunião precisamos de um notebook e nem todos poderiam utilizar a ferramenta ao mesmo tempo. Outro problema era a granularidade das tarefas. Outro era que cada um tinha sua lista de issues para resolver então eu passava horas (eu diria quase que 8) todo santo dia priorizando todas as issues abertas para cada desenvolvedor.
Para os desenvolvedores deixar o Jira um pouco de lado está sendo simples. Eles já não atualizavam o status dele mesmo! Eu tinha que encher o saco diariamente. Para os outros interessados no andamento do projeto não, após termos ensinado a todos a utilizar a ferramenta falar para olharem para uma outra não seria muito bem recebido. Além disso, muitos dos nossos clientes estão em outros prédios da empresa e não conseguem olhar nosso quadro. A solução encontrada foi mantêr as user stories no Jira, mas não as tarefas.
As user stories passaram a ser blogs. Quando alguém enfrenta uma dificuldade e resolve o problema ele “bloga” um comentário, mas não chega nem a atualizar o status. O uso passou a ser muito mais documental e menos de visão de status. Quando alguma story atinge o status de ‘done’ eu atualizo o status no Jira. A documentação não é tão util, já temos um wiki com especificações técnicas (segundo princípio de Agile Modeling, geralmente fotos dos whiteboards e descrições de alto nível apenas) e estou louco para me ver livre da obrigação de sincronizar com o issue tracker todo dia.
Um dos problemas é que não tínhamos espaço disponível. O escritório oferece uma boa disposição de mesas em baias de 4 pessoas, mas não há paredes disponíveis para pregarmos cartazes.
(desconte a poluição visual da minha mesa)
A solução imediata foi pregar o cartaz com os post-its num rack de servidores para desenvolvimento que fica no corredor.
Hoje já pegamos um antigo laboratório para nossas reuniões mais importantes, mas ficamos um bom tempo apenas com o rack e ainda o utilizamos. Salas de reunião ou mesmo o laboratório são fechadas e os cartazes lá dentro não estão 100% do tempo visíveis. Seguimos com o planejamento do sprint atual no rack e os outros cartazes e artefatos no laboratório. Antes que alguém pergunte tudo é registrado em câmeras digitais e como já me reportou uma vez o Vinícius sobre suas experiências as fotos nunca foram usadas além de decorar Flickrs e 8Ps.
Então todos os dias nos reunimos em frente ao rack para nosso Daily Scrum, uma reunião rápida diária. Um dos problemas que as pessoas sempre levantam para fazer este pequeno “compartilhamento de status” é a hora. Fazer muito cedo as pessoas podem não chegar, muito tarde não vai ser produtivo… bem, aqui a coisa é bem pior. Nossa equipe não exige a priori nenhuma restrição de horário, trabalhamos com pessoas que criam software e soluções, não com recepcionistas que precisam atender o telefone. Como consenso decidimos que as 11 da manhã todos estaríamos aqui. Temos ainda problemas, alguns dias falta um ou outro mas no geral vamos bem.
A reunião dura quase que exatos quinze minutos, para evitar que as pessoas se dispersem precisamos conversar algumas vezes e explicar que o foco é nos objetivos, não no desenrolar das tarefas. Outro ponto foi esclarecer que a equipe se reporta a ela mesma, não a mim. Eu viajei bastante nas últimas semanas e eles precisaram tocar sozinhos, o que fizeram com maestria.
O projeto já estava com as entregas definidas e renegociar não era uma opção. Infelizmente não conseguimos fazer reuniões de priorização com o cliente mas o responsável pela definição de negócio senta aqui do lado e nossos Sprint Backlogs, a lista de coisas que implementaremos a cada Sprint, já estavam bem definidas, com pouca margem para reagendamento (que foi devidamente utilizada).
Para fazer o pouco de planejamento que restava nós nos trancamos numa sala e estimamos todas as tarefas. Nas primeiras iterações mesmo explicando que um Story Point é dado por relatividade (primeiro você acha o mais simples depois estima os outros usando da métrica do “o quanto mais difícil é fazer X do que fazer aquele mais fácil?”) o time surgiu com valores quase que aleatórios para as tarefas, basicamente marcaram um número muito alto para todos. Nas iterações seguintes as estimativas foram ficando mais reais e hoje todos fazemos piada dos valores originais. Descobri que incluir uma reavaliação das estimativas na reunião de retrospectiva pós-sprint é útil para termos um melhor critério.
Na reunião de planejamento de Sprint nós deveríamos fazer uma versão inicial das listas do que precisamos fazer (tarefas) para atingir o objetivo (user story) de cada item do Sprint Backlog. Com medo de introduzir muita coisa nova eu optei por fazer apenas a lista da primeira Story. No final isso se mostrou irrelevante.
A empresa possui seu fluxo de processo já estabelecido e precisamos fazer nosso processo ser compatível com o das outras equipes, que inclui um grande teste de homologação no final. Antes das mudanças o desenvolvedor não executava teste algum, a equipe de QA era a responsável. Com o tempo percebemos o quanto isso era trabalhoso e propenso à erros. Uma das soluções que buscamos é ter testadores na nossa equipe mas enquanto isso não acontece nós mudamos a forma de pensar.
Lá no início da jornada o Guilherme e eu introduzimos testes unitários com JUnit no build. Demorou um pouco mas fatalmente as pessoas começaram a fazer (e as palestras do Guilherme fizeram com que pessoas de outras equipes começassem a fazer testes unitários por si só!). Quando o Bruno entrou na equipe, antes do projeto, uma das primeiras tarefas que dei para ele foi configurar o CruiseControl para fazer build e executar testes unitários. Mais problemas: não havia um servidor disponível para instalar. Conversa aqui, conversa ali conseguimos espaço num servidor de testes que roda diversas máquinas virtuais de VMWare, instalamos Ubuntu e o dito cujo (hoje usaria o Buildx), pronto. Após o CruiseControl o Bruno tratou de integrar o Fit ao nosso processo para fazermos testes de integração, e rodando com o CruiseControl.
Como ninguém tinha experiência com o Fit, o Bruno trabalhou em par com quem pegava a tarefa de implementar os testes. Com uma semana as pessoas estavam escrevendo Fixtures razoáveis, mesmo os estagiários.
Outro ponto que precisávamos testar era a interface, quase sempre web. Avaliamos o Selenium e mesmo com limitações ele parecia razoável mas não ideal. O Tiago investiu um dia integrando o Selenium no nosso build e trabalhando com test-cases em XSTL e fez o mesmo esquema que o Bruno para passar conhecimento. Agora nosso desenvolvimento só está “pronto” quando o código foi criado, com JUnit, com testes no Fit e com Selenium. O último QA achou apenas um bug em um módulo que alguém esqueceu de testar com caracteres especiais.
No primeiro Sprint eu não fiz reunião de revisão. Foi um erro cometido pela pressa mas imperdoável. No segundo nós fizemos uma reunião extremamente útil, levantamos pontos bons e ruins e colocamos num quadro (cuidado, termos fortes abaixo. ambiente irreverente é assim mesmo):
A maior parte dos pontos ruins (no “nem F$#%endo”) eram interrupções externas que eu preciso trabalhar. Minha viagem (que era um dos pontos ruins) recente fez com que os desenvolvedores respondessem por compromissos meus (outro ponto: reuniões que duram dias inteiros) , além de deixá-los sem proteção de interrupções externas (outro ponto citado) como telefonemas e até suporte a outras equipes integrando com nossos sistemas. Tirei daí que se precisar me ausentar preciso deixar alguém como Scrum Master, ainda que o time perca um membro ativo. Diluir o papel de Scrum Master causa mais prejuízos do que tirar uma pessoa do time de desenvolvedores.
Os pontos positivos incluíram o trabalho em equipe, os mecanismos de teste que ajudaram no desenvolvimento, o QA não ter encontrados bugs, a janela para produção ter sido tranquila e outras coisas que basicamente derivam da nova maneira de trabalhar.
Dos pontos ruins o que me preocupou mais foram os referentes a plataforma tecnológica da aplicação. Fizemos uma mudanças grande na direção de uma arquitetura SOA e como qualquer empresa não temos tempo de treinar todo mundo rapidamente.
O desenvolvimento desta arquitetura foi feita basicamente antes do projeto iniciar. Eu incubi o Guilherme de levantar possíveis soluções para nossos problemas de integração e esboçamos o projeto dos WebServices com tudo que tínhamos de melhor, incluindo REST. O primeiro uso desta infra-estrutura foi num projetinho bem curto que realizamos no início do ano e ela se mostrou muito boa.
O problema foi que neste projeto apenas o arquiteto (o próprio Guilherme) e eu metíamos a mão neste sistema. Quando começamos o projeto maior os conceitos ali dentro precisavam ser espalhados. Na primeira iteração com algumas cabeçadas conseguimos um desempenho bom mas ainda não o suficiente. Também vimos alguns pontos onde a arquitetura estava diminuindo muito a produtividade das entregas e que a introdução dos conceitos de WebServices REST, Hibernate/JPA, caches distribuídos e outras coisas menores precisa ser feita com mais cuidado. Algumas pessoas aprendem rápido e sozinhas, outras não e isso não tem a ver com habilidade técnica e sim com perfil (coisa, aliás, que defendo aqui desde sempre).
A solução que pensamos foi adicionar como tarefa um workshop arquitetural. Eu não queria cometer o mesmo erro e trancar o projeto na mão de um membro do time apenas (ou alguns), então nos reunimos durante a tarde. Na primeira parte da reunião o Guilherme explicou a arquitetura do início, mesmo para quem teoricamente já sabia foi útil.
Para estruturar a coisa eu pedi ao Guilherme quatro visões: a estrutura lógica (componentes), a estrutura física (servidores, bancos de dados, etc.), a de pacotes (como os módulos são divididos) e a de caso de uso (descrição do que acontece numa user story relativamente complexa do início ao fim).
Depois nós realizamos um exercício que aprendi no curso da TeamWare: cada um recebeu um bloco de post-it e uma caneta. Por cinco minutos escrevemos tudo que atrapalha nossa produtividade rapidamente, se alguém não pensasse em nada escrevia “nada” no papel. Depois discutimos cada ponto destes sorteando um de forma aleatória. Da forma escolhida para sortear surgiu o nome interno da técnica: a Dança do Siri (derivado da maneira “curiosa” de obter os papéis pelo Tiago):
Houveram poucos pontos técnicos, a maioria de infra-estrutura. Neste meio surgiram também coisas de processo como o papel dos estagiários no time. Um dos pontos levantados é de que nosso time não é tão homogêneo (e qual é?) e nem todos conseguem trabalhar em todas as partes do sistema. Uma estratégia que definimos foi de fazer pares quando ocorrerem estes casos e se tudo mais falhar partir para outra tarefa. O importante é quebrarmos os feudos de sistemas.
Todas foram discutidas, os pontos cabíveis foram anotados e mantivemos o histórico:
Na reunião para a entrega do primeiro pacote tínhamos um problema: descobrimos um erro no cronograma inicial (criado antes do projeto iniciar e antes de adotarmos o processo novo) que iria atrasar o projeto em oito dias. Começamos a reunião com uma descrição do processo de desenvolvimento para os clientes (aqueles que não participam no dia a dia do produto), revisão dos fatos ocorridos que desencadearam no atraso, o que faríamos para voltar ao rumo e a demonstração das funcionalidades. Para nossa surpresa a resposta foi excelente. Os clientes elogiaram a transparência do desenvolvimento, elogiaram o fato de verem algo em produção tão rapidamente e terminamos tendo que responder a uma pergunta: mas por que não fizemos assim antes?
Nós não implementamos o Scrum por completo (me viu falar em burndown chart aqui?), ainda falta bastante. Também não conseguimos eliminar problemas de prazo, tivemos que trabalhar algumas horas extras no último Sprint e possivelmente neste também. Algumas pessoas não se adaptaram aos novos processos e deixaram a equipe. Mas o importante aqui é que elevamos a qualidade do nosso trabalho consideravelmente -a ponto do cliente perceber- e as pessoas estão felizes em trabalhar desta forma, tanto as de fora quanto as de dentro. Paramos de correr atrás do prórpio rabo resolvendo problemas aleatórios diários e estamos trazendo resultados.
Engraçado que outro dia alguém falou comigo no corredor “Poxa, tô sabendo que vocês estão indo muito bem no projeto, heim? Perguntei pra Fulana -uma cliente- e ela disse: ‘É, eles estão gerenciando na linha dura desta vez, estilo sargentão’”.
Será?
eu sei o que acontece em webmidia mais pelo que bairos ja conversou comigo (trabalhamos juntos), mas nao sabia que voces estao “encaixando” scrum aos processos de la… muito legal phillipe, seria legal voce compartilhar tais experiencias com o pessoal la de desenv arquitetura, minha area..
abraco Fagner
Uau, ótima descrição, explanação, comentários, sugestões de como a coisa funciona e como fazer funcionar, saindo um pouco da parte teórica e mostrando os problemas, uma visão mais realista, afinal uma coisa é ler num livro, a outra é colcoar a mão na massa. Faltou, não sei se é possível, comentar qual o tamanho da equipe para se ter uma idéia.
Essa ultima interpretação, a do estilo sargentão, me lembrou aquele e-mail que você me mostrou, sobre a relação de formas de mercado com gerenciamento de projeto, e como as pessoas se confundem sobre as definições. Mas, o que importa é que a coisa está indo!
Oi, Edufa,
A equipe hoje conta com aproximadamente dez pessoas, entre scrum master, desenvolvedores e outras pessoas com integração diária com o projeto.
De ponta a ponta, incluindo pessoas envolvidas apenas em etapas, eu contaria umas 25-30 pessoas.
[]s
Para dizer o quanto gostei deste post vou tomar emprestado a frase do lado esquerdo do quadro da reunião de revisão.
Uma das melhores coisas que li em blogs nos últimos tempos. E que corrobora o que jé penso há muito tempo sobre Gantt, project, sargentões e a felicidade de fazer as coisas com paixão.
Obrigado.
Fala Phillip! Não consegui ler o post todo ainda, mas to achando já bem interessante.
Realmente falta em muita gente a ousadia de tentar o diferente assiscando um fracasso(e um sucesso!).
A gente se fala! Abraço.
Valeu Phillip.
Sua contribuição com a comunidade é fantástica e, já algum tempo venho aprendendo muito com seus artigos e posts.
Esse tipo de trabalho só nos incentiva a continuar estudando e acreditando que podemos melhorar apesar dos empecilhos diários.
Como disse muito bem o Luca, vide “frase do lado esquerdo do quadro da reunião de revisão”
Bom saber que ainda a esperança nessa area. Ainda sonho em trabalhar em um lugar assim.
Tivemos uma experiência muito similar, aqui na Siemens, que por sinal, tem processo de desenvolvimento baseados nos mais rigorosos e burocráticos CMMIs.
Meu setor, responsável por soluções de testes e inovações, veio com essa história de desenvolvimento ágil, quebrando alguns paradigmas por aqui. Fizemos uma curso com o Klaus Kleinfeld, e resolvemos colocar o XP em prática.
Vimos quais práticas seriam bem adotadas por aqui, em quais teríamos problemas (e como contorna-los) e hoje o processo está funcionando à todo vapor. A reclamação dos nossos clientes? Que somos rápidos demais, e que eles mal conseguem testar uma funcionalidade importante que outra já aparece!
Foi uma sensível melhora. Hoje os sistemas são menores, menos estressantes de se fazer, mas muito mais valiosos para os clientes. Afinal, cada pequena funcionalidade inserida é a mais importante para o cliente e, pelo processo ser rápido, ele se sente seguro em deixar para lá aquela que ele fica em dúvida se é importante ou não. Bem diferente do método mais lento, que, em caso de dúvida, ele preferia colocar o requisito no projeto “para não perder a oportunidade”.
Parabéns pelo artigo. Está muito bacana mesmo e eu reitero o que você disse lá em cima. As empresas podem até ser diferentes, mas isso não é desculpa para que não invistam num processo de desenvolvimento moderno e em inovação. As soluções estão aí, falta só um pouco de boa vontade para usa-las.
[...] O Phillip Calçado escreveu um excelente post no blog dele sobre como funciona nossa equipe de desenvolvimento ágil. [...]
Parabéns pela experiência passada, muito do que ocorreu contigo ocorre comigo.
Penso que “processos” precisam ser criados, adaptados e evoluídos para a empresa que desenvolve, processos não podem travar (assim como acontece na maioria das empresas) a criação de sistemas, metodologias ágeis ajudam e muito isso.
Muito bom! Pela primeira vez estou me dando conta do quanto já evoluimos. Só ficou faltando falar das sessões de Wii :)
Parabéns Phillip, excelente texto, já recomendei pra dúzias de pessoas, tomará que isso abra a mente de muita gente, obrigado pelo relato!
PS: estou muito feliz em ver que existe uma mesa mais bagunçada que a minha rs
Um bom relato. Ando lendo bastante sobre o assunto e vejo finalmente uma luz no fim do eterno túnel. Estou pensando em propor o Scrum na empresa que trabalho, mas vejo alguns pontos que não ajudam a encaixar:
- aqui não é fábrica de software, nossa equipe trabalha como analista de negócio/sistema, e o desenvolvimento é de terceiros, através de cotação. O que dificulta as reuniões diárias.
- atendemos demandas de várias áreas, ou seja, prioridades são diferentes. Podemos até saber a prioridade da demanda de uma área, mas pra decidir prioridade entre as áreas fica um pouco mais complicado.
Alguma sugestão?
[]´s
Parabéns pela iniciativa. Vamo que vamo!
Phillip,
Excelente post, simplesmente perfeito! Continue com o bom trabalho, está de parabéns!
Parabéns à equipe. Este relato é um verdadeiro MBA em Gestão de Projetos. Já que eu li tudo, onde pego o meu diploma?
Mas que tal uma apresentação no XPRio?
“..Agora nosso desenvolvimento só está “pronto” quando o código foi criado, com JUnit, com testes no Fit e com Selenium. O último QA achou apenas um bug em um módulo que alguém esqueceu de testar com caracteres especiais..” Essa é sem dúvida uma das maiores recompensas. Nada pior que vc entregar um “produto” todo feliz.. e um dia depois chuver ligações de reclamação de bugs e mais bugs…
Phillip, excelente post, parafrasenando o Guilherme, na correria do dia a dia a gente não repara o que já fez apenas o que tem para fazer… e realmente ahco que já andamos bastante para a frente.
Um ponto importante que venho reparado na equipe é que, com o novo processo o pessoal acaba vestindo mais a camisa, pois no daily scrum, vc assume um compromisso do que vai fazer e do que vc esta entregando, isso faz com que cada um tenha mais responsabilidade sobre o que esta fazendo e a melhor parte é que, o compromisso assumido não é com um gerente ou coordenador, mas sim com os seus colegas, com as pessoas que tb assumiram o desafio com vc.
Acho que estamos no caminho certo, seja qual for ele :-) , acho que o que importa é vc fazer parte de algo que vc acredita, é vc acordar todos os dias com vontade de compartilhar seus conhecimentos, suas experiencias, as brincadeiras, os sucessos, os erros, as frustrações e encarar os desafios que estão pela frente… nada na vida é fácil (especialmente aqui :-) … mas acho que é só assim que acabamos dando valor ao que conquistamos.
abs, Toninho
Muito bacana a iniciativa de mostrar como você adaptou algumas coisas do Scrum no seu dia a dia. Acabei de imprimir um livro na InfoQ que fala justamente sobre a experiencia pessoal do autor do livro sobre a maneira que ele faz Scrum junto com XP.
Graças a deus, ainda existem pessoas que sabem o valor da palavra adaptação. Especialmente neste mundo de TI que, infelizmente em alguns ambientes, esta ficando cheio de processos, práticas e coisas sem valor de negócio!
Bom saber que o curso da Teamware foi o pontapé inicial desta ‘brincadeira’ toda. Grande abraço e sucesso!
Olá Phillip,
É interessante ver que as mudanças introduzidas são down-up. Estou passando por uma fase muito crítica com relação aos gestores que simplesmente não conseguem enxergar que o desenvolvimento de software é “people-intensive” e muitas vezes atrapalham uma mudança importante que está emergindo dentro das equipes.
Caí na besteira hoje de mostrar os “valores ágeis” para um board de diretores na minha empresa (é, no lugar que estou tentando ser o agente de mudanças temos uma administração de 1970). Eles simplesmente não concordaram com nenhuma das 4 sentenças. (ilusão minha achar que tradicionalistas vão concordar que “working software” é mais importante que documentação extensa).
Mas SCRUM é isso aí mesmo. Foco em “working software”, muita comunicação e teamwork, foco em objetivos e não tarefas. Um time auto-organizável naturalmente vai começar a valorizar o ROI. Não vejo outras alternativas de se gerenciar um projeto de software que não foque nesses fundamentos.
Ah… não ligue para o Burndown Chart. É uma ferramenta para equipes mais indisciplinadas. Se vc está cumprindo os objetivos não precisa dele. A não ser que vc queira ficar olhando para ele para se gabar que as coisas estão andando nos eixos.
Parabéns por este excelente post!
Mesmo tendo uma experiência mínima na área, consegui através dele ter um belo panorama das dificuldades e conquistas obtidas ao se implantar um processo ágil como o Scrum.
O post foi muito bom Philip.
Relatos como estes ajudam muito a quem precisa “convencer” o cliente de que metodologias ágeis funcionam!
Parabéns!!
Josir
Oi Philip,
parabéns pelo post. Depoimentos assim são bem mais úteis que 100 mensagens retóricas marteladas diariamente em grupos de discussão e afins (o que inclui meu blog).
[]’s
Paulo
Excelente post. Resumiu muito bem toda a mudança que ocorreu ao longo do tempo, citando exemplos dos problemas e afrontando-os com as soluções sugeridas. Espero que essa boa visão que o cliente está tendo possa abrir caminho para que outras áreas consigam se agilizar mais rapidamente.
Cara, simplesmente sem palavras. Obrigado por compartilhar esse tipo de experiencia conosco, processo de desenvolvimento é algo muito bonito na teoria, mas na prática existem detalhes nao previstos.
Sorte da tua empresa ter uma equipe assim.
Aliás…quais os bons titulos de livros sobre agile e scrum?
[...] Acompanhe o excelente post na íntegra. [...]
[...] pelo post no blog Fragmental, onde a equipe da Globo.com mostra como foi implantado o SCRUM dentro do setor responsável pela [...]
Excelente post, parabéns pra equipe de vídeo da Globo!
“trabalhamos com pessoas que criam software e soluções, não com recepcionistas que precisam atender o telefone”
Essa frase deveria estar estampada em todas as empresas que trabalham como feudos. É muito bom o desenvolvedor ir para o trabalho descansado, sem sono, tranquilo e o melhor, de bem com a vida. É como você mencionou, desta maneira a coisa anda. Post maravilhoso!
[...] Phillip Calçado escreveu um post excelente sobre Agilidade, vale a pena ler. Parte do post que mais me identifiquei: “Nossa [...]
Simplesmente sensacional, parabéns pelo sucesso, quem tem talento sabe fazer a coisa acontecer.
Vejo pessoas boas por aqui.. Provando q a campanha do estadão sim é q é uma grande piada! Tb estamos seguindo na linha do Scrum na empresa e o resultado fica evidente já na segunda semana !!!
[...] this is basically a redux version from a post in my Portuguese [...]
Nossa Cara!!! Muito bom, nunca pare de escrever sobre estes temas, aprendi muito com a leitura… Abraço
Olá phillip.
Venho procurando a um bom tempo algum artigo decente falando sobre agile developmenr, e agora lendo o seu acho que encontrei o que procurava. O fato de mostrar uma experiência real aplicando essa metodologia nos deixa mais claro os benefícios que pode nos trazer.
Espero que aqui na empresa eles possam adotar essa metodologia logo, pois acredito que o processo de desenvolvimento vai subir muito de nível, sendo que hoje são utilizadas aquelas, planilhas do project que não trazem confiança nenhuma para equipe, pelo menos não para mim.
Muito bom o artigo, parabéns!
Ei Shoes,
Parabens pela post, sou André Lima e tive o prazer de assistir a sua palestra sobre esse tema em Vitória-ES, enviei um e-mail sobre a palestra para pcalcado@gmail.com, seria este e-mail mesmo? valew e aguardo resposta.
André Lima
Phillip,
parabéns pelo relato. Foi de extrema ajuda para mudanças que estou querendo implantar no processo de desenvolvimento aqui na empresa. Goataria de tirar duas dúvidas com você, se for possivel.
1) Aqui utilizamos o Jira como Issue Tracker, e nele criamos um workflow, onde depois de codificado, o status das Issues mudam para Em teste. Assim a equipe de testes (nao os testes unitários com o JUnit, mas sim de funcionalidade), sabe o que tem para ser testado e qualquer problema encontrado muda o status para Correcao. Assim tambem os desenvolvedores sabem o que tem para ser corrigido. No seu caso, onde o status e alterado por voce e somente no fim, como o pessoal sabe o que precisa ser corrigido ou o que tem pra ser testado?
2) Vocês utilizam uma ferramenta de Wiki para o projeto? Para quais informacoes voces utilizam essa ferramenta?
3) Essa ferramenta de Fit, serve exatamente pra que?
Muito obrigado.
Alessandro
Car(*)lho, Shoes, que post é esse? Li com muito atraso, mas como estou num projeto onde se esta começando a idéia de utilizar Scrum, foi muito útil. Parabéns.
André ‘dreamspeaker’ Barbosa
[...] o Phillip Calçado, que cordena uma equipe de 8 desenvolvedores na globo.com, escreveu um excelente texto sobre como adotar agilidade na sua empresa. Nesse texto o Phillip começa falando sobre essa reação negativa a respeito de novidades, e em [...]
Fala Philip! Vou acabar repetindo a frase que você já cansou de ouvir ( se bem que elgios a um bom trabalho não há quem se canse de ouvir, né )
Achei excelente o seu post!
Muito interessante ver o dia-a-dia da implantação de um novo processo, onde podemos ver os pontos negativos, os desafios e cada ponto positivo.
Parabéns! Pena que essa implantação não ocorreu no período em que estive por aí! rs
E mando uma sugestão: o que acha de um teck talk ou uma reunião da sua equipe com as outras equipes de desenvolv para difundir e tentar viabilizar a implantação?
Abração!
Phillip,
Muito inspirador este seu relato. Tão inspirador que estou fazendo minha reserva para o curso de Scrum na Caelum.
O melhor case que já vi a respeito sobre o assunto, pelo menos no que diz respeito à realidade em que vivo hoje.
Estou coordenando a implementação de Scrum em quatro equipes aqui. Nós topamos com praticamente cada dificuldade e surpresa que você mencionou. E adotamos algumas soluções muito parecidas com as de vocês. É bom saber disso pois devemos estar no caminho certo.
Estamos bem atrás no que diz respeito a parte de “baixo nível” - testes, integração contínua, etc - mas já vemos alguns bons resultados de coisas como pair programming.
Obrigado por compartilhar essa experiência. Teu blog já foi devidamente adicionado ao meu leitor de RSS.
[...] E pensem em como sua metodologia apóia este tipo de revisão de estimativa, como seu cronograma pode se adaptar a isso. Se não achou nada no seu cenário atual, mude. [...]
[...] de estar numa equipe onde não há escolha: ou se é eficiente ou não se é nada; e desta forma conseguimos introduzir muita coisa legal. Em breve deve estar visível para o público nosso primeiro projeto feito com técnicas de Scrum e [...]
[...] ..daquele projeto? Pois é, tá no ar. Mais que um site, é uma plataforma de vídeos completamente integrada com todos os outros sistemas do portal. O site é apenas um catálogo de vídeos, o projeto GloboVideos 4.2 não era sobre site, era sobre disponibilizar serviços. [...]
[...] paradigma, no Brasil apesar de ainda engatinhar sobre o assunto em uma perspectiva geral, algumas empresas já iniciaram a adoção de XP com [...]
[...] pensei na Audaces, onde o Victor está ajudando a inserir Agilidade na empresa, além disso enviei alguns depoimentos de empresas que adotaram desenvolvimento Ágil. De qualquer forma, ele aprovou utilizar [...]
[...] e feudais, precisam pensar em transmitir e gerar conforto e felicidade para seus funcionários. Veja o comentário que deixei nesse [...]