Many software people look at creating great user experiences as a black art, something to guess at and hope for the best. It doesn't have to be that way! Jennifer Fraser explores the key ingredients for great user experience (UX) designs and shares the techniques she employs early-and often-during development. Find out how Jennifer fosters communications with users and devs, and works pro-actively to ensure true collaboration among UX designers and the rest of the team. Whether your team employs a formal agile methodology or not, Jennifer asserts that you need an iterative and incremental approach for creating great UX experiences. She shares her toolkit of communication techniques-blue-sky brainstorming sessions, structured conversation, and more-to use with different personality types and describes which types may approach decisions objectively versus empathetically.
Warning! Warning! Managing software projects may be accompanied by continued bouts of nausea-brought on by unmet expectations, process churn, late deliveries, and worse. In their attempt to conquer these problems, many managers stiffen their resolve, create stricter schedules, and install rigid processes to guide development from inception to production. Howard Deiner demonstrates that better results come from fundamental changes in the way managers and the organization approach problems. Drawing on W. Edward Deming’s "14 Obligations of Management," Howard reprises (with volunteers from the audience) Deming's famous Red Bead Experiment on its 30th anniversary and draws conclusions about how our approach to problem-solving affects our day-to-day work. Expect to get up on your feet and have a lot of fun "working" in a simulation of a modern workday environment, leading and managing the development efforts.
Developers and testers are under constant pressure to operate more efficiently, cut costs, and deliver on time. Without access to scalable, flexible, and cost effective computing resources, these challenges are magnified. Brett Goodwin explains how to create scalable dev/test environments in the cloud, and shares best practices for reducing cycle time and decreasing project costs. Learn how scalable, cloud-based data centers can run software without complicated re-writes; enable rapid defect resolution with snapshots and clones; and provide global collaboration for multiple product and release teams. Brett presents a case study of Cushman and Wakefield, the world's largest privately held real estate services firm, which struggled with an on-premises development and testing environment.
Development teams often fail to recognize the complex group interactions and multi-person relationships that are critical to build and maintain a highly productive team. Instead, they adopt follow-the-crowd practices such as stand up meetings or Kanban boards without understanding the underlying fundamentals. Michael Wolf introduces group interaction patterns of highly productive development teams to provide a framework for understanding group interactions and a vocabulary for discussing ways to improve. Michael demonstrates a simple tool-based on nine keystone patterns-that you can use to observe and understand your team members' interactions. He shares case studies that illustrate successes, failures, and turnarounds he's observed and explores how they relate to the different group interaction patterns.
Cloud computing is here to stay-and it is changing the way we test software. Cloud-based testing offers flexible, scalable, and on-demand infrastructure services. And as a bonus, because the cloud offers pay-per-use purchasing options, cloud-based testing usually costs less. Tauhida Parveen describes the concept of cloud-based testing: scope, specific requirements, benefits, and drawbacks. She explains how cloud-based testing brings new capabilities and options for your testing activities-instantly creating and dismantling test environments and miming production environments in early testing. Tauhida discusses how to engineer scalable environments for load, stress, and performance testing. Then, she introduces cloud-based compatibility, cross-browser, and cross-platform testing opportunities you can exploit.
According to the Standish group, 64 percent of features in systems are rarely-or never-used. How does this happen? Today, the work of eliciting the customers' true needs, which remains elusive, can be enhanced using data-driven requirements techniques. Brandon Carlson introduces data collection approaches and analysis techniques you can employ on your projects right away. Find out how to instrument existing applications and develop new requirements based on operational profiles of the current system. Learn to use A/B testing-a technique for trying out and analyzing alternative implementations-on your current system to determine which new features will deliver the most business value. With these tools at hand, you can help users and business stakeholders decide the best approaches and best new features to meet their real needs. Now is the time to take the guesswork out of requirements and get "Just the facts, Ma'am."
Picture this scene from three years ago: Employing the corporately mandated processes, a software engineering team is delivering system updates about once every nine months. When their senior user suddenly demands the next delivery in twenty-two weeks-half the current cycle duration-the team realize that they must quickly change development practices. Mathew Bissett describes how Her Majesty's Government did precisely that-and much, much more. First, they reduced delivery cycles from unpredictable dates every nine months to predictable releases every six weeks. Then, they cut releases cycle time to once every week. By identifying and mitigating risks early in the work intake process, enforcing quality gates, executing multiple test levels concurrently-and more-they dramatically increased throughput with the same or better quality. Today, these new processes provide their teams the best balance of structure versus agility.
Advances in technologies-virtualization, cheap storage, high-speed networks-and a growing comfort with the Internet's security and reliability are leading to widespread adoption of cloud computing. Still, traditional software development methodologies are unable to make full use of the power and flexibility cloud computing offers. Yash Talreja describes how he helped his clients implement lean and agile software development methodologies to take full advantage of cloud computing. Find out how a social networking site and a branded instant messaging company combined the ease and economy of cloud-based system installation, management, and maintenance with the speed of lean and agile practices. They were able to simplify the deployment and upgrade process offered by the cloud, and combine the benefits of a tight feedback loop between developers and end-users.
As if releasing a quality software project on time were not difficult enough, poor management dealing with planning, people, and process issues can be deadly to a project. Presenting a series of anti-pattern case studies, Ken Whitaker describes the most common deadly habits-and ways to avoid them. These seven killer habits are mishandling employee incentives; making key decisions by consensus; ignoring proven processes; delegating absolute control to a project manager; taking too long to negotiate a project's scope; releasing an "almost tested" product to market; and hiring someone who is not quite qualified-but liked by everyone. Whether you are an experienced manager struggling with some of these issues or a new software manager, you'll take away invaluable tips and techniques correcting these habits-or better yet, avoiding them altogether.
One principle architects employ when designing buildings is "form follows function." That is, the layout of a building should be based upon its intended function. In software, the same principle helps us create an integrated design that focuses on fulfilling the intent of the system. Ken Pugh explores congruency-the state in which all actions work toward a common goal. For example, as Ken sees it, if you form and promote integrated teams of developers, testers, and business analysts, then personnel evaluations should be focused on team results rather than on each individual’s performance. If you embrace the principle of delivering business value as quickly as possible, the entire organization should focus on that goal and not the more typical 100% resource utilization objective. If you choose to have agile teams, then they should be co-located for easy communication, rather than scattered across buildings or the world.