单一开发人员完成所有 SDLC 活动 -- 我应该如何进一步进行?

发布于 2024-09-09 01:23:11 字数 266 浏览 0 评论 0原文

作为 .net 程序员(单独)在客户端(非 IT)工作,并要求开发 Windows 应用程序。没有项目经理,没有SRS,没有技术人员来领导......等等。

根据客户的需要直接从客户那里获取要求。它不断变化并且有很多歧义。由于客户不了解冻结要求,处理起来变得非常头痛。必须自行编写需求文档、编码、测试、错误修复和交付构建,并教育用户仅由我自己使用应用程序。向老板汇报,老板是非技术人员,总是不理解这些问题。

现在它变成了由单个开发人员完成所有 SDLC 活动。我该如何应对这种工作环境?

Working at client (non-IT) place as a .net programmer (alone) and asked to develope a windows application. No project manager, no SRS, no technical people to lead..., etc.

Directly getting requirement from customer on-their-need basis. It keep changes and has lot of ambguity. As the client is not understaning need of freezing requirement, it becomes huge headache to deal with. Has to do self document of requirement, coding, testing, bug-fixing and delivering build, educating users for application use by myself only. Reporing to a Boss, who is non-technical guy and always not understanding these problems.

Now it becomes, single developer-to-do-all SDLC activities. How should I proceed with this work environment?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

凉风有信 2024-09-16 01:23:11

首先对您的环境以及对您的要求提出要求
要求在编写一行代码之前以书面形式固定并商定要求和截止日期。
要求您在开发周期中有足够的时间进行测试和错误修复。
要求您有时间设置源代码控制、自动构建等(无论您认为您的开发环境需要什么,以促进有效的工作)。
要求您有时间编写文档,这样您就可以花更多的时间编写代码,而减少做应用程序演示的时间。

继续备份
记录并向你的老板展示一些关于你如何利用时间的统计数据。如果事实证明您在实际编写代码时使用的时间少得多,也许他会考虑将一些与编程相关性较低的任务交给部门的其他成员。

最后,请记住,这这不是世界上唯一的公司:
Robert L. Lead 在他的如何成为一名程序员:简短、全面和个人总结:在识别何时回家下,他只是状态:

如果必须的话就退出。

这可能不是一个非常令人信服的选择,但如果真的发生了,那就离开公司,去另一边更绿的地方。如果你的工作条件没有改善,甚至告诉你的老板你准备辞职,可能会帮助你真正得到你想要的东西。我怀疑贵公司是否希望留下一个突然无法支持或更新的软件产品,因为他们唯一的开发人员退出了。

Start by making demands on your environment, and on what is asked of you:
Demand that requirements and deadlines are fixed and agreed upon, in writing, before you write a single line of code.
Demand that you are given enough time for testing and bugfixing in the development cycle.
Demand that you are given time to setup source control, automatic builds etc (whatever you feel like you need for your development environment to promote effective work).
Demand that you are given time to write documentation, so that you can spend more time writing code and less time doing application demos.

Continue with backing it up:
Document and show your boss some statistics on how you use your time. If it turns out you use much less on actually writing code, maybe he'll consider giving some of the less programming-related tasks to some other member of the department.

And finally, remember that this this is not the only company in the world:
Robert L. Lead has a very good point in his How to be a Programmer: A Short, Comprehensive and Personal Summary: under Recognizing when to go home, he simply states:

Quit if you have to.

This might not be a very compelling option, but should it come to it, leave the company for the greener grass on the other side. Even telling your boss you're ready to quit if your working conditions don't improve might help you actually get what you want. I doubt that your company want to be left with a software product that suddenly can't be supported or updated, because their only developer quit.

无需解释 2024-09-16 01:23:11

我会说,数数你的祝福。通常,站在开发人员和用户之间的所有人员都只会妨碍开发成功的软件。

我认为采用一些敏捷工具来组织自己是一个好主意,例如 Scrum 白板,并定义冲刺周期/迭代。这将允许管理你的老板和用户的期望,并仍然让他们控制应该优先考虑的事情。不要忘记安排 SDLC 任务,以便您的老板可以看到它们。您应该随意将敏捷工具视为超市:选择您认为有用的东西,并记住其余的以供以后考虑。

