我是一家非常小的公司的独立开发人员.我的工作非常混乱,我正在寻找方法使其更有条理.
一个问题是我的项目实际上没有管理.很少有人问我正在做什么,或者我有什么问题.在某些时候,有人谈论每周一次的状态会议,但那是一段时间以前.似乎如果我想要这样的东西,我将不得不自己安排.有时我对我应该做的事情有点迷失,因为我没有定义任务或明确的时间表.
从书籍和文章中我发现了许多可能有用的东西.就像有一个好的编码标准(在我看来只有一个粗略的风格指南,有点过时),代码检查,TDD,单元测试,错误数据库...但在一个小公司,它似乎没有资源或时间任何不重要的事情.我在嵌入式域中工作的事实似乎使事情变得更加复杂.
我觉得在短时间内也有偷工减料的习惯.这导致未完成和不专业的产品和错误等待在以后出现.我想他们也很难维持.所以,我即将继承一个具有挑战性的代码库,进行新的开发,需要学习很多新东西,我想尝试同时为它们构建一个流程.它最终可能会有所回报,但由于经验不足,我不确定是否可以将其拉下来.
在这样的小商店里,环境远非编程的最佳选择.还有许多其他事情需要偶尔完成,如客户支持,接听电话,签署包裹,硬件测试,装配以及可能出现的任何其他任务.所以你了解了资源.这并不全是坏事(有时解决一些客户问题很有启发性),我相信它可以改进,但这是我真正关心的其他事情.
是否有可能在这样的地方进行开发？
进行某种管理会有所帮助吗？什么样的？
是否有可能用小资源制造优质产品？
我如何让自己和其他人相信几十年来成功运作的公司需要改变？什么是必要的？
也许有人在类似的商店工作？
lod*_*d3n 17
我的建议不是极端.根据我的经验,纯粹的敏捷或纯粹的传统将无法奏效.在使用任何过程之前,请先了解解决的问题.
我个人使用的变种Agile RUP.我做了一些前期工作,比如调查实际需求,做可能扩展的高级设计.并要求客户签署一些主要的高级要求.
如果您在小组工作,详细设计或规格可能不值得.当然,如果有一些库被许多人共享,那将是值得的.
根据风险(可能性和影响)确定预先投资的内容.
此外,许多SW最佳实践真的是"最好的",如版本控制,自动测试(对我来说,我只是用它来早期检测回归,因为我不相信TDD是开发的驱动力).我建议你阅读' 实用程序员 ',它介绍了许多技术.
至于回答你的问题:
(1).是否有可能在这样的地方进行开发？
是的,但正如我所说,预告它适合您的组织.
(2).进行某种管理会有所帮助吗？什么样的？
管理有帮助,但没有控制狂.计划在做什么时:整合,解决冲突,某些里程碑的死线.并且大致按时完成(我特别喜欢Scrum的冲刺).
(3).是否有可能用小资源制造优质产品？
绝对一旦工作的规模,发展的时间和团队的规模是平衡的.如果您对Quality的定义与我相同.对我而言,质量意味着:以高效可靠的方式解决它所面临的问题.
(4).我如何让自己和其他人相信几十年来成功运作的公司需要改变？什么是必要的？
指出问题所在.如果没有,为什么要改变？如果您想要更改,您应该能够识别问题或潜在问题.指出问题所在.
一些重要的是:
没有任何过程,新招募的人很难融入其中,因为他们必须从观察其他如何处理事物中学习.
没有过程,就很难在压力下工作.
没有时间表,很难确定进度.
如果没有自动测试,则需要更多时间来识别问题和回归.
如果没有版本控制,就很难回滚错误,并且每个团队成员的工作分离都会变得混乱.
只是我的.