“Employee communication has become a competitive advantage for companies,” says communication specialist Terry McKenzie, who once served as a senior director of global employee communications and communities at Sun Microsystems. While at Sun, McKenzie introduced a communication goal tool referred to as the KAA model using knowledge, attitude and action to facilitate organizational change. In this tip, we’ll take a look at how the KAA model works and how it might be applied to organizations that are transitioning to an Agile software development environment.
Using the KAA model to help in facilitating change
The basic principles of KAA are straightforward. For each of the three areas – knowledge, attitude and action – you look at your current state and your desired end state. You then put together a strategy that will help you reach your end state in each goal area. McKenzie emphasizes that just telling employees about a change is not enough. You must actively communicate with the employees by discussing the change, getting their input and following up on their questions or suggestions.
Seven questions McKenzie suggests to ask about change are:
1. What is it and why is it needed?
2. What does success look like?
3. What will the results be, and how will they impact me?
4. How will the change be supported
5. How are concerns being handled?
6. How will it be rolled out?
7. What will you do to make it stick?
Let’s take a look at how this tool might be applied in organizations that are adopting a new Agile methodology, such as Scrum.
Knowledge of Scrum
You’ll start by assessing the existing knowledge of Scrum within your organization. You will want to take a look at the skill sets and experience level of your project team members. Your desired end state may be that you would like all the project team members educated in the use of Scrum. You may want to go beyond just the team members, however,
Show Me More
More on Scrum software development
Get help from the community
Powered by ITKnowledgeExchange.com
and make sure that even those who aren’t directly on the Scrum team receive some amount of training so that everyone is speaking a common language.
Put together a plan of the level of knowledge of Scrum that you think will be necessary and then put together a training plan that will help you reach your knowledge goals. Perhaps it will include outside training or Agile coaches. In the tip, Adopting Agile: Eight traction tips to make Agile development stick, we find that Howard Deiner stresses the importance of training the entire organization, saying that a foundation is important for everyone. Other Agile luminaries such as Scrum coach Jean Tabaka and Scott Ambler also speak frequently of the importance of education and learning from experienced mentors when it comes to an Agile transition.
Attitude about Agile adoption
When it comes to attitude, again, we start by assessing the current feelings of the people affected by the change. Team members may be very excited about an Agile adoption or they may be resistant. “Some people take to certain changes very easily and other people don’t. And if they don’t, and you want that change to happen, you have to figure out, ‘What is it that keeps them from changing?’ Almost invariably they’re worried about losing something they value. So what is that thing that they value? The best way is to ask them,” says Agile expert George Dinwiddie in an interview about cultural change at the 2011 Agile Development Practices West conference.
In the tip, Real world Agile: Gaining internal acceptance of Agile methodologies, we hear from Scrum Masters who have struggled with the task of gaining buy-in from people, both managers and team members, who are not ready to jump on the Agile bandwagon. Matt Weir found that those who were once the biggest resistors ended up becoming his biggest allies in the effort to gain acceptance. “The skeptics were the ones who were asking the right questions and came up with some really great ideas,” he says.
Action in Agile adoption
Along with the knowledge and the attitude, you have to evaluate the actions that are taking place regarding your Agile transition. Is your entire organization adopting Agile, or are you starting small and transitioning one project at a time? Where are you now and where do you want to be? What will your roadmap look like?
Though it may be tempting to take the ‘big bang’ approach, some Agile consultants recommend against this. “Friction between those who want a new way to do things, and folks who prefer the old way, is the cause of a fair amount of conflict, strife, and failure in Scrum adoption,” says Matt Heusser in his tip, Large-scale Agile: Making the transition to Scrum.” When it comes to Agile transition, he recommends, to not do it all at once, “but instead incremental, done in a way that respects people and gives them options.”
Conclusion
Regardless of whether your entire organization has moved to Agile or you are starting slowly with a few teams, you need to continually evaluate how the team is doing by using retrospectives. The Agile methodologies include processes allowing for continual improvement, so take the time after each iteration to evaluate the team’s competencies in terms of knowledge, attitude and action. How close is the team to reaching desired end states?
Though we used the example of Agile adoption to step through use of the KAA model, this model can be applied to any type of change. Take the time to have conversations with people that will be affected by change. Listen to their concerns and work with them to address those concerns. If you keep an eye on knowledge, attitude and action, communicating effectively and openly about your goals in each area, you’ll gain the support needed for effective change.
Thursday, September 29, 2011
Monday, September 26, 2011
What are the main activities in Scrum?
The sprint itself is the main activity of a Scrum project. Scrum is an iterative and incremental process and so the project is split into a series of consecutive sprints. Each is timeboxed, usually to between one week and a calendar month. A recent survey found that the most common sprint length is two weeks. During this time the team does everything to take a small set of features from idea to coded and tested functionality.
The first activity of each sprint is a sprint planning meeting. During this meeting the product owner and team talk about the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to perform during the sprint.
On each day of the sprint, a daily scrum meeting is attended by all team members, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than fifteen minutes. During that time, team members share what they worked on the prior day, will work on today, and identify any impediments to progress. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint.
At the end of a sprint, the teams conducts a sprint review. During the sprint review, the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality. But it may just as likely result in revising or adding items to the product backlog.
Another activity performed at the end of each sprint is the sprint retrospective. The whole team participates in this meeting, including the ScrumMaster and product owner. The meeting is an opportunity to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.
The first activity of each sprint is a sprint planning meeting. During this meeting the product owner and team talk about the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to perform during the sprint.
On each day of the sprint, a daily scrum meeting is attended by all team members, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than fifteen minutes. During that time, team members share what they worked on the prior day, will work on today, and identify any impediments to progress. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint.
At the end of a sprint, the teams conducts a sprint review. During the sprint review, the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality. But it may just as likely result in revising or adding items to the product backlog.
Another activity performed at the end of each sprint is the sprint retrospective. The whole team participates in this meeting, including the ScrumMaster and product owner. The meeting is an opportunity to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.
Introduction to Scrum - An Agile Process
As a brief introduction, Scrum is an agile process for software development. With Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long. While an agile approach can be used for managing any project, Scrum is ideally suited for projects with rapidly changing or highly emergent requirements such as we find in software development.
What is Scrum?
Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.
These agile development teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a sprint, team members commit to delivering some number of features that were listed on the project's product backlog. At the end of the sprint, these features are done--they are coded, tested, and integrated into the evolving product or system. At the end of the sprint a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
What is Scrum?
Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved.
These agile development teams are supported by two specific individuals: a ScrumMaster and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are timeboxed iterations no more than a month long. At the start of a sprint, team members commit to delivering some number of features that were listed on the project's product backlog. At the end of the sprint, these features are done--they are coded, tested, and integrated into the evolving product or system. At the end of the sprint a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
Thursday, September 22, 2011
Logic and Software Testing
Summary: Formal logic is what runs computers, but it is only a part of the logic used by a software tester. In this installment of his ongoing series on philosophy and software testing, Rick Scott explains.
QSM
Finally, we come around to a branch of philosophy in this series that most people will immediately associate with software. Logic is what runs computers, right? After all, they are logical machines. However, the software we are testing often seems to behave in a way that is anything but logical. So, what exactly is logic, and how is it relevant to software testers?
What Is Logic?
We bandy the word “logic” around a great deal, but our mental definition of it tends to be a bit amorphous. While we have a good general idea of what logic is, we tend to conflate it with “thinking" and “reason.”
Thinking is, broadly, any mental process. Reason is a kind of thinking—specifically, a mental process of arriving at an answer to a question or of deciding amongst choices. Logic tries to enumerate rules for reasoning—rules that allow us to reason in an orderly manner and help to ensure our conclusions are sound. As such, logic is invaluable for ensuring that we make robust decisions, that we are systematic in our consideration of difficult issues, and that we can perceive the flaws in erroneous arguments before they mislead us.
Formal Logic
Formal logic (also known as “mathematical logic”) is the flavor of logic that comes to mind when we speak about computers. It’s based on “propositions” or “Boolean variables” that can be either true or false. These are combined with logical connectives, such as AND (true when all constituent propositions are true) and OR (true when any constituent proposition is true). This, along with conditionals (IF ... THEN), is the foundation of how computers “make choices” or “reason” at both the hardware and software levels. For example:
IF the user is logged in,
AND the user has the correct permissions,
THEN show the user the configuration page.
IF this exception is uncatchable,
OR we haven't provided a way to handle it,
THEN crash.
Testers make use of formal logic in ways beyond understanding the machines we work with, particularly when it comes to testing strategy. Whether we explicitly say so or not, we often plan our test steps and allocate our time using formal logic: IF performance is slow AND it’s slow in browsers other than Internet Explorer 6, THEN I'll spend more time on performance testing; otherwise, I'll devote more time to inspecting the new UI. In those blessed (albeit infrequent) scenarios where we can enumerate all the possible inputs and outputs of a test scenario, we can use truth tables to make sure we don't miss anything and sometimes tools such as Boolean algebra or Karnaugh maps to separate the inputs that should affect the outcome from the ones that shouldn't.
Informal Logic
As software professionals, half of our job is interfacing with technology and half of it is interfacing with people. While it is laudable to have found an important bug buried deep in a application’s dark recesses, it does no good for the users of the software if you can’t convince management or the development team that it is worthwhile to fix it.
Informal logic (sometimes called "persuasive logic") is how we form arguments and attempt to reason with each other in our everyday lives. As opposed to the mathematical structure of formal logic, it deals with argument and reasoning in natural language. An argument consists of one or more premises, a line of reasoning, and a conclusion reached thereby. Informal logic outlines what constitutes a sound premise and what constitutes valid reasoning so that the conclusions we reach are both justified and defensible.
As one of the core skills involved in bug advocacy, informal logic is invaluable to testers. It lets you argue why something is in fact a bug and why that bug is important enough to fix. In a broader context, informal logic is the tool that lets you advocate for any of the myriad ideas and initiatives that you come up with. It may be clear to you that the test team needs more resources or that one feature should be prioritized over another, but neither course of action is likely to happen unless you can present a convincing argument for it to someone in management.
Logical Fallacies: Learning by Counterexample
While studying the attributes of a sound argument seems like the most straightforward way to get a grasp of informal logic, learning about common logical fallacies is a more accessible route to take. The language used to describe them is colourful (as opposed to the rather dry theory often associated with formal logic), and you can usually come up with instances of their occurring in your life or workplace.
To illustrate, let’s see what specious arguments we can muster to rally support for a statement that is patently false. I’m going to make the claim that pigs can fly. When someone points out that they can’t, I can try to discredit him or her personally: “Do you have a degree in biology? And, didn’t you just tell a lie the other day?” This is called ad hominem (Latin, “to the man”). I’m attacking the person presenting the argument instead of refuting the argument’s substance. Alternatively, I can reply with the following: “Why do you think animals can't fly? Birds fly all the time.” This is a straw man. I’ve misrepresented my opponent’s argument, then attacked that misrepresentation instead of the actual argument.
When it comes to affirming my own dubious position, I have many options:
* Argumentum ad populum (“appeal to the people”)—“Ten thousand people believe that pigs can fly, so surely they can.” This is claiming that something is true because many people think it is.
* Argumentum ad verecundiam (“appeal to authority”)—“Professor Bloggins says pigs can fly.”
* Argumentum ad consequentiam (“appeal to the consequences”)—“A world where pigs can fly would be an awesome place, so I'll believe that they can.”
* Argumentum ad baculum (“appeal to force” or, literally, “appeal to the stick”)—“If you don’t agree that pigs can fly, I’ll punch you in the nose.”
* Argumentum ad nauseam—Finally, ridiculous though my case may be, if I continue pressing it long enough, everyone else will get sick of arguing with me.
Setting aside the arguments of questionable relevance we’ve made in favor of flying pigs, the varied types of faulty reasoning also constitute fallacies of their own.
Offering premises that give no support to one’s conclusion is called a non sequitur (“It does not follow”). “His dissertation was excellent, since he served doughnuts at the seminar where he presented it.” Doughnuts are good in and of themselves, but they have nothing to do with whether the dissertation was good or poor.
Affirming the consequent is the fallacy that arises from the mistaken belief that “if X, then Y” also means “if Y, then X.” “When it snows, it’s cold outside. It’s cold outside, therefore it must be snowing.”
Finally, though begging the question is often taken to mean “"raising the question” nowadays, it refers to a circular argument in which the conclusion appears as one of the premises. In other words, one assumes at the outset what one is supposed to be proving. “Bob is always right.” Why? “Because Bob says so, and he’s never wrong.”
Knowledge of logical fallacies is a powerful tool for both improving your own reasoning and examining the arguments of others. Many of them seem ridiculous or absurd on their faces, but people actually do formulate and fall for arguments that use them! There are many more named logical fallacies. If this whets your appetite, Wikipedia’s list makes a good jumping-off point, and an introductory text on informal logic makes an even better one.
Conclusion
Testers need to reason with both computers and other people, and logic is at the heart of both. Whether analyzing the flow of a program, making a case for fixing an involved bug, or evaluating next quarter’s development plan, a solid grounding in logic will serve testers well.
QSM
Finally, we come around to a branch of philosophy in this series that most people will immediately associate with software. Logic is what runs computers, right? After all, they are logical machines. However, the software we are testing often seems to behave in a way that is anything but logical. So, what exactly is logic, and how is it relevant to software testers?
What Is Logic?
We bandy the word “logic” around a great deal, but our mental definition of it tends to be a bit amorphous. While we have a good general idea of what logic is, we tend to conflate it with “thinking" and “reason.”
Thinking is, broadly, any mental process. Reason is a kind of thinking—specifically, a mental process of arriving at an answer to a question or of deciding amongst choices. Logic tries to enumerate rules for reasoning—rules that allow us to reason in an orderly manner and help to ensure our conclusions are sound. As such, logic is invaluable for ensuring that we make robust decisions, that we are systematic in our consideration of difficult issues, and that we can perceive the flaws in erroneous arguments before they mislead us.
Formal Logic
Formal logic (also known as “mathematical logic”) is the flavor of logic that comes to mind when we speak about computers. It’s based on “propositions” or “Boolean variables” that can be either true or false. These are combined with logical connectives, such as AND (true when all constituent propositions are true) and OR (true when any constituent proposition is true). This, along with conditionals (IF ... THEN), is the foundation of how computers “make choices” or “reason” at both the hardware and software levels. For example:
IF the user is logged in,
AND the user has the correct permissions,
THEN show the user the configuration page.
IF this exception is uncatchable,
OR we haven't provided a way to handle it,
THEN crash.
Testers make use of formal logic in ways beyond understanding the machines we work with, particularly when it comes to testing strategy. Whether we explicitly say so or not, we often plan our test steps and allocate our time using formal logic: IF performance is slow AND it’s slow in browsers other than Internet Explorer 6, THEN I'll spend more time on performance testing; otherwise, I'll devote more time to inspecting the new UI. In those blessed (albeit infrequent) scenarios where we can enumerate all the possible inputs and outputs of a test scenario, we can use truth tables to make sure we don't miss anything and sometimes tools such as Boolean algebra or Karnaugh maps to separate the inputs that should affect the outcome from the ones that shouldn't.
Informal Logic
As software professionals, half of our job is interfacing with technology and half of it is interfacing with people. While it is laudable to have found an important bug buried deep in a application’s dark recesses, it does no good for the users of the software if you can’t convince management or the development team that it is worthwhile to fix it.
Informal logic (sometimes called "persuasive logic") is how we form arguments and attempt to reason with each other in our everyday lives. As opposed to the mathematical structure of formal logic, it deals with argument and reasoning in natural language. An argument consists of one or more premises, a line of reasoning, and a conclusion reached thereby. Informal logic outlines what constitutes a sound premise and what constitutes valid reasoning so that the conclusions we reach are both justified and defensible.
As one of the core skills involved in bug advocacy, informal logic is invaluable to testers. It lets you argue why something is in fact a bug and why that bug is important enough to fix. In a broader context, informal logic is the tool that lets you advocate for any of the myriad ideas and initiatives that you come up with. It may be clear to you that the test team needs more resources or that one feature should be prioritized over another, but neither course of action is likely to happen unless you can present a convincing argument for it to someone in management.
Logical Fallacies: Learning by Counterexample
While studying the attributes of a sound argument seems like the most straightforward way to get a grasp of informal logic, learning about common logical fallacies is a more accessible route to take. The language used to describe them is colourful (as opposed to the rather dry theory often associated with formal logic), and you can usually come up with instances of their occurring in your life or workplace.
To illustrate, let’s see what specious arguments we can muster to rally support for a statement that is patently false. I’m going to make the claim that pigs can fly. When someone points out that they can’t, I can try to discredit him or her personally: “Do you have a degree in biology? And, didn’t you just tell a lie the other day?” This is called ad hominem (Latin, “to the man”). I’m attacking the person presenting the argument instead of refuting the argument’s substance. Alternatively, I can reply with the following: “Why do you think animals can't fly? Birds fly all the time.” This is a straw man. I’ve misrepresented my opponent’s argument, then attacked that misrepresentation instead of the actual argument.
When it comes to affirming my own dubious position, I have many options:
* Argumentum ad populum (“appeal to the people”)—“Ten thousand people believe that pigs can fly, so surely they can.” This is claiming that something is true because many people think it is.
* Argumentum ad verecundiam (“appeal to authority”)—“Professor Bloggins says pigs can fly.”
* Argumentum ad consequentiam (“appeal to the consequences”)—“A world where pigs can fly would be an awesome place, so I'll believe that they can.”
* Argumentum ad baculum (“appeal to force” or, literally, “appeal to the stick”)—“If you don’t agree that pigs can fly, I’ll punch you in the nose.”
* Argumentum ad nauseam—Finally, ridiculous though my case may be, if I continue pressing it long enough, everyone else will get sick of arguing with me.
Setting aside the arguments of questionable relevance we’ve made in favor of flying pigs, the varied types of faulty reasoning also constitute fallacies of their own.
Offering premises that give no support to one’s conclusion is called a non sequitur (“It does not follow”). “His dissertation was excellent, since he served doughnuts at the seminar where he presented it.” Doughnuts are good in and of themselves, but they have nothing to do with whether the dissertation was good or poor.
Affirming the consequent is the fallacy that arises from the mistaken belief that “if X, then Y” also means “if Y, then X.” “When it snows, it’s cold outside. It’s cold outside, therefore it must be snowing.”
Finally, though begging the question is often taken to mean “"raising the question” nowadays, it refers to a circular argument in which the conclusion appears as one of the premises. In other words, one assumes at the outset what one is supposed to be proving. “Bob is always right.” Why? “Because Bob says so, and he’s never wrong.”
Knowledge of logical fallacies is a powerful tool for both improving your own reasoning and examining the arguments of others. Many of them seem ridiculous or absurd on their faces, but people actually do formulate and fall for arguments that use them! There are many more named logical fallacies. If this whets your appetite, Wikipedia’s list makes a good jumping-off point, and an introductory text on informal logic makes an even better one.
Conclusion
Testers need to reason with both computers and other people, and logic is at the heart of both. Whether analyzing the flow of a program, making a case for fixing an involved bug, or evaluating next quarter’s development plan, a solid grounding in logic will serve testers well.
Tuesday, September 20, 2011
Difference between Functional Requirement and Non- Functional Requirement
The Functional Requirement specifies how the system or application SHOULD DO where in. Non- Functional Requirement it specifies how the system or application SHOULD BE.
Some Functional Requirements are,
Authentication
Business Rules
Historical Data
Legal and Regulatory Requirements
External Interfaces
Some Non-Functional Requirements are,
Performance
Reliability
Security
Recovery
Data Integrity
Usability
Some Functional Requirements are,
Authentication
Business Rules
Historical Data
Legal and Regulatory Requirements
External Interfaces
Some Non-Functional Requirements are,
Performance
Reliability
Security
Recovery
Data Integrity
Usability
Different Types of Severity
1. User Interface Defects - Low
2. Boundary Related Defects - Medium
3. Error Handling Defects - Medium
4. Calculation Defects - High
5. Interpreting Data Defects - High
6. Hardware Failures & Problems - High
7. Compatibility and Intersystem Defects - High
8. Control Flow Defects - High
9. Load Conditions (Memory Leakages under testing) - High
2. Boundary Related Defects - Medium
3. Error Handling Defects - Medium
4. Calculation Defects - High
5. Interpreting Data Defects - High
6. Hardware Failures & Problems - High
7. Compatibility and Intersystem Defects - High
8. Control Flow Defects - High
9. Load Conditions (Memory Leakages under testing) - High
Friday, September 9, 2011
BMR
BMR. Basal Metabolic Rate measures the minimum calories necessary to sustain life in a resting individual. Calories are burned by bodily processes such as respiration, the pumping of blood around the body and maintenance of body temperature. BMR can be responsible for burning up to 70% of a person’s total calories expended.
Thursday, September 8, 2011
Ghrelin
Ghrelin. Ghrelin is a hormone that makes people hungry, slows metabolism and decreases the body's ability to burn fat. Research shows that Ghrelin levels in the blood spike before meals and drop afterward. First identified by researchers in 1999, this hormone continues to be the focus of efforts to further explain eating variations and perhaps correct eating disorders.
Subscribe to:
Posts (Atom)