Archive for December, 2007

Planning Extreme Programming

December 16, 2007

Planning Extreme Programming by Kent Beck and Martin Fowler

Amazon.com: “The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better.
Simplicity is the watchword of the XP software process. This book is virtually devoid of traditional software-engineering jargon and design diagrams, and yet does a good job of laying the foundation of how to perform XP–which is all about working with a customer to deliver features incrementally.

The terminology in the book is commonsensical. (In the terms of XP, each iteration adds certain new features, or stories. It’s up to the customer to decide what functionality is more important and will be delivered first. By never letting a working build get out of sight, the XP process virtually ensures that software will be close to what the customer wants.)

Early chapters borrow analogies from everyday experience–like planning a trip or driving a car–to set the stage for XP process planning. The book has plenty of advice for dealing with the stakeholders (customers) of a project. Because of confidentiality agreements, however, we don’t get many details from the real world, although the discussion is anchored by a hypothetical project for planning the Web site of the future for travel, with some specifics.

There is plenty of advice for planning projects, based on individual and team “velocity” (a measure of productivity) and the like–practical suggestions for running daily, short status meetings (in which all of the participants stand up, to keep them short). Clearly, there’s a culture that surrounds many XP teams, and this text does a good job of conveying some of this to the reader.

At fewer than 150 pages, Planning Extreme Programming is notably concise, and that’s probably the whole point. Most shops today work on Internet time, which doesn’t wait for extensive project analysis and design documents. In XP, you create working software from the very start. This book is an essential guide to anyone who’s working in XP shops or who might be interested in what this innovative, iterative software process can offer. –Richard Dragan

Topics covered:

  • Introduction to planning
  • Risk management in software
  • “Driving” as a metaphor for software development
  • Roles for software development: business vs. technical people
  • Four variables for project planning: cost, quality, time, and scope
  • Predicting future programmer productivity, based on past performance
  • Project scope and estimation
  • The XP process: software releases, iterations, stories, collecting, and writing stories (features)
  • Hints for ordering features
  • Tips on planning and status meetings
  • Using visual graphs to monitor project progress
  • Tracking and fixing bugs
  • Project red flags

Book Info
Focuses on the time and cost for developing each user story and determining its priority, and planning software releases accordingly. Covers such topics as outsourcing, making changes to the team, dealing with bugs, and working with business contracts. Softcover. DLC: Computer software–Development.”

Milestone: 2000 spam comments

December 11, 2007

It’s a sweet moment again.

Everybody hold each others hands and say “Thank you!” alltogheter. :)

spam_milestone_2000.png

Version Systems

December 5, 2007

I didn’t take care of them until, in 2003, a collegue of mine talked about CVS.
I already read that term somewhere … mmmm … it was on my Unix book!

Shame on me! ;(

It took 2 weeks reading a 30-some pages tutorial, understanding what CVS did and did not, merge, branch, commit, check-out, and so on.
CVS was one of many professional Big Bang.

Since CVS, I’ve always pushed for using one of those sw, CVS, SVN, SourceSafe, etc.

Yes, most of the times what I needed was nothing more that check-in, check-out, sometime get that changeset, etc,
it was related to lifecycle of software I was developing.

Next-step in my version system user experience was TFS, so a higher user level came; I had to branch, and merge, and re-branch, and re-merge.
Only few times, but it helped me to better understand the tests I always made on my own.
Of course, few tests with 30 files set on your pc are different to a 300 files solution, with some developers and testers waiting for you. ;)

If you want know more, please have a look at “Enter Distributed Version Control” section in this post: Version Control and “the 80%.
It has remembered to me that I would not shave without a version system, if only I could. :)

Is it time to move next step ?
Am I ready for DVCS ?

Technorati tags: Version Systems, CVS, SVN, TFS, DVCS

There was no error (Re: Spot the error)

December 2, 2007

About a month ago, in Spot the error, I wondered how VAT was calculated.
I asked for infos, and the company support kindly answered, with something like this: “VAT includes shipping costs”.
So, based on that example, VAT is: (43.99 + 7.00) * 20% = 50.99 * 20% = 10.20 E .
Perfect.
Another mistery unveiled :D

  •  

    December 2007
    M T W T F S S
    « Nov   Jan »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • .

    .Net Agile Antivirus Book C# Programming Hyper-V MVVM Resharper SCRUM Security SQLServer Unit Test Virtual PC Visual Studio Windows7 WPF XeDotNet