INFO3600
Capstone Projects
Week 2
2015
Overview of the semester
• Website tour
– XP and roles
– Assessment – note especially the individual mark
operating as a cap on your final mark
– Tools
• The role of the tutorial
– Tutor to assist the group
– Tutor to provide feedback
– Group to meet and plan and co-ordinate and discuss
progress
• The role of the assessments
– Week 5/6 formative
Priorities for this week
•
•
Every student in a group
Getting in contact with the client
• Decide roles, starting with Week 2 Manager and Tracker
• Decide on regular meeting times outside class
• Decide on group contract
•
•
Each group should nominate a Bitbucket expert (or two) that will be familiar with
this system and how to use it.
Record everything you decide, everything you do, every event on the wiki in a
logical and findable place
• Create your Bitbucket site
– Front page has key information for group to co-ordinate and links to rest
– A personal page for each team member: who will record personal goals for the
coming week, then record reflection on them at the end of the week
– A page for the group contract
– A page for minutes of the meetings in each lab, and in between
– Link every claim to evidence
Group contract
•
Policy on meetings
– time and place (can be electronic) to meet outside class each week
– Agreed policy on dealing with unavailability (eg timetable, known events)
•
Timing for
– main meetings -- at least 2 such blocks of time in addition to Mon 3-6
– adding meeting minutes to wiki
– each team member checking these and indicating agreement or identifying problems (***
needed for later)
– creating new Issues
– Tracker reviewing progress each week
•
About the Issues
– Include all tasks: reading, test design, creating wiki resources, writing code, testing that code…
– Policy for updating these
– Policy for linking them to the individual member’s wiki page
•
Process for reporting difficulties with a team member
– Clearly defined commitments that have not been met
– Opportunity to meet them by a new deadline
– Need for handing task to another person
Leadership and XP Roles
• In Weeks 2, 3 and 4, allocate different people to the two key
leadership roles:
• Manager
– schedules meetings (e.g. IterationPlan, CommitmentSchedule),
– makes sure the meeting process is followed,
– records results of meeting for future reporting as Bitbucket Issues
(during the class is a good time for one bout)
– Does not tell people what to do (Customer and IterationPlan do that),
when to be done (CommitmentSchedule), or check to see how they're
doing (Tracker).
• Tracker
– 2-3 times a week, check the Bitbucket site for each person’s progress
– asks each Programmer how they are doing, listens to the answer, takes
action if things seem to be going off track.
Online tools
• Bitbucket (BB)
– The wiki:
• Place where each individual in the team records plans,
reflections on them
• Place where team keeps key information
– Front page
• This is where we assess your “reports”
– They are organic, growing as your work
– Issues
– Hg repository
• Slack
Fine wikis
Client interaction
• Whole group may meet once early on
• Client interaction role then allocated and that
person meets the client
• The person responsible for this role must
record all discussion on the wiki
• Communicate with client - check client agrees
with your record of key decisions
This lab and week
• Getting started
– Essential group roles
– Getting in contact with the client
– Getting Bitbucket set up, mindful of its role in
enhancing team effectiveness as well as a
repository of all materials
• Grading for Week 5/6 deadlines
• [Next week’s lecture will introduce the
literature review presentation]
About XP - The 12 core practices
http://www.jera.com/techinfo/xpfaq.html
• The Planning Game: Business and development cooperate to produce the
maximum business value as rapidly as possible. The planning game happens at
various scales, but the basic rules are always the same:
– Business comes up with a list of desired features for the system. Each feature is written out as
a User Story, which gives the feature a name, and describes in broad strokes what is required.
User stories are typically written on 4x6 cards.
– Development estimates how much effort each story will take, and how much effort the team
can produce in a given time interval (the iteration).
– Business then decides which stories to implement in what order, as well as when and how
often to produce a production releases of the system.
•
•
•
Small Releases: Start with the smallest useful feature set. Release early and often,
adding a few features each time.
System Metaphor: Each project has an organizing metaphor, which provides an
easy to remember naming convention.
Simple Design: Always use the simplest possible design that gets the job done. The
requirements will change tomorrow, so only do what's needed to meet today's
requirements.
•
Continuous Testing: Before programmers add a feature, they write a test for it. When the suite
runs, the job is done. Tests in XP come in two basic flavors.
–
–
•
•
•
•
•
•
•
Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test
typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit
testing framework, such as JUnit.
Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall
system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of
it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very
least, an acceptance test could consist of a script of user interface actions and expected results that a
human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a
separate acceptance testing framework.
Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with
confidence that you didn't break anything because you have the tests.
Pair Programming: All production code is written by two programmers sitting at one machine.
Essentially, all code is reviewed as it is written.
Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able
to work on any part of the codebase at any time.
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have
to run 100% both before and after integration.
40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime
is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very
wrong with the process.
On-site Customer: Development team has continuous access to a real live customer, that is,
someone who will actually be using the system. For commercial software with lots of customers, a
customer proxy (usually the product manager) is used instead.
Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by
looking at it who on the team has touched a specific piece of code.
XP roles to allocate this week
record on the wiki + explanation
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tracker *
Manager *
Customer (aka client)
Programmer = everyone in group, with some people mainly doing this as their contribution
Coach
Doomsayer
Programmers
Integration Tester
Usability Tester
Presentation
Presentation
Mercurial expert(s)
Bitbucket expert(s)
Extreme Programming expert(s)
Software Researcher (desirable to have > 1)
Existing Systems Researcher (desirable to have > 1)
Priority tasks for this week
Get internal communication for the group organised, making use
of the contract
Allocate roles (with rotating leadership roles for Weeks 3-5)
Identify tasks to do this week
Task: Learn about user stories from resources
Elicit the first user stories from the client