Скачать презентацию Feature Injection Chris Matts Agile 2008 Knowledge Скачать презентацию Feature Injection Chris Matts Agile 2008 Knowledge

25930bbef3a2a1b4d67ad2b2e36e3b96.ppt

  • Количество слайдов: 40

Feature Injection Chris Matts Agile 2008 Feature Injection Chris Matts Agile 2008

Knowledge Transfer Knowledge Transfer

Know that you Know When you know that you know some information, you understand Know that you Know When you know that you know some information, you understand the information and realize its relevance and importance to the problem you are trying to solve. When you are in this state, you are able to plan your further actions for attacking the problem and transfer that knowledge to the rest of the team. Let’s say you are working on an application to automate the decision making process for a mortgage. Anyone who has ever borrowed money to purchase a house knows that the borrowers are asked to provide information about their income so that the lender can determine their capacity to pay back the loan. You understand the importance of information such as the borrower’s employment income, whether that income is from salary, hourly wage, or commission, the borrower’s employer, and the length of their employment. Know That you Don’t Know There are several cases during the early stages of a project where you are aware of specific pieces of information about the problem space that are extremely relevant and important to know, but that you have not had the opportunity to learn or experienced yet. The way you manage your knowledge, or lack thereof, in this state is through risk management. You can move to the Know that you Know state by finding the answer, or issue resolution. Considering the mortgage lending example again, you know that there are rules surrounding how income is treated in the loan decision process, but you do not know what those rules are. In order to get to the point where you are able to transfer that knowledge to the other team members who have to translate those rules, you have to find the answer to the question “what are the rules for dealing with income? ” Don’t Know that you Don’t Know All problems have a certain amount of information that the people trying to solve those problems do not know and do not know the information exists (ie realize that there is information that is relevant to their problem domain). The key here is for teams to realize there are things that they do not know and manage for that uncertainty. They can also attempt to move out of that space through a process we call structured learning. In this approach you aren’t answering questions, rather you are trying to ask the right questions before the project team stumbles on the question in a more costly manner. Giving an example for this particular state is challenging, because the minute you acknowledge the existence and relevance of a certain piece of information, you are already in the Know that you Don’t Know state, but let’s suspend disbelief for a second. In a mortgage lending decision project, there can be credit policy rules established by the credit risk department which are critical for a proper decision but are not widely communicated. Until you actually find out about the existence of these rules, let alone their relevance to the application, you will not be able to do anything about them, nor would you be inclined to. You have to actively seek out this information before it becomes apparent in a bad decision after it is too late. You need to ask the right questions. Don’t Know that you Know Initially this state sounds a little like amnesia (which would actually be don’t know that you knew something or somebody. ) Remember that we defined Awareness as the realization that information exists and that it is relevant and important to the project at hand. The key in this situation is that the information is relevant and important. This is the state that you find yourself in when you are an absolute storehouse of what initially seems like useless information, but never connect the importance of that information to the project on which you are working. The key here is for teams to determine if they have gaps in their knowledge and then determine the relevance of information they do have in order to fill those gaps. Taking another look at our mortgage lending example, we know the general difference between a salary and a bonus is that the salary is a consistent amount that you earn every two weeks or month, while a bonus is something that is not necessarily guaranteed and is received on a very irregular schedule. You probably didn’t however realize the relevance of that particular piece of information to mortgage lending until you connect the fact that you are using past earning experience to determine future earning potential and the ability for a borrower to pay back their loan. Its common knowledge that you wouldn’t initially apply to your project until you determined its relevance.

An Average Project Member An Average Project Member

The Dream The Dream

The Reality The Reality

The Fear The Fear

The Truth The Truth

Know that you Know When you know that you know some information, you understand Know that you Know When you know that you know some information, you understand the information and realize its relevance and importance to the problem you are trying to solve. When you are in this state, you are able to plan your further actions for attacking the problem and transfer that knowledge to the rest of the team. Let’s say you are working on an application to automate the decision making process for a mortgage. Anyone who has ever borrowed money to purchase a house knows that the borrowers are asked to provide information about their income so that the lender can determine their capacity to pay back the loan. You understand the importance of information such as the borrower’s employment income, whether that income is from salary, hourly wage, or commission, the borrower’s employer, and the length of their employment. Know That you Don’t Know There are several cases during the early stages of a project where you are aware of specific pieces of information about the problem space that are extremely relevant and important to know, but that you have not had the opportunity to learn or experienced yet. The way you manage your knowledge, or lack thereof, in this state is through risk management. You can move to the Know that you Know state by finding the answer, or issue resolution. Considering the mortgage lending example again, you know that there are rules surrounding how income is treated in the loan decision process, but you do not know what those rules are. In order to get to the point where you are able to transfer that knowledge to the other team members who have to translate those rules, you have to find the answer to the question “what are the rules for dealing with income? ” Don’t Know that you Don’t Know All problems have a certain amount of information that the people trying to solve those problems do not know and do not know the information exists (ie realize that there is information that is relevant to their problem domain). The key here is for teams to realize there are things that they do not know and manage for that uncertainty. They can also attempt to move out of that space through a process we call structured learning. In this approach you aren’t answering questions, rather you are trying to ask the right questions before the project team stumbles on the question in a more costly manner. Giving an example for this particular state is challenging, because the minute you acknowledge the existence and relevance of a certain piece of information, you are already in the Know that you Don’t Know state, but let’s suspend disbelief for a second. In a mortgage lending decision project, there can be credit policy rules established by the credit risk department which are critical for a proper decision but are not widely communicated. Until you actually find out about the existence of these rules, let alone their relevance to the application, you will not be able to do anything about them, nor would you be inclined to. You have to actively seek out this information before it becomes apparent in a bad decision after it is too late. You need to ask the right questions. Don’t Know that you Know Initially this state sounds a little like amnesia (which would actually be don’t know that you knew something or somebody. ) Remember that we defined Awareness as the realization that information exists and that it is relevant and important to the project at hand. The key in this situation is that the information is relevant and important. This is the state that you find yourself in when you are an absolute storehouse of what initially seems like useless information, but never connect the importance of that information to the project on which you are working. The key here is for teams to determine if they have gaps in their knowledge and then determine the relevance of information they do have in order to fill those gaps. Taking another look at our mortgage lending example, we know the general difference between a salary and a bonus is that the salary is a consistent amount that you earn every two weeks or month, while a bonus is something that is not necessarily guaranteed and is received on a very irregular schedule. You probably didn’t however realize the relevance of that particular piece of information to mortgage lending until you connect the fact that you are using past earning experience to determine future earning potential and the ability for a borrower to pay back their loan. Its common knowledge that you wouldn’t initially apply to your project until you determined its relevance. STOP DOCUMENTING REQUIREMENTS

