Articles

Adapting to Change in Your Agile Strategies

Len Whitmore writes on using agile practices for the development of software. In the ten years since the Agile Manifesto, the agile development domain evolved, as evidenced by such things as the six levels of planning: strategy, release, iteration, daily, and continuous, with strategy appearing to be the least evolved of the planning levels.

Len Whitmore
Writing Good Test Cases

We all know writing test cases is an integral part of the testing activity. In order to write good test cases, we must first understand what a test case is and why we need to write test cases. Can’t we live without writing test cases?

Anand Gupta's picture Anand Gupta
Options for Promoting and Controlling Changes in Risk Adverse Environments

Change occurs everywhere, and every day - especially in the software world. Knowing how to navigate that change, and maximizing it's acceptance across the board is crucial for development teams to reach their goals. Learn how this can be accomplished in processes that are easy to adopt.

Anonymous
Accelerating Agile Files Accelerating Agile Development through Software Reuse

One of the main attractions of agile methods over traditional heavyweight approaches to software engineering is their ability to accelerate the software development process. By minimizing superfluous activities and artifacts such as models and documentation and focusing developers' efforts on coding, agile methods increase productivity and reduce overall development time.

Using Process-Enabled SCM Tools to Facilitate the Software Development Lifecycle

When used appropriately, process-enabled SCM tools facilitate iterative team software development in a highly dynamic environment. As SCM practitioners, we should educate and guide our customers, the members of software development teams, to exploit the application lifecycle capabilities of process-enabled SCM tools.

Michael Sayko
Less Is More

Twentieth Century architect Ludwig Mies van der Rohe, who coined the dictum, "less is more," is known for his simple designs. Interestingly, this concept has proven true time and time again in the software industry. In this column, Linda Hayes explains reasons why simplifying your team when it comes to quantity is so vital and shares some surprising statistics on how team size can affect quality.

Linda Hayes's picture Linda Hayes
Cook until Done

There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software—they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.

Andy Hunt Dave Thomas
The Goldilocks Parable: How Much Process Is Just Right

Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.

Ed Weller's picture Ed Weller
QA Preventing Failure Suffering for Success

One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense.

Linda Hayes's picture Linda Hayes
Design and Code Inspection Metrics

In this study, historical inspection data from large real-time embedded systems were analyzed with the intention of improving the current review process.

Alison A. Gately's picture Alison A. Gately

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.