• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

assessment guidance (Word document)

  • 282 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
282
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Team Agile Methods Assessment Notes This document considers assessment issues identified from interviews and questionnaires given to users of agile systems, both student and staff. Thanks are due to the 2005 and 2006 students of the School of Computing, University of Dundee, and to Alex Gibson (industry agile user), Jon Bowyer (industry agile user and project technical developer), Stephen Mudie (project technical developer), Craig Ramsay (lecturer in object-oriented analysis and design), Glenn Rowe (lecturer in GUI programming), Janet Hughes (project manager and lecturer in software engineering). The structure of this document takes the form of four key topics shown in bold followed by the issues relating to these, in bullet point form. Discussion topics The topics are: 1. team constitution a. groups or pairs? b. what size should a group be? c. should pairs be rotated? d. should teams be self-selecting? 2. project topic a. new topic or follow-on from previous work b. GUI or not? c. Large or small? 3. project duration a. 10 calendar days b. 15 work days c. 1 semester 4. project materials a. should a partially complete design be provided at the start? b. should skeleton code be provided? c. should user stories be changed during the project? 1 Funding: Microsoft & HEA-ICS
  • 2. Team Agile Methods 1. Team Constitution a. Should students work in groups or in pairs? groups pairs • Often taking an agile process means • Student feedback indicates that pair membership rotates, so there are enough team projects marking a pair would be impossible already. • A pair only exists while developing • Each pair works on a different code and unit tests, therefore section of code with different scope marking a pair focuses on marking for tests so it would be difficult to CI and TDD more than the agile judge different pairs fairly when process as a whole they are required to do different tasks • If marking a team as a whole, • Pairs would not only be marked on poorly performing individual the code and tests that they produce members are more likely to be but also on a blog that keeps track penalized by other team members of their interaction with the team • Marking groups results in reduced • A true understanding of a student’s marking effort compared to experience is harder to gain should marking pairs the group be marked over the pair • Agile philosophy is team based • Easier to set up Team Server reports rather than pair based - teams are to show group tests/build results judged at the end of a project, not rather than specific pairs (current pairs setup described in this project) • Large teams give pairs a reason to be continuously integrating their code, to ensure different pairs’ code works together. Pairs gain experience of using CI and learn why to use CI 2 Funding: Microsoft & HEA-ICS
  • 3. Team Agile Methods 1. Team Constitution b. what size should a group be? • Minimum number should be four (experienced user) • Best number is five, to encourage rotation (experienced user) • Three pairs (student user; experienced user) • Unlikely that a class will split evenly into groups of six (lecturer) • More than two (student feedback) • More than two (experienced user: “agile works badly with only two members”) • Larger teams will produce more overall which can cause greater satisfaction (technical developer) • Larger groups reduces the number of TFS team projects and the components along with them, which reduces the setup effort (technical developer) • Team member permissions are more easily controlled with smaller teams (technical developer) 3 Funding: Microsoft & HEA-ICS
  • 4. Team Agile Methods 1. Team Constitution c. should pairs be rotated during the project? Rotate pairs Do NOT rotate pairs • Rotating pairs is an agile practice • Poses a problem if marking pairs that is used to give developers an overall idea of how a program works • Helps to avoid people getting • Unsuitable for student projects of “bogged down” on sections of work short duration • It would be necessary for an odd numbered team 4 Funding: Microsoft & HEA-ICS
  • 5. Team Agile Methods 1. Team Constitution d. should teams be self-selecting? Self-selecting Selected • Teams may select according to • “fair” selection can be used to friendship rather than ability level match ability levels • • “fair” selection can be used to provide spread of ability levels and skills • 5 Funding: Microsoft & HEA-ICS
  • 6. Team Agile Methods 2. Project topic New topic Follow-on from previous Follow-on from design topic previous year • Students will not have a • Students have good • Lab tutors have pre-conceived design or background knowledge experience of model that influences the of the topic so no time creating solution agile approach to design wasted becoming with agile practices familiar with the topic • students energised by • Student satisfaction from fresh start and “clean opportunity to slate” implement a system already designed, ie deliver product • Minimise risk of plagiarism GUI (game) topic No GUI • game topic has good test scope for the • GUI testing is not a key feature of functional code behind it test-driven design • game topic provides the need for pairs • students do not have the time to learn to use mock objects how to write GUI tests Large project Small project • students motivated by challenge of • most large programs would be real-scale project expected to be GUI-based • genuine need for continuous • integration 6 Funding: Microsoft & HEA-ICS
  • 7. Team Agile Methods 3. Project duration 20 hours (10 days) 30 hours (15 work days) 1 semester • Students will have • Students can • The greater amount of other studies to give experience additional time spent on a project, attention to as well as agile processes, such as the more that is created the daily requirement customer interaction, and the greater the for agile project time: project estimation satisfaction at the end short project (units of work and of the time period. minimises tension velocity) and the use of between competing iterations. demands. • Students will focus • Students may postpone • A project can become a strongly on a short the start of the work to chore if it drags over a assignment. the latest possible time, long time period. negating the benefit of a longer time period. • Intensive demands of • A medium time scale • The impact of any the server and provides time to technical difficulty is maintenance is for a consolidate less than in a short short time. understanding of agile time-scale project. practices. • All student work must • It gives students a be lab-based to access similar experience to the server, which can their fourth year team be impractical for part- project time or working students. 7 Funding: Microsoft & HEA-ICS
  • 8. Team Agile Methods 4. Project materials a. Should students be given a partial design (UML) for the project at the start of the assignment? No UML design provided Provide UML design • This would be an un-agile thing to • A design could focus attention on do: normally there is no real up- functionality rather than GUI issues front design, only high level ideas. • If the project topic follows on from • If the project topic follows on from earlier work, the students already earlier work, those students that did have knowledge of a possible not do well at that stage will be able design. to start with the same understanding of the design as those who did do well, ie there is no second penalty. • Some of the roles a developer • A standard UML diagram would normally takes are removed if a make marking easier, given the design is provided. similarity of projects’ structures. • It is less motivating to work from • Having to work with designs someone else’s design than from created by others is a useful real-life your own creation. learning experience. • Any design provided could be treated as a suggestion to start from; students may ignore the design if they prefer not to use it. • A design could be created that gives students good scope to experience refactoring. 8 Funding: Microsoft & HEA-ICS
  • 9. Team Agile Methods 4. Project materials b. Should students be provided with skeleton code? Provide no code Provide some skeleton code • This would be an un-agile thing to • Students will appreciate the benefit do. of tests that support the code development. • If using skeleton code there is a • GUI code could be provided to need to allow students time to allow developers to concentrate on understand the code. other functionality. • Provided code may reduce • Having to work with code created developers’ satisfaction as they by others is a useful real-life have not been involved from start to learning experience. finish. 9 Funding: Microsoft & HEA-ICS
  • 10. Team Agile Methods 4. Project materials c. Should the user stories be changed during the project? User stories evolve User stories remain unchanged • Agile practices provide flexibility to • Changes will increase the student adapt to change, therefore changes workload (tests and functional to user stories should apply well to code). agile. • Having to cope with changes • Students will dislike changes being imposed by others is a useful real- made during the project. life learning experience. • If students are working in pairs, and each pair is developing its own user story, then care is needed that all changes give similar challenge - otherwise a change to one user story may require more effort to implement or have better test scope than a change to another user story. • Changes may mean the GUI needs to be modified. 10 Funding: Microsoft & HEA-ICS