Um bom design é…

Publicado em 20 de março de 2010 por Rodrigo Yoshima

Revista de Avião é cultura. Nessa semana, num dos meus vôos pelo Brasil, deparei com um texto interessante:

BOM DESIGN É INOVADOR
BOM DESIGN TORNA O PRODUTO ÚTIL
BOM DESIGN É ESTÉTICO
BOM DESIGN TORNA O PRODUTO COMPREENSÍVEL
BOM DESIGN É DISCRETO
BOM DESIGN É HONESTO
BOM DESIGN É DURADOURO
BOM DESIGN É MINUCIOSO, ATÉ O ÚLTIMO DETALHE
BOM DESIGN É AMIGO DO MEIO AMBIENTE
BOM DESIGN É O MÍNIMO DESIGN POSSÍVEL

Esses são os 10 princípios de um bom design de Dieter Rams, um designer industrial alemão.

Perguntas:
Isso é aplicável a design de software?
Isso é aplicável a design de websites/UX?
Seus designs seguem esses princípios?

Meus exemplos de bom design: Apple, Porsche, Rails e o corpo da mulher.
Meus exemplos de mau design: Land Rover, JSF e o site da IBM.

Publicado em arquitetura, mercado | 9 comentários

Extreme Programming na Imagem

Publicado em 20 de março de 2010 por Rodrigo Yoshima

Uma das coisas que mais tem me chamado a atenção no mercado é que várias empresas tem procurado a Aspercom para contratar nosso treinamento Extreme Programming. No último mês até grandes bancos solicitaram proposta de consultoria e treinamento em XP. Algumas empresas que já arrumaram suas práticas de gestão com Scrum estão buscando melhorar a qualidade interna de suas aplicações. Nosso treinamento XP foi ampliado nesse início de ano para dar mais foco em TDD, e partir de fevereiro, ele foi direcionado somente para as plataformas Java e .NET.

A Imagem é uma empresa especializada em software de informações geográficas. Sim, assim como a Scheffer, é mais uma empresa que foge totalmente de “sisteminhas web”. Sem querer ser perjorativo: software não se limita a Websites. Os clientes da Aspercom têm me mostrado ultimamente que desenvolvimento de software é algo muito vasto. É um assunto abrangente demais. Como exemplo, apesar de gostar muito do Scrum, nos últimos 8 meses tive contato com ao menos 5 empresas onde o Scrum não rola. Isso é assunto para outro post!

Sistemas de informação geográfica (GIS) auxiliam empresas em diversos aspectos. Geralmente são empresas gigantes. Esses sistemas podem auxiliar a manutenção de linhas de transmissão de energia, o projeto de um oleoduto, a construção de uma nova fábrica, logística em lugares remotos, compreender o impacto de fenômenos naturais e muito mais. Isso envolve imagens de satélite, informações geológicas e meteorológicas e muitos cálculos complexos.

O treinamento XP e TDD na Imagem foi muito divertido. Nosso treinamento tem muitas dinâmicas, muitos pairings e a colaboração exigida nas equipes para cumprir o sistema exemplo é empolgante.

image

Parabéns a todos da Imagem. Muito sucesso nos importantes projetos e clientes que vocês têm atuado.

Publicado em agilidade, cases, extreme programming, mercado | 2 comentários

Scrum e OOAD na Scheffer Logística

Publicado em 20 de março de 2010 por Rodrigo Yoshima

No mês de fevereiro de 2010 a Aspercom esteve em Ponta Grossa ministrando treinamento para a equipe da Scheffer Logística. Antes de falar sobre o que aconteceu durante os treinamentos, assista ao video abaixo:

Eu realmente creio que modelar e implementar um domínio desses seria a tafera mais divertida do mundo. Projetos de automação como esses são desafiadores, e se você é um aficionado em orientação a objetos deve ter sentido uma vontade irresistível de modelar algumas entidades vendo este vídeo.

