|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
On the other hand, changing practices for the sake of going mobile doesn't make much sense unless it's backed with sound business strategy. Such is Joel Semeniuk's belief; he has been a project manager for more than 20 years and is now executive vice president of agile project management at Telerik, which creates a broad palette of software testing tools and UI components for .Net.
"Since mobile is all the rage," Semeniuk says, "it's too easy to get caught up in the mobile-first strategy and not stop to consider the real customer value provided by the mobile application." Such value includes creating the right tool for the needed job: "Some applications aren't well-suited with mobile scenarios -- for example, those that require large amounts of data entry."
2. Find the right mix of development methodologies to meet project needs
The wars over development methodologies -- agile, XP (extreme programming), waterfall, and so on -- are fast giving way to a more fluid and flexible approach to producing
and refining a product. Telerik's Semeniuk is one of many in the modern development world who sees development methodologies
not as dogmas to be followed to the letter, but toolkits to be raided for what's useful. Confining a development team to one methodology is becoming a thing of the past.
"We have an iteration pattern for each problem," says Semeniuk, "in which we continually adjust or 'pull in' new agile practices that solve those problems. Sometimes we 'pull in' all of Scrum, because it solves the wide range of problems that come up in that particular environment. Sometimes we pull in pieces of Scrum or XP or Combine because it makes better sense if you're in maintenance mode." Semeniuk calls this the "agile buffet table" model.
For Telerik, though, the most important motive behind using any particular development practice is why. "We like to start with the 'why' and use agile to solve a real problem we're having. The biggest reason for that is when we try to just push out practices, they don't stick; people don't identify with the reasons these practices make sense. And not all practices fit all projects," he says.
Applico's Powers says his company also uses a variety of development models -- mainly agile and iterative. In his case, the "why" is driven by client needs.
"Some clients like rigid development timelines and documentation," says Powers, "especially ones that want to bring it in house. Others like the fluidity of the agile process and the ability to be brought in the loop at all times."
Some, however, caution that agile can't simply be sprayed onto an existing development process. A former program manager who has declined to be named but has five years of experience as a Scrum master has time and again seen agile used in development, but with no corresponding changes in other facets of bringing software to market.
"There's no intermittent QA; instead, there's old-school 'toss it over the wall to QA'-style QA," he says. "Instead of regular releases, they're using agile to get a release out, then having the schedule disrupted by support." In his purview, there has been a battle between traditional software releases and agile, with a lot of people simply using agile merely to drive old-school models.