Friday, December 04, 2009
Technology should touch lives
Tuesday, December 01, 2009
TEDxChennai - Talks that made me think...
Wednesday, October 28, 2009
Agile Scrum – A brief overview
Scrum is one of the methodologies used for iterative software development within the available set of agile methodologies. SCRUM is not an acronym and it has been derived from the game rugby. Scrum is a project / product development methodology which fits to the current changing paradigm and also gives more importance to project governance.
Unlike the current development team structure, scrum has only 3 roles to play within a team,
- Scrum Master – one who maintains the process and works to ensure the realization of goals of the Sprint.
- Product Owner – the primary stakeholder of the product. Basically the customer who is responsible for prioritizing the backlog.
- Scrum Team – a self organized group who do the analysis, design, implementation and testing.
- Sprint – a 2 to 4 week cycle where the scrum team works to accomplish a set of tasks. The duration of the sprint can be decided by the team. The output of each sprint must be a working piece of software.
- Product Backlog – is a high level document of the entire set of requirements for the project / product. This is prepared by the Product Owner and would be the input for arriving with the sprint backlog. Each item in product backlog would be prioritized.
- Sprint Backlog – is the detailed document of the items that would be performed for the current sprint to accomplish either a set of or a single item in the product backlog. The selected item(s) from the product backlog are broken down into granular tasks which can be accomplished within 8hrs of effort. These tasks would constitute the sprint backlog. This is done by the team.
- Sprint Burn Down Chart – is a line chart showing the remaining hours available to be burnt for completing the sprint. This chart is owned by the Scrum Master and has to be updated on a daily basis.
The Methodology
The product owner comes up with the story for the scrum. The story meant here is a one liner of the requirement that would be accomplished to meet the specific business need. This requirement is further broken down into detail requirement points called the product backlog.
Now once the product backlog is ready is when the scrum starts. There happens a scrum planning meeting where the product owner meets with the entire scrum team and discusses on the priority of the items in the product backlog. In this meeting it is also decided on the during of the sprint. Once the product backlog is completely created a Sprint Planning Meeting is initialized.
The duration of the Sprint planning meeting is 8 hours. During the first half, the product owner describes the goal of the product and the details of the product backlog to the team. The second half of the meeting, the team selects specific requirements from the product backlog that can be accomplished per sprint based on the priority. The selected requirements are broken down into tasks which are called the sprint backlog. It is to be kept in mind that each sprint is expected a deliver a shippable product / feature.
The Sprint begins and lasts of the agreed duration. There is no change allowed or entertained to be added / modified to the sprint backlog.
1. What did I do since yesterday?
2. What have I planned to do today?
3. Is there any issue that is obstructing my task?
Each sprint team member is expected to answer this question.
· There is nothing called schedule variance or effort variance for a sprint. It is only the Sprint Burndown chart.
Tuesday, October 13, 2009
Be real
The world will often discourage you from giving love. Give love anyway.
Many times, despite your best efforts, you will not be understood. Keep giving it your best anyway.
The treasures in life are not what you get back. Those things are only shadows of life's true value.
The real treasures are what you're able to give of yourself. And as long as you give authentically, from the heart, with the best you have, it doesn't really matter what comes of it.
It's nice to be acknowledged and respected and understood. Yet even when you're not acknowledged or understood, there is still great value in doing what you know is right, what you know is best.
Smile a peaceful smile to the depth of your being. Be real, and know that all is well.
Tuesday, September 29, 2009
PayPal Innovate 09 - The intersection of Ideas & Money
- 1. Get exclusive access through 2009 to PayPal payment technology for developers that is above and beyond Adaptive Payments
- 2. Hear Tim O’Reilly deliver the keynote address
- 3. Preview PayPal’s roadmap for 2010
- 4. See profitable early-adopter applications build on PayPal technology
- 5. Network with hundreds of other developers, VCs and PayPal engineering staff
- 6. Learn how to grow your business with PayPal’s payment solutions. Whether you are new to PayPal or an existing developer, the conference has tracks dedicated to helping you drive the most business with your products
Tuesday, September 08, 2009
My LWD with CSS Corp
Thursday, July 23, 2009
Interesting Amazon S3 tools
Monday, July 20, 2009
Interesting days...
Friday, July 10, 2009
Thoughts On Architecture - What does it mean to be an architect?
Monday, June 29, 2009
Cloud computing - the recent BUZZ
Cloud computing is now gettings exposed as public and private cloud and now the new flavour interests people. That's it. Let me share few extracts of the discussion that I had with a friend in LinkedIn:-
Discussion topic:- CloudComputing, XaaS! What are the disadvantages?
Reply 1:- Cloud computing can be broken down into 3 basic categories.
- SaaS - software as a service (using a hosted product such as SalesForce.com or CRM Online)
- PaaS - creating an application that is then deployed into a hosted environment (Windows Azure, Google App Enging)
- IaaS - a virtualized infrastructure hosted in the cloud (Amazon EC2, GoGrid and to an extent Windows Azure)
Based on the above three categories is what we need to talk about advantages / dis-advantages. But one thing we need to keep in mind is that when we talk about Cloud Based solution it-self, we are talking about a low-cost, PAYG model. Thus know that we are talking about a PAYG model, we will definitely need to understand that there are going to be more challenges that roses. But there are also paid models available with Amazon and Google where they ensure a well defined SLA.
Question again:-We are an ISV, we develop software in the tradional way. We install some desktop apps and a server. What would be the disadvantages if we would implement all three layers of cloud computing? Build our own Iaas, develop our SaaS on our PaaS. The user would access our apps through the browser. Why should we switch to the cloud(proprietary or from a vendor)? Why not? What speaks against it?
Reply 2:-
Question 1. When you say you would install some desktop apps and a server, then you are now under the IaaS category. Personally, I am not able to say that by working in IaaS you implement PaaS and SaaS, because they are three different categories. But essentially the provider would also have built a PaaS on top of IaaS and similarly SaaS on top of a PaaS, but there the provider has the entire control and knowledge of the underlying hardware. But in our case, though we get into IaaS, we do have limitations. Though you are said that you would be allocated a processor with X Ghz speed with XGB HDD and XGB RAM, it is only in a Virtualized environment. We would not be able to do any virtualization on top of the HW that we get to host VIA cloud. (This is equal to the Shared Hosting concept) Data security is something that you need to take into account since on a cloud based environment, you need to make sure that you don't share any of your data with others. This can be achieved only by encrypting your data when you load it to the cloud and your app only knows to de-crypt it. But this is going to kill your application response time. Also be aware of the SLA that the provider gives. If there is NO SLA, and your's is a critical business app, better to not chose cloud. Hence for the first question, there is no big disadvantage, but there are certainly a lot of limitations when trying to implement all the three layers by getting initially into a IaaS.
Question 2: For cost and scalability. Cloud is currently in the PAYG model. Let's assume that you have a site hosted in your own physical box at your site. Now you want to publish voting results of your place and you expect more people to use your site for that period of time. What would you do conventionally? Add HW. Right? But with cloud, we can host the result publish site alone as a seperate with a very high HW and BW to support the user volume of the one or two days and channelize it via our own site. Now after two days you can bring the site down. With Amazon EC2 kind of environment (Linux) it would cost you less that $5 for two days! Another example would be for a test bed. If you wish you test your SW to see it's performance you can very well do it from the Cloud by running multiple EC2 instances at the same time and kill all once your testing is done. To conclude on Q2, switching from vendor to cloud is a very high level decision that you need to make. The entire Cloud Computing space is not yet very mature except of one or two vendors in IaaS and SaaS space. So if your's is a mission critical application, it is better to be with the known devil as of now.:)
Question 3: Having spoken a lot in Q1 and Q2, I think it answers Q3 by itself.