TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Less is more agile

282 点作者 beny23超过 2 年前

36 条评论

twawaaay超过 2 年前
There is a whole industry of selling &quot;Agile&quot; to corporations that is peddling this shit.<p>If you are implementing a set process from a book you are by very definition anti-agile.<p>When I implement agile at companies I don&#x27;t even call it agile. And the only initial practices are:<p>* transparency -- you can&#x27;t fix what you can&#x27;t see<p>* improvement loop -- you need to learn from your mistakes and feed the results into next cycle<p>* process building fundamentals -- once you learned you need mechanisms to preserve the results. Checklists, templates, documentation, automation, infrastructure as code, etc.<p>Everything else is result of the learning. As we go, we spot problems or improvement opportunities and we decide how to fix it together. A lot of these fixes come from agile literature. Nobody said you have to reinvent everything. But now that we have implemented it in response to our actual problem we know why it is there which is way better than just implementing it without understanding.<p>Along the way people learn they have power to change things in a realistic way and not only they are welcome to do so but it is actually their job. Which is exactly the goal of all of this and yet completely missing when you put forward a book and say the process has to be implemented exactly as in the book.
评论 #32712373 未加载
评论 #32712766 未加载
teeray超过 2 年前
Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically.<p>However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not.<p>I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.
评论 #32709543 未加载
评论 #32711147 未加载
评论 #32711479 未加载
评论 #32709937 未加载
xlii超过 2 年前
I&#x27;m seeing a lot of people making Agile something it isn&#x27;t&#x2F;shouldn&#x27;t be. There&#x27;s a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it.<p>Agile wasn&#x27;t meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was &quot;weaponized&quot; by business but (at least from my experience) everything that is wrong with it was brought to the table by those business practices.<p>Agile isn&#x27;t for planning long term projects or managing projects portfolios. It isn&#x27;t a communication method not a risk management one. There are dozens (if not hundreds) of PM methods implementing full scope of PMBOK&#x27;s areas of concern that one should use for those. Some even use Agile as an internal process, but still plan using other tools.<p>Yet, I understand many of comments here. In many places I&#x27;ve seen Agile is misused if not bastardized to a level where I hated it.<p>But just to show the contrast: I&#x27;ve worked recently in an environment where there was no scrum, no sprints, no agile points, and environment was really allergic to any mention of Agile (Oh no, we don&#x27;t use it HERE). There was a lead who talked to everyone on Monday and said &quot;we want to have X by the end of the week, can you do it?&quot;. Every single person had their X and everyone worked toward that goal. That planning usually worked and each week ended with deploying next iterative version of the software. It was the most Agile place I ever saw.
评论 #32711514 未加载
评论 #32711208 未加载
评论 #32711327 未加载
评论 #32711513 未加载
评论 #32712353 未加载
Surfactant7超过 2 年前
&gt; Allen described his work as a consultant when he goes into a new organisation:<p>&gt; - First he observes<p>&gt; - Then he would try to identify the biggest problem<p>&gt; - Then he would try change it (i.e. run an experiment)<p>&gt; - Then if that works, run another experiment<p>&gt; - If it doesn’t work, go back<p>It&#x27;s probably no accident, but this is pretty close to the scientific method.
评论 #32708782 未加载
评论 #32710186 未加载
stephc_int13超过 2 年前
Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time.<p>Unfortunately, Agile quickly turned to be even worse than what preceded.<p>Corporate bureaucracy should be fought against at all times and by all means.<p>If you work in software, you are valuable enough to have a say, and a choice about who you work for.<p>Not everything has to turn into a bullshit job.
评论 #32709082 未加载
评论 #32709114 未加载
lkrubner超过 2 年前
The only practice that I&#x27;ve found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting would not happen unless one of those people needed to talk to the other person, so 100% of the people in attendance are needed in that meeting. (I&#x27;m excluding those companies that have mandatory one-on-one meetings, where the mandatory nature of the meeting sometimes makes the meeting as useless as a large group meeting.)<p>I&#x27;ve known managers who say &quot;Group meetings are great because I get to meet with everyone at once and it saves me so much time!&quot; But that only benefits the manager. Meanwhile some of the people in the meeting are just sitting there, killing time, bored, waiting for the manager to have 10 minutes to talk to them. By contrast, more one-on-one meetings, even if only for 10 minutes, allows everyone to be involved during the moments when they need to be involved.<p>When we criticize some of the rituals and bureaucracy that has become associated with the word &quot;agile&quot; most of the time we are criticizing group meetings. That includes the daily standup. I&#x27;ve run teams successfully by having quick one-on-one 10 minute meetings with everyone on my team, everyday. But I rarely feel the need to get the whole team together. In fact, when I&#x27;m leading a large team, I never need to get the whole team together, it is always some smaller subset that I pull together.<p>If you are the team leader, then you need to think carefully about who you need to talk to for any given purpose. If you have the discipline to only talk to the minimum set of people you need to talk to, then you are freeing up a lot of people to keep working on their real work, since they are not in a meeting with you.
评论 #32711477 未加载
评论 #32710905 未加载
ineptech超过 2 年前
I generally agree, couple observations:<p>1. If the people on the team can&#x27;t change the process, it ain&#x27;t agile<p>2. Sprints aren&#x27;t a failure of agile, they&#x27;re a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it&#x27;ll be fine<p>3. Estimates aren&#x27;t literally the devil, execs need to have a rough idea how big it is, just don&#x27;t get more granular than months
评论 #32709919 未加载
评论 #32709702 未加载
评论 #32711286 未加载
评论 #32709662 未加载
travisgriggs超过 2 年前
Here’s the part that jumped out at me:<p>&gt; The problem is that Scrum started out as a lightweight wrapper around Extreme Programming (XP) to make it palatable to management, and it is all that extra cruft that people of added that is the problem.<p>Look at that statement, and then let’s abstract it and make it a bit more “polymorphic.”<p>The problem is that process ______ started out as a wrapper around idea&#x2F;adhoc practice _______ to make it include management, and it is all the other crap that is added that is the problem.<p>Every time management gets involved with the teams I work on, this is what happens. I hear tales of people who have “helpful” management. Some of my managers have been the nicest guys, and tried to do well by me. But because they’re not part of the team, they rarely add value, but rather burden the team with their non value adding presence.<p>(Kinda ranty, I know, I’m just channeling the OP which was titled a rant, I guess)
skeeter2020超过 2 年前
A lot of this really resonates with me as a manager of dev teams, but once again the very unhelpful advice for &quot;how do you figure out when you&#x27;ll be done?&quot; is &quot;refuse to do it&quot;. If an executive is asking me when we will deliver something this is a completely valid question. It&#x27;s how everyone outside software development lives. If lean aglie can&#x27;t give me a way to shape expectation of what we&#x27;re building AND answer the delivery question we&#x27;re stuck with BS agile, or we might as well go back to waterfall which (accurate or not) has always been very clear with a delivery date.
评论 #32714386 未加载
haspok超过 2 年前
&gt; It is not the technology that matters, it’s interacting with people. The better engineers can communicate, the better a team will perform.<p>This pretty neatly summarizes my ~25 years of experience in the industry! With the additional observation that most developers and managers are not aware of this phenomenon... :(
zac23or超过 2 年前
&gt; Don&#x27;t estimate I agree. But in my experience, the real problem is out of the developers&#x27; hands:<p>1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway.<p>2. On another project, my team didn&#x27;t need to estimate or have a deadline. BUT at every meeting the boss said the project was behind schedule. WE WERE LATE EVEN WITHOUT A DEADLINE. Total nonsense.<p>If your boss is crazy, your job has a lot of politics, etc, nothing will work, and this kind of environment loves to embrace Agile methods.
评论 #32709951 未加载
samizdis超过 2 年前
&gt; Recruiting people does not work by doing laundry lists of questions asked by HR drones that don’t understand context or demand 10 years of experience in a technology that’s 8 years old. Five rounds of interviews, tests and exams where people have to recite algorithms by heart are pretty pointless.<p>I second that sentiment.<p>I&#x27;ve worked in places small and autonomous enough that the office manager would handle the admin of posting a job ad, passing on the CVs to the person who knew what their team was looking for in a colleague - note, a colleague, not a &quot;new hire&quot;. The absence of an HR filtering layer left hiring decisions to those it most directly affected, but with the admin side handled by office managers (or in some cases COOs).<p>I&#x27;ve also worked in far larger places with heavyweight HR departments. Frustrating and backed by corporate policy (and as declared to shareholders) regarding recruitment processes. The question &quot;<i>Why can’t hiring be agile?</i>&quot; is worth exploring, I think.
评论 #32709433 未加载
评论 #32710321 未加载
O__________O超过 2 年前
Agile is a way being, not a thing to be.<p>For the majority of people, they just want to know what to do and expecting them to “become agile” is like asking them to change their beliefs related to politics, religion, etc. — AND more importantly, practice them.<p>If you want to become more agile, focus on improving yourself and finding others that align to what you feel is agile.<p>____<p>* Personally, to me, Boyd’s OODA model of agility is the the most adaptable. Problem is it’s not a check list and requires you to internalize is. For example, most people think being agile is always about speed, but it’s not, it’s about dynamically controlling yourself in to optimally control what is not yourself; sometimes most agile thing to do is be slow, or even do nothing — to see what happens, force someone else to act, etc. People that to me felt the most agile are the ones that enjoy being agile all the time and playing agility games.
dhasso超过 2 年前
I&#x27;m always very confused about this kind of statement: &quot;Don’t estimate&quot;. To me, projects without estimates tend to take way too much time. It&#x27;s also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal and not a business one? How to manage the lack of estimation when company planning is important? I can hardly see how &quot;Ok everybody, we are going to release a product but we don&#x27;t know when! Soon!&quot; could work.
评论 #32709955 未加载
评论 #32712051 未加载
评论 #32747010 未加载
评论 #32732624 未加载
ajb超过 2 年前
The problem with this kind of article is that it doesn&#x27;t recognise that software is built in different contexts. &quot;Don&#x27;t estimate&quot; may be fine if your product is an SAAS that gets updated incrementally. It won&#x27;t cut it if your clients question is &quot;we&#x27;ve booked the O2 arena for April 2023. Can you build this by then?&quot;
评论 #32710846 未加载
评论 #32711407 未加载
mbrodersen超过 2 年前
It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. Use the priority list to negotiate with your stake holders. That’s it.<p>I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.
评论 #32709552 未加载
osigurdson超过 2 年前
If you don’t have a good idea, don’t even start. The problem with a lot of projects is they focus on the process (because it’s easy) without having a good or clear vision to begin with.<p>If you have a clear and compelling vision, then everything else falls into place.<p>Start with no process and add (sparingly) as needed. Always treat process as the least important thing on any project.
he0001超过 2 年前
Aren’t all business models at odds with agile (agile is one but hardly taught in economics schools, or?)? It sure feels like it, as soon as a agile process gets formalized towards business, it crashes. Execs wants metrics, which gets abused from both sides of it. And to create relevant metrics you need details which just adds to the bureaucracy and slows things down. As there are deliveries to consider and business contracts, management and sales wants hard deadlines to sell. Thus you need to estimate everything to give management an idea if and how relevant something is to do in relation to what needs to be done from a sales perspective. It always ends up in bureaucratic hell because the more formalized something gets, the more data it needs to be accurate and deterministic, which is a goal from management.
mihaigalos超过 2 年前
I loved this article.<p>Countless times I had to estimate Jira &quot;tickets&quot; (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven&#x27;t gotten a pertinent answer other than &quot;the business needs it for planning, they&#x27;re paying us, so you do it.&quot;<p>Yet this contradicts at least 2 Agile Manifesto pillars:<p>1. People and interactions over processes and tools (fostering the estimation ceremony + booking time rather than actual interaction or developer happiness).<p>2. Reacting to change over following a plan (plan-the-work and work-the-plan over reacting to change).<p>How do you even &quot;do&quot; estimates?! Clean Agile (ISBN-13: 978-0135781869) says &quot;Estimates are never commitments. They are guesses.&quot;<p>So it seems the business is trying to get a commitment out of an estimation, at hour granularity.<p>What are your thoughts here?
评论 #32711443 未加载
cube00超过 2 年前
<i>&gt; And at the end of it, the estimate has to be thrown out anyway because the devs who picked up the story didn’t have the same experience as the devs estimating.</i><p>I thought the &quot;rule&quot; was a single core team, not multiple sub-teams of devs.<p>If devs with less experience are also at the planning poking table to voice their concerns; the more experienced devs can take that feedback on board to come to a consensus estimate.<p>Individual tasks may be over or under depending on which dev picks it up but the idea is to get the average as close as possible to being accurate.
rufflez超过 2 年前
I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that &quot;Agile&quot; leaves in its wake.<p>My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor&#x2F;low code solution etc.<p>If the development team doesn&#x27;t know the estimate, how is management expected to know? Simply put, management will be held to whatever number (of person hours) they provide, and are also expected to keep it low enough to close the deal. Deadlines are part of doing business, no matter how much we try to dance around that fact. This is why management will immediately turn around and convert story points into hours. These guesstimates will then become deadlines. I hate having deadlines for creative work, and would rather not be bothered by them, but they exist nonetheless.<p>Until you convince your customers to accept &quot;NFC&quot; and still do business with you, Agile will remain a quixotic idea for the corporate world<p>Can we please not fool the next generation of software developers into believing all this bs?
评论 #32717864 未加载
thejackgoode超过 2 年前
I disagree with “don’t estimate” part. If it’s hard, it doesn’t mean it’s wasted effort. And it’s very valuable to business to know with higher degree of precision how much things cost to develop.<p>It depends on many things, but from my experience, it’s possible, we went from 40% to 10% margin of error per quarter. When there’s a will, there’s a way.
serial_dev超过 2 年前
The way I use these words goes like this.<p>Agile is what managers who have no clue about the agile manifesto do after they attended a mandatory, 6 hours long SAFe training. &quot;Doing Agile helps the coding monkeys output three times as much as before? Gotcha!&quot; When you prescribe the same sprint start day across the entire organization, that is Agile. If you have 6 weeks sprint commitment, that&#x27;s Agile. When all teams need to estimate stories using Fibonacci, that&#x27;s Agile. When the dev team needs to commit how much time they need for a feature that is planned for next year Q4, that&#x27;s Agile. When the company needs an certified coach, that is Agile. When I need to create a Jira ticket and got it approved by three people to change the name of a small class, that&#x27;s Agile.<p>I use &quot;agile&quot;, when a company or product team understands that when writing software, you need to adapt to the things you find out. You don&#x27;t know what you will do in 27 weeks and there is no point in story point estimating that stuff a half a year in advance. The company is agile when one team can use Scrum, another team can do Kanban, yet another can do whatever they come up with that works for them.
teddyh超过 2 年前
Related: <i>The Land that Scrum Forgot</i> <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=hG4LH6P8Syk#t=5m37s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=hG4LH6P8Syk#t=5m37s</a>
locallost超过 2 年前
Everybody else does it, we have to do it, don&#x27;t question anything even though you think it&#x27;s not really that important or even detrimental. It&#x27;s emperor&#x27;s new clothing all the way down.<p>I agree it&#x27;s helpful that there&#x27;s a common theme on how &quot;we&quot; do things, but the point about making it organic is spot on. Nobody does things so they do scrum. The goal is to deliver something useful, how that gets done might be very different in different contexts. So mold it to how you do things.
polotics超过 2 年前
Nice enough article, but I don&#x27;t know where the author found such a poor definition for the word &quot;ceremony&quot;. A ceremony ain&#x27;t just going through motions, it is going through motions to reconnect with elders, identity, re-confirm to all the position of some in the local structure of power, show symbolic values. As such, that word is the most precise one in the Faux-Agile lingo, and clearly shows the purposes have nothing to do with delivering better software faster...
tpoacher超过 2 年前
I don&#x27;t agree with the &quot;no estimates&quot; sentiment.<p>My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.
评论 #32709627 未加载
评论 #32709973 未加载
j45超过 2 年前
An idea I’ve begun to understand better is the the higher the formality.. often the lower the average velocity, experience, capability and trust in and among the team.<p>Standards, structures and processes are still something I wouldn’t do without, but the configuration or extent can vary based on the team.
vermooten超过 2 年前
Waterfall &#x2F; no process -&gt; Scrum -&gt; Kanban -&gt; XP<p>Problem I found with this journey is that Scrum concepts pollute Kanban and beyond. We now just do what works, as little process as works for us - and we implicitly review the process with each commit.
ess3超过 2 年前
I think what’s missing from a lot of agile teaching material is how you build trust with your stakeholders&#x2F;management. Without it whatever process you implement will still morph to have to include deadlines and estimates.
grahamm超过 2 年前
&#x27;A&#x27;gile is broken and should be stopped. I am seriously considering doing something else than the job I love for the reasons in this post.
FpUser超过 2 年前
When I hear agile and SCRUM I just want to puke. Luckily I&#x27;ve been agile free for all my programming life.
评论 #32709821 未加载
torginus超过 2 年前
Scrum is like communism. It never fails, but when it does, it wasn&#x27;t real Scrum anyways.
SuperSandro2000超过 2 年前
Less is more
ethical超过 2 年前
What a crock of poo. No security as ever. Fowler now bothers to mention Threat mOdeling. You engineers are rubbish. You are so lazy, and hate security so much. Even in healthcare and medical devices. Security is EASY! but alas, most of you and the management drones do not have a clue.<p>Agile has killed more people than Waterfall. Terrible. You should all be ashamed of yourselves. Do try harder! lol
peteradio超过 2 年前
&gt; Compared to waterfall, it is fundamentally less constrained. Waterfall demands that we know the system and all the possible problems upfront<p>How I know you don&#x27;t know what you&#x27;re talking about in 2 dozen words or less.
评论 #32708418 未加载