O treinamento da Scheffer começou normalmente, mas terminou com uma sessão de modelagem ágil, Domain-Driven Design e práticas de BDD e Design Incremental usando Fitnesse. É bastante comum um treinamento corporativo iniciar como um curso e terminar com pairings e consultoria.

A Scheffer é uma empresa nacional pioneira na tecnologia de transelevadores em armazens automatizados, um setor em franco crescimento. Foi muito interessante conversar com pessoas que trabalham com TI num domínio tão diferente. Um aspecto bastante interessante é que apesar dos métodos ágeis dizerem tanto para “abraçarmos as mudanças”, digo para vocês que existem sim projetos com escopo fixo, aonde o Scrum perde muito do seu brilho, pois usamos iterações exatamente para ter feedback e com isso, mudanças. Um projeto de automação geralmente é direcionado pelo maquinário utilizado, as restrições do escopo da automação e etc… Um cliente que tem um armazém de 20.000 metros quadrados não terá mudanças na sua forma de automação. Geralmente o projeto físico inicial (feito por engenheiros especializados) não muda, e com isso a solução do software também tende a não ter alterações vindas do negócio. Logicamente a Scheffer se beneficiará de iterações, design incremental e outras técnicas aprendidas para limitar seu próprio risco do projeto.

Parabéns a todos da Scheffer!

Publicado em agilidade, cases, gestores, liderança, scrum | Deixar um comentário

Treinamento ScrumMaster Oficial CSM

Publicado em 2 de março de 2010 por Rodrigo Yoshima

Muitos de vocês já devem ter dado uma passeada no site da Aspercom e visto o novo Treinamento ScrumMaster Oficial na nossa home ou no nosso calendário. É isso mesmo! A Aspercom em parceria com a Goldentec está oferecendo o treinamento e certificação ScrumMaster em todo o Brasil na língua portuguesa.

Todos que me conhecem sabem que sempre fui contra a certificação da Scrum Alliance. Sempre critiquei as motivações das pessoas em buscar o título CSM e o fato de não ter uma avaliação final. Sempre critiquei bastante e hoje vejo que o motivo de grande parte das minhas reclamações não era culpa da Scrum Alliance e sim da postura de pessoas sobre o CSM aqui no país. Com razão ou não, estou só dando explicações e me retratando sobre a Scrum Alliance.

No mês de janeiro conheci o Michel Goldenberg, o novo CST brasileiro e um nome muito influente dentro da própria Scrum Alliance no mundo. Ele quis me conhecer e durante janeiro conversamos muito sobre o mercado Agile no Brasil e sobre como a Scrum Alliance é na verdade com as mudanças que tem acontecido na sua organização e etc…

O Michel se mostrou um CST diferente. Antes de mais nada, ele é um “Techie Guy” com muito trabalho na comunidade Scrum no mundo. Ele trabalhou como Arquiteto de Software em grandes empresas como o ING e a Bombardier e tem experiência em implementação de projetos complexos aqui no Brasil e no exterior. Ele conhece muito bem XP, e isso me chamou a atenção, pois na Aspercom defendemos o uso do Scrum recheado de boas práticas engenharia.

Por fim, o Michel me convenceu que se quero mudar o sistema e a comunidade Scrum, a melhor maneira é fazer parte disso. No ano de 2010 firmamos uma parceria para ministrar alguns treinamentos juntos. Sim, eu também estarei presente nas classes CSM da Aspercom com o Michel. Com isso, queremos ter um treinamento CSM alinhado às necessidades que mais vejo no mercado brasileiro. Nossos diferenciais estão aqui:

1. Dois instrutores experientes em implantações Agile
2. O conhecimento será prático, como todos nossos treinamentos
3. Introdução a boas práticas ágeis de engenharia
4. O foco em conhecimento e não certificação

Com essa parceria queremos principalmente melhorar a qualidade da comunidade Scrum no Brasil, que a meu ver, vai muito mal.

