Actually, I'm a Waterfall developer in an Agile organization.
Things that don't "feel" right to me include:
Starting work on a project with barely any idea what it should do.
Documenting the processes, but not the products; being unable to get information without having to go talk to someone. All I should need is a Requirements document, a Design document (which I may write myself), and Google.
Spending more time in meetings than coding.
Spending more time coding at home than at work.
Having no idea when the project will be done.
PM's being useful in any way.
Having a meeting to prepare for a meeting to prepare for a meeting where somebody else logs onto a server and copies a file; thus spending six hours on a process that takes six minutes
Multiple checkouts
Knowing how something should flow, but not having actual requirements.
Developers' unique skill sets are downplayed or outright ignored as they make the developer non-interchangeable.
When there are no stories remaining... nothing to do... just kinda sit there... Could be adding a new feature; may not be needed but the time isn't being wasted...
Every six months when I change contracts, I have to adapt to a new coding standard? By the time I get used to it, I'm already looking for my next contract.
Why are these practices incompatible with waterfall? As far as I can tell almost all of these if not absolutely all of them are possible with a waterfall approach. There is no particular reason waterfall development has to be chaotic. It may have other drawbacks/challenges but chaos is not likely to be high on the list.
Without getting down into the "whine" mode.. I'd choose to answer the "Dealing with it" part of the question. I've reached the following options from my experience
Somewhat-Easy way: Quit and find a place that is more to your liking... I say somewhat easy because of misc. sub-problems: 'agile' workplaces may not exist in your immediate vicinity.. relocation may not be a feasible approach, the people in an agile workplace may be 'non-agile',
The middle path: Continue to be agile personally. Help and teach others who are interested.. Maybe the org. will change slowly for the better.. Hope for the best and pray that you do not reach the 'quitting point of no-return'
The super-hard way: Strive to bring about change in your organization. This is not everyone's cup of tea. The culture of an organization cannot be changed within a short time... you need a "Local Sponsor" in management to start anything substantial. Couple that to the fact that you can't really change another person except yourself. So if you're passionate, patient, relentless, highly optimistic and willing to slug it out, I'd recommend "Fearless Change" with all my heart. (source: informit.com)
Firstly, Agile methodologies emphasize on these practices but they have not introduced them. They have been there in software development process well before Agile came in. So simply saying that if you are not using Scrum/XP/RUP then you are not following these practices is plain wrong. If you are a professional software development organization, these practices will exist in one form or other.
Secondly, whether you are an agile developer in a Waterfall organization or vice-versa, you can not do much, at-least not effectively or significantly. What development 'culture' the organization has is a function of the commitment and focus of the management and executive. If that does not exist, you can do your 'bit' but you will lose out in the end. That is the reason Agile fails in many organizations when they transition to it, because they are unwilling to make the cultural change.
I'm in a pseudo agile organisation and here's my responses to those points you raised:
not writing unit tests: I'm a believer in 100% coverage. And yes it is easy to say you can have 100% coverage and write really bad tests, however, any new code I write, I do my best to have acceptance or integration tests and have 100% coverage for what I work on. In the build, I have put in a coverage check to make sure it doesn't drop below the current limit.
not having a continuous build: Because of the way everyone has worked prior, most people run the build without the coverage check and therefore can willy nilly check whatever they like in without it being tested. Not to mention the continuous build sometimes seems to be on and sometimes seems to be off. I am very close to just setting up a CI box of my own.
not refactoring: I refactor whatever I can so I don't throw up when I see that same class again.
not having a team coding standard: The company has a coding standard, however, there are many things that are wrong with it. Therefore I do my best to bring things up with those higher up to get it changed. It hurts sometimes to code the way they think is right. e.g. putting huge java comment section headers for the public, private, protected, fields, constants etc throughout your file. I believe this was done once upon a time because classes got so out of control (e.g. thousands of lines long) that they needed section headers so you could find where your public methods started and where your private methods started(!!)
not pair programming: Fortunately I have someone who thinks like me sitting behind me and we turn our chairs to talk and discuss ideas as often as possible to compensate.
not doing iterations: We have 3 week iterations, but it feels very ad hoc. There is a cleanup/review week in between each iteration which makes it theoretically a 4 week iteration. I can't do anything else about it. It's hard to convince them to make those iterations shorter because the code is so bad is actually takes 3 weeks to write something that should take only 1 week.
Seriously, if your organization is as chaotic and amateurish as you describe, I would start looking for another job before they go under. As Martin Fowler once quipped
If you can't change your organization, change your organization
If, on the other hand, you feel like they can change, then I'd make an attempt to start that change by introducing retrospectives before anything else on your list. If you can get people talking to each other and starting to identify the waste that goes on, and someone involved has sufficient mandate to listen to that feedback and make changes, however tentative, you'll be on the right track.
All of the other practices you've identified are techniques for eliminating particular types of waste - writing unit tests, for example, to reduce the waste of fixing defects later in the project. By holding retrospectives you'll shine a light on these wastes and give people a space do decide they might like to do things more professionally.
In the end, it's about self-respect: yours, your colleagues, and the organization as a whole. Are you satisfied to just muddle along the way things have always been, or do you want to try to be as good at what you do as you possibly can be?
发布评论
评论（6）
实际上，我是敏捷组织中的瀑布开发人员。
我“感觉”不正确的事情包括：
Actually, I'm a Waterfall developer in an Agile organization.
Things that don't "feel" right to me include:
为什么这些实践与瀑布不兼容？ 据我所知，几乎所有这些（如果不是绝对所有）都可以通过瀑布方法实现。 瀑布式开发没有什么特别的原因必须是混乱的。 它可能还有其他缺点/挑战，但混乱不太可能在列表中名列前茅。
Why are these practices incompatible with waterfall? As far as I can tell almost all of these if not absolutely all of them are possible with a waterfall approach. There is no particular reason waterfall development has to be chaotic. It may have other drawbacks/challenges but chaos is not likely to be high on the list.
在不进入“抱怨”模式的情况下..我会选择回答问题的“处理它”部分。 根据我的经验，我得出了以下选择
（来源：informit.com）
Without getting down into the "whine" mode.. I'd choose to answer the "Dealing with it" part of the question. I've reached the following options from my experience
(source: informit.com)
首先，敏捷方法论强调这些实践，但没有引入它们。 在敏捷出现之前，它们就已经存在于软件开发过程中。因此，简单地说，如果您没有使用 Scrum/XP/RUP，那么您就没有遵循这些实践，这是完全错误的。 如果您是专业的软件开发组织，这些实践将以一种或多种形式存在。
其次，无论您是瀑布组织中的敏捷开发人员还是反之亦然，您都无法做太多事情，至少不能有效或显着地做。 组织拥有什么样的发展“文化”取决于管理层和执行人员的承诺和关注点。 如果不存在，你可以尽你的“一点”，但最终你会失败。 这就是许多组织在向敏捷转型时失败的原因，因为他们不愿意进行文化变革。
Firstly, Agile methodologies emphasize on these practices but they have not introduced them. They have been there in software development process well before Agile came in. So simply saying that if you are not using Scrum/XP/RUP then you are not following these practices is plain wrong. If you are a professional software development organization, these practices will exist in one form or other.
Secondly, whether you are an agile developer in a Waterfall organization or vice-versa, you can not do much, at-least not effectively or significantly. What development 'culture' the organization has is a function of the commitment and focus of the management and executive. If that does not exist, you can do your 'bit' but you will lose out in the end. That is the reason Agile fails in many organizations when they transition to it, because they are unwilling to make the cultural change.
我在一个伪敏捷组织中，以下是我对您提出的这些观点的回应：
I'm in a pseudo agile organisation and here's my responses to those points you raised:
说真的，如果你的组织像你描述的那样混乱和业余，我会在他们破产之前开始寻找另一份工作。 正如Martin Fowler 曾经打趣的
另一方面，如果你觉得他们可以改变，那么我会尝试在其他事情之前通过引入回顾来开始这种改变在你的名单上。 如果你能让人们互相交谈并开始识别正在发生的浪费，并且相关人员有足够的授权来听取反馈并做出改变，无论尝试性如何，你都会走在正确的轨道上。
您确定的所有其他实践都是消除特定类型浪费的技术 - 例如，编写单元测试，以减少项目后期修复缺陷的浪费。 通过举行回顾，您将了解这些浪费，并为人们提供一个空间，让他们决定是否愿意更专业地做事。
最后，这是关于自尊：你的自尊、你的同事以及整个组织的自尊。 你是否满足于一味地混日子，还是想尽力做好自己所做的事情？
祝你好运！
Seriously, if your organization is as chaotic and amateurish as you describe, I would start looking for another job before they go under. As Martin Fowler once quipped
If, on the other hand, you feel like they can change, then I'd make an attempt to start that change by introducing retrospectives before anything else on your list. If you can get people talking to each other and starting to identify the waste that goes on, and someone involved has sufficient mandate to listen to that feedback and make changes, however tentative, you'll be on the right track.
All of the other practices you've identified are techniques for eliminating particular types of waste - writing unit tests, for example, to reduce the waste of fixing defects later in the project. By holding retrospectives you'll shine a light on these wastes and give people a space do decide they might like to do things more professionally.
In the end, it's about self-respect: yours, your colleagues, and the organization as a whole. Are you satisfied to just muddle along the way things have always been, or do you want to try to be as good at what you do as you possibly can be?
Good luck!