Agenda for Second Meeting

-- Determine Team Name

-- Determine Presentation Flow -- materials needed, discussion details, for next day's meeting with Joe -> use proposal as basis

Roberts Rules of Order

I take most of this from http://www.robertsrules.org, since I can't find my book with the rules.

There are several rules, and their intent is to allow decisions to be made in a straightforward manner. The language used in Robert's Rules sounds somewhat Victorian. Maybe I can break it down into more modern English.

Definition of "motion": a formal proposal for action made to a deliberative assembly for discussion (google definitions, princeton website)

We might say, "propositions", or even better, "offers". The other meaning of "motion" could be captured by the word "plan".

The main offers have a certain order of precedence, meaning when one is offered with lower priority than what is currently going on, it gets ignored.

Main Offers (from lowest priority to highest):

- to begin discussing a plan

- to end permanently the current plan

- to reword the current plan

- to let a committee figure out the details of a plan

- to postpone a plan to a certain time

- to limit or extend a debate

- to close a debate

- to lay aside a detail temporarily

- to follow the agenda for the day instead of whatever was going on

- to complain about something going on in the proceedings

- to take a break

- to end a meeting

There are a few other things you can do, as situations arise, like have a plan reconsidered, cancel a previous action, request information, enforce rules, and avoid making a decision about something. Pretty neat way to run meetings.

Agenda for first meeting

Tasks:

- Nominate a product owner

- Make a wiki with product backlog / tasks to do

- Have a script that can log onto facebook and access the Farmville app

- Establish a database and write a script that goes online, verifies the identity of the server, and then sends and receives verification of its certificate in the server database.

- Give "point" values to upcoming tasks on list based on time required

Sprint workshop:

- decide how many points to aim for on this iteration

- discuss in detail (user stories) all items to be accomplished this iteration

- estimate time to be taken by each sub-task and figure out how much time each team member will devote to getting this sprint done. Include "stretch" tasks for being done early.

- establish where we'll work and have a TODO list, "test cases in progress" list, "code in progress" list, "ready to be verified" list, and a "done" list

- establish a time for every day to briefly all check in together and report on progress since yesterday. Have scrum leader update "burndown" chart to indicate hours needed left to complete sprint.

Remember:

- team members should try to work on the same code together, and when your tasks are finished early, work on someone else's or a sprint task.

- review every sprint at the end, the burndown chart, the team velocity, discussing what went well, what could be done better, and what will be done differently next time. Continue process through every iteration.

First meeting with team

We are all free on Tuesdays and Thursdays, 4 of us at 11, 4 of us at 12:30, and all of us after 1:15. We will meet in the Farris building tomorrow and arrange our scrum stuff. I will be gathering details I need for an effective meeting...

Pharmville specs

• This is based on the Volere Requirements Specification Template.

Also, remembering the five points to a SMART goal: Specific, Measurable, Attainable, Realistic, Timely / Timed.

1. The Purpose of the Project

-- Service Goal

• Allow customers to gain experience, prestige, and credits inside Zynga games in an automated manner. This goal is actually a set of goals to be attained, and can later be transformed into a set of goals to make the service faster or more reliable over a set period of time.

-- Revenue Goal

• Starting small, we expect revenue to be in the 10s of dollars by the end of the semester. Further goals will not be stated here.

-- Legal Goal

• Have the product and company comply with all state and federal laws, avoiding torts and copyright infringements.

-- Security Goal

• The product shall employ online verification mechanisms to avoid being hacked and distributed without permission.

-- Learning Goal

• Production team shall learn how to employ agile techniques in the product development cycle, how to advertise on Facebook, how to program in Python, and how to use some of the Facebook APIs for python.

2. The Stakeholders

-- the client: Joe Kniss

-- the customer: millions of Facebook users

-- other stakeholders: team members who will be graded on our performance

-- hands-on users of the product: same as the customer

3. Mandated Constraints

-- Solution constraints

• Follow the direction of the teacher
• Be legal
• Use python, php, SQL, and developer APIs

-- Anticipated workplace environment

• We expect school, as well as team members' houses. Maybe even the institute.

-- Schedule constraints

• Other classes
• 10 weeks

-- Budget constraints

• No money

4. Naming Conventions and Definitions

-- Not currently applicable

5. Relevant Facts and Assumptions

-- Not currently applicable

6. The Scope of the Work

-- The Current Situation

• Not started yet

-- The Context of the Work

• Not currently important

-- Work Partitioning

• TBD

7. Business Data Model and Data Dictionary

-- Not sure

8. Scope of the Product

-- Product Boundary

• Users are to play with the product, but not reverse engineer or otherwise misuse it

-- Product Use Case Table

• TBD

9. Functional and Data Requirements

-- Functional Requirements

• Should be broken down into atomic parts, and kept track of by the product owner
• The product shall maintain a history of what it's done for the user
• The product shall check in with a server every 15 minutes for verification
• The product shall allow user to set different behavior modes

-- Data Requirements

• There shall be a user database, that includes payment receipts and history

10. Look and Feel Requirements

-- The product shall be user tested for quality

11. Usability and Humanity Requirements

-- Ease of use

• The product shall be user tested by a wide demographic

-- Personalization and Internationalization Requirements

• We'll cross that bridge when we come to it

-- Learning Requirements

• The product shall be easy to use

-- Understandability and Politeness Requirements

• The product shall be tested for sensitivity to audience's sense of appropriateness

12. Performance Requirements

-- Product shall be fast on an ordinary computer

-- Product shall be safe to use and void of dangerous bugs

-- Product shall be robust and updated to reflect changes in Zynga games

... and the list continues. See http://www.volere.co.uk/template.htm

My vote

all five to JH

Imperfect Voting

There are a couple things that are interesting to consider. First, there is Pareto efficiency. That is to say, can we be assured that the final selection is done such that there are no changes that could be made in terms of players in teams or project selected for implementing such that it improves at least one person's situation while not diminishing anyone else's?

Then there is Arrow's impossibility theorem. It states that we cannot have a fair ranking system and at the same time have everyone's preferences considered equally, with Pareto efficiency, and such that adding a new proposal to the group won't change the over all results besides giving the new proposal a chance to win.

These suggest a couple different voting systems. First, people can vote in some manner and have the bottom scorers removed from the pool, and then have the voting continue again. It could be made in one pass if everyone's preferences were ranked, and when options were removed, all the options below them would be augmented and the votes re-totaled, continuing until we hit the top five.

Second, we could have people vote and result in a top 10 or so projects. After that, the people who gave the proposals would be the only ones with a vote, and they pick the top 5 projects. I think that system would lead to some interesting results and some good debate.

For the basic voting schema, I still think people should give all proposals a ranking between 1 and 5, and then add all the scores together. Also, these rankings should be prefigured and no one should know the overall results until all the votes had been decided. The top 10 or so results from there can have the people who made the proposals decide which they want to do.

If the top proposal people decide to team up and choose, say, only 3 proposals, the rest of the class should be able to re-vote, and form groups to tackle whichever proposal wins.