我是一名系统管理员大使(实际上,是一名负责连接这两个领域的开发人员),我的任务之一是向上层管理层提交改进建议。我一直在考虑每周为系统管理员领域的同事们规划一些任务……但我不知道是否有更好的方法。
我的意思是……我想让系统管理区域更“灵活”一点,如果你明白我的意思的话。我的老板也要求在这个领域进行某种项目规划……
你有什么建议?
答案1
很多人都在尝试将敏捷软件开发原则应用于系统管理。关于这方面的文章比我在这里能说的还要多。稍后我会提到一些资源,但首先是一些提示:
- 了解你的系统管理员做什么。(正如其他人已经指出的那样)
- 不要将变更强加给系统管理员,并非所有原则都适用于每家公司。
- 询问您的系统管理员是否已经有改进的想法。
- 您是否有足够的管理员,因此有些人只能在项目上工作一段时间?(通常不是演员,但也许你很幸运)
- 不要试图一次引入所有敏捷原则。从小处做起,让你的系统管理员习惯新的原则。
以下是提到的资源:
- 敏捷系统管理博客和新闻组:
- 另一个试图拉近开发人员和系统管理员距离的“运动”:devops
- http://www.devopsdays.org/
- 只需在 Google 上搜索 devops
- 看板以及系统管理员的 scrum:http://www.infoq.com/minibooks/kanban-scrum-minibook
这是 Scrum 与丰田开发的精益原则的比较。
答案2
您能否更具体一点地说明您将尝试改进的领域?并非所有系统管理员的工作都适合“项目”——其中很多是操作性的(重复性任务、检查表、预防性维护),很多更像是调试(处理支持电话),还有一些是设计、构建和部署新的基础设施。并非所有这些工作都能很好地映射到敏捷方法中,但可以肯定的是,有些可以。
在开始这项工作时,我能给你的最好建议是了解他们的总体工作量,并试着弄清楚他们有多少时间与工作的各个方面有关。如果你有兴趣提高交付新\改进基础设施的能力和时间,那么一定要参与其中一个项目。了解团队并解释为什么需要这种桥梁(顺便说一句,我认为这是个好主意)。如果我是你,我会从一开始就把它变成一条双向的道路——因为我们想要改进 X、Y 和 Z,那么你希望我们(无论是开发人员还是管理人员,还是两者,无论你扮演哪个角色)做什么作为回报。
需要注意的一件事是确定哪些事情真的很重要。例如,如果我正在部署一些新的基础设施,然后收到警报,说 SAN 存在性能问题,或者防火墙出了问题,我将停止项目工作,专注于生产问题,直到问题解决,或者由其他人接手。如果这意味着项目截止日期已到,那就这样吧。现在我认为这很明显,但我曾经遇到过这样的情况,我因为错过最后期限而被部署 PM 严厉批评,因为我正忙着在灾难发生后恢复 20 亿美元的生产设施,所以我对我认为的提高项目效率的糟糕尝试并不陌生。
根据我的经验,随着组织规模不断扩大,开发人员和管理员群体之间会产生相当大的(且不健康的)距离,这是一种遗憾,消除或避免这种情况的努力是值得称赞的。
答案3
每周开会通常听起来不错。但如果你想弥补差距,你应该去问他们或者如果有领导的话,也可以问问他们的领导。我认为你应该首先尝试了解他们是做什么的,他们的常见任务是什么等等。然后你可能会对工作结构有更好的想法。如果你带着计划去,却没有和他们交谈,他们可能会对此持防御态度,并觉得你有点敌意。
这对于未来的关系很重要,因为最好的环境可能来自于开发人员和管理员能够满足彼此的需求,并花时间了解彼此的观点。如果你看起来不像你最关心的是先了解他们的观点,他们可能不会接受你的观点。
另外,你可能需要谨慎对待他们,不要太“敏捷”,他们可能会把你看作某种狂热分子;-)
答案4
在开始推荐任何更改之前,您绝对需要与您的系统管理员同事聚在一起,了解他们所做的工作。即使您之前有 IT 经验,每个公司都有自己的特点,没有什么比有人试图告诉他们该做什么,却不了解他们实际上在做什么更让人恼火的了。
我首先要弄清楚的是他们如何跟踪需要完成的工作。应该有一些根据时间表执行的重复性任务,以及一些一次性任务,包括用户的支持请求和 IT 正在开展的项目。如果在多个地方有多个列表,您可以先尝试合并内容,最好以多人(需要访问权限的人)可以访问的电子形式进行。不属于特定项目的任务应组织到一般项目中。例如,IT 维护任务项目可以包括每天/每周/每月执行的所有日常维护任务。如果多个任务相关,则更明确地进行分类可能是明智之举。例如,如果有七个任务与数据备份相关,您可能希望将它们放在自己的项目中,而不是通用的 IT 维护任务项目中。
第二件要弄清楚的事情是他们如何确定优先级。它更像队列(FIFO)还是堆栈(LIFO)?计划任务是否比一次性请求更重要?什么是暂时搁置的,什么要留到下雨天再做?你应该会发现灾难性问题被提升到了列表的顶部,因为用于生产的系统需要运行,否则什么都做不了,就像程序员会优先修复错误而不是添加新功能一样。因为你提到了“敏捷”这个词,所以我会留意在确定优先级时是否考虑了完成请求所需的时间。我发现立即执行快速任务(10-15 分钟或更短)有助于降低音量并让用户满意。较长的任务应该按尽可能多的级别进行优先级排序;这取决于有多少任务以及有多少资源可用于处理这些任务。每个任务应该分配给一个资源,每个资源都应该能够过滤任务列表以仅显示自己的任务。经理类型的人应该能够看到他们下属每个人的任务,并可以按人员或项目进行分类。