就需求文档而言,我会保持很高的水平。我不介意完全跳过它,但我可以想象它感觉很草率,而且这也许也是记录你的成就的一种方式。

Count your blessings, I'd say. Usually all the people standing between the developers and the users are just getting in the way of making successful software.

I think it is a good idea to adopt some agile tooling to organize yourself, like a scrum whiteboard, and by defining sprint periods/iterations. That will allow to manage your boss's and users' expectations, and still give them control over what should get priority. Don't forget to schedule for SDLC tasks, so you can make them visible to your boss. You should feel free to consider agile tooling as a supermarket: take what you think is useful and keep the rest in mind for later consideration.

As far as requirements documentation is concerned, I'd keep it very high level. I would not mind skipping it altogether but I can imagine that it feels sloppy, and it is perhaps also a way to document your achievements.

阿楠 2024-09-16 01:23:11

教育你的客户和老板的结合; 敏捷方法在这里可能会有所帮助。这取决于该项目如何向客户计费。

如果客户获得的是固定价格交易,但允许更改规格,那么请向您的老板(或对项目财务结果负责的任何人)介绍以下内容:该项目的影响。这意味着客户可以提出他们想要的任何要求,而无需支付更多费用。如果项目没有时间限制,你的老板就会以固定价格赠送无限的开发时间。说清楚。如果项目有时间限制,请解释改变意味着重做,并且在时间耗尽之前只有这么多重做。如果他不认为这是一个问题,请记录您的时间使用情况

这相当于去汽车修理店,谈好价格,然后催促机械师不仅修理你的空调(原来的范围),而且还更换你的机油,升级你的悬架并进行全面的发动机大修。从长远来看,期望客户要求汽车能够飞起来,解决世界饥饿并带来世界和平。

如果您正在进行按小时计费的项目,那么您的麻烦就更大了。你的老板可能没有任何动力让客户提出合理的要求,他可能只是关心你有效地外包给客户并带来收入。在这种情况下,通过与客户商定敏捷方法来负责项目,这样您至少可以交付一些可以满足某些客户需求的东西。随意负责,似乎您是事实上的经理 - 只需确保您了解该项目的合同条款并在这些范围内工作即可。如果合同是一笔糟糕的交易,请提醒你的老板,但你的公司将需要安然度过或重新谈判。

以两周的冲刺为单位进行工作,向您的老板和客户展示交付的功能/特性与开销(返工)与其他工​​作(培训等)的比率。这可能会变得非常清楚很快就会发现您的项目资源不足,或者对商定的价格要求很高。 则在电子表格中进行跟踪,或使用轻量级敏捷项目管理工具,例如 TargetProcess

如果客户无法工作并且您的老板无法工作, 只看到你在某人拉皮条,重新考虑你是否想在这样的地方工作,以及是否有任何特殊原因导致你在当前的公司而不是另一家公司度过你的职业时间。

请记住,您可能处于相当有利的位置,可以推动一些改变以改善情况。如果您是非 IT 商店中唯一的开发人员,并且您辞职了,那么您的公司将很难履行其对客户的义务 - 您的老板,免得他是个傻瓜,会注意到这一点。当然,威胁退出是核选择,不要轻易打这张牌。

A combination of educating both your customer and boss; and an agile approach could be helpful here. It depends on how this project is billed to the customer.

If the customer is getting a fixed price deal, yet is allowed to change the specs, then educate your boss (or whoever is accountable for the financial results of the project) about the implications of this project. It means that the customer gets to ask for whatever they want, without needing to pay more. If the project isn't time boxed, your boss is giving away unlimited developer time at a fixed price. Make that clear. If the project is time boxed, explain that changing means redoing and that there's only so much redoing before you run out of time. If he doesn't see this is a problem, document your time use.

It's the equivalent of going to a car-repair shop, agreeing a price and then pushing the mechanic to not only fix your airconditioning (the original scope), but also replace your oil, uprate your suspension and do a full engine overhaul. In the long run, expect the customer to be demanding that the car flies, solve world hunger and bring world peace.

