I only can say that you probably want to develop on supported platform (for the sake of close alignment with you target production environment(s)) - that means you should stick to documented product requirements.
Exact layout of your VMs is up to you, but separate SharePoint box is definitely way more aligned with any production deployment and allows you to do more realistic testing / spot some problems which never occur if SharePoint hosted locally on the same box with K2 server. I would say you need DEV SharePoint Server(s) of required versions and separate K2 server(s) of required version(s). If we don't speak about locally hosted VMs (on developer's workstations), then you just share K2 VM between your developers, or best of all let them connect to it and have developer tools on their workstations without sitting on the server when it is not strictly necessary.

Thanks for the reply.

We are talking about locally hosted developer VMs on developers workstations.

While our client environments (dev, staging and production) are all the same (separate SP, Search and K2 servers), our developer vms are not. All deveper VMs are single servers hosted within their own workstation.

I think the safest is to go with 2 VMs hosted locally. I think there will be a lot of potential issues if we go from each developer having a dedicated SharePoint/K2 environment to a shared K2 vm that is accessible to each developer VM. 

I worry about stringtable/variable collisions, package and deployment conflicts, not to mention I'm not sure how the K2 for SharePoint 2013 broker/smartobjects would work given that there's multiple SharePoint farms/webapps all with the same...

Kent,

I tend to agree with you on the 2 VM approach, as a matter of personal preference. 

I suppose you could also set up a single SP 2013 environment and have each developer have a local K2/SQL server that integrates with their own site collection. Just a thought. There are always nuances to these "one-box-wonder" situations. I understand the safety and convenience factors of having isolated dev environments, where no developer can accidentally step on anyone else's work. And I also understand wanting to consolidate some services for simplicity of maintenance. 

So, I guess I'll give you the age-old infamous K2 response of "it depends!" 

Maybe others out there have their own variations of development environments, with isolated and/or shared components? I'd love to hear what others are doing on this topic.

Best regards,

Gail

Nothing bad with ¨I think the safest is to go with 2 VMs hosted locally¨ - though there may be a bit of overhead in terms of keeping synchronized snapshots of 2 VMs in certain scenarios (the only downside I can think of). As for sharing K2 development server/environment between developers, well, this is fully supported scenario which I guess was in mind when product was designed (can't be other way with server products) - your developers either work on separate solutions (no interference to each other) or collaborate in some way/work on the parts of solution (some process should be agreed on, irrespectively of the product/techonlogy in such scenarios). Though giving them their own VM allows them to be absolutely free/flexible in their development experiments and prototyping of solutions - they kind of fully autonomous in this case :)