Software penetrates every pore of human existence. We look up the weather info over the web, giving up on outdoor thermometers. We’re driving to destinations with GPS navigator (forget paper maps with their G7 sections on page 59). We turn on RunKeeper when riding a bike to calculate the average speed and run and boast in Twitter. We’re using software every single day of our lives. It seems we’re hugging our dear gadgets a lot more than our loved ones.
No one knows the exact how-to of writing great software fast, that’s the problem. Waterfall passed away at the crossing of 2 centuries, whereas new software development methodologies (agile) fail at solving the fundamental problems so far. We’re living in very interesting times. Software development industry grows fast right here, right now, and the foundation for a quantitative leap is building up.
Have you ever asked the question, ‘When are we planning to do bug analysis?’ in a Sprint retrospective? This is one of those questions that is thought about but not asked during the initial iterations of Agile projects. Also, unfortunately, this question is forgotten over several subsequent iterations and asked during the end of projects when it becomes too late. By ‘bug analysis’ I mean the analysis of a group of bugs to study factors such as distribution of defects on priority, severity or application module as well as other aspects such as reproducibility or dependencies.
Several years ago, I became cognizant of asking this question. It was never an ideal situation for us to deliver bug free production ready software at the end of iteration. I am sure, even these days delivering production ready software at the end of iteration is not very common across projects. It is a tough goal. If you have achieved this goal, I should say you belong to a high performance team. In all general circumstances, bugs do accumulate, get prioritized, and fixed. Is this an adequate approach to execute projects? Don’t we need to identify the right time to initiate bug analysis and have a consensus on the frequency of performing bug analysis?
The first time when I asked this question the answer was, ‘The product is not stable enough to perform bug analysis.’ That took me by surprise and triggered additional thoughts. I asked further, ‘Should we wait for the product to become stable to do bug analysis? Or should we perform bug analysis in order to find ways to make the product stable? Also, shouldn’t we use visual boards to display bug trends and analysis so that the team understand not only the progress of user stories but also trends on product quality?.’ That’s when our approach matured to the next level.
Essentially, it makes sense to have a sizeable number of bugs to perform bug analysis and it depends on your project. Also, how detailed you perform bug analysis depends on your project as well. Bug analysis can reveal variety of useful information such as distribution of bugs across modules, distribution in terms of bug priority or severity, distribution of bugs in terms of bug status etc., The earlier we analyze and understand these parameters, the better it is for us to improve product quality.
Thinking of bug analysis late in the game seldom yields efficient measures to improve product quality. Next time when you talk to your Agile team try to trigger this question. Am sure you will come across interesting responses.
All said and done, bug analysis is a practice that can yield results in Agile projects. Do you use a visual board that displays bug analysis results and trends in your work area? What has been your experience in performing bug analysis? How frequently you do it? Is it beneficial?
Raja Bavani is Technical Director of MindTree’s Product Engineering Services (PES) group and plays the role of Product Engineering Evangelist and Agile Coach. Check his Product Engineering blog.
How does a great design differ from a good or mediocre design? Often the difference is just in the smallest details. These details shape user experience and greatly affect the way we feel about a product. The product may look great, but people remain cold using it. They don’t feel it is designed for them.
Views functionality in TargetProcess is not a rocket science. There are thousands of applications with views. View is such a boring page to work with usually .
New Views in TargetProcess are crafted with great attention to details. Every single detail is thought out. Every single decision was debated. Let’s dig into details. I will show and explain all of them.
Inline Edit
Inline edit (edit-in-place) is a huge thing. It allows you to edit everything very quickly. These two words are important: everything and quickly. In our new View you can indeed edit everything and do that really quick. But this is not all. Watch these two very short videos.
Inline edit in JIRA
Now compare it with inline edit in TargetProcess
The difference is clear. When you are editing something in JIRA, the effort value jumps back and forth. It is somewhat confusing and unpleasant. Effort in TargetProcess stands stone still as you edit it. This produces a totally different feeling. When everything is still you feel that things are under control. The jumps, on the contrary, are quite distracting, and you feel that something is not good (but often can’t say what exactly).
People assignments
People assignments component has all the small details that make it just awesome. Avatars enable quick recognition. You may think that avatars are not important, but with time you’re so used to them that you identify a person in a split second. Humans recognize image patterns much faster than words. With first and last names only you have to read. With avatars you just scan.
Quick filter is the fastest way to find someone if you have a large development team.
Popular actions are available on the top. Quite often you want to assign work to yourself or un-assign work. It is always a good idea to put popular actions to a visible place.
Moreover, potentially dangerous actions are marked red on mouseover, which secures them from accidental clicks. Also, the red mark builds up quick memory for actions. For Unassign, you will point mouse cursor and click quickly if the button is red without reading.
Links and Actions
There are two types of links: some links represent actions and some links are usual links. There should be a clear distinction between the two types of links, thus action links have a different underline style (dotted):
If you can perform an action (like edit), you miss an opportunity to jump to entity. This problem was resolved by adding a tiny icon. The icon is an idiomatic pattern to navigate away from the current page.
When a property is empty, it is not clear if you can edit it or not. You point cursor to an empty row and think something like “Hmm, is it possible to edit something here?” Then you click, and it appears that it is indeed possible to edit this value. But why make people think? The clear message is shown in an empty row when you move mouse over it:
Hidden Stuff
It is a good idea to show only relevant details. For example, you want to change release or iteration. Releases and iterations have end date, you have many releases and iterations that are already done. Most likely you don’t want to assign a user story to an old release. Thus, old releases are hidden by default.
Mouse over pattern is everywhere. So, all actions are hidden by default. You need to move a mouse cursor over a comment to edit or delete it. Thus interface is clean and not burdened with repeated buttons. There is one disadvantage in this approach: available actions are invisible by default for new users, and they might not be actually aware that they can edit something. But we consider this a good trade-off. We don’t design for new users, we mainly design for people who continuously use our product.
Multi-attach
How often you do you need to upload several files, one by one? It is intolerable in a modern web application. People should be able to upload all the files at once:
Layout
The general layout is pretty straightforward. You have a content area with title, tags, description, attachments and comments on the left, and more details area with miscellaneous information on the right. This separation is logical.
The layout of the area on the right is beautiful. The most important information is on top. For example, status of a user story and its progress. Then you see all assigned people with estimated effort. Everything is lined-up and there are no unclear labels or weird information. Only relevant information is visible. You can also hide information blocks if you want to.
This is it. New views are in beta and more improvements are coming. Stay tuned and give us your feedback. We live by it.
