I recall a discussion I had with an product manager at Oracle. We were talking about how they were trying to get into a more "agile" workflow. I wa...
For further actions, you may consider blocking this person and/or reporting abuse
It's about time we all got off our tiny planets and explored the vast galaxy together. There are too many things to try and see to allow ourselves to be boxed in by the meaning of todays-favourite-trend-word™.
We should be trying to fulfill goals, not processes.
Good point Ben! I totally agree with you. I just had a similar situation on New Year's Day with one of my good friends (also dev), when we discussed the word: platform. For him, it was something like Facebook, Twitter and so on. And I totally agree with that, these are very good examples for social media platforms. But for me it was also kind of a business model, which means the software is particularly designed to be a platform. So we ended up with 2 point of views and a long discussion.
It is also the same with the word: servers. It really depends on your point of view. As a hardware guy, you mean the host computers (server-racks, server-farms, physical machines), but as a software guy you interpret servers differently. It is software, which runs on a machine and provide something for you. In context of the web, these might be web-severs, like NGINX, etc.
I think what would be really cool, especially for beginners, to have kind of a dictionary, which contains the common words and their definitions and highlight also some misinterpretations and different point of views. Maybe this is something what the DEV.to community could build over time 😉
I'm not sure what the "Agile methodology" is.
The Manifesto for Agile Software Development is a set of four values and twelve principles. It does not prescribe any kind of process.
There are many different kinds of development methodologies that embrace those values and principles. For example, XP.
There are also lightweight management processes, such as Scrum (q.v., The Scrum Guide), that compliment using some sort of agile-based methodology, such as XP.
In my experience, I have never seen Scrum implemented in practice as described by-the-book. At best, maybe a 50/50 blend of Scrum and... umm... Not Scrum; at worst, using Scrum terminology for the parts of a Waterfall heavyweight management process. “In theory, theory and practice are the same. In practice, they are not.”
From my perspective, the practical part of agile software development that makes agile actually agile is Engineering Practices Necessary for Scrum.
All that being said, the greatest factor is not the management process, nor the development methodology... it's the people and having a functional team and using The Joel Test as a quick tally sheet.
I didn't knew Joel test and your conclusion seems good thanks for sharing
I disagree that it's "not a case of semantics". As a philosopher will tell you, you need to define your terms and scope before you start, otherwise all you do is argue semantics. When you define a term, you need to define it in terms of its scope.
I tend to agree here. Some of this is different perspectives, the problems I face day to day to day and try to solve is different from yours. The other part is that we all make assumptions what common terms mean, that is why defining terms so we all are coming from the same point is important.
I think we are all guilty of this.
My blog posts are aimed at small business programmers working alone or with maybe three devs tops. So when I write about documenting your processes and making your passwords available to your boss in the event of your sudden death, what's acceptable in my context is completely different (and possibly dangerous) if you worked at Google or Adobe or something. Yet, I didn't clearly state that assumption in the post. I assume my readers will figure it out from everything else on my blog and my bio but it's certainly not guaranteed.
Interesting...So when we pair with someone should we make it clear what we understand about a particular topic from the start ? Should this be done even before the pairing ? Like should we build a relationship with a co-worker and understand their view point objectively and vice-versa ?