The Latest
 |
Book Reviews for BAs[magazine] Get a head start on your New Year's resolution. Hone your business analysis skills or learn new ones, and make 2012 the highlight of your career. |
|
|
Tips and Advice: Test-Driven Development—Bob Payne and George Dinwiddie[article]
Podcast
George and Bob Payne discuss one of the most beneficial and underutilized agile technique, test-driven development. The data is in, and you need to be doing this if you want to call yourself an agile engineer. |
||
|
ADP West 2011: Ken Pugh—Acceptance Test-Driven Development[article]
Podcast
Ken and Bob Payne talk about Ken's book on acceptance test-driven development. This is a topic that has been gaining a lot of traction in agile teams. Acceptance test-driven development is a technique that some teams are using to improve quality and collaboration between business, testing, and development. |
||
|
Make an Attitude Investment[article] Whether you’re concerned about your day-to-day work or the long-term goals you’ve set, a good attitude can make all the difference. In this article, Laura Brandenburg expands on some tips gathered from Jeffrey Gitomer’s Little Gold Book of Yes! Attitude. |
||
|
Improving QA-Development Communication: An Interview with Amit Chopra[interview] In this Sticky ToolLook interview, Microsoft senior program manager Amit Chopra takes a look at some of the common communication breakdowns between QA and development teams and offers suggestions for avoiding or repairing those situations. |
||
|
Estimating the Unknown: Dates or Budgets, Part 5[article] In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost. |
||
|
From One Expert to Another: Meeta Prakash[article] Meeta Prakash has been involved in testing for twelve years. In this installment of the From One Expert to Another interview series, Anne-Marie Charrette speaks with her about her testing experience, coaching, and the importance of understanding the different cultures with which you engage. |
||
|
Helping the Customer Stick to the Purpose of a User Story[article] Lisa Crispin writes that you need to understand the purpose of a user story or feature. Start with the "why." You can worry later about the "how." The customers get to decide on the business value to be delivered. They generally aren't qualified to dictate the technical implementation of that functionality. It's up to the technical team to decide the best way to deliver the desired feature through the software. |
||
 |
Estimating the Unknown: Dates or Budgets, Part 1[article] Almost every manager I know wants to know when a project will be done. Some managers decree when a project will be done. Some managers think they can decree both the date and the feature set. There is one other tiny small subset, those managers who ask, “When can you finish this set of ranked features?” |
|
|
Is It Beautiful?—Aesthetics in Software Testing[article] With all the faces it presents, surely software can be said to possess or lack beauty. But, what does it mean to have beautiful software, and how do we evaluate it? In this installment of his series on philosophy and testing, Rick Scott takes a closer look at software aesthetics. |
||
|
How to Lose a Customer[article] Giving your clients the opportunity to voice their opinions after conducting business with you is a great way to express your interest in continuing to work with them. Just make sure you're earnest in hearing their thoughts and that you don't simply think this is accomplished with a survey alone. |
||
|
Edit Those Epics[article] It can be tricky for managers and technical leaders to make the transition to agile. They’re likely accustomed to doing things a particular way. What’s more, they may try to squeeze their old ways into the new, agile approach. Here, Johanna Rothman describes why that isn’t a good idea, especially regarding stories that are too big. |
||
|
Agile or Not: How to Get Things Done[article] Agile software development always felt intuitive to me. Developing software incrementally, in close collaboration with the customer is the obvious way to deal with the uncertainty inherent in both software requirements and implementation. The technical practices of automating necessary but time consuming tests, and deploying, early and often are the obvious ways to give an team the ability to evaluate the functionality you have and to to decide if the software works as expected. And it's also important to decide if what you built still makes sense given the current environment. |
||
 |
Getting to "Done" in Agile Development[article] When the tasks in the "Done" column needed more attention, the team created a "Done Done" column. Later, they created a "Done Done Done" column. In this article, Brian Bozzuto discusses how you can stop adding columns and honestly get to "done" without having to kid yourself. |
|
|
More on Being Done[article] Continuing the conversation from last week, Andy Singleton followed up on my post on being done with this post. Which is good as this is one of those questions that sounds simple in theory, but in practice contains some subtlety. |
Pages
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.