|
Twelve-Step Program for a Better Test Process We can't make software better by testing the quality into it. However, if we manage our testing processes and educate the rest of the team about what it takes to make better software, we can make a difference. First, we have to get the testing world under control and work to reasonable expectations; then, we can spread the word to the rest of the organization. Judy McKay describes how to gain control of the test process-while still getting the real work done-and shares ways to educate the rest of the team about quality awareness. Using Judy's twelve-step program, test managers and testers will regain their sanity as they take control of the testing workflow and share it with the project team. By allowing developers to become part of your world, quality assurance can become a reality in your organization.
|
Judy McKay, Test & Automation Consulting LLC
|
|
A Manager's Survival Guide to Going Agile When software development teams move to Agile methodologies, they often leave the project managers behind. Traditionally trained project managers are confused about their new roles and responsibilities in an environment that no longer allows them to make stand-alone decisions. In this session, Michele Sliger focuses on re-defining the job of the project manager and their new-and often more important-role in development. Michele discusses the shift in a project manager's role from "boss" to one who serves and supports the team. Find out facilitation and collaboration skills can make you a better Agile project manager. Leave with a better understanding of the necessary changes to lead and support an Agile team and take away clear, practical guidelines to make these changes.
|
Michele Sliger, Rally Software Development
|
|
Agile Process Improvement and the Evolution toward Software Factories The concept of software factories is becoming a hot topic in software engineering circles. So, how can the factory model fit with Agile development practices? Damon Carr makes the case that Agile development is a stepping stone-not an alternative-to software factories. This is not the dreary vision of mindless workers in a factory. Instead, think of highly skilled individuals working with multi-million dollar machinery to develop systems. Even if you are not considering the factory model, Damon offers new practices that can reduce overall Agile development costs by as much as 40 percent. These include explicit refactoring to design patterns in your iterations, quantitative risk management, metrics for understanding the health of your project, and a new approach to team structure.
|
Damon Carr, AGILEFACTOR
|
|
Introduction to Agile Coaching Techniques In Agile processes such as Scrum and eXtreme Programming (XP), there is a coach whose primary function is to shepherd the process along and help keep everyone on the same page. On a traditional software team, there may be a product manager, project manager, technical lead, software architect, or even a user who informally takes on the role of coach. Based on his and the experiences of others as coaches, Christian Sepulveda shares his insights on this important role and the patterns that he employs as a coach. Understand why every team needs a coach, find out about the typical day in the life of a coach, and learn whether an individual acting as the coach also function in other roles. Find out how to balance the coaching needs of your organization and process.
|
Christian Sepulveda, Nominum Inc
|
|
A Guide to Using XP for Geographically Distributed Development Teams It has been said that eXtreme Programming (XP) and Agile development work only for development teams working closely together and collocated with their users. Because of the collaborative nature of Agile development, geographically disbursed team location often is used as a deciding factor against using Agile practices. So, how has XP worked at VA Software in the past two years with their distributed and offshore development team? In some cases it has worked very well ... in other cases, not well at all. The good news is that, because of XP’s fast turnaround and visibility, results were apparent after only a few weeks, allowing course corrections and schedule adjustments. Learn about the practices for XP, based on Mark Striebeck's real-world experiences, which can be applied to your teams whether they are distributed across town, across the country, or across the globe.
|
Mark Striebeck, VA Software Corporation
|
|
A Manager's View -- Evolving from Traditional to Agile Development Go inside a high risk, high reliability application environment with a combination of legacy and newer systems. These highly complex embedded and real-time systems support huge businesses and are expected to operate almost flawlessly every time. Most of the systems were originally developed with traditional waterfall and iterative processes and require extensive development documentation. So, how have they adopted leading edge Agile concepts with the full support of management while continuing to deliver products with the reliability demanded by their customers? Jon Hagar tells a fascinating story with many lessons for those of us living with hundreds of thousands or millions of lines of code that run our businesses. To avoid becoming antiquated and ending up losing not only market share but also your best people, you can make a commitment to improvement and evolution into the Agile world.
|
Jon Hagar, Jon Hagar Educational Services
|
|
Agile QA - An Oxymoron? Your software development group is adopting Agile practices. Documentation and processes now are lightweight. There are more unit tests, and all are automated. The software changes quickly with new releases every one to two weeks. What's happening with QA? Quality Assurance groups are typically accustomed to more heavyweight processes in which they spend a third or more of their time documenting tests and tracking results. QA groups that automate user interface tests have difficulty keeping up with the rapid changes inherent in an Agile environment. So, is there a need for Agile QA? Based on her experiences on Agile projects and the experiences others have shared with her, Elisabeth Hendrickson shows how QA teams can respond by becoming more Agile themselves and learning new ways to support the team and the users when the development team moves to an Agile process.
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
The Return on Investment for Finding Defects in Test For testers, finding defects is a way of life. However, we usually don't reflect on what an undiscovered defect can cost a business or how much it costs to find defects late in development. Geoff Horne seeks to put real costs on both of these situations and looks at practical ways to reduce the costs of not finding defects. With real-life case studies that you can use to justify the need for more testing, Geoff provides simple measures and statistics to calculate whether your allocation of testing dollars is too high, too low, or just right. Learn to show how testing can actually save money and how to get the best return for your testing dollar. After all, stock market investors assess their options based on risk and potential return. Why should testing be any different?
|
Geoff Horne, iSQA
|
|
Lean Software Contracts Agile development is great, but it cannot possibly be for you because your software development is done under a contract-outsourced or under an internal service agreement. Right? Wrong! Similar to the way automobile manufacturers have embraced lean manufacturing, you can escape the deadly waterfall development process even in contracted development environments. Lean manufacturing companies have learned over the past twenty years that trust with suppliers lies in specific actions and expectations, not in interpersonal relationships. They understand the "game" of outsourced contracting and know how to structure relationships and write contracts so that both sides are motivated to contribute to the common good. Join Mary Poppendieck, an expert in lean software development, to explore ways to change the contracting game in software development for the better.
|
Mary Poppendieck, Poppendieck LLC
|
|
Describing Software Requirements with User Stories All projects start with needs or requirements. How those requirements are documented and expressed has a tremendous affect on the rest of the project. The technique of expressing requirements as "user stories" is one of the most broadly applicable techniques introduced by eXtreme Programming (XP). However, user stories are a valuable approach on all time-constrained projects, not just those using XP. Although user stories originated in the Agile processes, they are useful even if you are not planning to employ Agile development. In this session, Mike Cohn will help you identify and write good user stories and understand the six attributes of all good stories. Explore how user role modeling can help when gathering the initial stories for a project.
|
Mike Cohn, Mountain Goat Software
|