Help Others Learn Help Others Learn

Issue Resolution Issue Resolution

Traditional Issue Resolution Traditional Issue Resolution

“Real Option” Issue Resolution “So how do we stop this thing? ” “Real Option” Issue Resolution “So how do we stop this thing? ”

Structured Learning Structured Learning

The Questions are out there! The Questions are out there!

If Only we had the tools to find them If Only we had the tools to find them

Development Analysis Test Plan A Familiar Process? Development Analysis Test Plan A Familiar Process?

I(d) Development I(a) I(t) Analysis Test Plan I(tp) Look at the Information flows I(d) Development I(a) I(t) Analysis Test Plan I(tp) Look at the Information flows

I(d) I(a) Development I(t) Analysis Test Plan I(tp) Oops I(d) I(a) Development I(t) Analysis Test Plan I(tp) Oops

I(a) Analysis I(d) I(t) Development Test Plan I(tp) The Same Process…. . But in I(a) Analysis I(d) I(t) Development Test Plan I(tp) The Same Process…. . But in a different order.

Feature Injection Feature Injection

As we pull value from a system, we inject features. As we pull value from a system, we inject features.

WHY? WHY?

WHY? WHY?

WHY? WHY?

Business Value Business Value

Where is the value? Where is the value?

Input? Output? Input? Output?

Input? Output? Input? Output?

DEVELOPMENT VALUE INPUTS PROCESS OUTPUTS INPUTS DEVELOPMENT VALUE INPUTS PROCESS OUTPUTS INPUTS

ANALYSIS VALUE INPUTS PROCESS OUTPUTS INPUTS ANALYSIS VALUE INPUTS PROCESS OUTPUTS INPUTS

DEVELOPMENT Spot Example Reflect Model Test DEVELOPMENT Spot Example Reflect Model Test

DEVELOPMENT ACTUALLY Spot Example Reflect Model Test DEVELOPMENT ACTUALLY Spot Example Reflect Model Test

ANALYSIS Spot Example Reflect Model Test ANALYSIS Spot Example Reflect Model Test

Exercise – Payroll Costs per Department • Tim works for IT • Karen works Exercise – Payroll Costs per Department • Tim works for IT • Karen works for IT • Anne works for IT • Neil transferred from Operations in February • Stephane works for IT • Melanie was on maternity leave last year. • Billy Bob works part time for Middle Office and Operations • Tim is in Cost Centre 96457. • Lynn left in 2003 and came back last year.

I(a) Analysis I(d) I(t) Development Test Plan Familiar? I(tp) I(a) Analysis I(d) I(t) Development Test Plan Familiar? I(tp)

I(a) I(d) Development Spot Example Reflect I(t) Test Model Test I(tp) The Missing Link! I(a) I(d) Development Spot Example Reflect I(t) Test Model Test I(tp) The Missing Link!

Feature Injection Business Analysis feeding Examples into a BDD/TDD Process Feature Injection Business Analysis feeding Examples into a BDD/TDD Process

Thank you to all the Flickr contributors who made this slide show possible. Abacus Thank you to all the Flickr contributors who made this slide show possible. Abacus : http: //www. flickr. com/photos/amyadoyzie/491995798/ , Leaf : http: //www. flickr. com/photos/bassqee/1462406627/ Money 1 : http: //www. flickr. com/photos/kussler/86541739/ , Money 2 : http: //www. flickr. com/photos/[email protected] 08/2244971220/ Money 3 : http: //www. flickr. com/photos/raisinsawdust/2703698410/ , Money : http: //www. flickr. com/photos/[email protected] 08/2479674264/ Business Value : http: //www. flickr. com/photos/woolyman/2473999495/ , Oil Refinery : http: //www. flickr. com/photos/okenezak/317648353/ Oil Storage Tank : http: //www. flickr. com/photos/pablozom/452912744/ , Camera Man : http: //www. flickr. com/photos/ipjmike/133384453/ Eating Food : http: //www. flickr. com/photos/kim_fritts/2608334316/ , Harvesting Wheat : http: //www. flickr. com/photos/silverwood/1053050408/ Growing Wheat : http: //www. flickr. com/photos/visbeek/2421075393/ , Waterfall : http: //www. flickr. com/photos/dirgon/446839052/ Sunset : http: //www. flickr. com/photos/[email protected] 03/2368655746/ , Odd one out : http: //www. flickr. com/photos/lisanorwood/1046416640/ Model : http: //www. flickr. com/photos/[email protected] 00/322977386/ , Eye test : http: //www. flickr. com/photos/indigo 2 brown/1401441754/ Audience : http: //www. flickr. com/photos/centerforasianamericanmedia/2451489234/ , Sowing Seeds : http: //www. flickr. com/photos/goddette/2403752038/