Outro ponto: Sabemos que um treinamento CSM é caro, principalmente no nosso caso que temos dois instrutores. Independente disso, buscaremos ao máximo melhorar o preço do treinamento: Oferecemos desconto Early Bird com preço abaixo do mercado e um bom desconto para ex-alunos Aspercom. Não só isso, vamos devolver para a comunidade parte dos nossos lucros na forma de eventos gratuitos nas cidades que visitarmos. Esses eventos serão focados em Agile, Scrum e também um outro assunto muito importante para a comunidade brasileira:Liderança Técnica. Maiores detalhes acompanhe aqui no Débito Técnico. Teremos novidades já para março em São Paulo.

A nossa agenda para as primeiras turmas já estão marcadas no calendário:

São Paulo: Dias 22 e 23 de março
Rio de Janeiro: Dias 5 e 6 de abril
Brasília: Dias 8 e 9 de abril

Sobre o Workshop Scrum

Muitas pessoas e empresas de todo o Brasil já foram treinadas por mim no treinamento Workshop Scrum. Este treinamento vai continuar no nosso catálogo cumprindo a sua função como uma opção sem certificação e mais acessível. Apesar de ter turmas abertas freqüentes em todo Brasil, o Workshop é mais direcionado a empresas médias e pequenas que querem implantar Scrum, e esta estratégia tem dado certo nos nossos clientes.

Nossa visão e missão como empresa é melhorar o desenvolvimento de software no Brasil com transparência e dedicação. Vamos continuar com outros treinamentos, mentorings, consultorias, palestras gratuitas em empresas e participação ativa em eventos. Jamais vamos virar uma empresa que só vende certificações. Se tiverem mais dúvidas ou quiserem comentar fiquem a vontade.

Publicado em agilidade, anúncios, extreme programming, mercado, scrum | 12 comentários

Definição de Pronto

Publicado em 14 de janeiro de 2010 por Rodrigo Yoshima

Uma discussão surgiu na lista Scrum-Brasil… Muitas pessoas postaram coisas boas, mas em linha geral, achei que alguns conceitos estavam errados (e me preocuparam bastante). A discussão está aqui:

http://br.groups.yahoo.com/group/scrum-brasil/message/5618

Um dos maiores benefícios do Scrum é organizar o backlog nos seus itens e suas prioridades. O objetivo do Scrum é matar o backlog, ou ter o maior retorno possível com os itens do backlog que são implementados Sprint por Sprint, de maneira iterativa. Como falei no post anterior, o objetivo do Sprint é ter funcionalidades potencialmente implantáveis. Mais uma vez, esse é um conceito fundamental do Scrum que muitas vezes é esquecido, essencialmente porque isso é garantido por boas práticas de engenharia.

Definição de pronto é uma premissa que visa garantir que o que está sendo entregue REALMENTE atende as necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnlogia. A Definição de Pronto tem relação com a qualidade, a manutenção futura do sistema e os objetivos do produto. Logicamente isso pode variar de projeto para projeto, mas não tem relação alguma com a maturidade da equipe. Se a equipe não consegue atender ao critério definido afrouxar o critério pode ter consequências desastrosas…

Vou dar um exemplo aqui de como ter uma má definição ou ter essa definição baseada nos skills da equipe pode ser ruim. Imagine que estou fazendo um produto de software para o mercado. Esse geralmente é o ambiente ISV que tenho trabalhado. Um software desses atende centenas de usuários, deve ter uma manutenção constante e barata, ter um deployment fácil, excelente usabilidade e farta documentação do usuário e sistema.

Se você quiser fazer um exercício, prezado ScrumMaster, peço que você escreva o que você acha que deve ser a definição de pronto deste produto antes de prosseguir a leitura do artigo.

Estamos iniciando o primeiro Sprint depois de uma concepção ágil e visamos nesse primeiro Sprint entregar as funcionalidades mais importantes para nossos usuários (e espero que vocês também estejam fazendo isso nos Scrums de vocês). Bem, vamos escrever uma definição de pronto baseada na maturidade comum das equipes que vemos por aí:

