There’s something in videogames that sadly life doesn’t have, that’s called a checkpoint. That’s right, that beautiful part of the game where a weird icon appears, normally in a corner of a screen, that indicates 2 things. The first one is that something that will make your progress more difficult is about to happen, and second, that you’ll probably die a lot of times and that it’s a good planning point to rethink your courses of action and strategies in the case of it. Videogames give you an infinite amount of chances to learn from your mistakes, maybe polish a strategy or change your view entirely. Sadly, life is not as good guy as videogames are. Life doesn’t give you a second chance to repeat a scene or a moment, if you did wrong, you did wrong, and you can’t keep on repeating until you get it right. Time is linear and the only thing you can do is get the fullest of the experience, learn and try to not make the same mistakes in similar, yet not equal, situations.
Nevertheless, what life does allow us is to take a certain amount of time to meditate our course of action. It’s not that of a douchebag that will keep enemies spawning and not giving any armor. No, life is comprehensive to a certain point, and in the stage delivery method, each end of stage is a good “checkpoint” to meditate our agains and never-agains so that we don’t keep repeating the same errors over and over again. Thank you not so douchebag life.
Propose changes and recalibrate estimates
The end-of-stage wrap-up is a good moment to speak up. If you would like to propose a change in the process or aggregate a certain feature there’s no
So, while I kept reading this book, I learnt a lot of things but my thoughts on some topics are the same as in Software Project Survival Guide, this book talks about Planning, Requirements, Risk Management, etc. and the same stuff as in the other book, obviously with a different approach but if you would like to know what the book says you should go ahead and read it, my blog isn’t meant to make a summary of everything, it has the purpose to give a personal opinion about what I’m reading.
In the blog posts about this book I will be writing about the chapters I found different or I have found a different opinion
This is it, this chapter talks of what I think it is the most important factor in everything, motivation, while I was talking about this in my post about Software Project Survival Guide Ch 12-14 I said I was thinking of doing a post about this and this isn’t it, I’ll give my opinion about what the book says about it, but now I will for sure make a post about motivation.
The book talks about the general factors that move people, after that the book explains you how to use the top five motivation factors in your favor, which I think it’s awesome, I don’t want to sound like I don’t care about people and I don’t want to use the following phrase but I think that manipulating people is a great factor to everything and if you are a leader believe it or not, you have to do it, you have to manipulate them and I think that the word manipulate doesn’t mean something bad.
Another thing I found incredibly good in this book was the Morale Killers, this is
At the end of every process, a stage of team feedback is pretty much a good practice. Learning from the experience and publishing the good and the bad of the project can make a team great. Several things can be made after the system was released, as a team and individually. The main topic is to stay with something after working on the project, either it was a huge success or a sad failure. We all learn from many things.
Of course our dear book recommends a series of activities to do after the software was laucnhed. The first of all is to hold a meeting in which the team suggests changes internally. As I understand, defect correcting is now used to fix internal trouble, and many things can be seen to make the team better. Another good thing to do at this point is to recalibrate the team’s estimates. Now that we have a finished project we can compare the estimates the team did and the real things. These reestimates include time, money and everything else. A difference is made between reestime (recalculate things) and slip (failure to meet a milestone).
Another things to check now is the team’s performance compared to the plan. How did the team follow the plan? This question can make a lot of bad things arise. Recall that plans must be kept public, credible and up-to-date. Documentation and project media can also be seen. Material for creating the project and documentation for its correct usage, as well as the plans and relevant working documents must be obviously kept, and many times these things can be made better. Finally, all these final analysis must be updated in the project log. We will keep things like project estimates, adjustments, schedules, dates, defects, changes, and things like
While I was thinking about chapter 12 I also had the idea to relate it to motivation, I will but something brief about it and maybe later I will create a blog post about motivation, i think it is really important in every aspect of our lifes. I’m also thinking of using a TL;DR section to summarize everything for those who doesnt want to read everything.
Okay, for this chapter I’m going to relate it to motivation, I do think motivation is the way to success. In order for us, the people in the world, to get motivated we need to have goals that we can achieve, things we dream of and try to accomplish them, thats why i think stage planning is an awesome idea, each time you finish something in a stage plan you will see results and you will have the feeling of finishing a goal you have, a milestone.
This chapter talks about how you need to create a staged plan and milestones, but a part that I liked a lot was when they talk about what to do when you miss a milestone or miniature milestone, well I do like a phrase that one of my aunts says: “There is no crisis that can handle 10 hours of work”, I personally think he is right everytime i have had some timing problems the solution comes from hard work, but hard work comes from motivation.
Detailed Design, as soon as i read the title to this chapter I completly knew i agreed with the importance of it, some time ago I had a project where a friend of mine(which was my client) came with an idea, we decided to do it and we started the project.
Imagine yourself at a bar, there’s a beautiful/handsome girl/guy and you want to conquer her/his heart with your sparkling personality, but he/she is surrounded by his/her hideous friends that won’t let you get nearby. You need someone to help you take the target friends far away, to create a distraction and give you the opportunity you’ve been mourning for. That angel in disguise is called a wingman (either men or women are called like that… I think). He creates the distraction you need in order to get close to your target and whether you achieve or not your goal it’s up to you, but you can’t deny you got all the support that you needed, and you know who also need a lot of support to achieve the quality desired in the code they’re developing? Developers of course, and you know who are their wingmen? Testers.
Testing and why is important?
Sometimes you’re so drunk in love by your own creation that you can’t see all the errors and defects it has. Sometimes you just need that outsider look that gives you objective feedback, and that is the testers job. In order to achieve the desired quality for the project, and for it to accept and integrate more code there needs to be a certain testing process that assures that quality and that can guarantee that the code won’t break with further integration of more code. This can earn a lot of debugging hours in the integration testing, because if it unit is correctly tested, then you can be sure that the only thing you need to test is integration problems and not unit problems. Your schedule and budget will thank you later.
Hopefully, at this point, we now have a reliable system (or reliable enough) to fulfill the requests, with changes approved and correctly tested functionality. It is time to launch the system! The defects should not interfere a lot with the functionality, documentation should be ready and rough, and other issues should be addressed. Theoretically, every build of the project should end in a launching state at the end of each test, but that is not always possible. McConnell says that one very well thing to do is to overlap the release of one phase with the detailed design of another. Having checked the quality of everything also brings good things to this point!
But a hard question comes to mind: when is the best moment to launch a system? How can we know that? Well, first of all, is it better to deliver low quality software early or high quality late? The latter. Several techniques are brought to us here. First of all, the most basical way to know this is through the defect count. Comparing the defects that are correected with the new ones to see if the project is having more corrections than bugs. If that’s the case, the project is under control! One can also consider the time a programmer delays on correcting a defect and make a prediction on how much time they still have to use. Another nice technique is the defect density, which is simpy the number of defects per line of code. This also helps to make predictions and see if everything is under control.
Defect pooling is also a good technique. Think of the defects as a division between two pools, divided in a Venn diagram with pool A and B. This technique works for programmers to be divided into the defect
In the middle of the war there’s no time for hesitation, there need to be quick actions and quick responses to enemy retaliation and the mission of the ruler is to stay calm and lead his army to victory. One famous phrase, and so ancient as well, is the rule of divide and conquer. This rule states that in order to achieve victory, it can be applied to war, politics and sociology; you need to divide the intended group, either a government or an army, into smaller more manageable groups in order to strike. Is easier to carry pieces of a rock than a huge block as well as killing a man is easier than a group of 20.
Applying this approach to software development it’s time to start analyzing how to break our project into manageable stages, and how to break those stages into even smaller parts called miniature milestone, and breaking THOSE MINIATURE MILESTONES INTO EVEN MORE, wait… that’s it, miniature milestones Is the atomic part. Well let’s see how to do it.
Stage planning and its parts
I know by this time around you’re absolutely tired of the word planning, but I swear that it’s something absolutely necessary. Please believe me! As I was saying, the beginning of each stage is about planning a detailed course of action; there needs to be and individual stage plan describing how to conduct individual design, coding, technical review, testing, integration and other needed activities. The most difficult part is to divide each stage into miniature deliverable milestones that help you track the progress of completion of each stage and the visibility status.
Stage delivery means turning a big project into little, more manageable projects, and each stage cycle being a mini project needs to be
A short treatise on testing is made on our book. Testing is, well, seeing how the system behaves, works and getting all the defects it could have. Diverse manners to test software are found, test cases and quality assurance seem to be the favorite ones. We must suppose that, at this point, testers can, well, test the software through a nice and realistic prototype and using manuals. Some systems doesn’t have these things, not even at this point, so testing becomes hard.
The test cases should be wide, so that all functionalities and requirements can be tested. The previously mentioned “smoke test” is still made at this point on daily builds. Developers must also still be ready for anything, because as defects arise, changes must be made quickly. A chart including them is a nice practice, and to keep the good quality, number of changes weekly should be kept in a lower number than 10. If a module like that is found, then it is likely that it is the one that may casue the bigger trouble. Finally, developers should be open to changes, and must be willing to work on them. If a developer says that he or she is working on something else and cannot work on the changes, that developer must be corrected.
McConnell, S. (1998). SOFTWARE PROJECT SURVIVAL GUIDE. Redmond: Microsoft Press