Agile is making its way into the enterprise as a project methodology for industrial-strength projects. Why the popularity? The answer lies in the requirements paradox: “We want requirements to be stable, but requirements are never stable.” Discover some key agile concepts as they affect business analysts.
Optimism is normally viewed as a positive trait, but not when it comes to goals and estimates. Project managers who don their rose-colored glasses when faced with the harsh light of reality are setting themselves up for disappointment.
Agile and ALM are two terms that you don’t often see side by side. To most developers, agile means team interaction, customer collaboration, dynamism, and responsiveness to change. In contrast, ALM seems to imply the opposite of agile, with echoes of rigid procedures, inflexibility, and top-down process control. But are the agile and ALM approaches as contradictory as they first appear to be?
Agile software development is designed to thrive within even the most dynamic business and technical environments. All agile methodologies include integrated practices and processes that manage evolving requirements to efficiently develop a continuous stream of new software capabilities. However, what Agile does not address are changes related to enterprise support that falls outside the scope of the project work. Enterprise Change Management (ECM) provides a framework that addresses many of these missing factors.
Even though it is easy to say that you should continuously test your application for performance during development, how do you really do it? What are the processes for testing performance early and often? What kinds of problems will you find at the different stages? Chris Patterson shares the tools and techniques he recently used during the development of a highly concurrent and highly scalable server that is shipping soon. Chris explores how developers and testers used common tools and frameworks to accelerate the start of performance testing during product development. Explore the challenges they faced while testing a version 1 product, including defining appropriate performance and scale goals, simulating concurrent user access patterns, and generating a real world data set. Learn from his team's mistakes and their successes as Chris shares both the good and the bad of the process and results.
About 12 months ago, our company started an initiative to adopt agile practices across our entire organization—not only our software development organization, but our business organization. For years we had experienced outstanding results by utilizing Scrum for our clients' application development projects. Team productivity improved, executive visibility strengthened, and overall quality increased. Our goal was to capture similar results for our business. Find out how we're doing!
A phrase heard often in agile development practices discussions is "let the product lead." Applied correctly, these four words powerfully focus an agile team's energy directly on work that provides the highest business value. Traditional engineering practices that focus on process often divert a technology team's energy away from quick delivery of business value, and toward design of infrastructure and architecture.
Every system has an architecture, even systems developed using agile methodologies. Whether you attempt to define that architecture up front in detail or whether it emerges over time is up to you. My experience is that most agile teams follow a strategy somewhere between these two extremes. That strategy, combined with proving your architectural ideas as soon as possible through working code. This article summarizes a collection of strategies for addressing architectural concerns on agile projects and discusses how such strategies can be applied to scale agile methods to large development efforts.
Open source software has come a long way in the past few years. However, for automated testing there still are not many ready-made solutions. Testers often must spend their time working on test cases rather than working on a test automation framework. Allen Hutchison describes the elements of an automated test framework and demonstrates a framework that you can quickly assemble from several open source software tools. He then explains how to put the pieces together with a scripting language such as Perl. Once you build the framework, you can improve and reuse it in future test projects. At the end of the presentation, Google will release the described framework as a new open source project that you can begin using immediately.
Beta testing is an industry standard practice to obtain user feedback prior to general availability of software. Have you ever considered that the Beta release can be used to validate the software's value to customers and application users? Extending the Beta concept will result in higher customer satisfaction (and higher revenue for commercial products). Also, you can employ Beta testing to evaluate not only the software product, but the distribution (and sales) process, training, customer support, and usage within your customers' environments. Far beyond just finding defects in the product, you can focus Beta testing on how well the software is meeting your customers' needs. What does that mean to the Development team and the organization as a whole? What are the risks and challenges that we face? What are the rewards?