Let’s do it! – The trial begins

--Originally published at TI2011 – Project Evaluation and Management

Resultado de imagen para lets do it

This post will be focused on all that I learned from reading Survival Guide and Project Evaluation and Management (TI2011) and how I am going to apply all of this.

Firstable, The next week I am going to be part of a development project, in which the team will be of 3 developers and I’m one of them, so the project seems to be consistent because the project requirements and project process have been taken from one month ago.

Thus, reviewing the requirements I start to make my own plan besides the sprints and delivery times that are stablished at the beggining. Also I am trying to fixed my schedules and designed the architecture for every delivery and see how every one will affect the other ones.

One of the important things that I think it is important is to see if the project could have risks and how can every development and stage will affect in the whole project. Also something I like for the plan that is that every development has contemplated the code time to do it and some extra time to the testing cases of each one.

So, finally I am eager to see what is coming and to make the most of this experience of being part of a project from the beginning.


I’m a Pragmatic Programmer

--Originally published at TI2011 – Project Evaluation and Management

Final review for The Pragmatic Programmer by Hunt, A. & Thomas, D.

Resultado de imagen

The book contains a quick reference guide with 70 tips using entertaining anecdores to explain the way the autors made his workflow more efficient and very productive.

So here is the review of all the 70 tips:

  1. Care about your craft – Why you soend your life developing software?
  2. Think! About your work – Take control, explain what can be done.
  3. Provide options, Don’t make LAME excuses 
  4. Don’t live with broken windows – Fix bad designs, wrong decisions and poor code
  5. Be a Catalyst for Change – Show how can it be and help in creating it.
  6. Remember the Big Picture – Check what’s happening around you.
  7. Make quality a requirements issue – involve users to determinate the real quality
  8. Invest regularly in your knowledge portafolio – make learning a habit
  9. Critically Analyze What you read and hear – analyze information in terms of you and your project
  10. It’s both what you say and the way you say it – Know how to communicate effectively your ideas
  11. DRY – DON’T REPEAT YOURSELF – Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
  12. Make it easy to reuse – it it’s easy to reuse, people will.
  13. Eliminate effects between unrelated things – Design components that are indepentedent and self-contained
  14. There are no final decisions – No decision is cast in STONE
  15. Use tracer bullets to find the target 
  16. Prototype to Learn – Prototyping is a learning experience
  17. Program Close to the Problem Domain – Design and code in your user’s language.
  18. Estimate to avoid surprises – Estimate before you start.
  19. Iterate the schedule with the code – Use experience you gain as you implement to refine the project.
  20. Keep Knowledge in Plain Text – It helps start your
    Continue reading "I’m a Pragmatic Programmer"

Build the software

--Originally published at TI2011 – Project Evaluation and Management

Chapter Fourteen – Software Project Survival Guide by Steve McConell

Resultado de imagen para build software

When we are planing a project, we try to visualize how is going to work, which tools we will need, how many time do we need and other questions that we are talking about in the previous post. So, in this post I am going to talk about Construction stage during a project.

Construction is the stage where we create and bring to life the project. If you made the necessary plans, then you will even be able to make more “fancy” your project, perhaps add something that you believe it is not on the requirements but it will help a lot the user.

So, this chapter give us some recommendations in order to add more to the construction:

  1. Develops a piece of code.
  2. Unit tests the code.
  3. Interactive debugger.
  4. Integrates preliminary code with a private version of the main build.
  5. Submits code for technical review.
  6. Test case preparation.
  7. Code is reviewed.
  8. Fix any problems identified during the review.
  9. Fixes are reviewed.
  10. Integrate final code with the main build.
  11. Code is “complete.”

This recommendations are very useful because those help us to reduce errors, make us sure that we submitted the code and it covers all the features that it was proposed.

For this stage we should have an order, start building the skeleton of the project, keep in mind the previous recommendations, documenting all changes and test and fix according with the previous list.


Almost done? – Final preparations

--Originally published at TI2011 – Project Evaluation and Management

Chapter Eleven – Software Project Survival Guide by Steve McConell

Resultado de imagen para almost done

Once we know the important things about how we are going to plan, design, avoid and develop our proyect then we are ready for final preparations.

The developers team is ready to create its first estimates, develop plans for deliverys and get a solid organization on the project.

So, lets talk about create meaningful estimates, because it is posible that the team can give its own estimates, but they must know that the estimates must contain effort, cost, and shcedule, should be written, assuming that the team will not work overtime, it should be created over estimation software, should be based on previous projects. All of this must have a lot of organization because estimates can change everytime.

Keep in mind risks in every stage and estimate in the project. Write a Staged Delivery Plan, deivering in stages with functionalities.

It is important that everything (risks, changes, bugs) can happen on a project, so the project estimation is necessary and important because is the way to know what you will deliver and do, and always try to see if the estimate will be reachable in order to say yes or no for the develoment.