At my first job, we had daily scrums, wrote automated tests, had automated builds, pair programmed, etc. We had been in the agile groove for several years. And for our efforts, we were rewarded with software that I wouldn't touch with 20ft pole. The quality of our product was atrocious: I'd describe as the piecemeal hacking of 100 amateur developers.
What went wrong:
The company I worked at had a notorious reputation for hiring entry-level developers for the lowest pay ($25-27K/yr was the norm), and frequently we'd outsource work to the lowest offshore bidder. I've heard that agile just doesn't work on inexperienced developers, and I think it showed through the code and our turnover rate.
No documentation of any sort. No functional documentation, no technical documentation, no requirements, no bug tracking. No one ever wrote things down on persistent media: all requirements and bugs were communicated by email, word of mouth, and psychic mindreading.
Lousy testing: our automated tests were invaluable, but QA and UAT testing was a disaster. Since we didn't have any formal requirements documentation, QA users didn't know what new functionality they were testing, so all QA consisted more or less of haphazard end-to-end testing. User acceptance testing was performed in production: we installed the product on our customers servers and reported bugs as they occurred in production.
Crisis-driven development: bugs were handled by using the "OMG WE HAVE TO FIX THIS AND REDEPLOY PRONTO! NOW NOW NOW! NO TIME FOR TESTING JUST FIX IT!" management methodology.
Although we did everything right and really adhered to agile principles by the book, the methodology failed harder than anything else I've ever seen.
In contrast, the company that I work for now uses a waterfall-like methodology, produces a few hundred pages of documentation for each project, has few automated tests but a sizable QA team. Interestingly, the quality of our product is through the roof, and the work environment is orders of magnitude above and beyond the other company.
I know many people have had the opposite experience. As is usually the case, methodologies are not a golden hammer --- you can probably start a successful project no matter what methodology you choose. In my experience on successful and unsuccessful projects, I get the feeling that methodology doesn't matter as much as environment: comfortable, happy developers and sane project managers are all it takes make a project work.
At my company, we made a wholesale switch to agile practices about 4 years ago when a new VP came in. This VP had experienced success with Agile in the past, and decided it was what we needed.
As it turns out, he was right. I was a developer at the time (albeit a somewhat junior one), and I loved the practices. Pair programming really aided knowledge transfer and prevented the formation of knowledge silos. Unit testing, test driven development, and test emphasis in general made for more robust code that wasn't over-engineered. No Big Design Up Front meant that instead of spending 6 months writing requirements documents (by which time the market had passed us by), we were prototyping and delivering real value to customers in a timely matter. Working closely with a customer surrogate (in our case, a technical product manager) greatly shortened cycle feedback time, which helped us deliver what the customer actually wanted.
Our organization had quite a few talented developers, but we were very prone to cowboy coding. A few developers didn't like the new practices ("What do you mean, write tests? I'm a developer!"), but generally everyone loved the changes. Defect rates went down, customer satisfaction rates went up, and our office became very well regarded in our company.
About a year ago I became a manager, and I heavily use Agile practices, incorporating some Lean principles as well (value stream analysis, waste elimination, kanban). Tightening up release cycles has been an ongoing activity, and my team now releases as often as possible (with quality!) - often every two weeks. We have no field reported defects from my team in the past year, and the sales people and product management love the shorter release cycles.
As a developer, Agile really increased my confidence in working with various areas of code (I now feel nervous whenever I'm changing anything in a package that DOESN'T have 100% unit test coverage!), taught me to be a more well-rounded programmer (thinking of test implications, business impacts, etc.), and helped me write simple, self-documenting code. As a manager, Agile and kanban gives me predictability, lower lead times, lower defect rates, and an empowered team. This is not theory, or speculation, or hand waving - our team morale, defect rate, customer satisfaction, and balance sheet have proven that Agile can do wonderful things for an organization.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This was a double-edged sword for my last site -- valuable was taken to mean 100% perfect and bug-free.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I still communicate with that site and just today, their rock-hard deadline date, they were given a requirement change. That was just the way things were there; it's almost as if they wanted failure.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The norm for many years was basically build and deploy daily, hourly, near real-time...
Business people and developers must work together daily throughout the project.
Some of the meetings/reviews with respect to this were hilarious. We were reprimanded for not working with the people (because they asked us not to because they were already working 9-10 hour days) and then for bothering them because they were busy.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Ahh, here's our problem... We had top-of-the-line PCs but the business side wasn't supportive. The positive morale essentially got beaten out of you after about a year or so... This also negates your micromanagement concern (if implemented correctly).
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This worked out well. Personally I prefer email because I hate taking notes.
Working software is the primary measure of progress.
No doubt here.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
I agree with this 100%; the problem with the last business team I worked with was the expectation of 30-hour days, 10-day weeks, and 400-day years was not a pace I agreed with.
Continuous attention to technical excellence and good design enhances agility.
This is where some developer morale & education was needed.
Simplicity--the art of maximizing the amount of work not done--is essential.
I love this one and it's long been one of my goals. However, there was a "if you're not typing, you're not working" attitude that was tough to overcome.
The best architectures, requirements, and designs emerge from self-organizing teams.
I agree with this about 90% -- my only caveat is that they must be well-educated and well-informed teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
We just failed here and it likely caused a lot of other problems we had. The business side was really good at saying "you need to do what we say needs to be done."
To wrap it up, if you're working somewhere where everyone is informed and on board with an Agile methodology, it should be a great place to work. When the goal is great software, momentum alone will carry any project.
From my personal experience, Agile methodology tends to create a huge technical debt in the long term, and while it might save you (as a business owner/management) a couple of bucks short term, in the long term it will come back and bite you. Whatever you do not fix now will eventually cost you many hours of work to fix at a much higher cost than it would have cost you to invest some more hours into the original problem.
Agile is always great from the point of view of beginners and management, but I do not know one experienced programmer who actually loves it. The whole point of Agile is to save development money for a company, it has nothing to do with actual product quality. In fact most of the methodology promotes bad code done quick over well-engineered code. The difference is that a few years down the road, you have to do the whole work all over again whereas the well-engineered code can last decades without corrections. Good programmers do not need Agile methodology most of the time.
We have a business logic library written 22 years ago here by a single team of 3 programmers using waterfall methodology, and that code hasn't needed a single correction since. Because it was tought properly, was well-engineered, and the three programmers took their time and were careful with their implementation. Agile methodology would instead ask of those three to do the strict minimum to make sure some ill-defined tests passed, and then wait until the next time you hit a wall to add some more duct tape code. It's a ridiculous way to work and goes against every engineer fiber in my body.
To this day I refuse to work in an Agile environment, because frankly I do not need it, and I do not need an employer who thinks I do need it.
Agile has worked awesomely for me as a Developer in my current environment. Here are some practices and why it seems to work so well:
Pair programming - This prevents anyone from feeling an individual ownership of the code. Pairs of developers tend to make better code than one person's "mad science" code that seems to happen if one person writes a bunch of code in isolation. This also allows for someone else to be brought in if someone goes away and that feature or enhancement has to get done while the person is away. Sometimes, one developer may think something will be great but if no one else can understand the code, it is useless to have unless it is perfect and futureproof which isn't likely.
Scrum - This creates both an accountability and communication so that each person knows what the other is doing. If someone wants to know how the sprint is going, just show up at the stand up. The standup is really simple in that it is just 3 questions: What did I do yesterday, what I am doing today and what would prevent me from getting that done?
Test-driven development - A variation on this is practiced where I work in that we generally try to have tests for most of the plumbing code we are writing to customize a CMS in the big project we are doing. This mindset can be tricky to get into though it does get easier as one practices it more.
YAGNI - The "You Aren't Gonna Need It" principle that can really be hard if you've been a perceptive programmer that generally puts in 101 things as a "Well, I might need this someday..." mindset. Another way to put this is a "Keep It Simple, Stupid" idea.
Sprints - The idea here just seems to prevent a sense of being overwhelmed as we are just working for 2 weeks on this or that, and don't look too far forward as it may well change.
Demos - Showing off what we have done, getting feedback on what is good and what isn't is crucial for getting things better and having a mindset that we want "continuous improvement" in the project and what is good enough today, won't be good enough tomorrow and get better at what we do.
IPM, Retrospectives - The ability to look back at what was done in retrospectives is useful for venting frustrations, celebrating things working well and finding ways to address pain points. IPM is where we determine our future for the next sprint in terms of what will be the goals and how long do we think various things will take by using a couple of different estimation tools, one for points on "epics" as we call them and the other for hours on an individual task or card which is part of a story that is something between the epic and a small piece of work.
Storywall and user stories - Now this low tech tool since it is just a few whiteboards, with dividers and post its provides some structure to things. We have lanes for each of the epics and various columns for states of work: Backlog, in development, on dev, or on test. There are also places for the task backlog, blocked cards, questions, standards and practices and a few other things that may be useful for managers to see to get an overview on the current status if they want more of a bigger picture than what they would get at standup.
Broken windows/technical debt/tasks - These are similar in some respects and are useful as a way to illustrate that quality matters,i.e. we don't want broken windows that can be easily explained in non-technical terms by either using a house in a neighbourhood or the New York Subway sytem as starting points. Technical debt being something that doesn't immediately add business value that is sometimes an important thing to use to prevent some problems as there may be problems with a particular architecture and so part of a sprint may be spent doing a re-arch that has to be communicated so that if there is a sprint with little to demo this is why.
I don't know if the idea of a "self-organizing" or "self-managing" team is part of Agile, but it has been a bit of a challenge for me to have enough faith and trust in my co-workers that things will work out fine. The professionals that are the rest of my team know what has to be done, are reasonable, honest people with integrity to just get the work done and not be jerks about getting things done. There aren't egos or bad attitudes which really do help foster building a team.
Agile hasn't worked for me, the main reason being that the systems I usually develop need a well-defined and well-thought architecture, which is hardly realisable by an agile approach. Agile approaches tend to write as little code as necessary to pass the applicable tests, and thus to grow the system organically. This can be nice from many perspectives, but it wreaks havoc from the architectural viewpoint.
Agile is not a methodology, it is a subset of methodologies that have a common set of goals, and more often then not those methodologies have wildly varying results based on team makeup, corporate culture, and implementation.
Off the top of my head, purely developer agile practices would include pair programming, TDD, user stories over specs, the assumption that all code is going to be refactored several times (although this is part of TDD) and code reviews more then anything. Things that impact us are daily standups, being engaged with users regularly and directly, postmortem introspections, and very tight development cycles.
I'm a developer and a manager at the same time, so I either have special insight or my opinion is totally invalid. ;)
I will say that Agile means a lot of things. It's actually a whole family of methodologies and guidelines at this point.
Exposing yourself to all these interesting ideas is really the thing. As a manager, it's very hard for me to decree that a whole team suddenly adopt a whole methodology, but if they see me constantly trying to improve every aspect of my game, I think they appreciate that. And hopefully, if they like what they see, they follow my example.
I've managed to slowly implement a bunch of things from Scrum without (hopefully) coming off as a tool. Burn down reports, stand-up meetings, and story cards on the whiteboard have really made us better at shipping software. For instance, on any project tasks are constantly being done ahead of schedule or late. In a really big project, it can become very difficult to tell what that's doing to your ship date. With burn down reports, I can tell what a slip does to our ship date, and if we need to just start cutting features in order to meet a deadline.
That's more of a management thing, but the other devs here care about it because it might mean they get to keep their jobs or avoid a death march. :)
But it's not just management stuff. There's tons in Agile about best practices for source control, unit testing, etc. Just good solid best practices. As an industry, we are pretty terrible about mentoring, so it's good that this information is out there.
From the developers perspective I think it works well. In my point of view agile techniques have in common that the loop between defining the task, working on the task and getting feedback from that task is a very small one as compared to a non-agile approaches.
Take TDD as an example: Code the test, red bar, code the functionality, green bar, refactor, red bar, fix, green bar.
From the managers perspective this faster feedback loop is also true: Daily meeting one, status green, daily meeting two, status yellow, countermeasures / re-assign ressources, daily meeting three, status green.
Immediate feedback and knowing where you are heading gives a feeling of safety.
In the so called 'traditional team', Agile development would increase the visibility of individual developers to management. That would probably allow managers and architects to plan their work better. Ofcourse that could be interpreted as micromanagement.
But from an organizational perspective, if it produces results, who cares.
I guess what makes an "agile" project agile, is the methodology: "Design for today not for tomorrow".
For any not life-critical software systems this is a way to keep programmers coding in stead of discussing ages about design. Please note that design is not scrapped, it is just done in smaller and therefore more overseeable chunks.
All other techniques that are associated with agile, like pair programming, are more borrowed ideas that could also be used effectively in any other methodology.
Now, does this technique 'work'? Yes! If applied correctly, the technique promotes that the software product will be ready for shipping at any time to react to competition.
On the other hand, because programmers are feeling they are coding more, they are generally happier. And they are less irritated by writing specs because this phase is inherently always small.
But again, if you know exactly what your product is going to be and especially if it is life-critical like the space shuttle, agile development is not what you want.
Nearly every management is aware of "Agile" by now: It's this thing, you know? Alone by your initial question I would assume that something is really going wrong. I really recommend you reading a book like Practices of an Agile Developer (as the title suggests - it's about what's in for you).
Some managers read a book and then will know what agile is all about. They are telling you what to do and everything is fine, isn't it?
If you look around, there are a lot of developers (in Agile companies) who can't tell you within a second what the purpose of a stand-up is - and that's an issue. If you (and maybe even nobody else) don't know the why the StandUp won't make things better.
Take a look at time tracking (and time estimation) - there are some managers who think it's about measuring how much work you do: Hey, you have a 40h contract but the time tracking tool says that you have only be working for 38h this week! That's not how it was meant to be used.
The only thing you can do about that: you need to learn what agile methods are out there. Mediocre managers will pick the ones they find interesting. Good managers will grasp the why and not only choose the methods for their direct benefit - but also those which will make the team more happy / efficient / teamish (Team vs Workgroup).
P.S. Something you really need to take care of: In agile there is no place for slackers. Everybody has to do stuff on their own. You have to put personal interest into the success of the product. If you don't do things on your own, somebody will tell you what to do (and then there's micromanagement).
Before there was "Agile Programming" there were equivalent largely unrecognized methodologies. I thought these were called incremental prototyping but apparently this has been split into that and evolutionary prototyping.
I suspect that many or most of the successful systems were so constructed. Just because the methodology grew a new name doesn't mean that it suddenly appeared.
It's just that Waterfall and other broken management techniques that got all the press.
I say Agile works. I say it's the only thing that ever worked.
发布评论
评论（13）
在我的第一份工作中，我们每天进行 Scrum，编写自动化测试，进行自动化构建，结对编程等。我们已经处于敏捷状态好几年了。由于我们的努力，我们获得了我用 20 英尺长的杆子都不敢碰的软件作为回报。我们产品的质量非常糟糕：我将其描述为 100 名业余开发人员的零碎黑客攻击。
问题出在哪里：
我工作的公司因以最低工资（每年 25-27,000 美元）雇用入门级开发人员而臭名昭著，而且我们经常将工作外包给出价最低的海外投标人。我听说敏捷不适用于缺乏经验的开发人员，我认为这一点通过代码和我们的流动率就体现出来了。
没有任何类型的文档。没有功能文档，没有技术文档，没有需求，没有错误跟踪。没有人在持久性媒体上写下东西：所有需求和错误都是通过电子邮件、口口相传和心灵读心来传达的。
糟糕的测试：我们的自动化测试非常宝贵，但 QA 和 UAT 测试却是一场灾难。由于我们没有任何正式的需求文档，QA 用户不知道他们正在测试什么新功能，因此所有 QA 或多或少都包含随意的端到端测试。用户验收测试是在生产中进行的：我们将产品安装在客户服务器上，并报告生产中发生的错误。
危机驱动的开发：错误是通过使用“天啊，我们必须修复这个并立即重新部署！现在现在现在！没有时间测试，只需修复它！”来处理的。 。
尽管我们做的每件事都是正确的，并且真正遵守了书本上的敏捷原则，但这种方法比我见过的任何方法都失败得更严重。
相比之下，我现在工作的公司使用类似瀑布的方法，为每个项目生成几百页文档，几乎没有自动化测试，但有一个相当大的 QA 团队。有趣的是，我们的产品质量非常高，工作环境也比其他公司高出几个数量级。
我知道很多人都有过相反的经历。通常情况下，方法论并不是金锤子——无论您选择哪种方法论，您都可以启动一个成功的项目。根据我成功和不成功项目的经验，我觉得方法并不重要，环境更重要：舒适、快乐的开发人员和理智的项目经理就足以使项目成功。
At my first job, we had daily scrums, wrote automated tests, had automated builds, pair programmed, etc. We had been in the agile groove for several years. And for our efforts, we were rewarded with software that I wouldn't touch with 20ft pole. The quality of our product was atrocious: I'd describe as the piecemeal hacking of 100 amateur developers.
What went wrong:
The company I worked at had a notorious reputation for hiring entry-level developers for the lowest pay ($25-27K/yr was the norm), and frequently we'd outsource work to the lowest offshore bidder. I've heard that agile just doesn't work on inexperienced developers, and I think it showed through the code and our turnover rate.
No documentation of any sort. No functional documentation, no technical documentation, no requirements, no bug tracking. No one ever wrote things down on persistent media: all requirements and bugs were communicated by email, word of mouth, and psychic mindreading.
Lousy testing: our automated tests were invaluable, but QA and UAT testing was a disaster. Since we didn't have any formal requirements documentation, QA users didn't know what new functionality they were testing, so all QA consisted more or less of haphazard end-to-end testing. User acceptance testing was performed in production: we installed the product on our customers servers and reported bugs as they occurred in production.
Crisis-driven development: bugs were handled by using the "OMG WE HAVE TO FIX THIS AND REDEPLOY PRONTO! NOW NOW NOW! NO TIME FOR TESTING JUST FIX IT!" management methodology.
Although we did everything right and really adhered to agile principles by the book, the methodology failed harder than anything else I've ever seen.
In contrast, the company that I work for now uses a waterfall-like methodology, produces a few hundred pages of documentation for each project, has few automated tests but a sizable QA team. Interestingly, the quality of our product is through the roof, and the work environment is orders of magnitude above and beyond the other company.
I know many people have had the opposite experience. As is usually the case, methodologies are not a golden hammer --- you can probably start a successful project no matter what methodology you choose. In my experience on successful and unsuccessful projects, I get the feeling that methodology doesn't matter as much as environment: comfortable, happy developers and sane project managers are all it takes make a project work.
在我的公司，大约 4 年前，当一位新副总裁上任时，我们全面转向敏捷实践。这位副总裁过去在敏捷方面取得了成功，并认为这就是我们所需要的。
事实证明，他是对的。当时我是一名开发人员（尽管还比较初级），我喜欢这些实践。结对编程确实有助于知识转移并防止知识孤岛的形成。单元测试、测试驱动开发和测试重点通常可以使代码更加健壮，而不会过度设计。无需预先进行大型设计意味着我们无需花费 6 个月的时间来编写需求文档（此时市场已经超越了我们），而是进行原型设计并及时为客户提供真正的价值。与客户代理人（在我们的例子中是技术产品经理）密切合作大大缩短了周期反馈时间，这有助于我们交付客户真正想要的东西。
我们的组织拥有不少才华横溢的开发人员，但我们很容易进行牛仔编码。一些开发人员不喜欢新的做法（“编写测试是什么意思？我是开发人员！”），但总的来说每个人都喜欢这些变化。缺陷率下降了，客户满意度上升了，我们的办公室在公司中得到了很好的评价。
大约一年前，我成为一名经理，我大量使用敏捷实践，并结合了一些精益原则（价值流分析、消除浪费、看板）。收紧发布周期是一项持续的活动，我的团队现在尽可能频繁地发布（高质量！） - 通常每两周一次。在过去的一年里，我们的团队没有现场报告任何缺陷，销售人员和产品管理人员喜欢较短的发布周期。
作为一名开发人员，敏捷确实增加了我处理各个代码领域的信心（现在，每当我更改软件包中没有 100% 单元测试覆盖率的任何内容时，我都会感到紧张！），教会我成为一个更好的人- 全面的程序员（考虑测试影响、业务影响等），并帮助我编写简单的、自记录的代码。作为一名经理，敏捷和看板为我提供了可预测性、更短的交付周期、更低的缺陷率以及一支强大的团队。这不是理论、猜测或挥手——我们的团队士气、缺陷率、客户满意度和资产负债表已经证明敏捷可以为组织带来美妙的事情。
At my company, we made a wholesale switch to agile practices about 4 years ago when a new VP came in. This VP had experienced success with Agile in the past, and decided it was what we needed.
As it turns out, he was right. I was a developer at the time (albeit a somewhat junior one), and I loved the practices. Pair programming really aided knowledge transfer and prevented the formation of knowledge silos. Unit testing, test driven development, and test emphasis in general made for more robust code that wasn't over-engineered. No Big Design Up Front meant that instead of spending 6 months writing requirements documents (by which time the market had passed us by), we were prototyping and delivering real value to customers in a timely matter. Working closely with a customer surrogate (in our case, a technical product manager) greatly shortened cycle feedback time, which helped us deliver what the customer actually wanted.
Our organization had quite a few talented developers, but we were very prone to cowboy coding. A few developers didn't like the new practices ("What do you mean, write tests? I'm a developer!"), but generally everyone loved the changes. Defect rates went down, customer satisfaction rates went up, and our office became very well regarded in our company.
About a year ago I became a manager, and I heavily use Agile practices, incorporating some Lean principles as well (value stream analysis, waste elimination, kanban). Tightening up release cycles has been an ongoing activity, and my team now releases as often as possible (with quality!) - often every two weeks. We have no field reported defects from my team in the past year, and the sales people and product management love the shorter release cycles.
As a developer, Agile really increased my confidence in working with various areas of code (I now feel nervous whenever I'm changing anything in a package that DOESN'T have 100% unit test coverage!), taught me to be a more well-rounded programmer (thinking of test implications, business impacts, etc.), and helped me write simple, self-documenting code. As a manager, Agile and kanban gives me predictability, lower lead times, lower defect rates, and an empowered team. This is not theory, or speculation, or hand waving - our team morale, defect rate, customer satisfaction, and balance sheet have proven that Agile can do wonderful things for an organization.
根据我在尝试过的网站的经验来评论敏捷宣言的原则 > 它。
对于我的上一个网站来说，这是一把双刃剑——有价值意味着 100% 完美且无错误。
我仍然与该网站进行沟通，就在今天，他们的截止日期，他们收到了要求变更。事情就是这样。就好像他们想要失败一样。
多年来的规范基本上是每天、每小时、近乎实时地构建和部署......
与此相关的一些会议/评论非常搞笑。我们因不与人们一起工作而受到谴责（因为他们要求我们不要这样做，因为他们已经每天工作 9-10 小时），然后因为他们很忙而打扰他们。
啊，我们的问题是……我们拥有顶级的个人电脑，但业务方面并不支持。大约一年左右后，积极的士气基本上就被打败了……这也否定了你对微观管理的担忧（如果实施得当）。
这效果很好。我个人更喜欢电子邮件，因为我讨厌做笔记。
毫无疑问这里。
我100%同意这一点；与我合作的上一个业务团队的问题是，每天 30 小时、每周 10 天、每年 400 天的工作节奏并不是我所同意的。
这就是一些开发人员士气和信心的所在。需要教育。
我喜欢这个，这一直是我的目标之一。然而，“如果你不打字，你就没有工作”的态度很难克服。
我大约 90% 同意这一点——我唯一的警告是，他们必须是受过良好教育、消息灵通的团队。
我们只是在这里失败了，这可能会导致我们遇到很多其他问题。业务方面非常擅长说“你需要做我们说需要做的事情”。
总而言之，如果您在一个每个人都了解情况并采用敏捷方法的地方工作，那么它应该是一个很好的工作场所。当目标是伟大的软件时，光靠动力就能推动任何项目。
To comment on the Principles of the Agile Manifesto from my experience at a site that tried it.
This was a double-edged sword for my last site -- valuable was taken to mean 100% perfect and bug-free.
I still communicate with that site and just today, their rock-hard deadline date, they were given a requirement change. That was just the way things were there; it's almost as if they wanted failure.
The norm for many years was basically build and deploy daily, hourly, near real-time...
Some of the meetings/reviews with respect to this were hilarious. We were reprimanded for not working with the people (because they asked us not to because they were already working 9-10 hour days) and then for bothering them because they were busy.
Ahh, here's our problem... We had top-of-the-line PCs but the business side wasn't supportive. The positive morale essentially got beaten out of you after about a year or so... This also negates your micromanagement concern (if implemented correctly).
This worked out well. Personally I prefer email because I hate taking notes.
No doubt here.
I agree with this 100%; the problem with the last business team I worked with was the expectation of 30-hour days, 10-day weeks, and 400-day years was not a pace I agreed with.
This is where some developer morale & education was needed.
I love this one and it's long been one of my goals. However, there was a "if you're not typing, you're not working" attitude that was tough to overcome.
I agree with this about 90% -- my only caveat is that they must be well-educated and well-informed teams.
We just failed here and it likely caused a lot of other problems we had. The business side was really good at saying "you need to do what we say needs to be done."
To wrap it up, if you're working somewhere where everyone is informed and on board with an Agile methodology, it should be a great place to work. When the goal is great software, momentum alone will carry any project.
从我个人的经验来看，从长远来看，敏捷方法往往会造成巨大的技术债务，虽然它可能会在短期内为您（作为企业主/管理层）节省几块钱，但从长远来看，它会回来并咬人。你。无论你现在不解决什么问题，最终都会花费你很多时间来修复，其成本比你投入更多时间解决原始问题所花费的成本要高得多。
从初学者和管理人员的角度来看，敏捷总是很棒的，但我不知道有哪个经验丰富的程序员真正喜欢它。敏捷的全部意义在于为公司节省开发资金，与实际的产品质量无关。事实上，大多数方法论都提倡比设计良好的代码更快地完成糟糕的代码。不同之处在于，几年后，您必须重新完成整个工作，而精心设计的代码可以持续数十年而不需要更正。优秀的程序员大多数时候并不需要敏捷方法。
我们有一个 22 年前由 3 名程序员组成的团队使用瀑布方法编写的业务逻辑库，从那以后该代码就不需要进行任何更正。因为它处理得当，设计精良，而且三位程序员花时间、小心地实施。相反，敏捷方法会要求这三个人执行严格的最低限度，以确保通过一些定义不明确的测试，然后等到下次碰壁时再添加更多的胶带代码。这是一种荒谬的工作方式，违背了我体内的每一条工程师纤维。
直到今天，我拒绝在敏捷环境中工作，因为坦白说我不需要它，我也不需要一个认为我确实需要它的雇主。
From my personal experience, Agile methodology tends to create a huge technical debt in the long term, and while it might save you (as a business owner/management) a couple of bucks short term, in the long term it will come back and bite you. Whatever you do not fix now will eventually cost you many hours of work to fix at a much higher cost than it would have cost you to invest some more hours into the original problem.
Agile is always great from the point of view of beginners and management, but I do not know one experienced programmer who actually loves it. The whole point of Agile is to save development money for a company, it has nothing to do with actual product quality. In fact most of the methodology promotes bad code done quick over well-engineered code. The difference is that a few years down the road, you have to do the whole work all over again whereas the well-engineered code can last decades without corrections. Good programmers do not need Agile methodology most of the time.
We have a business logic library written 22 years ago here by a single team of 3 programmers using waterfall methodology, and that code hasn't needed a single correction since. Because it was tought properly, was well-engineered, and the three programmers took their time and were careful with their implementation. Agile methodology would instead ask of those three to do the strict minimum to make sure some ill-defined tests passed, and then wait until the next time you hit a wall to add some more duct tape code. It's a ridiculous way to work and goes against every engineer fiber in my body.
To this day I refuse to work in an Agile environment, because frankly I do not need it, and I do not need an employer who thinks I do need it.
在我当前的环境中，作为一名开发人员，敏捷对我来说非常有效。以下是一些实践以及为什么它看起来如此有效：
结对编程 - 这可以防止任何人感受到代码的个人所有权。成对的开发人员往往会编写出比一个人的“疯狂科学”代码更好的代码，如果一个人单独编写一堆代码，似乎就会发生这种情况。如果有人离开，并且必须在该人离开时完成该功能或增强功能，这也允许其他人加入。有时，一个开发人员可能会认为某件事会很棒，但如果没有其他人能够理解代码，那么拥有它也是没有用的，除非它是完美的且面向未来的，而这种情况不太可能发生。
Scrum - 这创建了责任和沟通，以便每个人都知道对方在做什么。如果有人想知道冲刺进展如何，只需出现在站立会议上即可。站会非常简单，因为只有 3 个问题：我昨天做了什么，今天我在做什么，以及什么会阻止我完成这件事？
测试驱动开发 - 在我工作的地方，我们通常会尝试对我们正在编写的大部分管道代码进行测试，以在我们正在进行的大型项目中定制 CMS。这种思维方式可能很难进入，但随着实践的增多，它确实会变得更容易。
YAGNI - “你不会需要它”原则，如果你是一个有洞察力的程序员，通常会以“好吧，有一天我可能需要这个......”的心态放入 101 件事，那么这个原则真的很难。 。另一种表达方式是“保持简单，愚蠢”的想法。
冲刺 - 这里的想法似乎只是为了防止一种不知所措的感觉，因为我们只是在这个或那个上工作了 2 周，并且不要看得太远，因为它很可能会发生变化。
演示 - 展示我们所做的事情，获得关于什么是好的、什么是不好的反馈，这对于让事情变得更好至关重要，并有一种我们希望项目“持续改进”以及今天什么已经足够好的心态，明天还不够好，并在我们所做的事情上做得更好。
IPM，回顾 - 在回顾中回顾所做的事情的能力对于发泄挫败感、庆祝运作良好的事情以及找到解决痛点的方法很有用。 IPM 是我们通过使用几种不同的估算工具来确定下一个冲刺的未来，包括目标是什么以及我们认为各种事情需要多长时间，其中一个用于我们所说的“史诗”点，另一个则花费数小时完成单个任务或卡片，该任务或卡片是故事的一部分，介于史诗和小作品之间。
故事墙和用户故事 - 现在这个低技术工具，因为它只是一些白板，带有分隔符和帖子，它为事物提供了一些结构。我们为每个史诗都有通道，并为工作状态提供各种列：待办事项、开发中、开发中或测试中。还有一些地方可以存放任务积压、被阻止的卡片、问题、标准和实践以及其他一些内容，如果经理想要了解比他们想要的更大的情况，可以查看这些内容来了解当前状态的概述。站起来。
破损的窗户/技术债务/任务 - 这些在某些方面是相似的，并且可以作为说明质量问题的有用方法，即我们不希望可以通过使用非技术术语轻松解释破损的窗户附近的房子或纽约地铁系统作为起点。技术债务不会立即增加业务价值，有时是防止某些问题的重要手段，因为特定架构可能存在问题，因此冲刺的一部分可能会花在重新架构上，而重新架构必须进行沟通，以便如果冲刺几乎没有演示，这就是原因。
我不知道“自组织”或“自管理”团队的想法是否是敏捷的一部分，但对我的同事有足够的信心和信任，这对我来说是一个挑战。事情会顺利的。我团队中的其他专业人士知道必须做什么，他们都是通情达理、诚实的人，正直地完成工作，而不是急于完成工作。不存在真正有助于促进团队建设的自负或不良态度。
Agile has worked awesomely for me as a Developer in my current environment. Here are some practices and why it seems to work so well:
Pair programming - This prevents anyone from feeling an individual ownership of the code. Pairs of developers tend to make better code than one person's "mad science" code that seems to happen if one person writes a bunch of code in isolation. This also allows for someone else to be brought in if someone goes away and that feature or enhancement has to get done while the person is away. Sometimes, one developer may think something will be great but if no one else can understand the code, it is useless to have unless it is perfect and futureproof which isn't likely.
Scrum - This creates both an accountability and communication so that each person knows what the other is doing. If someone wants to know how the sprint is going, just show up at the stand up. The standup is really simple in that it is just 3 questions: What did I do yesterday, what I am doing today and what would prevent me from getting that done?
Test-driven development - A variation on this is practiced where I work in that we generally try to have tests for most of the plumbing code we are writing to customize a CMS in the big project we are doing. This mindset can be tricky to get into though it does get easier as one practices it more.
YAGNI - The "You Aren't Gonna Need It" principle that can really be hard if you've been a perceptive programmer that generally puts in 101 things as a "Well, I might need this someday..." mindset. Another way to put this is a "Keep It Simple, Stupid" idea.
Sprints - The idea here just seems to prevent a sense of being overwhelmed as we are just working for 2 weeks on this or that, and don't look too far forward as it may well change.
Demos - Showing off what we have done, getting feedback on what is good and what isn't is crucial for getting things better and having a mindset that we want "continuous improvement" in the project and what is good enough today, won't be good enough tomorrow and get better at what we do.
IPM, Retrospectives - The ability to look back at what was done in retrospectives is useful for venting frustrations, celebrating things working well and finding ways to address pain points. IPM is where we determine our future for the next sprint in terms of what will be the goals and how long do we think various things will take by using a couple of different estimation tools, one for points on "epics" as we call them and the other for hours on an individual task or card which is part of a story that is something between the epic and a small piece of work.
Storywall and user stories - Now this low tech tool since it is just a few whiteboards, with dividers and post its provides some structure to things. We have lanes for each of the epics and various columns for states of work: Backlog, in development, on dev, or on test. There are also places for the task backlog, blocked cards, questions, standards and practices and a few other things that may be useful for managers to see to get an overview on the current status if they want more of a bigger picture than what they would get at standup.
Broken windows/technical debt/tasks - These are similar in some respects and are useful as a way to illustrate that quality matters,i.e. we don't want broken windows that can be easily explained in non-technical terms by either using a house in a neighbourhood or the New York Subway sytem as starting points. Technical debt being something that doesn't immediately add business value that is sometimes an important thing to use to prevent some problems as there may be problems with a particular architecture and so part of a sprint may be spent doing a re-arch that has to be communicated so that if there is a sprint with little to demo this is why.
I don't know if the idea of a "self-organizing" or "self-managing" team is part of Agile, but it has been a bit of a challenge for me to have enough faith and trust in my co-workers that things will work out fine. The professionals that are the rest of my team know what has to be done, are reasonable, honest people with integrity to just get the work done and not be jerks about getting things done. There aren't egos or bad attitudes which really do help foster building a team.
敏捷对我来说并不奏效，主要原因是我通常开发的系统需要一个定义良好、经过深思熟虑的架构，而这是敏捷方法很难实现的。敏捷方法倾向于编写尽可能少的代码来通过适用的测试，从而有机地发展系统。从许多角度来看，这可能很好，但从架构角度来看，它会造成严重破坏。
Agile hasn't worked for me, the main reason being that the systems I usually develop need a well-defined and well-thought architecture, which is hardly realisable by an agile approach. Agile approaches tend to write as little code as necessary to pass the applicable tests, and thus to grow the system organically. This can be nice from many perspectives, but it wreaks havoc from the architectural viewpoint.
敏捷不是一种方法论，它是具有一组共同目标的方法论的子集，而且通常情况下，这些方法论不会根据团队构成、企业文化和实施而产生截然不同的结果。
在我的脑海中，纯粹的开发人员敏捷实践将包括结对编程、TDD、规范上的用户故事、所有代码都将被重构多次的假设（尽管这是 TDD 的一部分）以及代码审查。影响我们的事情包括日常站立、定期直接与用户互动、事后反思以及非常紧张的开发周期。
Agile is not a methodology, it is a subset of methodologies that have a common set of goals, and more often then not those methodologies have wildly varying results based on team makeup, corporate culture, and implementation.
Off the top of my head, purely developer agile practices would include pair programming, TDD, user stories over specs, the assumption that all code is going to be refactored several times (although this is part of TDD) and code reviews more then anything. Things that impact us are daily standups, being engaged with users regularly and directly, postmortem introspections, and very tight development cycles.
我同时是一名开发人员和一名经理，所以我要么有特殊的见解，要么我的意见完全无效。 ;)
我想说敏捷意味着很多东西。目前，它实际上是一整套方法和指南。
让自己接触所有这些有趣的想法确实很重要。作为一名经理，我很难下令整个团队突然采用一套完整的方法，但如果他们看到我不断努力改进比赛的各个方面，我认为他们会欣赏这一点。希望如果他们喜欢他们所看到的，他们会效仿我的榜样。
我已经成功地慢慢地从 Scrum 中实现了很多东西，但没有（希望）成为一个工具。燃尽报告、站立会议和白板上的故事卡确实使我们能够更好地交付软件。例如，在任何项目中，任务总是提前或延迟完成。在一个非常大的项目中，很难判断它对您的发货日期有何影响。通过燃尽报告，我可以知道一个错误对我们的发货日期有何影响，以及我们是否需要开始削减功能以赶上最后期限。
这更多的是管理问题，但这里的其他开发人员关心它，因为这可能意味着他们可以保住工作或避免死亡行军。 :)
但这不仅仅是管理方面的事情。敏捷中有大量关于源代码控制、单元测试等最佳实践的内容。只是良好可靠的最佳实践。作为一个行业，我们在指导方面非常糟糕，所以有这些信息是件好事。
I'm a developer and a manager at the same time, so I either have special insight or my opinion is totally invalid. ;)
I will say that Agile means a lot of things. It's actually a whole family of methodologies and guidelines at this point.
Exposing yourself to all these interesting ideas is really the thing. As a manager, it's very hard for me to decree that a whole team suddenly adopt a whole methodology, but if they see me constantly trying to improve every aspect of my game, I think they appreciate that. And hopefully, if they like what they see, they follow my example.
I've managed to slowly implement a bunch of things from Scrum without (hopefully) coming off as a tool. Burn down reports, stand-up meetings, and story cards on the whiteboard have really made us better at shipping software. For instance, on any project tasks are constantly being done ahead of schedule or late. In a really big project, it can become very difficult to tell what that's doing to your ship date. With burn down reports, I can tell what a slip does to our ship date, and if we need to just start cutting features in order to meet a deadline.
That's more of a management thing, but the other devs here care about it because it might mean they get to keep their jobs or avoid a death march. :)
But it's not just management stuff. There's tons in Agile about best practices for source control, unit testing, etc. Just good solid best practices. As an industry, we are pretty terrible about mentoring, so it's good that this information is out there.
从开发者的角度来看，我认为它运作良好。在我看来，敏捷技术的共同点是，与非敏捷方法相比，定义任务、处理任务和从任务获取反馈之间的循环非常小。
以 TDD 为例：编写测试代码，红条，编写功能代码，绿条，重构，红条，修复，绿条。
从管理者的角度来看，这种更快的反馈循环也是如此：每日会议一，状态绿色，每日会议二，状态黄色，对策/重新分配资源，每日会议三，状态绿色。
即时反馈并知道您要去哪里会给您一种安全感。
From the developers perspective I think it works well. In my point of view agile techniques have in common that the loop between defining the task, working on the task and getting feedback from that task is a very small one as compared to a non-agile approaches.
Take TDD as an example: Code the test, red bar, code the functionality, green bar, refactor, red bar, fix, green bar.
From the managers perspective this faster feedback loop is also true: Daily meeting one, status green, daily meeting two, status yellow, countermeasures / re-assign ressources, daily meeting three, status green.
Immediate feedback and knowing where you are heading gives a feeling of safety.
在所谓的“传统团队”中，敏捷开发将提高单个开发人员对管理层的可见性。这可能会让经理和建筑师更好地规划他们的工作。当然，这可以解释为微观管理。
但从组织的角度来看，如果它产生了结果，谁在乎呢。
In the so called 'traditional team', Agile development would increase the visibility of individual developers to management. That would probably allow managers and architects to plan their work better. Ofcourse that could be interpreted as micromanagement.
But from an organizational perspective, if it produces results, who cares.
我想是什么让“敏捷”项目变得敏捷，是因为方法论：“为今天而不是为明天设计”。
对于任何不是生命攸关的软件系统，这是一种让程序员继续编码而不是讨论设计问题的方法。请注意，设计并没有被废弃，它只是被分成更小的、因此更容易监督的块。
与敏捷相关的所有其他技术（例如结对编程）都是借用的想法，也可以在任何其他方法中有效使用。
现在，这项技术“有效”吗？是的！如果应用得当，该技术可以促使软件产品随时准备好交付以应对竞争。
另一方面，由于程序员感觉自己编写的代码更多，因此他们通常更快乐。而且他们对编写规范不太恼火，因为这个阶段本质上总是很小。
但同样，如果您确切地知道您的产品将是什么，特别是如果它像航天飞机一样关系到生命，那么敏捷开发就不是您想要的。
I guess what makes an "agile" project agile, is the methodology: "Design for today not for tomorrow".
For any not life-critical software systems this is a way to keep programmers coding in stead of discussing ages about design. Please note that design is not scrapped, it is just done in smaller and therefore more overseeable chunks.
All other techniques that are associated with agile, like pair programming, are more borrowed ideas that could also be used effectively in any other methodology.
Now, does this technique 'work'? Yes! If applied correctly, the technique promotes that the software product will be ready for shipping at any time to react to competition.
On the other hand, because programmers are feeling they are coding more, they are generally happier. And they are less irritated by writing specs because this phase is inherently always small.
But again, if you know exactly what your product is going to be and especially if it is life-critical like the space shuttle, agile development is not what you want.
现在几乎每个管理层都意识到了“敏捷”：就是这个东西，你知道吗？仅凭你最初的问题，我就认为确实出了问题。我真的推荐你读一本像敏捷开发人员的实践< /a> （正如标题所暗示的 - 这是关于你适合什么的）。
有些经理读了一本书，然后就会知道敏捷到底是什么。他们告诉你该怎么做，一切都很好，不是吗？
如果你环顾四周，就会发现很多开发人员（在敏捷公司中）无法在一秒钟内告诉你站会的目的是什么 - 这就是一个问题。如果您（甚至可能没有其他人）不知道为什么站会不会让事情变得更好。
看看时间跟踪（和时间估算） - 有些经理认为这是衡量您做了多少工作：嘿，您有 40 小时合同，但时间跟踪工具显示您本周只工作了 38 小时！ 这不是它的用途。
对此你唯一能做的就是：你需要了解现有的敏捷方法。平庸的管理者会选择他们感兴趣的。优秀的管理者会抓住原因，不仅选择适合他们直接利益的方法，而且还会选择那些能让团队更加快乐/高效/有团队精神的方法（团队与工作组）。
PS 你真正需要注意的事情：敏捷中没有偷懒者的容身之地。每个人都必须自己做事。你必须将个人兴趣投入到产品的成功中。如果你不自己做事，有人会告诉你该怎么做（然后是微观管理）。
Nearly every management is aware of "Agile" by now: It's this thing, you know? Alone by your initial question I would assume that something is really going wrong. I really recommend you reading a book like Practices of an Agile Developer (as the title suggests - it's about what's in for you).
Some managers read a book and then will know what agile is all about. They are telling you what to do and everything is fine, isn't it?
If you look around, there are a lot of developers (in Agile companies) who can't tell you within a second what the purpose of a stand-up is - and that's an issue. If you (and maybe even nobody else) don't know the why the StandUp won't make things better.
Take a look at time tracking (and time estimation) - there are some managers who think it's about measuring how much work you do: Hey, you have a 40h contract but the time tracking tool says that you have only be working for 38h this week! That's not how it was meant to be used.
The only thing you can do about that: you need to learn what agile methods are out there. Mediocre managers will pick the ones they find interesting. Good managers will grasp the why and not only choose the methods for their direct benefit - but also those which will make the team more happy / efficient / teamish (Team vs Workgroup).
P.S. Something you really need to take care of: In agile there is no place for slackers. Everybody has to do stuff on their own. You have to put personal interest into the success of the product. If you don't do things on your own, somebody will tell you what to do (and then there's micromanagement).
敏捷真的有效吗？ “是。”
在“敏捷编程”出现之前，存在着相当大的未被认可的方法。我认为这些被称为“增量原型”，但显然这已分为“渐进原型”和“进化原型”。
我怀疑许多或大部分成功的系统都是这样构建的。仅仅因为该方法有了新的名称并不意味着它突然出现。
只是瀑布和其他失败的管理技术引起了所有媒体的关注。
我说敏捷有效。
我说这是唯一有效的方法。
Has Agile really worked? "Yes."
Before there was "Agile Programming" there were equivalent largely unrecognized methodologies. I thought these were called incremental prototyping but apparently this has been split into that and evolutionary prototyping.
I suspect that many or most of the successful systems were so constructed. Just because the methodology grew a new name doesn't mean that it suddenly appeared.
It's just that Waterfall and other broken management techniques that got all the press.
I say Agile works.
I say it's the only thing that ever worked.