|
|
An Agile Approach to Defect Management In each round of the party game Limbo, you set the bar lower and lower. Players must dance under the bar with only their feet touching the floor. When it comes to bugs, we also want to set the bar lower and lower as the project progresses–fewer bugs is always better. Lisa Crispin explains how agile teams address defects, and how you can apply an agile approach even in a "traditional" environment. Explore different approaches to deal with defects–from "fix and forget" to employing a traditional defect tracking approach. Lisa describes insights we can gain from defects, such as the missing features they might represent and development improvements they suggest. Learn new ways to "lower the bar" on bugs in your projects and take away novel ideas for taming your backlog of defects. Discover ways your team can work together to minimize or eliminate bug reports altogether.
|
Lisa Crispin, ePlan Services, Inc.
|
|
|
The Agile Build Pipeline: A Tester's Lessons Learned When Insurance Australia Group wanted to launch a new online car insurance service, complex technical issues called for early integration and strong testing capabilities. The project was distributed across multiple partners, each working on different horizontal components and employing different development approaches. In this environment, it was critical to continuously integrate the software and test-test-test. Kristan Vingrys shares his experience establishing a build pipeline that started with pre-commit tests and ended in the pre-production environment. The agile build pipeline often enabled changes to go into production the same day the code was written and with high confidence that the new build would not cause any regressions. Significantly, this build pipeline approach supported going live only two weeks after the last feature was completed in a six-month development effort.
|
Kristan Vingrys, Thoughtworks
|
|
|
Agile Development Practices East 2010: Resistance as a Resource As a developer or tester, you are a creative, intelligent, and insightful member of your team. Whether you know it or not, you also are a change agent. When you have an apparently good idea about how to improve, you may sometimes hear "We tried that before, and it didn't work" or "We've never done it that way here" or "No real user would ever do something like that!" What you're meeting is resistance. So, what do you do? Dale Emery explores an approach to resolve resistance and help you and your organization move to a higher plane as a learning organization. Whatever else it may be, resistance is information-about others' values and beliefs, about the organization, about the change you are proposing, and about you as a change agent. Find out how to turn resistance from a frustration into a resource that translates into actions to improve yourself, your organization, and its products.
|
Dale Emery, DHE
|
|
|
Critical Success Factors for Acceptance Test-Driven Development (ATDD) A good analyst or tester knows what questions to ask to quickly bring clarity to a murky subject. When they first hear about Acceptance Test-Driven Development (ATDD), a core practice on agile projects, their initial questions often are "Can examples really capture functional requirements?", "Where do user stories come from?", and "Will the analyst and tester roles become extinct?" When Jennitta Andrea worked on her first agile project in 2000, she asked all of these questions and more. As a hands-on practitioner and keen observer of teams and processes on more than a dozen agile projects since then, Jennitta has discovered that success comes from knowing how ATDD fits within an ecosystem of roles, practices, and tools. Learn what Acceptance Test-Driven Development is, the critical success factors for ATDD, and the details of several key success factors.
|
Jennitta Andrea, The Andrea Group, Inc.
|
|
|
The Twain Shall Meet: Incorporating User Experience Design in Agile Development Traditional user experience (UX) design methodologies are often seen as too slow and not flexible enough for use in agile software development. Scott Plewes explodes this myth by showing how to avoid dogmatic practices that undermine the value of UX design. Learn how to involve users, experience designers, and other UX design assets directly into your agile development process-without giving up the value of sprints, Scrums, minimalist documentation, or anything else that makes a well-oiled agile process work. Scott describes how and when to incorporate user feedback into the agile development process. Learn to determine which user requirements can potentially shift and which are likely to be more stable. Discover what type of user interface documentation is appropriate for your product and process as you explore how to get timely UX design information to developers and other team members.
|
Scott Plewes, Macadamian Technologies
|
|
|
The Value of Value Story Cards Many agile team members never reach their potential because they have no way to link their company's values with their day-to-day development work. The use of value story cards (VSCs), which provide executive management a tool to set high-level direction and tie it to the team's activities, is one step toward solving that problem. Jared Richardson describes VSCs, how to use them within your team, and how they can become a transformational tool. By defining three to five VSCs-such as "Move into this market space" or "Lower customer-reported bugs"-executives set the company direction.
|
Jared Richardson, Logos Technologies
|
|
|
Agile Program Management: Architecture, Risks, and Constraints Once you move to large agile development programs with multiple projects and sub-projects, how do you make progress and keep an architecturally coherent product? How do you create a product backlog and then manage working off the backlog among several or many project teams? How do you address the risks of having multiple project teams? How do you create an architecture that works for the product without retreating to a waterfall approach? In this class, Johanna Rothman describes a framework for analyzing your program's context so you can select from among several approaches for managing the architecture, handling backlogs, working across project teams, and more. She describes the roles of Chief Product Owner and the Program Manager and then discusses how they participate with the teams to ensure they know what they need to deliver and how to see overall program progress.
|
Johanna Rothman, Rothman Consulting Group, Inc.
|
|
|
Products and People over Process and Dogma If people in your organization are spending time "going agile," "being agile," or "doing agile" instead of simply using agile methods that work in your context, this session is for you. Ten years into the agile movement, the original ideals around lightweight process are putting on some pounds and calcifying in dangerous ways. David Hussman challenges you to stop focusing on improving your process and start focusing on improving your product-that thing your process produces-and your people-you know, the ones who do the work. Come ready to think, question, and rethink your use of agile practices and what may have become dogmatic processes. Explore the places where meaningful and lasting agility thrives, where agile practices are powerful tools, and where people don't talk about being agile.
|
David Hussman, DevJam
|
|
|
Pairing in Software Development Two people working at one computer collaborating on the same deliverable-sounds like double the work and double the costs doesn't it? Not so. Based on empirical studies, pair programming, properly implemented, has been shown to result in higher quality code, better program design, reduced risk, and improved knowledge management-all without a significant productivity hit. Laurie Williams describes the benefits and the resistance she's seen with teams that utilize pair programming and discusses "partner picking principles" in which the right engineers collaborate based on the task at hand. Beyond pair programming, your team can employ pairing throughout the software development lifecycle with similar value and results. Some highly productive software development teams pair all day, every day and on all development tasks.
|
Laurie Williams, North Carolina State University
|
|
|
Between BDUF and Anarchy: Finding Modeling's Sweet Spot "Big Design Up Front" isn't usually the best way to develop systems. Neither is anarchy, where developers code first and ask questions later. Somewhere between these two extremes lies the "sweet spot," a place where just enough up-front design is followed by incremental design to support individual iterations. Modeling, the representation of a business problem or its solution at different levels of abstraction, is a powerful tool in finding the sweet spot. Tom Nedwek discusses modeling approaches across the solution-delivery spectrum-describing a high-level business process, deciding what the system should accomplish, and designing how that solution will be implemented. Tom provides you with practical design and modeling guidance in each step of the lifecycle, sharing his experiences integrating modeling into multiple companies' development methodologies.
|
Tom Nedwek, Avanade
|