Definição de Pronto 1.0:
Testado no ambiente de homologação

Na primeira iteração a equipe está super contente com o resultado. Eles conseguiram “entregar” umas 5 ou 6 histórias. O Product Owner até esboçou um sorriso no Review e a moral da equipe está no alto (primeira entrega no Green Field sempre é assim).

Inicialmente essa definição de pronto parece ser boa. Há um sentimento de valor sendo entregue. Até a quinta iteração essa definição pareceu boa, porém, a equipe percebe que ela está cada vez mais devagar. Com as funcionalidades se acumulando está cada vez mais difícil executar os testes e refatorar o sistema para entrar os itens do backlog. A qualidade está decaindo rapidamente. Este cenário é bastante conhecido e bastante citado aqui no blog: A FALTA DE PRÁTICAS ÁGEIS DE ENGENHARIA como testes automatizados, integração contínua e etc…

Esse problema foi causado porque nossa definição de pronto era baseada na maturidade da equipe, e não nas necessidades do projeto. Nesse momento é necessário contratar treinamento, chamar uma consultoria para parear com os desenvolvedores, mudar o mind-set da equipe para orientá-la a testes, aprender novas tecnologias, trocar membros da equipe e etc… No entanto, o problema MAIOR é que temos 5 iterações já implementadas sem testes que se tornaram um péssimo legado. Tudo terá que ser revisado e muitas coisas reescritas na sexta iteração (e isso vai fazer mal para a moral da equipe, acredite). Bem, com tudo isso ajustado, mudamos a definição de pronto para a sexta iteração (que na verdade será uma refatoração gigante):

Definição de Pronto 1.1:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de homologação

Creio que o Product Owner e o bolso dele não ficaram muito feliz com esse fato. Houve uma ruptura na Value Chain (corrente de valor) e com isso, um sentimento de falha do próprio Scrum. Porém, com a definição ajustada as entregas das próximas iterações possuem uma qualidade e confiança muito maior. Não estamos mais perdendo tempo com testes que podem ser automatizados. Os processos de integração contínua estão mostrando falhas o mais rápido possível e o design está simplificado. Durante as iterações 6, 7 e 8 a definição de pronto 1.1 mostrou ser a ideal.

Até que no início da 9a. iteração (de umas 20 previstas) o Product Owner diz que quer colocar o produto no mercado em produção. Ele quer faturar com a solução, antecipando o ROI, afinal, é isso que o Scrum promete. Isso significa que após a décima iteração a equipe terá que lidar com mais práticas SCM, e não só isso, manuais de sistema devem ser elaborados para o pessoal de suporte, assim como manuais de usuário, help on-line, materiais de treinamento e etc…

Mais uma vez, vimos que a definição de pronto não foi suficiente para atender ao conceito de funcionalidade potencialmente implantável. Mais uma vez a equipe deverá parar totalmente para melhorar seu deployment, escrever manuais, fazer transições e etc… Mais uma vez a iteração 9 será um grande refactoring para atender a nova definição de pronto:

Definição de Pronto 1.2:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de produção
- “One-click deployable”
- Com documentação técnica e do usuário

Há uma grande correlação entre o conceito do Value Stream do Lean e a Definição de Pronto do Scrum, e esse exemplo que coloquei aqui demonstrou claramente que o processo de desenvolvimento dessa equipe não é fluído: foram necessárias “fases” de estabilização para se ter valor, se aproximando de um estilo Waterfall. É interessante notar que um sistema Kanban pode deixar a corrente de valor mais visível que uma definição de pronto. Ter uma telinha do sistema que entra e funciona sem dar pau é uma parte bem pequena de um produto de software: não só isso irá gerar ROI. Aquilo que sai da equipe deve ser um incremento completo e não só aquilo que é importante, ou visível.

