Skip to end of metadata
Go to start of metadata

20100826 Construction Planning

Construction discussion
Logistic issue

Invited
Alan Chave
Matthew Arrott
Bill Pritchett 
Michael Meisinger
John Graybeal
Jack Kleinert
Kelly Tucker
Mark James
Ilya Zaslavsky
David Stuebe
Steve Pasco

Discussion of Dropped/May Impact from http://etherpad.ooici.org/20100826-20CI-Sr-Dev-mtg 

Action Items
MA and KT put list of tasks on Google docs - due by Friday
Rest of team review task and apply assessment - due by Monday
Assessment of the use cases and services completed by MM and JG by noon tomorrow (11:30 - 12) 
Link to Google Doc: https://docs.google.com/leaf?id=0AttCeOvLP6XMdEJaeE5oT0tmZkVQY2I0eUhtUFdtdlE&sort=name&layout=list&pid=0B9tCeOvLP6XMYmFlYTc4OTctYjA2Yi00MTJmLTkzMDYtN2U2NTA4ZmIxMzJh&cindex=9

MA-assessment, 1st level weed out, from the task list:
Alan, Michael, John G, Matthew, Developer and or expert from the sub-system.  Many of the task may not be needed in construction.
May not be able to use the names from Elaboration, it is a 1 to many relationship.  
I hope there are a lot we can weed out.   How do you prioritize what can be weeded out.  Develop the principles and criteria before individuals can review the "drop may impact" list from elaboration.  JG approach is a judgment call.  MM-from the list of task, it is realistic to continue them.  If 50% are irrelevant and 10-15% we will see the recommendations for deletions.  If we have the principle base it will make reviewing the task more accurate.  The principles should be used to guide us forward.  We should not develop this process from reviewing Elaboration, but to look at the construction phase and R1, and from the foundation review the risk items, and what we need to accomplish.  Some of these things that were left out of elaboration, take them into consideration.  The items we closed, look at the risk registry to see if we satisfied it, or if it's still open.  BP agrees that we know what we need to do for construction 1,2,3.  There may be some over lap.  Analyze what we can achieve, what is the use case.  Building up to the use case and working backwards.  We have to deliver a sustainable system and then build the principle from there.  SP - what can we achieve, and keep performance texting in mind.  Usability presentation.  We are in the planning phase, MA proposal is identifying what do we want to do 1st, use cases, that will take some time as a group.  Goals and objective set for R1, building the minds eye, it has a time period with it. Not go for what is trivial, and then the other personal assessment, architect Dev mgr and Sr, dev rank High med low of priority.  In the columns for the use cases and services add a column "trivial" not needed against task list Prioritization in use cases.
Release tasks ,may be missing something.  Re-Phrase:  parallel effort that uses JG model take tasks as defined, "re-open with impact"  rank just not worth it, can be independently.  Give Matthew the list put on Google doc, (MA & KT) and each can look their list.  A lot of task were stated with high ambition.  primary value of high rank weighing the tool, ranking the most important.  IIya, devil is in the semantics between design and construction.  When we feel there is enough # of tasks that can be moved over to construction.

Evaluate task to priority
Level of effort - some metric, trivial, non-trivial, Major (feel of the size of the task)
How much am I willing to invest - point method get some understanding of how you weight these.  The way MA would like to start the principle discussion is to look at the risk assessment.  JG 2 things 1-development  of principles (risk assessment) and looking at use case and prioritization. 2 asking the Sr. Dev (task thing) very specific MM, JG and Sr. Developer sweep over the tasks and their sub-system.  Apply the model of democracy and create a shared view.
Task stuff can occur once the list is assemble on an individual level - before you leave tomorrow.  MA&KT review information on Monday (working bottom up).   

Can we go ahead and execute the work on the task and move forward to developing the principles and strategy?  Construction what we can do and what we need to do.  take existing construction plan and the list of re-open and dropped task in one list of implementation effort, set of criteria order 3 will be used to assess each of the task across the entire list by JG and MM and Sr. Dev. Anyone that wants to participate can.  MA interest in hearing what the people who know the task feel.  UX is an official sub-system and will have it's own WBS and set of requirements. 

Iteration of criteria for the tasks:     all tasks in construction plan with drop may impact and re-opened tasks.
    1) priority - the lowest level is not needed.  (High, med, low) Keep needed this is from a personal perspective.  
    2) Understanding the assessment of level of effort.  in the space of complexity Trivial, moderate and complex
    3) Maturity of the description Where do you want to put your resources.  where you put value in the system You get $10. Put the $$ where you feel it needs to be "most important" - instinctual
    
