Para quem não conhece Ruby on Rails (RoR), RoR é uma framework para desenvolvimento ágil de aplicações Web. Utiliza a linguagem de programação Ruby. Uma framework equivalente, mas em Java, pode ser o  Tapestry 5, por exemplo, que também é uma framework para desenvolvimento ágil de aplicações Web, mas em linguagem Java.

RoR não é a única framework para desenvolvimento de aplicações Web com Ruby e uma das mais activas frameworks “rivais” ao RoR é a Merb.

A novidade aqui, pelo menos para mim, é o anúncio do merge entre Ruby on Rails e Merb no RoR 3.

Fica aqui um vídeo com a  novidade, dada pelo criador do RoR, que não é um anúncio, mas uma aula.

Para quem não liga nada a RoR, pode ver a partir do minuto 45, tem umas excelentes dicas para qualquer pessoa envolvida no desenvolvimento de software.

Quero aproveitar também para emendar um pequeno detalhe num dos meus últimos posts. No post ‘O poder do “E” e do ‘Mas’” quero alterar de Programador para Parceiro . Vejam o vídeo a partir do minuto 58 para perceber porque é que quero mudar isso . Ahh! E vejam também a resposta à primeira pergunta, a partir do minuto 59

Vale a pena ver mesmo quem não quiser saber nada de RoR, mas quiser saber alguma coisa sobre desenvolvimento de Software.

Good talk.

Ainda se notam alguns “bugs” no software, por isso é que ainda é fechado, mas já dá para fazer umas coisas muito interessantes.

Um vídeo em Português sobre o Google Wave.

Na minha opinião é uma ferramenta única para colaboração. Se alguem quiser um convite deixe-me um comentário com uma pequeno texto a descrever para que querem utilizar o Wave.

Boas ondas.

I’ve introduced this book here in Portuguese.

I haven’t read it, but I will, I promise and I hope you, as an agile wannabe, read it too so you will not make anything stupid when planning your releases .

This chapter deals with release management.  What is covered:

• Planning the release and creating the release plan
• Estimating product backlog items
• Determining velocity
• Managing cost
• Dealing with risk
• Tracking and reporting the progress
• Practices for large projects including lookahead planning and pipelining

Have a nive reading.

This week I came across the question:

“For what are Gantt charts useful?”

And because we live in knowledge the wisdom of the crowds era, I decided to throw an message in LinkedIn’s IT Project Manager group.

Let me start to quote my self in that question:

Are gantt charts useful for software projects?

Software projects are complex not only because the technology but mainly because the human behaviour. Humans collaborate to create solutions for complex problems, are Gantt charts useful to model human behaviour and collaboration?

It seems to me that Gantt charts are well suited for very predictive projects or production lines with machines, and software projects are everything but predictive. What is the point of using a technique that assumes a predictive future in a environment in constant change?

As far as I know, Henry Gantt worked with Frederick Taylor and I assume they had the same way of thinking. Now, if Taylor is a Theory X manager what’s the point to use their tools when you are a theory Y manager? Does it make any sense to use gantt charts to manager projects, specially SW projects?

Additionally, I heard from someone that the first time Henry Gantt introduced what we today know as Gantt charts never used the word projects, mainly because those charts were used to manage assembly and production lines… why are we using Gantt charts to manage the complexity of projects?

I received two answers, till now. One from Maryann Snider, PMP and other from William W. (Woody) Williams in the discussion.

These answers led me to think again in the usefulness of Gantt charts. My current opinion about Gantt charts is (as seen in LinkedIn discussion):

Ok, so a Gantt chart is only a communication chart, right? We can think of it as a tool for visual management if the stakeholders are educated in that way, I guess.

I understand that Gantt charts can be used to show critical path/s calculated with CPM (Critical Path Method).A lot of more tools and techniques exists to assist us in creating a tentative schedule, like the critical chain method as William mentioned. But at the end, a Gantt chart is only a tool for communication, right?

IMHO, there’s a risk with Gantt charts

PMI, for instance, as well as Agile Manifesto, promote face-to-face communication. The heavy use of Gantt charts can be seen as a risk when they start to flow, more than desired, through email within your organization.It’s not only a question of everyone seeing different versions of a project, it’s also a question about the wrong message your organization can be passing to stakeholders: email-communication culture is Ok.

I think we’re loosing sight of what its important in projects, the People. So, the use of Gantt charts for communication of project status, progress, etc should be revisited, IMHO. Moreover, I think that a “Go see” culture is the most effective way to access progress.

I’m not against the use of gantt charts in any way. I just have to believe in their utility before using them.

And you, how do you feel about the uselfulness of Gantt charts?

Windows® Azure is a cloud services operating system that serves as the development, service hosting and service management environment for the Azure Services Platform. Windows Azure provides developers with on-demand compute and storage to host, scale, and manage Web applications on the Internet through Microsoft® data centers

Os developers que se atreveram a experimentar cedo este serviço, já experimentaram também 24 horas (+/-) de quebra de serviço.

http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/6c1cd8a2-8d9d-43e9-a1d8-928e0ca4de78

http://blogs.zdnet.com/BTL/?p=14698

http://www.theregister.co.uk/2009/03/16/azure_cloud_crash/print.html

Tenho lido bastante sobre as tendênicas do cloud computing, mas estas quebras de serviço não têm ajudado a ganhar a confiança merecida. Talvez por causa disso, algumas estratégias passam por disponibilizar as mesmas aplicações offline, como é o caso do Google Calendar.

Pessoalmente acredito neste novo paradigma que economicamente faz muito sentido e também compreendo todo cepticismo envolvido.

Acho que negar esta realidade pode ser perigoso para as empresas que não reconhecem o cloud computing como uma forma de vantagem competitiva.