Muito se fala em equipe multi-disciplinar. É comum achar que um arquiteto, um desenvolvedor e um tester fazem um Carnaval, porém, a característica multi-disciplinar da equipe deve corrobar com aquilo que essa equipe pretende entregar. O backlog nos fala o que deve ser entregue e a definição de pronto, ortogonalmente, nos fala exatamente os critérios dessa entrega. Nesse aspecto, os itens do backlog não tem só relacão com funcionalidades, mas sim, com VALOR.

Publicado em agilidade, gestores, scrum | 9 comentários

Incrementos

Publicado em 12 de janeiro de 2010 por Rodrigo Yoshima

É bastante comum as pessoas reclamarem que a empresa que trabalha não é ágil. Da mesma forma é bastante comum culparem os gerentes, coordenadores, diretores, o cara que cuida dos processos e etc… Algumas pessoas lutam com muito afinco por mudanças e as vezes conseguem adotar uma ou outra prática do Scrum ou até contratam um treinamento. A questão é que na maioria das vezes o que vai impedir o sucesso da adoção Agile na empresa não é o seu gerente, nem seus gerentes de projeto e nem o cara que cuida dos processos: o que impede a adoção Agile na maioria das equipes que tenho contato é a falta de conhecimento de boas práticas de engenharia.

Como já havia citado aqui, design incremental é uma das práticas de engenharia que poucas equipes dominam. Poucas equipes sabem exatamente o que é um incremento. Um dos conceitos do Scrum que é bem pouco comentado e que costumo dar bastante enfoque no meu treinamento é exatamente a definição do pedaço de funcionalidade potencialmente implantável. O próprio Ken Schwaber disse no Gathering que somente 20% das equipes conseguem entregar algo potencialmente implantável ao final da iteração. Inclusive, essa é a motivação dele ter fundado a Scrum.org após sua saída da controversa Scrum Alliance.

Quando dizemos que estamos entregando algo potencialmente implantável isso nos leva a uma visão que poucas equipes Scrum tem: no andar das iterações é o cliente que decide a hora que ele quer ir para a produção, e seu software deve permitir isso. Tudo aquilo que você “incrementou” deve ser capaz de resolver algum problema de negócio sem depender de grandes investimentos em preparação de ambientes ou “Sprints de estabilização”. O que você incrementa além de atender a sua definição de PRONTO deve ser sólido, refatorável, bem arquitetado e durar para sempre. O software criado deve ser um ativo, que coloca dinheiro no bolso de alguém.

Quanto eu estou pareando com alguém ou trabalhando num incremento eu vejo algumas características na realização desse trabalho. Basicamente um incremento é:

- Documentado e especificado (usando BDD, TDD ou outros documentos)
- Analisado (parte do ciclo TDD, refactorings)
- Sólido (incremente com boas práticas OO)
- Coberto por testes (incrementos futuros não quebram o atual)
- Integrado Continuamente (há outros na equipe incrementando)
- Potencialmente Implantável (o cliente decide quando vai pro ar)

A prática dos Baby Steps

Um fato que é bastante interessante é a velocidade dos times ágeis: é um mito achar que times ágeis programam numa correria desatada e que agilistas trabalham num ritmo barulhento, frenético e alucinado. Muitas pessoas que tem contato com uma equipe ágil pela primeira vez pode até estranhar a calma, seriedade e tranquilidade que cerca esses times ágeis. Por incrível que isso possa aparecer, times realmente ágeis “aparentam” ser lentos. É comum ver eles mais pensando do que digitando. Porém, cada passo de bebê que eles dão são passos firmes, determinados, bem pensados e principalmente na direção correta. Numa equipe ágil a cada 2 ou 3 horas vários passos pequenos foram dados e cada incremento agrega valor para o projeto.

Chega ser ridículo quando vou conversar com certos empresários e eles dizem: “- Aqui já somos ágeis… é uma correria do cacete aqui!”

Mentalidade Cascateira do Programador

O maior motivador deste artigo é a minha experiência depois de ter ministrado algumas vezes o nosso novo treinamento Domain-Driven Design. Neste treinamento as atividades práticas são orientadas a testes, e tenho visto que alguns alunos penam para completar os exercícios mesmo quando nós já fornecemos os testes automatizados escritos.