Maturity of the task.  JG agrees with 1&2.  We are going to use this task list to combine and review.  It will give us focus as to where we need to put our resources. Lets see if it is useful 
Suggestions for additional criteria?  Holding the door open when going into construction can be bad.     
    
Principles for construction  
Risk assessment
Work of this team, people in this room.  Do we have competencies to complete the task?  
3 levels completing,skill mix, do we have the resources "capacity issues" capability can be leveled locally.  Do we have the capability to accomplish this task? Skill assessment of the team, then the capacity.  Bottle neck issue...
JK-Applicability - features that will be delivered as part of R1 is this task applicable (use cases are the features) services to the principles that we have advertised.  There are no more use cases than the 35 for E1.  There are combination and variations of the 35.  The program is fixed to the 35.  
Michael recommended
Strategic - Value to release 2

Take all tasks in the construction plan and combine with dropped may impact and reopened:
Judge by 3 criteria:
- priority: high, medium, low
- level of complexity: trivial, moderate, extreme
- maturity of the description

candidates for later:
- split 100 points over all tasks and apply for value
- type: design, develop, integration, test

Use cases and services: to be vetted in this meeting
- capability (this is an independent dimension) rank 1-5
- capacity    overall assessment that comes later 
- value to R1 users rank 1-5 (5=highest)
- value to R1 infrastructure 1-5
- value to R2/future 1-5
- Cost (complex long term - short term ) to complete (effort to complete) - days remaining, maturity
- Technology Risk   with completing, having such a criteria in the solution

4 criteria
Benefit value 1 to 10 (Strategic) - overlaps with value for users/infrastructure/R2+
Penalty value - 
Cost 
Risk - Technology
Capability effort  (level of effort)

Delivery
Highest target level user
Level maturity

Michael created a doc for the user caseshttps://docs.google.com/leaf?id=0AttCeOvLP6XMdEJaeE5oT0tmZkVQY2I0eUhtUFdtdlE&sort=name&layout=list&pid=0B9tCeOvLP6XMYmFlYTc4OTctYjA2Yi00MTJmLTkzMDYtN2U2NTA4ZmIxMzJh&cindex=9

Next Subject.....
1-logistics approach to deal with design period next week list of IT's by Thursday  and results of De-scoping 
    good list of IT's we need a completed construction plan
2-start assessment of the use cases and the services by reviewing the aggregate numbers based on what was done prior to LCA
    Do we agree as a group.
    
Are there some use cases that we have complete all the tasks associated with them.  No, in the UI alone we have not completed.
MA working from that understanding that there is no single component ready to go into production.  MM agrees.  The exptectation was that would not be complete.  When we reach LCO no code to take forward, it was for the sole purpose of inquiry.  LCA - 50% of code will advance to construction, but still a lot of the code will advance to construction.
In the worse case you are starting from the Kernel of the components.  They still need to be filled out and developed.  

Brief, covering today list of IT by designers, Sr. Dev can participate (SE-15). 
    How we can move the process forward using the designers.  It would help John G get a feel if we should include the designers.
        Michael, can you see a path designer focused to including the designers in the list of IT's development process?  3 differnt diamentions Reality check, assesment of size and scope, need to fill out the descriptions, priority of what we want to do.  
        
        
******************

Is there a known process for achieving the desired outcome for the tasks, to get them to ListIT status
Michael AI->(Michael): make a list of the 4 or so basic steps we'd normally like to happen to produce the ListITs. 
We will use that list as starting point for our starting point for a discussion tomorrow.
Note from Ilya: Good to have a get-together for designers once every 6 months or so, to make sure they are on same page https://spreadsheets.google.com/ccc?key=0AttCeOvLP6XMdHl6T3ZLUjFqY1ZvU28yN051TmFaMVE&hl=en#gid=2

Definitions:

RISK
Low = will be there
Medium = May be there
High = Likely won't be there

MATURITY: If delivered will be
Planned = as intended
Required = Sufficient and necessary
Descoped = Less than deemed sufficient

USER
User = Appears in UX
Operator = Engineering UI
Developer = API Published
Test = Programmatic Access

Notes from review of the Use Cases:
Need to reword UC 5 - Synchronize State Data -- to reflect the original intent, that this represents synchronization of different stores in different parts of the system

3 things, just 4 things, tomorrow:

1) How we will do ListITs
2) Vet the groupings of Use Cases and Services  
   AI->(Graybeal) 
3) Review list of Use Cases evaluations
4) As a group, where do we want to place our bets?

Principles? Might decide by classes of use cases, e.g., favor COI infrastructure over user interface.  Really not principles, but key decisions.

We don't have an engineering decision log. Can achieve this through our process of Etherpad notes and transfer to Confluence (the latter should support browseable results)

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.