|
|
Warning: This post is the impression based on the feedback of one specific Scrum team. It does not try to enumerate all the properties that a Scrum tool should have, and you would be able to find many more posts from other people about specific benefits of one Scrum tool vs. the other.
We have been working with a Scrum team for the past 2 years, and one of the biggest problems that we were facing was about the usage of a tool. In the context of economy, we first tried to modify the existing tool we were using for Waterfall based development method, and used it for some time for Scrum. However, we used to run into issues within the first Sprint cycle itself, since the team pointed out several items that were not a good mapping for the artifacts and information that they learned about in the training, and during their usage of the tool, a percentage of time was spent in discussions about the tool. We figured out that there was a lot of discomfort related to the tool, and the percentage of time that the team was spending on the tool was more than we could afford, and was not at all productive. And it was getting very frustrating to the team, as even matters such as maintaining the backlog (even though it was was maintained by the Product Owner, the team wanted access to the Backlog to see what features were planned for future Sprints), breaking the stories into tasks and capturing the efforts pending for the task, and a good display of the Burn Down chart, were all either not good or were not there at all. We tried using Macros and other reports to make up for what was not there, but the overall satisfaction level was not there.
Finally, after another round of discussion with the team, we decided to get confirmation from management about buying licenses for the Scrum team members in a professional tool to handle Scrum, and went about the process to evaluate the demo versions of different tools. The evaluation process was intense, too long to be captured in this post, which essentially deals with the standards we used to evaluate these tools and determine whether they were appropriate for our use. These criteria were:
- Ability to capture the backlog items in an unreviewed state by the Product Owners and others, and then for the PO to review and do the prioritization
- Ability of the team members to view the reviewed and prioritized Backlog
- Ability to take items from the prioritized Backlog and assign them to the next incoming Sprint
- Ability to capture more details about these items, including User Stories and other free form text, such that details about these items could be captured to make sure that the items have enough information about them
- Ability to take these items and create tasks for them, including marking whether explanation by the PO and estimation by team members has been done for these tasks
- Ability for team members to update these tasks in an easy manner, so as to update the estimates for the pending tasks
- Ability to see the Burn Down chart in an easy manner
- Additional reports such as being able to calculate the Velocity of the team, and compare across Sprints
- Another additional criteria that would be a good factor was about whether the tool could be installed locally on a server inside the company rather than on a remote server. This helps a lot in terms of speed, but there are issues about maintenance and who will bear this responsibility
(If you folks feel that there are other items that would help, please provide these in comments).
- A deadlock is quite a frequent situation in the systems that have multiprocessors or do multitasking.
- When the two competing actions struggle for the same resource, they actually wait for each other to complete using the resource.
- But no one actually finishes and both the processes get trapped with each other.
- A deadlock occurring out of exactly two actions competing for a resource is known as the deadly embrace.
- It occurs whenever any thread or process try to access a resource that is being used by some other process which is also waiting for some other process to release some resource and so on.
- Then these processes and threads enter a waiting state.
- If it becomes almost impossible for the process to change its state because of the resources that it is requesting are being held by other process that are also in waiting state, then a deadlock is said to have occurred in the system.
- Deadlocks are counted among the most common problems of the distributed systems, parallel computing and the multiprocessing systems.
- In these systems the shared resources are handled by the means of the hardware and the software locks.
- Process synchronization is also implemented with the help of same means.
- Deadlocks are also common in telecommunication systems because of the signals getting lost or corrupt rather than due to resource contention.
Causes for a Deadlock
There are 4 conditions or causes also known as the Coffman conditions that if occur simultaneously lead to a deadlock situation. These causes are:
1. Mutual exclusion: Among all the resources there is one that cannot be shared. At any point of time that resource can be used by only one of the processes requesting for it.
2. Resource holding (hold and wait): One resource is held by at least one of the processes and these processes are further requesting for other resources that are being used by other threads or processes.
3. No preemption: Resources should not be de-allocated after allocation by the operating system. The processes holding them must release them by their own. We mean to say that there should be a voluntary surrender of the resources.
4. Circular wait: There is a set of processes all in waiting state. The first among these is waiting for the second one to release the resource and the second one is waiting for the resource from third one and so on. And the last one is waiting for the first one to release the resource.
- A deadlock would occur only if all these four causes or conditions are present.
- The occurrence of the deadlocks can be prevented if any one of these four causes is removed.
- There are a number of non – standard manners in which the operating systems respond to the occurring deadlocks.
- Today, a number of strategies have been developed for handling the deadlock situations.
- In one approach it is simply assumed that there are no chances of occurrence of a deadlock.
- One such example is of the ostrich algorithm.
- Systems such as the UNIX and the MINIX were the first one to implement this approach.
- This approach was used when the duration between the occurrences of deadlocks was wide enough and the data loss could be easily tolerated.
- Deadlock detection is another strategy for handling the deadlocks.
- Here, the deadlocks are allowed to occur but they are corrected also.
- This approach employs an algorithm for tracking the allocation of the resources and the states of the processes.
- Deadlocks can be avoided if it is known whether the following stages of the process will be safe or unsafe by using the details of the resources currently in use.
One of the constant issues that we hear on a regular basis is about the imbalance in terms of teams being busy during parts of a Sprint rather than through the Sprint. For example, one of the biggest problems reported was that the development team would be busy during the early parts of a Sprint, and after they had made the delivery of their components to the testing team, that would be the time when the testing team would become busy. The expectation was that things need to be configured such that this sort of cycle needs to be avoided, and that the testing team should not be busy only for parts of the sprint, but through the sprint in order for the productivity of the team to be increased and kept at an optimum level.
If you keep the normal cycle of a Sprint in progress, it would follow that the team would be given tasks, they would estimate and bid for the tasks, and then would start working on the tasks. However, this also meant that if the developer had a task, there would be time involved in doing design for the task, there would be the working with the user designer in order to get the dialogs and other user interface ready, and all of this would happen during the Sprint. It was only when all this was done, and then coding happened would this work get to the tester for actual testing, and in some cases, the amount of time available for this testing was a stretch, because the Sprint done timeline was coming up fast and there would be a lot of hectic work involved in testing, defect fixing and re-testing.
One idea of course which works in many cases is to re-look at the breakup of the tasks that are being assigned to the development team. If there are many days that go by before the work can be given to the testing team, then the tasks are not being broken down into smaller sections as much as desired. If the tasks can be broken down to 1-2 day sections, then the testing of those tasks can start very early, and the time duration in which the tester apparently does not have enough to do is reduced.
The next thing to do is to not have loading of the design of the tasks in the current Sprint, but ensure that all the major design work, especially the interaction with the Interface and Visual Designer happens in an earlier Sprint, captured as a separate task. Working with the designer for workflows can take time and be iterative in nature, and putting this in the current Sprint along with the development (writing of the code for the same) can lead to the same problem about the testing team not receiving it in due time.
Yet another item is about ensuring that the tester team is also working towards preparing the test plans and test cases for the User stories. These are based on the requirements, and not on the code that the developer is generating, and so can happen in parallel with the development effort and ensure that the testing team has enough on their plate to do in the early parts of the cycle. Combining these approaches led us to ensuring that we had lesser of this problem of the testing team sitting with not enough tasks, but it would still happen sometimes.
Memory is a vital element and central also. Memory can be thought of as an array of many locations having their own addresses.
About Memory Management
- The processes interact with each other through a sequence of read and write operations at the specific address spaces.
- The program is fetched by the operating system from the disk and stored in to the main memory.
- For the execution of the program it should be mapped with its absolute address and then loaded in to the main memory.
- Usually, the programs are stored on the disk as the executable files.
- That is why they have to be brought in to the main memory and assigned a process for executing.
- These processes are what that form the ready queue.
- Generally, it is from this ready queue, that the processes are fetched for execution.
- During all this processing, the addresses might be represented in a number of ways such as in symbolic form or source code address and so on.
- This symbolic address is bound to the address that can be relocated by the compiler.
- Next, these relocation addresses are bound to their absolute addresses by the linkage editor.
- Before storing a program in memory, the memory addresses that it is going to use must be bounded.
- Binding process is all about assigning the address to code and data.
- Binding can be done either at the compilation time or loading time or execution time.
- At the compilation time, if the memory location is known beforehand, generating the absolute code is possible.
- At the time of loading, if the location is not known, it has to generate relocatable addresses.
- All the modules must be kept on the disk and that too in a relocatable format for better memory utilization.
- Here, only the main program is fetched and executed.
- The other routines are called only if required and loaded and then executed.
- This kind of loading is termed as dynamic loading.
- The responsibility for dynamic loading lies on the user and not on the operating system.
- The purpose of the operating system is to just provide the library routines for its implementation.
Overlay Concept in Memory Management
What to do if the size of the process is larger than the available memory?
- This problem is overcome by using the technique of overlays.
- This implementation of this technique does not require support from the operating system.
- This technique is also implemented by the users.
- The whole program is divided in to sets of data and instructions in such a way that the required set can be loaded in to the memory when required and released when used.
- These sets are called overlays and program loads and unloads them.
- Formally, it can be defined as a part of the application program that is loaded at the same point where before some other parts of the program were loaded.
- A program that follows the overlay scheme consists of the following:
- A piece which always resides in the memory called root.
- Set of overlays
- Overlays serve as a means for the program for extending the physical memory that is very much limited.
- Mutual exclusion is an important concept related to the identification of the overlays.
- Mutual exclusion concept emphasizes on routines that do not invoke one another and therefore cannot be loaded in to the memory at the same time.
- Overlaying has made it possible for the programs to be larger than what the memory of the system can hold.
- Overlays are usually used in the embedded systems because they have a very limited physical memory i.e., their internal memory and they lack the virtual memory techniques.
|
Software Jobs If you have the following profile, and are looking for a job in India or in the US, please send an email to getitjobsindia@gmail.com
1. Software developer in Java / C / C++ / C# with experience more than 2 years
2. Software quality tester with experience more than 2 years
3. Product Management for a software company
4. Program Manager / Project Manager for a software company
5. User Interface Designer / Graphics Designer / Visual Designer
6. Tech Writer
7. Software products support
|
Recent Comments