Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Options
Would be really nice to see a timeline of new coming features being worked on.
mcconnell113
Member Posts: 74 ✭✭
in General
One of the things I really liked about fusion 360 is that they inform their followers on what's next. This tends to keep things more exciting. Being in the dark is no fun and it makes it harder to commit yourself to learn something if it may not be what you hope it will be down the road. Thoughts?
John McConnell - Let's change things.
Saplingstore.com
Saplingstore.com
0
Comments
Twitter: @onshapetricks & @babart1977
Saplingstore.com
http://www.spiked3.com
This doesn't mean that we don't have a list of important features that we're working on this year, but being responsive to our users means that priorities can shift. We care a lot about how you interact with features, how they look, and how they scale with thousands of users hitting them all at once. All of this takes time. We're more than willing to make a feature wait until we get it right.
On the flip side, we're also willing to put a feature out with basic functionality and see how people are using it (or misusing it) and work to improve it across multiple releases. Your feedback here in the forums and through support really does influence the direction we take, so let us know what you think!
Do you know any examples of HW companies that embrace Agile development?
In my company too, for the vast majority of projects, classical project planning just DOES-NOT-WORK. We do try: we have operating plans, project plans, milestone plans, traffic lights... However, these tools do a very poor job of helping me to focus on solving real problems. I think people sometimes forget these planning tools are just that... tools, not some sort of religion.
Requirements can (and do often!) change at any time and sometimes with great repercussions on previous decisions. The tools we use are quite bad at capturing/tracking such 'detours'.
I like iteratively refining my designs. It's my most natural state of being and how I perform best.
Dries
most are not. most cannot understand that product development is a non linear process. If you want a mediocre outcome, drive a project like it is an accounting exercise.
Contrast this approach with the SME where the person driving the project may be the person making the product/selling the product/dealing with customer feedback. Totally different, faster, more archaic, harder work but ultimately more rewarding.
my biggest annoyance-by far- is when a small company employs or brings in a consultant who has big company process mentality...like it is some magic bullet to nirvana. What works for IBM works for IBM because they have the resources and scale to operate a process. It does not work in a 20 person company on one site.
so, a bit of chaos is good.
Dries
And the welcoming of a bit of chaos is even better!
@Kevin Quigley It's even worse when they refuse to see that it's not working, blaming people in the wake. It becomes an object lesson of how not to do things. Reminds me of this quote ... "The more the plans fail, the more the planners plan."
Unfortunately I don't know of any @DriesVervoort_Caradon
They must exist for sure. I'm naturally inclined this way and I understand that others gifts may be more organizational and that's why they tend approach design this way. But design is not like manufacturing where you know all the steps involved and what's needed each step of the way. I often like to work on things I know will be needed at some point, it gives me more time to understand a problem and think about it more freely without an artificially imposed timetable. I think the best ideas come this way, almost serendipitously - our brains literally continue to work on the problems subconsciously while we go about other things. I have been softly reprimanded for continuing to develop something for next year because its not in the current schedule - yet when the schedule affords there's never enough time allocated to do it like it really should be done. That's maybe not even Agile, but is in my opinion much needed and not encouraged enough in the manufacturing realm.
This is why our support and product development/UX team is one group. We want to truly understand how you are using the system, what workflows are jammed and how to improve while still achieving the bigger, long term goals.
In my last role (where I was engineering director), we developed products that had significant electronics, mechanical and software content. The software team started out using a Scrum (agile) approach, then moved to Kanban with Jira task / bug tracking. The Kanban / Jira method was then implemented across the board by the whole engineering group. It worked very well in that context, giving the benefits of flexibility with open and clear communication. The classical Gannt timing chart was still required at a higher level of course, as the real world was waiting out there but I’d recommend it internally if the program can support the less conventional behaviours and reporting format – some customers, internal and external, can’t work with it, often for perfectly valid reasons. The hardware teams didn’t struggle with it at all, as it was a great improvement over issue tracking spreadsheets and Gannt charts.
A problem many engineers (particularly software) have with agile methods is the conflict between flexibility (ie which tasks are best executed next or possibly even which tasks to abandon) and the absolute need to meet timelines (customer promises, key production dates, test and development builds etc). Classical program managers (using Gannt charts, Microsoft Project etc) often won’t or can’t adapt to reflect the changing needs of the business or the market – instead sticking to them religiously just because that’s what was signed up to a year ago. Flexibility mustn’t be confused with tolerance of slipping timescales but it very easily is. The planning sessions are key to this.
In this instance, there is surely nothing to prevent the publication of a provisional roadmap that reflects today’s view, with periodic updates as the vision is refined and the product features delivered. In the real world of business, there are various stakeholders (not least the shareholders and other investors) who have been promised certain outcomes for their investment. Unless there is no budget, resource plan, timeline etc, then surely there must be some idea of how the various features will be “rolled out”(yuk) over the currently authorised and resourced phase of development.
On a lighter note, it’s amusing to be told by evangelists about new program tools emerging from software circles that promise to transform program delivery (with names like Agile, Lean and Kanban). Often they seem to have little or no awareness of the origin of these words and the philosophies behind them but come to believe that they are so powerful that they could even be applied even beyond the software environment. Just so!
Saplingstore.com
People talk about political polling being a bad thing in the run-up to elections.
I think they overlook that most of the bad outcomes arise from the results of the polls being made public, instead of simply making them available to the policy-setters and campaign managers.
And the damage, such as it is, tends to be invisible to those who focus on how humans SHOULD behave rather than how they do behave.
It's always an interesting problem to measure an organic process without unduly affecting it.
And to give a shout-out to Oleg Shilovitsky
http://beyondplm.com/2014/07/03/who-will-make-plm-for-extreme-manufacturing/
@murray_1 ; Can I ask what you liked more about a KanBan and Jira approach over the scrum based approach?
http://www.amazon.com/dp/0470548681/ref=cm_sw_su_dp
http://techcrunch.com/2015/07/05/how-old-school-management-kills-work-culture/#.hnq6ht:fQxj