Peer code review is universally acknowledged as a valuable practice that often catches 60 percent to 90 percent of the bugs in code. So why would most developers rather be poked in the eye with a sharp stick than attend a Fagan style inspection meeting? Take a cue from the crowd working on Wine (www.winehq.com), an open source implementation of the Windows API.
Better Software Conference & EXPO 2005
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.
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.
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.
Whereas the Agile Software Development Manifesto is a short and sweet list of principles for developers, the Declaration of Interdependence for Agile Project Management is more of a mouthful. The Declaration of Interdependence was written to provide concrete guidance for software projects and projects in general with applicability to general management. In constructing it, a dozen senior consultants, designers, and managers-project, product, and line-validated that it covered their individual core operating frameworks.
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.
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.
You've heard of eXtreme Programming (XP) and perhaps Scrum. How about Crystal Clear, Adaptive Software Development, Dynamic Systems Development Method, Rational Unified Process for Agile Development, and Feature Driven Development? These are some of the many variations of Agile development methods. Join Jeff McKenna as he explores the many flavors of Agile development methods and explains the similarities and differences.
In some contexts, the software development process can be optimized when it is thought of-and run-like a highly automated manufacturing production line. Rather than producing many identical widgets like a manufacturing plant, software organizations produce many programming changes. These changes may not be identical like manufactured widgets, but programming changes can start looking a lot like widgets when you look at the big picture.
Whether you are building a brand new product or evolving an existing system, understanding the business needs of your customers is the foundation of a marketable product or valuable internal application. Few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about requirements. Hone your elicitation skills and learn what it takes to get beneath the surface and understand your customers: their world, how they work, and what really bothers them.