|
Find Your Metaphor for Agile Software Design How you think about software design can have a big impact on how effective you are when you do it. All of us have different criteria for success, and some of them aren’t even conscious. We have to figure out what resonates for us so that we make the right choices, and we can get a clue about the right choices for us by looking at the metaphors we use when we talk about software.
|
|
|
The Value of Test-Driven Development when Writing Changeable Code Writing changeable code makes it easier and more cost-effective to add features to existing software. Writing changeable code doesn’t take longer, but it does require paying attention to certain things when building a system. It's important to have a good suite of unit tests that support refactoring code when needed, and test-driven development helps you create independently testable code.
|
|
|
Fitting Technical Writing into Agile Development As teams strive to move to a mature agile process, technical writers must adapt as effectively as the development personnel. This new agile process demands that knowledge dealing with software or product releases is only sparingly documented up front, making the technical writer's job of gathering information much more dependent on talking with people over reading requirements.
|
|
|
Document Why as Well as What: Finding the Purpose of Your Software Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
|
|
|
Project Teams Need to Overcome Their Fear of Coding Many organizations appear to suffer anxiety at the thought of programming. They want to get everyone but the programmers in a room to discuss a project down to the minute and the dollar, without a full understanding of the coding required. But a few hours of code experimentation generates far more understanding than days of debate by architects and analysts. Don't be scared of programming.
|
|
|
Paying Off the Technical Debt in Your Agile Projects Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.
|
|
|
Fixing a Broken Deployment Process When you have hundreds of applications performing various functions across several environments, it's tough to push all the code when it needs to be. Here are some steps to help your own team develop the internal tooling it requires to deploy thousands of applications if needed, all in a reliable, efficient manner.
|
|
|
Delivering Value with Agile and #NoEstimates #NoEstimates is a challenge to the traditional thinking that estimation is essential to agile development. Ryan Ripley believes there are more interesting tools available to help us determine what value is and when we could realize it, while still staying aligned with the businesses and customers we serve. Learn some other ways to deliver value to your customers.
|
|
|
Create an Agile DevOps Environment That Fosters Flexibility over Features When a company makes the move from software as a service (SaaS) to an API-first platform, a change in mindset is required. The successful transitions come from those who shift from features to flexibility. Technology teams should look to remove constraints and broaden the possibilities of their platform by constantly exploring ways to make their platform as flexible as possible.
|
|
|
When Postmortems Meet Retrospectives: Improving Your Agile Process If you want secure, reliable systems, you need all stakeholders actively communicating. This means involving both IT operations and developers in discussions after deployments, to ascertain if anything went wrong and can be avoided, and what went well or could be refined. Integrating your postmortems and retrospectives facilitates collaboration and improves processes.
|
|