If you're on a billable hours project, then you're in more trouble. Your boss may not have any incentive for the customer to make reasonable demands, he may just care about you being effectively contracted out to a customer and bringing in revenue. In that case take charge of the project by agreeing an agile methodology with the customer, so you can at least deliver something that will address some customer needs. Feel free to take charge, it seems you're the de-facto manager - just make sure you understand what the terms of the contract for this project and work within those boundaries. If the contract is a bad deal, alert your boss, but your company will need to ride it out or renegotiate.

Work in two week sprints, and show to both your boss and client the ratio of functionality/features delivered vs. overhead (rework) vs other work (training,...). It may become clear quite quickly that your project is under resourced, or the demands to high for the price agreed. Track in spreadsheet, or use a lightweight agile project management tool something like TargetProcess

If the customer is unworkable and your boss only sees you at somebody to pimp out, reconsider if you want to work in such a place and if there is any particular reason why you're spending your professional time at your current company over another company.

Keep in mind that you could be in a reasonably strong position to push for some change to improve the situation. If you're the only developer in a non-IT shop, and you quit, your company will struggle to fulfill its obligations to its customer - your boss, lest he's a halfwit, will be mindful of that. Of course, threating to quit, is the nuclear option, don't play that card lightly.

未蓝澄海的烟 2024-09-16 01:23:11

在这种情况下,我通常会做的事情(而且我遇到的这些情况比我想要的要多得多)就是要求一定的最低限度。只有当你有可以用来向你的“老板”施加压力的东西时,你才能要求一些东西。在单一开发人员包揽一切、包揽一切的情况下,你的施压手段就是你自己。

世界上有一些国家的员工保护很差,你必须要小心。对于任何其他国家来说,这几乎都是理所当然的事情:只需要求最低的工作条件即可。

这意味着:您列出了您需要的东西的简短清单。保持简单。保持它——几乎——免费。不要带着各种手续来。使用简单的错误跟踪系统,您也可以将其用于规划、报告、功能跟踪和新开发(我想到的是 Jira)。你的老板和你的客户都应该被教导如何使用它。对于您自己来说,如果您还没有源代码管理,您可能想添加它。

现在到了棘手的部分:在短时间内,变得非常严格。使用跟踪系统的评论线程进行交流。您的客户将继续给您打电话或发送电子邮件。让他吧。但是将所有内容复制到评论线程并在那里写下您的答案。向该人发送该线程的链接作为答案。

你的老板可能不喜欢这样,因为他认为这会减慢速度。告诉他可以做什么和将做什么将会变得更加清楚。他的钱(即:你的时间)去了哪里也会变得更加清楚。告诉他你想自己保持概览,但这对他也有好处。如果他不相信,请告诉他给我打电话,然后向他提议两个月内100%按照你的方式去做。他会做到一个月,然后你们就达成协议了。

这是一场艰难的比赛。但这是可行的。提出一些简单的步骤来改善您的环境、沟通和跟踪。如果他拒绝,你就拒绝做更多的事情,他就会陷入更糟糕的境地。

What I usually do in such situations — and these situations I come across much more than I'd like — is to demand a certain minimum. You can only demand something if you have something you can use to pressure your "Boss". In a single-developer-does-all-and-can-do-all situation, your means of pressure is yourself.

There are some countries in the world where employees are badly protected and you have to be careful. For any other country, this almost becomes a no-brainer: simply demand minimum working conditions.

This means: you make a short-list of things you need. Keep it simple. Keep it — almost — free. Don't come with all kinds of procedures. Use a simple bug-tracking system you can also use for planning, report, feature-tracking and new-development (Jira comes to mind). Both your Boss and your Client should be taught to use it. For yourself you probably want to add source control if you don't have it already.

Now comes the tricky part: for a short while, become very strict. Use the comment threads of your tracking system for communication. Your client will continue to call you or e-mail you. Let him. But copy everything to the comment threads and write your answer there. Send the guy a link to the thread as an answer.

You Boss may not like this because he things it will slow things down. Tell him it will become clearer what can and will be done. It will also become clearer where his money (i.e.: your time) went. Tell him that you want to keep an overview yourself, but that it's good for him too. If he's not convinced, tell him to give me a call and then propose to him to do it 100% your way for two months. He'll make it one month and then you have a deal.

It's a tough game out there. But it's doable. Propose a few simple steps towards bettering your environment, communication and tracking. If he refuses, you refuse to do anything more and he'll be stuck with an even worse situation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文