Salve!
Para quem se interessar desenvolvi um app para o iphone para dividir conta em mesa de bar, hehe! Quem nunca teve problema levante a mão?!
Para quem se interessar é só procurar por SHARE IT na Apple Store, é de graça.
E para quem quiser mais infos acesse meu blog sobre iphone: iphone4fun.blogger.com
DC
Deixar um comentário » | 
Gerenciamento de Projetos, Scrum, iPhone 4 Fun | Etiquetado: iphone, free, download, app, scrum solo | 
Link Permanente
Escrito por danilocastrojr
“…saber que teremos mudanças para os planos ao invés de impormos planos para mudanças.”
“…times que durante o percurso conseguem cair, levantar e aprender sobre a queda tão rapidamente que as suas novas escolhas serão sempre mais atrativas que a da concorrência.”
Esta foi só para divertir mesmo!!
Deixar um comentário » | 
Agile | Etiquetado: Agile, discussão | 
Link Permanente
Escrito por danilocastrojr
De acordo com minhas necessidades coloquei em prática algumas diretivas que vieram a ser bem sucedidas no meu ambiente de trabalho, acabei descobrindo depois que elas pertenciam a diferentes corpos de conhecimento em gerenciamento.
LEMBRETE: AGILIDADE NÃO É PARA QUALQUER UM!!
Separei abaixo algumas boas práticas que podem, rapida e facilmente, ser aplicadas a ambientes de projetos ágeis.
1. Coletar o requisitos com um vocabulário que seja compreensível ao cliente
2. Escrever os requisitos em frases curtas e objetivas
3. Levar a visão do negócio para todos os envolvidos no projeto, criando assim um foco/comprometimento ao produto e não ao projeto = tarefas individuais.
4. Firmar relação de parceria com o cliente, mais do que apenas uma relação contratual.
5. Aproximar o cliente das entregas parciais de seu produto, alterando requisitos o mais rápido possível.
6. Não tenha medo de sugerir mudanças ao cliente que possam beneficiá-lo no futuro, porém não “suponha e faça”melhorias por conta própria.
7. Se não for naturalmente vindo da equipe, estabelecer a função de “líder técnico”, facilitando para todos a conexão entre a visão macro e micro do projeto e do produto.
8. Estime o esforço e duração do projeto juntamente com os envolvidos. Separar as reuniões do cliente e da equipe é importante para a agilidade e produtividade da mesma.
9. Reuniões curtas e diárias (de preferência stand-ups para aumentar a atenção dos envolvidos) com o time sobre bloqueios do projeto ou do produto, melhorando a visibilidade para antecipação de problemas do PM.
10. Se possível, não atribua tarefas as pessoas, deixe-as fazer isso por si próprias, porém estabeleça prioridades para as mesmas.
11. Quadro de tarefas e datas principais do projeto bem visíveis a todos envolvidos aumenta o comprometimento, incentiva a próatividade e espalha conhecimento.
12. Tarefas devem possuir um dono com nome escrito e comprometido com seu desenvolvimento. Porém isto não deverá ser utilizado para encontrar culpados.
13. Planejar em detalhes as partes q vc tem conhecimento e com visão macro aqueles que as incertezas são grandes.
14. Riscos devem ser avaliados e se necessários revistos com o cliente na mesma velocidade das reuniões com a equipe.
15. Não crie gargalos de teste. Fez, testou!
16. Enquanto o time desenvolve, o PM planeja, antecipa e relata.
17. Ao fim de cada entrega reveja oq foi feito. Oq fracassou descarte imediato, oq deu certo melhorar.
18. Defeito é retrabalho: antecipe-os sabendo quem está fazendo oq. Não crie culpados, crie facilitadores.
19. War room para times enxutos (4-10) é excelente, vale a pena entrar nessa briga.
20. Meça quantidade do produto desenvolvido e não percentual do projeto realizado. Foco no produto (cliente) e não no projeto (seu umbigo)!
Estas práticas foram por mim, livre e despretenciosamente, referenciadas dos seguintes materiais:
SCRUM
PMBOK
CORRENTE CRÍTICA
Deixar um comentário » | 
Corrente Crítica, Gerenciamento de Projetos, Scrum | Etiquetado: projetos inovadores, Agile, discussão, Scrum, Corrente Crítica | 
Link Permanente
Escrito por danilocastrojr
Infelizmente nada de novo foi abordado nestes 2 dias, nenhuma conclusão ou experiência inovadora, nenhum projeto com metodologias revolucionárias ou realmente incendiárias… nadinha! Não precisei nem me perguntar pq, simplesmente seguindo a conclusão sobre “inovação” que levamos em paralelo do congresso a conclusão fica óbvia. Então vamos a ela.
Quando a maioria fala em “projetos inovadores” na verdade fazem referência a projetos que tem como resultado produtos ou serviços inovadores. Existem excessões, mas reflitamos, um “projeto” inovador deveria ser por definição um projeto que trouxesse alguma novidade no modo de se gerenciar.
Acredito que isso ocorras, sabe quando? Quando estamos adaptando processos ou metodologias (as vezes largamente usadas) para as realidades de nossas empresas.
Exemplo: a primeira vez que foi utilizada Corrente Crítica ou Scrum por alguma empresa.
A partir do momento que transformaram isso em “modos de se operar” a inovação em projetos acabou, correto? (aberto a discussões).
Outro pode dizer:” sempre temos que adaptar nossos projetos para cada um de nossos produtos inovadores, então sempre geramos projetos inovadores.”
Perguntas: Qual o custo de se fazer produtos inovadores então? Os custos de criar novas metodologias a todo novo produto está incorporado? Vale a pena? Como este processo está sendo medido?
Entram aqui os “métodos ágeis”, que nada mais são que processos mínimos, com o menor impacto documental e grande maleabilidade para se adaptar a este tipo de projeto, projetos que geram produtos inovadores, que necessitam de entrada rápida no mercado, agregam alto valor tecnológico se comercializados no timming correto, que não possuem precedentes para termos análises de cases, altas incertezas, requisitos com alto indíce de mudança ao longo do projeto, etc, etc, etc.
Acho que posso dizer então que:
“De fato estamos trabalhando com “resultados inovadores”, não com “projetos inovadores” e procurando por metodologias mínimas altamente adpatáveis para que a criação da cultura de gerenciamento de projetos seja introduzida rápida e facilmente, sem trazer mais incertezas no projeto.”
A partir do momento que saímos da esfera da super novidade (pesquisas e análises de viabilidades, prototipagem, projetos em menor escala, etc) podemos então levar estes projetos para a “linha de produção” e após estes passos, aumentar o poder de monitoramente e controle, já partindo para otimizações dos processos anteriormente “inovadores”.
Isto tudo combina com a discussão que tivemos sobre a então maturidade do PM no Brasil, atualmente girando em torno de 1,8 (OPM3).
No fundo adotar “qualquer” atitude de gerenciamento de projetos e caminhar para o controle pleno é um ato comun de maturidade corporativa, e é isto que está sendo exigido dos projetos “inovadores”. Imaginando cada um como uma pequena empresa, eu vejo a mesma lógica sendo aplicada em ambos os casos.
E no caso de projetos tão curtos que nunca conseguem entrar na “linha de produção” (meu caso específico)?
Pensando cada um deles como se fossem empresas novas onde estaríamos sempre começando um processo de maturidade gerencial e nunca atingindo o seu fim, portanto, precisamos de um modelo de rápida absorção, que conte com GPs altamente motivados e capazes e equipes dinâmicas com facilidade de aprendizagem (e quem sabe treinamento de conceitos básicos de GP, seria uma boa?).
A idéia central em torno de técnicas ágeis seria “não temos tempo para preencher papéis!”.
Particularmente sou um control-freak e gerencio minha equipe com métodos de scrum adaptados ao pmbok tradicional. Mas tenho que admitir que a força do PM nestas estrutras tem que ser muito forte e altamente amparada pelo sponsor e pela própria estrutura gerencial.
Ferramentas interativas que facilitem a vida dos desenvolvedores não podem ser economizadas! Estas mesmas irão fomentar o PM com a base de dados estatísticos para o controle do projeto.
Muitas vezes imagino que a idéia utópica de “sem papel e sem planejamento” (parecido com seu lenço e sem documento.. pq será?) seja uma muleta em que são apoiados muitos projetos por simplesmente serem “complexos” de serem mapeados.
A questão de seguir uma “baseline” e atrelar o sucesso do projeto aos deliverables intermediários deve ser abandonada, isso não somente métodos ágeis propões como tb a visão holística de projetos, portanto, nada demais. Vamos somar oq é bom para cada necessidade!!
Lembrando que PMBOK tb não é metodologia e sim um conjunto de boas práticas, use-as conforme a necessidade e em caso de seus problemas não terem sido resolvidos procure um PMP (com experiência) mais próximo!!
Sobre o congresso. Acabou… infelizmente nada inovador!!
Deixar um comentário » | Agile, Gerenciamento de Projetos, Scrum | Etiquetado: inovação, projetos inovadores, Agile, seminário internacional, PMBOK, discussão, holistica | Link Permanente
Escrito por danilocastrojr
Onde está a INOVAÇÃO no PMI?
Para um PM de software falou em inovação em gestão de projetos = novas abordagens com relação ao PMBOK. Para minha, não muita, surpresa o tema tem pouca abordagem.
Pois então quais seriam as inovações propostas pelo time super experiente (com gringos envolvidos) de PMPs, MBAs, MScs, PhDs e quaisquer combinações de 3 letras 3 a 3 que encontramos por aí?
Até o momento, neste fim de dia 1, ficaram 2 grandes mensagens e uma pergunta:
1. Quando a estagnação de resultados chegar, cuidado ao procurar por novas respostas, talvez seja o momento de “gerar” novas perguntas. Perguntas fundamentais, que podem levar a novos rumos no negócio. Resumindo: as vezes trocar o “Como?” por um eloquente “Porquê?”.
Retirado da palestra de Kip Garland, 26/10/2009
2. Respire normalmente. Todos projetos se complicam em alguma parte, saiba disso e conhecça estes pontos de antemão. Respirar normalmente é a expressão de que vc detém o controle da situação.
Retirado da palestra de Peter Taylor, 26/10/2009
Pergunta: O que é inovação?
De acordo com o dicionário inovação é simplesmente “novidade”, porém no mundo corporativo ganhou algumas vertentes:
- Uma idéia que chega ao mercado agregando valor é uma inovação.
- Algum produto ou processo que aumente os ganhos de uma empresa ou segmento, é uma inovação
Falando de projetos inovadores, levou um colega PMP a levantar a seguinte questão numa dinâmica: “Se todos projetos são únicos então oq é um projeto inovador?”.
Vamos lá: UNICO quer dizer que suas características diferem dos demais em algum sentido, basta apenas uma diferença para ele ser único. Todos projetos são únicos por definição.
O inovador explicamos acima, então apesar de já ter respondido a questão, ela implicou em outros questionamentos válidos. Por exemplo:
- Uma vez que temos projetos não somente únicos, porém contendo várias características que implicam uma severa mudança no modo como as boas práticas do PMBOK devam ser empregadas, temos então um projeto potencialmente inovador, pois ele necessitára que as práticas sejam inovadas tb, isto é, sejam adaptadas a tal ponto que tragam “novidades” ao processo comun.
- Se este projeto gera ganhos (de qualquer espécie) utilizando este processo inovador, temos então uma inovação.
- Logo em seguida chega-se outro projeto inovador e temos que remontar e inovar novamente ao adaptar as práticas do PMBOK.
- Ao invés de fazermos isso, caminhos para uma solução mais simples: jogamos fora tudo oq precisaríamos inovar nos procedimentos do PMBOK, ficamos com a parte que comprovadamente foi necessária e essencial ao sucesso do projeto, e que a partir daquele momento deixa de ser inovadora (pois estamos re-utilizando), e seguimos o jogo dizendo que o PMBOK não serve para projetos de inovação.
Então algumas indagações extras:
- O problema da inovação no PMBOK está nos práticas quadradas ou nos PMs quadrados que não sabem como adaptá-las?
- Ao “inovarmos” uma variação do PMBOK e usarmos como metodologia não estamos cuspindo no prato que comemos?
- Vale a pena (em termos de ganhos) buscarmos “sempre” uma metodologia inovadora de projetos para todos os tipos de projetos?
- Se temos um limite claro entre projetos que melhor são geridos pelas práticas mais comuns do PMBOK e os que não necessitam de todas as práticas, pq estas variações não podem estar claras e apresentadas no próprio PMBOK como alternativa de processo?
Amanhã volta com estas questões para meus fellows PMs para tentar chegar num fim deste questionamento.
3 Comentários | Agile, Corrente Crítica, Gerenciamento de Projetos, PMBOK | Etiquetado: gerenciamento, inovação, projeto, projetos inovadores, software | Link Permanente
Escrito por danilocastrojr
Após perceber que estavámos bem carentes de métodos para proceder com o desenvolvimento, encontrei aí uma oportunidade de apresentar algumas idéias (até então incendiárias… quem diria!).
Comecei adotando algumas regrinhas para que conseguíssemos nos guiar e ao mesmo tempo aculturar o jovem time em gerenciamento de projetos:
1. Nosso bugtracker deveria conter todas as informações correntes sobre o andamento de cada uma das tarefas, para que eu ficasse a apenas um “click away” das informações correntes do projeto (deu trabalho mas valeu a pena) e pudesse tomar decisões de forma rápida e precisa com o cliente.
2. As soluções deveriam ser empacotadas indivdualmente (patches de código), um pedido do cliente que veio como uma luva. Mesmo perdendo mais tempo, fez com que o time sempre desse uma olhadinha extra no código antes de entregar.
3. Apesar do contratempo que tívemos nos patches, aproveitamos para que um revisor de código fosse implantado e utilizando os pacthes ele revisava isoladamente cada uma das correções, aprovando inclusive os procedimentos de se confeccionar o patch (na época parecia uma boa idéia, ficamos com ela até o fim do projeto dali a 3 meses).
4. Apresentamos aos developers as diretrizes do negócio e os desejos do cliente, detalhando oq ele quer e oq não quer. Fazíamos reuniões quase que diárias a respeito de quais funcionalidades requeridas pelo cliente eram praticáveis, quais não eram e aquelas que não conseguiríamos entregar no prazo dado.
5. No lado do cliente, passei a realizar ligações diárias e comunicações formais e informais (e-mails e skype) eram a chance de sempre colocar o cliente a par de tudo e introduzir um fator de responsabilidade nas decisões com relação a todas nossas dúvidas e dificuldades. Isso foi muito bom para eles e para nós.
6. Alteramos as reuniões semanais da “alta gerência” com o cliente para o nível dos líderes de projeto, assim conseguíamos um modo de colocar todos os líderes e gerentes a par de todos os projetos (de um modo macro, a reunião ainda dura entre 2-3 horas, aguardem próximos posts!!) melhorando o modo como os líderes se comunicam, sincronizando os pontos das semanas a seguir com o cliente.
7. Estipulamos que 2 desenvolvedores seriam o “Esquadrão de Elite” para pontos crucias de implementação, para que o time menos experiente consiga ter um líder técnico como foco para seguir do lado “de dentro”. Isso fez com que todos trabalhassem com um pensamento de técnico-negócio alinhado, facilitou também a comunicação captando idéias entre eles que não seriam expostas naturalmente em uma reunião.
8. Alguns padrões de comunicação oficial foram adotadas:
9. Devido as oscilações de trabalho (muito alguns dias e nenhum outros), programávamos a produção de “how-tos” nos sistemas internos (wiki), produção de documentação exigida pelo cliente nestes dias e promovíamos a apresentação de cases de resolução de bugs complexos ou tecnicamento desafiadores, onde o próprio developer com um projetor na sala de desenvolvimento discursava e discutia entre o time a solução realizada. Isso aumentou muito a conexão do time e ajudou a homogeneizar o conhecimento no time no projeto. Desta forma as folgas devido as horas extras começaram a ficar interessantes, pois todos conheciam muito bem o terreno que todos estávamos pisando. O esquadrão de elite neste momento de “meio de projeto” já não fazia mais tanta diferença no quesito técnico (oq era uma ótima notícia), mas por outro lado eu estava formando futuros facilitadores com neste grupo de elite.
Resultados
Apesar de comercialmente este projeto não ter sido um sucesso para o cliente (por motivos alheios aos nossos esforços), tinha sido um primeiro sinal de novos tempos para a empresa que reconheceu os procedimentos como “a serem adotados” pelo outros líderes. Estes começaram a utilizar as boas práticas advindas deste projeto e juntaram outras particularizadas, aliás um novo líder também havia surgido deste mesmo ambiente que criamos (o esquadrão de elite funcionou!) e com isso estas técnicas com certeza iriam ser aprimoradas de dentro para fora em seu próximo projeto.
Certamente, como empresa, temos muitos pontos a aprimorar, principalmente no que tange ao formato que realizamos nosso trabalho. Porém para dar um novo salto começo a buscar por metodologias de gerenciamento de projetos clássicos e vejo rapidamente o limite destas no quesito velocidade de mudanças e planejamento bem definido.
Ao mesmo tempo que eu busco pela agilidade foi iniciado um processo de implantação de um MPS.br na empresa (acho q eles gostaram da parte de “procedimentos e padrões”…uff!), bom resumindo, era tudo oq eu não queria no momento.
Minhas chances agora são demonstrar por A+B (assim como fizémos da primeira vez) que podemos ter procedimentos bem definidos, medições apuradas de performance, controle de qualidade e mesmo assim não atrapalhar o desenvolvimento própriamente dito, pois esta é a META MÁXIMA do nosso negócio: ENTREGAR O SOFTWARE, no momento que o cliente precisa e com as funcionalidades negociadas.
Deixar um comentário » | Gerenciamento de Projetos, Meus casos, PMBOK, Scrum | Etiquetado: gerenciamento, software, projeto, case | Link Permanente
Escrito por danilocastrojr
Minha jornada aqui busca descobrir como realizar o desenvolvimento de software de modo mais eficiente e produtivo do que fazemos hoje.
Em eficiente eu resumo:
E com o produtivo quero dizer:
A base de nosso desenvolvimento atual é como muitos por aí (acredito eu):
Situação Antes “da busca”
Como a empresa veio criando suas metodologias apenas na base das necessidades (oq ao meu ver até um certo ponto é bem sauldável) percebo que tínhamos procedimentos bem interessantes, porém uma série de medidas requisitadas pela cliente estavam faltando. Não só isso, mas algumas melhoras de qualidade e reduzir alguns gargalos estava impraticável, pois não conseguíamos ao certo saber onde atuar.
Juntando mais lenha na fogueira, rodávamos de 3 a 5 projetos com 4 líderes de projeto simultâneamente cada um com suas idiossincrasias e quase nenhum vocabulário comun, a não ser naquele que o cliente era geralmente tratado.
Com relação aos recursos, nossos desenvolvedores são extremamente competentes, porém na grande maioria recém-formados com pouquíssima (ou nenhuma) vivência de mercado, resumindo com visão de negócio próximo de zero e não posso deixar dizer que as visões da própria empresa (se existem ainda não foram divlgadas a ninguém) também nã0 ajudavam neste quesito.
Empresa muito nova tentando se colocar de pé e ao mesmo tempo sair correndo, já ouviram esta história em vários lugares, certo?
Umas das primeiras coisas que me lembro de ter feito (senão a primeira mesmo) foi uma planilha excel para o reembolso de uma noite de horas extras (uma de muitas que iriam por vir) de reembolso que enviei para meu gerente. Por incrível que pareça não existia nehuma antes… (só pra dar o tom de como começamos por aqui).
Era muito divertido ficar as noites em claro resolvendo problemas de todas as espécies para colocar no ar no outro dia pela manhã. De repente me vi a 6 meses fazendo aquilo quase todas as noites e nossos dias começavam as 11:00am, me sentia um astro do rock n’ roll!
Mas espere um segundo! Onde estavam as bebidas, as mulheres e os milhões de dólares… estávamos fazendo tudo errado.
Deixar um comentário » | Agile, Meus casos, PMBOK | Etiquetado: case, gerenciamento, projeto, software | Link Permanente
Escrito por danilocastrojr
danilocastrojr