When working with multiple larger Support-based contracts, "agile" can start to break down after the Implementation stage. Once a site goes live, often the project team will be adjusted, or sometimes it will change completely. Because of this, certain changes to the development workflow should be considered.
"Hey, I just had a great idea for a new module! It's new and different and it's going to be GREAT! So, let's see here, what do I need to do? Well, I've still got some Drupal 7 sites, so I'll need two versions of the module. Maybe I should put some of the code in a library, so I don't have to put the same exact code in the Drupal 8 version of the module. I guess that means I'll need to register my project with Packagist.
How many front-end developers do you have at work? 5? 10? 50? Do you know?
At IBM, we found that once we started to organize around our craft, the 50 or so that we knew about quickly grew in to thousands of practitioners. From back-end developers who had been asked to do front-end work, to designers who are interested in or already have started coding, to individuals whose full-time job was the front-end, a community was found, grew, and is now flourishing.
Managing projects is hard. Waterfall can help you define a project up front, but details change like sand under your feet. Cowboy and Extreme programming is terrifying for your stakeholders, leading to miscommunication. Your process is a jumbled mess and you want to just get your arms around it and wrestle it the ground.
We’ve all been there. You’re a site builder, and you were just shown a new design for article nodes. Within the post, you see a visually compelling tapestry of mixed media: text, photo slideshows, columns, dynamic lists, and even full-width photos.
The client will love it, but how do you give so much editing power to the end-user without writing custom code for each new post? The answer, my friends, is Paragraphs.