Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Score: 1 is best Refs: how many distinct relevant places you explicitly cited, including text and class slides ID Score Org Refs Notes strengths 2044156 2440447 2480334 2483770 2484797 2 3 2 4 4 weaknesses ok problems: large team + novel platform + slow information spread + final tasks too large + too little refactoring along the way + wholesale one-person refactoring + no TDD + no retrospectives or iteration planning; successes: project finished, value delivered 4 every iteration, so so problems identified: bus factor + fixed pairs + mixed dev envs + no weekly demos + large tasks + no vision + dropbox for source control + no daily standup + slow client response + single client point of contact; very short "how we fixed 2 things" good long list of issues too much narrative; many problems lumped into one section; analysis not drilled, e.g., 5 whys, nor linked to the literature problems identified: user stories + backlog not updated + empty iteration backlog + missed requirement; successes: jelled team + freq meetings + swarming + 6 good slice size; 5 whys on missed requirement organization by random topic (team, user stories) rather than problem or practice; inadequate fixes for 5 whys (for "we didn't refactor" just "we should refactor;" for "didn't ask questions" just "ask more questions"); misunderstood "technical debt" as monetary; seems to conflate unit testing with user testing; not clear why this project had just one deadline or why that means unit tests less necessary; several references to being just a "class" project; so so none problems: team size + task 1 management so so problems: complicated mvp + learning curve + overdependence on one team member + no team ownership + poor intra-team communication + client communication + poor iteration implementation + poor use of 0 backlogs + solns done and proposed: mailing list, small meetings, more detailed planning, wiki for documentation; one-level causal analysis, overly good links to the literature narrative; specific fixes to each problem;interesting ties to service design; no organization into sections; more narrative of what happened than analysis; no root cause analysis of problems so fixes random and not backed up with arguments; no connection to the literature; good (if rambling) description of client vision issues no causally-based fixes for client issues; reads more like a list of excuses for why the project was hard instead of features of the project that needed to be accomodated; no connections to the literature, not even book references! ID 2488594 2503052 2503324 2508792 Score 2 3 1 4 Org Refs Notes strengths weaknesses ok problems: not all teams had platform working + bus factor + scope creep + no user testing + no unit or integration testing + missed requirement ; solns: value every 5 whys on scope creep; missing week, frequent communication, requirement solution (multiple 3 communicate fears, scenarios) is OK ok more intuitions than analysis; 5 whys analyses not tied to multiple layers of response; little discussion of pros and cons of solutions proposed (many of which are more aspirations than actions); there are better links to literature for technical debt, overzealous refactoring, overachievers, etc; too problems: communication + large simplistic to say a course with team + members missing meetings solns proposed: google docs, students is that different than a + losing steam + little pride in taskboard, several 5 why's analyses real project with distributed project + one person taking over + (though not highlighted as such); links developers, including new hires, on 5 not everyone met client + to literature (not always the best) multiple projects good problems: tech platform issues + no tdd + code breakage before demo + communicating effectively with team as client + maintaining client engagement ; successes: learning from tech issues, using spike to test authentication alternatives early, frequent 3 deployment to target platform, good problems: losing team members + late user scenarios + inadequate testing + no refactoring + poor intra-team communication + poor 1 task management good use of book; very good 5 whys on tech platform issues, with good proportional fixes; good identification of specific bugs tdd might have caught faster; rambled a bit when bringing in prior experience; no layers of fixes for scope creep; limited use of literature little use of literature beyond class materials (book and slides) only book referenced; more narrative than analysis; no analysis of late user scenario problem causes and possible fixes (ultimately, the fault is on both sides); no specific causally-based (e,g., 5 whys)l fixes for testing, refactoring or team communication issues beyond "should do better" ID 2508926 2509574 Score 2 4 Org Refs Notes strengths weaknesses ok causal analysis stopped after 1 or 2 levels; sometimes focused on debating a practice, e.g., swarming, when the point is ) rather than analyzing and fixing an actual team issue; seems to claim that 2 subteams would have a bus factor problem and that the recommended cure for low bus factor is maximum redundancy all the time; didn't use the literature on subteams in large projects; recommended unit testing but didn't address causes of why it problems: large team size + didn't happen (CI only helps run inadequate communication of tests if tests exist); little specifications + scheduling recognized that practices, like daily connection to the much larger meetings + poor prioritization + standup, aren't the point--what they software development literature, inadequate test suite + inequal try to accomplish is what must be just Rasmussen and Brooks experience + technical debt + poor replicated; recognized that "better (briefly) -- Shannon reference is 2 use of pairing leadership" is not easily achieved; analogical at best so so problems: large team in demo project + understanding primary client goal + missed key requirement + platform learning curve + no refactoring + little testing; successes: cross-functional team + use of source control + swarming + jelled team + engaged client + frequent commits and 1 delivery of value problems: using source control effectively + late deployment testing + platform issues + midpoint attendance problems + midpoint intra-team communication + late client breakage + late scope creep; successes: swarming + jelling + high bus factor + inception deck + 6 focused MVP + low technical debt text rambles and is more narrative than structured analysis, e.g., no explicit root cause analyses; fix for honest look at weaknesses in fix to missing requirement (cover every code merge conflicts; good pondering possible scenario) not feasible; no about possible issues in agile project reference to literature beyond closure book 2529566 1 so so 2532239 2 so so interesting discussion on inception deck; very good 5 whys on source control failures, client organization by random topics; communication issues and late scope good analysis buried in long creep; narrative chunks just a few main sections (communication, server); overly problems: communication + bus narrative in sections, e.g., factor + stalling + lack of reflection; good (if rambling) analyses of differences of opinion on successes: email for problems and possible fixes; good use communication, problems with communication + swarming of Cottmeyer reference; good game server; references not easy 2 sessions with rotating members; discussion of agile for class projects; to find at a glance; fine problems: low productivity + novel platform + scheduling meetings + low bus factor + too few devs meeting client + varying skill levels + more skilled take over + eroding morale; solns: regular meeting times, small group swarms, wiki well organized; articulate but one1 docs, level analysis 2542682 3 more narrative than analysis; no 5 whys or layers of fixes; little connection to the literature ID 2549361 2551448 2553978 2557016 2559949 2561638 2584968 2617186 Score 1 1 3 3 1 3 2 3 Org very good Refs Notes strengths problems: source control + large size + organization + client communication + bus factor + technical debt + no refactoring + 4 user value not always created + so so 5 problem-based sections; 5 whys in each good mixing of issues then fixes; problems identified: learning curve connected fixed pairs to being cross+ fixed pairs + large tasks + silos + functional; 5 whys analysis on mixed client vision + slow client integration failure, with possible fixes response + bus factor + vague at each level; good use of Cohn 4 tracking + broken source control reference; so so problems: large team + team ownership + lack of jelling + learning curve + silos + meeting attendance and communication + task tracking + bystander effect; 2 successes: client communication weaknesses some fixes just "don't do that" or "make sure that …" -- those aren't fixes; used "large" bus factor to mean a small one, i.e., 1; "lack of training" is more a cause of problems than a problem; a problem is something bad that happens, like buggy or late code some good fixes considered for the large team size issue; "fixes" for learning curve not really fixes (don't do project not really an option in general, and help each other more doesn't address the causes for why this didn't happen) good 2 5 whys analysis with fixes; problems identified: no client value sectioned by problem; well+ large slices + learning curve + bus articulated concerns about agile for 1 factor beginners in a course 1st fix for first 5 whys (replace "learn X" tasks with "do specific tutorial X") doesn't address lack of client value; seems to say planning poker identifies features to build (it doesn't); seems to conflate "no value" with "didn't work when deployed;" no links to the literature good 5 whys on no early value, with problems: no early value + no reasonable proposed fixes; 5 whys on backlog + poor team meeting issues and reasonable fixes; overly narrative; 5 whys buried in 5 communication + too few meetings very good use of the literature; narrative text; ok 5 whys on scheduling problem gets hung up on just one factor (engagement); only that aspect problems: team meeting fixed; with source control, lack of 5 scheduling + conflicting changes in whys means how the fixes for source control + weak testing + layers of defense not explicit; no poor story writing and 5 whys on scheduling problem starts specific fix for client management + inadequate well; good multi-layer fixes for source communication problem; no communication with client + too control problem; good connections to connection to the literature other 1 much bugs accumulated book than book ok problems: broken code + no tdd + 4 technical debt + so so problems identified: bus factor + 5 whys analysis on big slices; good too experienced a team member + analysis of problems, ok hypotheses 9 untracked velocity on fixes 3 5 whys; 2nd 5 why causals not linear (3rd row didn't cause 2nd); root cause too often "we were still learning;" fixes for 2nd 5 whys mostly "do better;" 2nd and 3rd 5 why fixes about what they did rather than what they changed in process; too focused on just bus factor -even blamed large slices on it; all projects have many problems ID 2646877 2679230 2695649 2696988 Score 2 3 2 1 Org Refs so so Notes strengths problems: github learning curve + client tech platform constraints + ; successes: using branching in github, inception deck, communication with client, swarming, feature-driven development, frequent value 3 delivery ok 5 whys on tech platform conflicts; weaknesses weak problems: demo breakage + done didn't equal tested and deployed + good use of literature; reasonable integration failure + bus factor; question about short iterations 4 successes: 5 whys + iterations leading to shortcuts; sections organized by random topics (github, inception deck) rather than issues; says there was a 5 whys on github issues but none given; 5 whys on tech platform conflicts better but could've been laid out more clearly; more narrative than analysis; claims 5 whys used on demo failure and elsewere but doesn't present any; says large bus factor is bad when it's small that's bad, e.g., 1 ok problems: team turnover + learning curve + bus factor + poor task 5 whys for each problem; specific prioritization + inadequate client process changes for team cohesion 3 interaction + no tdd or ci; problem; 5 whys causes often subjective feelings, not specific actions or conditions; 5 whys for learning curve went to parallel causes than to linear chains; no real specific fixes for learning curve problem; 5 whys for task prioritization lost sight of asking real questions and became a laundry list of random factors; fixes basically just "do better"; no analysis or fixes for tdd problem ok poor fixes for 5 whys -- "changes must be communicated" is a requirement, not an action; "this was the actual reason" isn't a fix at problems: db broken by client + all; fixes should be process bad communication on updates + changes, e.g., "when x is present, risk from little testing at scale + ; do y," not "must" or "should successes: using branches in git haves;" a "all X must be Y" fix is appropriately, deployment hardly ever implementable or documentation was easy (tested on good connections to the literature, sustainable; some literature client though?), cross-functional book and class slides, e.g., Fowler on connections unmotivated by 7 high bus factor, good team trust, db evolution 2 5 whys analysis; project experiences;