Exemplo: Temos um caso de uso com 4 testes falhando para os alunos implementarem em uma hora. São 4 testes de integração, então, basta fazer cada teste passar em 15 minutos que a solucão está completa. Muitos não conseguem fazer isso, e a maior razão é não conhecer sobre Design Incremental. Eles olham aqueles testes falhando e entram em pânico. Saem cuspindo código sem rodar os testes querendo fazer todos eles passarem ao mesmo tempo. Nos últimos 5 minutos da atividade prática ainda está tudo RED e falham miseravelmente. Simplesmente não lhes parece natural fazer o primeiro teste passar, depois o segundo, depois o terceiro e assim sucessivamente. Eles não pensam em passos de bebê e nem em incrementos. Essa minha experiência é bastante relevante para a questão, e define a mentalidade cascateira:

O cascateiro é aquele desenvolvedor que espera que algo milagroso acontecerá nos últimos instantes do prazo, e tudo aquilo que não funciona passará a funcionar, seja por sorte ou intervenção divina.

Essa definição é essencialmente válida mesmo para quem diz que usa ciclos iterativos. Ciclos iterativos não necessariamente são Ágeis, pois se sua equipe ainda sofre para que tudo que foi implementado funcione ao final da iteração você ainda tem mentalidade cascateira, e precisa melhorar suas práticas de teste e integração contínua.

Você que é desenvolvedor pode fazer uma auto-avaliação prática. Acesse meu Github e baixe o projeto exemplo do treinamento Domain-Driven. Em seguida, acesse a classe CadastrarHospedeTest e tente fazer com que estes testes passem num prazo de uma hora. Pegue como exemplo a classe CadastrarQuartoTest. Depois, responda as perguntas:

1. Você conseguiu implementar em uma hora?
2. Quantas vezes aproximadamente você rodou os testes?
3. Você conseguiu fazer os testes passarem um por um?
4. De 0 a 10, como você avalia a confiabilidade do seu código?

Como eu sempre digo: Colar post-its na parede todo mundo quer, mas escrever testes automatizados ninguém quer.

Publicado em agilidade, arquitetura, extreme programming, gestores, mercado, scrum | 5 comentários

Agile e Scrum na Remaza e SGIweb

Publicado em 11 de janeiro de 2010 por Rodrigo Yoshima

Em dezembro a Aspercom treinou 20 pessoas da Remaza e SGIweb em práticas ágeis de gerenciamento de projetos com o nosso treinamento Scrum. Creio que o consórcio Remaza dispensa apresentações. A SGIweb é o empreendimento das Empresas Remaza focado no segmento tecnológico em produtos e serviços de software.

O produto principal da SGIweb são produtos e soluções para Procurement e B2B integradas com ERP e vendidas como serviços entre mais de 65.000 empresas participantes. Para maiores informações, visite o site do WebSupply em www.websupply.com.br. Foi muito legal ministrar este treinamento, principalmente porque a SGIweb é uma empresa com mais de 20 anos de mercado e que está inovando seus processos nas práticas Agile com vigor.

Mais um ISV para o portfólio da Aspercom, que em 2009 consolidou sua posição como a principal empresa em treinamentos corporativos e consultoria em Scrum, Extreme Programming e práticas Agile no setor. Que venha 2010!

Imagem0243

Publicado em agilidade, cases, scrum | Deixar um comentário

Scrum e Requisitos Ágeis na Leosoft

Publicado em 11 de janeiro de 2010 por Rodrigo Yoshima

Em novembro a Aspercom esteve em Francisco Beltrão – Paraná para ministrar os treinamentos de Requisitos e Scrum na Leosoft, empresa ISV com mais de 12 anos de mercado e focada em produtos de software para cooperativas de crédito.