O que acham?

Com cada vez mais organizações a adoptarem SCRUM para o desenvolvimento de software,  é importante que as responsabilidades do Product Owner sejam clarificadas e entendidas por todos.

De acordo com o autor Roman Pichler, este é um livro para todos os interessados em Agile Product Management, principalmente para os actuais Product Owners ou para quem está a pensar assumir essa função.

Já se podem ler o capítulo 1 e 2, e claro, dar o vosso feedback

Think about that for a moment. If you answer “No” (which I believe you do unless you’re a suicidal crazy person) I’m also sure you will not believe that a Certified Scrum Master (or a bunch of them) will save your projects and your business.

SCRUM is simple. SCRUM is hard. There is no ambiguity here. It is simple but it is hard.

Most of the organizations implementing SCRUM do not bother to find out why the “old” processes haven’t worked and simple jump into SCRUM because it is simple. People tend to judge that simple things are also easy thinks.

I think is a mistake, when you’re the adopting SCRUM framework (or any other agile process/methodology/practice/framework) to jump into it and trashing everything you learned from the past failures. This is a warning of continuing the failure path.

SCRUM, and any other agile methodology or process is not about the process or methodology itself, it is about a change in mindset and organization values and principles. SCRUM will help your organization to change, but will not change it by itself. Do not expect that SCRUM will solve all of your problems but expect it to show you all your problems.

What about the good engineering practices? Will SCRUM save your project if you are constantly building garbage? Probably SCRUM will help you to build garbage more quickly. That’s great if your business is all about building garbage.

I am just starting with this stuff of Agile Software development, so do not take what I have said here too seriously . I am sure your certified surgeon, with a two days course, will do a great job to your brains after a surgery to your head.

Além da análise de investimento permitir conhecer como e quando o investimento se materializa em retorno, esta análise permite também solidificar objectivos do projecto.  É diferente realizar um projecto que se propõe gerar 100k € no primeiro ano de produção do que realizar um projecto cujos benefícios nem sequer se conhecem.

Este artigo é o último da série  ”Como seleccionar um projecto” e apresenta o indicador Payback Period (Período de Recuperação de Investimento) que descobre o período de tempo necessário para recuperar o investimento total no projecto.

Exemplo: Se investir 500k € ao longo da realização do projecto A, ao final de quanto tempo é que os fluxos de caixa gerados pelo projecto somam os 500k €? Se existir uma alteração nos pressupostos feitos durante a análise, ou outras alterações,  quais os impactos nesse período de tempo?

É importante fazer estas perguntas, não apenas no inicio do projecto mas durante todo o projecto, porque alteração internas ao projecto ou externas (situação económica, mercado, etc) podem afectar o resultado final do projecto, por vezes, até, inviabilizando-o.

Para calcular o período de recuperação de investimento são utilizados os fluxos de caixa de entrada e saída do projecto (inflow e outflow) para calcular o período onde os fluxos de entrada anulam os fluxos de saída.

Para ilustrar o conceito, o gráfico em baixo mostra os fluxos de caixa acumulados e actualizados gerados pelo projecto SE4W (inicialmente apresentado no artigo sobre VAL).  – Os fluxos de caixa acumulados e actualizados do ano n, são calculados através da subtracção dos custos actualizados aos benefícios actualizados e somados aos fluxos de ciaxa acumulados e actualizados do ano n-1, quando n é maior que zero.

A linha a vermelho indica os fluxos de caixa acumulados e actualizados do projecto ao longo dos anos. É fácil, porém, verificar que os fluxos de caixa acumulados e actualizados começam a ser positivos a partir do ano quatro, significando que são necessários quatro anos para recuperar todo o investimento feito no projecto.

Para saber exactamente o Período de Recuperação de Investimento, utiliza-se a seguinte fórmula:

Com os dados do projecto exemplo SE4W:

P = 4, CFp = -6,881 e CFp+1 = 179,396.

O Período de Recuperação de Investimento (Payback Period) para o projecto SE4W é de 4.04 Anos ou 48.44 Meses.

Sempre que possível devem-se analisar os projectos à luz do VAL, TIR, RBC e PRI para aumentar o grau de confiança na realização do projecto.

E assim termino a série de artigos sobre modelos económicos para avaliação de projectos, onde foram introduzidos os indicadores VAL, TIR, RBC e PRI (Payback Period ou Período de Recuperação do Investimento).

É fundamental monitorizar estes estes indicadores ao longo da execução do projecto porque alterações ao projecto podem reduzir, ou aumentar, a viabilidade e benefícios do projecto.

Em projectos mais críticos e estratégicos, esta análise pode incluir outras variáveis, como o EMV (Expected Monetary Value) do riscos identificados e associados ao projecto.

E termino com a última versão do modelo económico em Excel.

Download da Versão 4 do Modelo Económico

No chaos report, por exemplo, são 65% os projectos que não têm sucesso. E apesar de isto ser um estudo elaborado nos Estados Unidos, nós temos por aí muitos casos fáceis de encontrar.

Apesar de muitas coisas se dizerem sobre a incompatibilidade entre o PMBoK e as metodologias ágeis de desenvolvimento de software, o importante é entender onde as coisas se encaixam.

Vou deixar aqui então o post antigo (13 Março 2008) revisitado com um conjunto de recursos.

Agile+PMBOK

Fica aqui uma apresentação, de Alan S. Koch para o Pittsburgh’s Chapter of the Project Management Institute, para reflectir sobre a compatibilidade entre os métodos ágeis de desenvolvimento de produto e o standard em gestão de projecto PMBOk.

Recursos

Scrum on!

Agile Advice

Agile Management

Chaos report