...
NCSU - refer to powerpoint for books to read
resources:
blog.mountaingoatssoftware.com
Books: http://library.mit.edu/item/001270790
http://library.books24x7.com.libproxy.mit.edu/toc.asp?site=bbbga&bookid=8392
notes from Emily's presentation:
Product backlog is supposed to be prioritized. But library staff have a difficult time prioritizing issues against each other. They work best talking generally about what they think should be part of a given iteration. Then we negotiate with them about what we think we can accomplish. The IT product manager plays a large role in determining final priorities here.
Testing – “the weakest link”. For smaller projects w/o massive codebase, when is it faster and better to automate testing? No QA experts, so try to utilize product teams with regular updates throughout the cycle. In the end, developers and IT product managers have to do first pass at QA testing. Have not done a good job defining acceptance tests for each piece of functionality.
Our group is responsible both for real-time support and development. How to handle? Working toward documenting time spent on real-time support emergencies in JIRA and track how much effort spent on that vs. development. This feeds our estimation of how many hours are available for each person for each cycle; assume some time goes to support.
Timeboxing of efforts within a 6-week development cycle helps keep us from getting bogged down in large implementations that go on for months and months and keep team from working on other projects. Instead, focus on the outset on a simplified set of work that can be accomplished in 1 cycle and then re-evaluate institutional priorities at the end of that cycle. This reduces feeling of black box stall on any given project.
Users hate seeing nothing. Using these methods, more people have seen some results faster. Incremental improvements that happen regularly produce much more positive feedback and energy both within the development team and out to our customers in the library.
Adapt to changing priorities. For example, move our EZProxy Administrator tool to the top of the list as needed for Shibboleth integration. We would not have been able to do this without causing problems if we had been already committed to months of development and a huge feature list for ReservesDirect, our course reserves system. Constant re-evaluation also always priorities within a project to change – since we haven’t committed beyond the current cycle this is easy to accommodate.
Greenhopper & JIRA
Google docs & JIRA