A Leosoft é uma empresa que já utiliza Extreme Programming há algum tempo, tendo sido treinada pelo renomado Vinicius Teles. Ambos os treinamentos foram customizados para focar em práticas que fortaleceram a visão de negócios dos produtos da empresa junto ao mercado, já que cliente presente é um grande desafio para os ISVs. De norte a sul do Brasil é muito interessante ver como empresas com times pequenos e auto-organizados conseguem excelentes resultados em seus produtos e empresas.

Imagem0222
Atividades práticas em grupo, muito comuns em treinamentos da Aspercom

Imagem0223
Um ambiente informativo compartilhado na vida real

Gostaria de parabenizar a todos da Leosoft pelos excelentes bate-papos e trocas de experiências. Muito sucesso em 2010!

Publicado em agilidade, cases, extreme programming, scrum | 2 comentários

Turmas de Dezembro em São Paulo: Faça Requisitos ou UML e ganhe Agile

Publicado em 20 de novembro de 2009 por Rodrigo Yoshima

Nessas férias aproveite o tempo para aprender mais sobre desenvolvimento de software com a Aspercom. Faça sua inscrição no treinamento Requisitos ou UML e ganhe grátis um mini-curso sobre Agile (17/dez).

Levantamento e Especificação de Requisitos
Estabeleça a Visão do sistema e Controle os Requisitos com sucesso
Noturno: Dias 1, 3, 8, 10 de dezembro (terças e quintas – calendário)
R$ 520,00 à vista com desconto ou 3x R$ 185,00 – Grátis: Mini-curso Agile

Orientação a Objetos com UML 2.0
Aprenda na prática sobre Casos de Uso, Design e Arquitetura de Software
Noturnos: Dias 7, 8, 9, 10, 14, 15, 16 de dezembro – (calendário)
R$ 890,00 à vista com desconto ou 4x R$ 230,00 – Grátis: Mini-curso Agile

Gerenciamento de Projetos com Scrum
Aprenda as práticas Agile que mais crescem aqui no Brasil
Sábado Integral: Dia 12 de dezembro – (calendário)
R$ 430,00 à vista com desconto ou 3x R$ 150,00

Descontos para 2 ou mais alunos.

Inscrições: contato@aspercom.com.br

LOCAL DOS TREINAMENTOS:
Domore – Av. Paulista, 807 – 18 andar
São Paulo – SP

Publicado em anúncios | Deixar um comentário

Minha experiência benéfica com o PMBOK

Publicado em 20 de outubro de 2009 por Rodrigo Yoshima

Quem ler esse título vai achar que eu enlouquecí depois do “O que matou o RUP pode matar o Agile“, mas o objetivo desse post é mais uma vez falar sobre mindset. Eu vejo que a grande dificuldade em entender práticas e metodologias vem de conflitos de mindset. Vou escrever mais sobre isso aqui no blog, pois vejo que combater prática contra prática ou metodologia contra metodologia é muito pouco produtivo. Os mindsets explicam tudo, apesar de ser bastante empírico escrever sobre isso. É dificil escrever sobre mind-set de maneira prática e útil sem descambar para um blá-blá-blá poético e filosófico.

Nesse artigo vou comentar sobre a polêmica que o José Papo criou primeiramente no seu Twitter. Não satisfeito postou também na Scrum-Brasil. Segue o link para a animada discussão “Scrum e PMBOK – determinadas incompatibilidades filosóficas”:

http://br.groups.yahoo.com/group/scrum-brasil/message/4810

A discussão estava indo como sempre vai: uns defendendo, outros criticando, até que passou pela questão “certificação”. Hoje existem muitos PMPs que também são CSM, e vejo que isso é bem natural – quem tem um mindset que busca certificações é esperado que colecione-as. O Luiz Aguiar postou algo interessante, falando que agilistas de verdade não ligam para certificações. Isso é interessante para esse artigo, pois, vou falar aqui que muitos que gerenciam projetos de verdade a lá PMBOK também não ligam…
Continue lendo →

Publicado em agilidade, cases, gestores, scrum | 18 comentários