Posts Tagged ‘Agile Principles’
September 2nd, 2012
Continuous integration is a way to applying quality control by integrates pieces by pieces of effort into project. When embarking a change, the developer takes a copy of the current code base on which he works on. As other developers submit changed code to the code repository, this copy gradually cease to reflect the repository code. When the developer submits his code to the repository they must first update their code to reflect the changes in the repository since they took their copy. If a lot of changes have happen to the repository, the more work the developer must do before submitting their own changes. If the repository becomes so different from the copy the developer is working on it becomes what is called as “integration hell”, where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-cast scenario, the developer may have to discard their changes and redo the work. In order to avoid “integration hell” the practice of continuous integration is used. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
One warning when adapting CI!
The focus of integration and automated builds leads to a false feeling of secure, as long as it builds and all tests passes people tend to be satisfied. But in order to gain all benefits that you strive for, like getting feedback on just work done these test isn’t enough. In order to be as productive as possible you need to really test as close to the development as possible. You will save a lot of time if you find a bug or mistake that you done today or this week, rather something someone may have done to the code base during the last 6 month.
Continuous integration is like one apple a day, it keeps the debug doctor away. But it doesn’t gain its full power if you also complements with frequent testing and verification of the system.
December 25th, 2011
One management practice in is that you might estimate everything you do in ideal time. Ideal time is how long a task takes if there were no interruptions. And when you plan you don’t plan that all work is 100% focused and non-interrupted. Instead you can calculate with a velocity. Velocity is the number of user stories (or user story points) you can do in one iteration (or sprint) in Scrum this is known as the focus-factor. If your team (4 persons) under a 3 weeks sprint working 40 hours a week completes user-stories that where estimated to be 360 hours of ideal time your focus factor / velocity would be 66%.
Advantages of the velocity term is that it is much easier to estimate in ideal time, it’s what comes natural when you think of how long something will take to do. You get a focus on prioritizing to work with only planed work tasks. People avoid interruptions. You don’t need to plan to do more work than time available × the focus factor per iterations so you don’t get false expectations. You are able to trace the velocity over time, velocity has ability to peek in the middle of a project and become lower in the beginning and in the end of a project. In the beginning it can have with that people are stumbling on how they will work and they might not have all infrastructure and roles on place. In the end of a project new unplanned work have a certain ability to appear. It often takes between 3 to 6 iterations for velocity to stop fluctuate and become more stable.
This doesn’t mean that 34% of the time was wasted it, is not just spend on things that where planed and prioritized from start.
May 29th, 2011
The Agile Manifest says that people is more important than a process. But what if you don’t have a great team that are smart, disciplined and attentive. If you projects consists of three trolls, a senior fresh out of school consultant from Accidenture and a relatively bright project manager, who happens to be deaf, blind and mute. No amount of coaching can help this team to magically self-organize and deliver a successful product. Then rules, micromanaging and a step-by-step process might be the only way. Smart, disciplined and attentive people simply do their jobs well and don’t get ticket for dangerous behavior. And the agile methodologies build an assumption of that you always got the great team. But the world isn’t perfect, sorry all employees. So self-organizing might not work so good for all teams.
Related post: Self-Organizing Teams the most debated Agile Principle
May 24th, 2011
Pair programming is sharing knowledge not only about how the code works, but also why it looks that way. It is sometimes difficult to write explicit instructions on why code looks a specific way and how it’s organized in pair programming. A common question about pair programming is will pair programming slow us down? The answer is yes and no. If the purpose is to spread knowledge, I would reformulate the question to will pair programming slow our learning or speed it up? Another advantage of pair programming is that interruptions tend be minimized.
Sometimes a group’s efficiency is linked to the specific knowledge of one or more people. When an expert becomes a bottleneck, let that expert be the adviser. By spreading the knowledge and letting the team try it first without the expert, it might not be as efficient, but in the long run, the knowledge spreads.
If you are not allowed to make mistakes, you will not understand the whole picture. If the expert isn’t directly involved, the rest of the team has to take more responsibility but still must have access to the expert as an adviser. The expert being fully involved is probably the most efficient approach, but if it limits the team’s performance, it would pay off in the long run.
May 22nd, 2011
Agile work uses short cycles so that developed things get too used fast. All code that isn’t used is just an inventory cost and isn’t learned from. The sooner that valuable result can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction. In order to learn as fast as possible about the real use and see how it works frequent deliver of the system is a core idea. There is an explicit trade off: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
May 16th, 2011
When the team focuses moves from “me” to “we” coding standards becomes a natural outcome. Code must be formatted to agreed coding standards. Coding standards keep the code consistent and easy for the entire team to read and re-factor. Individual style is great when you’re working alone. In team software development, however, the goal is to create a collective work that is greater than any individual could create on his own. Arguing about whose style is best gets in the way; it’s easier if we work together in a single style.
May 12th, 2011
Code reviewing has two purposes. The first is to make sure that the code that is being produced has sufficient quality. Is it ready for the next step in the process, might be check-in, merged to main track of the source or deployment. Code reviews are very effective at finding errors of all types, identify a poor structure or identify that the source doesn’t meet the business proposal. It’s a effective litmus test for quality of the code.
The second purpose is to spread knowledge, both for the coder and the reviewer. Developers learn when and how to apply techniques to improve code quality, consistency and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.
Code reviews can easily start off on the wrong foot, because they are perceived as an unnecessary step that has been forced upon the developers or seen as an evidence that managers doesn’t trust the developers. Code reviews are a proven way to minimize defects.
Image source: http://zuskin.com/coding_habits.htm