我正在制作一个将Scrum与OpenUP生命周期和可交付成果相结合的方法.我还希望将OpenUP学科与"项目管理"区分开来.我可以"隐藏"它,以便它在我生成的方法站点中不会立即显现出来.但是,当您导航到"风险列表"人工制品时,例如,PM仍被视为有贡献,如果您点击该链接,则会进入PM Discipline页面.
如何从我的方法中完全删除它而不从我正在使用的OpenUP库中删除它？
我们一直在寻求在地理位置分散的开发团队中实施敏捷方法,因此我需要您使用过的任何免费在线应用程序的建议并发现它们非常有用.
现在我们正在使用纸卡和墙来管理这个:),但我们想转移到一个优先免费的在线版本.
我在以前的工作中使用过TargetProcess!
我的核心要求是:
我很好奇其他人在他们公司中使用的物理看板/ Scrum板.我很欣赏因为敏感的商业信息,您可能无法提供董事会的照片.我正在寻找你的电路板看起来是什么样的,以及你如何在典型的sprint/iteration中组织用户故事和任务？
通常情况下,我在一个组织董事会的地方工作如下
User Story | Todo | In Progress | Ready for QA | Done |
UC-001 | Domain Object, Service | DAO(Bob) | | |
UC-002 | Payment UI Screen | | Payment Srv (Don)| |
UC-003 | | | UC-003 | |
| | | | UC-004 |
| | | | UC-005 |
总结一下:
这可以作为一个有形的白板,涉及人们与每个任务/用户故事(表示为便利贴)进行交互.在sprint/iteration之前创建电子版本,并且仅在与当前情况对应的sprint/iteration结束时更新.欢迎评论和批评:)
我们的IT经理正在推动ITIL,我只是对它非常熟悉并且想知道ITIL是否适合敏捷的工作周期？
根据我最初的印象,我会假设没有,主要是因为我们的经理提议的是将时间表与所有内容放在一起,将SLA告知业务"高优先级任务必须在x小时内完成"等等......我们会因为开发人员受到处罚如果我们不符合这些SLA的话.
如果有的话,我更喜欢谈判策略,其中时间表基于敏捷的速度和故事点方法,以便与最终用户协商预期的时间表.
We have our agile development practices in place, test driven development, continuous integration, there's areas for improvement but we're working on it.
What are others experiences with ITIL and Agile methods working together?
在传统的瀑布中,需求被收集 - 通常在MS-Word文档中 - 遵循一个深奥的模板.在"严格"瀑布模型中,此文档在需求阶段后冻结,并且变更控制/变更管理流程负责引入受控变更.(**)[通常,文件变成"活文件",最终成为"生活噩梦"]
目前,我将领导一个项目,将现有桌面应用程序重写为Web(从VB 6.0到ASP.Net).客户端具有他想要重写的应用程序的基线版本.[所以要求被冻结......没有范围蔓延].要按原样重用的数据模型.仅迁移前端/业务规则.看看应用程序,我觉得它最多是3/4主屏幕就是这样.
一些团队成员希望在他们开始新开发之前记录(在我看来,旧的思想流派).我和其他一些人认为,将UI转换为Web,查找旧代码,编写业务逻辑,进行自动化单元测试,继续进行集成测试以及按屏幕(或按功能划分的业务功能)进行屏幕显示相对容易
我的问题是:在敏捷开发中,如果我不优化它,我将如何保持"敏捷".我的意见是编写详细的文档是反敏捷的.你怎么看？敏捷大师将如何解决上述问题(将现有的VB 6.0应用程序重写为ASP.Net)？
免责声明: 创建1000页的功能规格可能是为了履行合同义务,这是一种政治需要,系统可能真的很复杂(现在,"复杂性"的定义是一片黑暗的旅程).
我正在研究一个正在探索采用敏捷开发实践的可能性的团队.
我们遇到的一个问题是决定何时完成迭代(sprint).
假设我们已经定义了我们的功能积压,并为他们制作了故事点估计,我们已经确定第一个30天的冲刺将包括功能A,B,D和F.如果你在你身边,你应该怎么办？到达冲刺结束时你已经完成了A,D和F - 但是B只完成了80%.你应该:
按时完成冲刺但排除功能B(将剩余的工作推迟到未来的冲刺)
将sprint扩展到完成功能B所需的时间,但不启动下一个sprint.
将sprint扩展到完成功能B所需的时间并开始处理下一个sprint.
整个sprint失败,捆绑所有工作成为未来版本的一部分.
我在选项1中看到的问题是团队没有提供它所承诺的内容.在某些情况下,您可能无法在不使整个版本无用(或至少实质上不那么有价值)的情况下排除功能B. 如果没有特征B,可能难以指导下一个冲刺的方向.
选项2的问题在于团队中的某些成员可能在很长一段时间内闲置 - 这会影响整体生产力.您可以添加更多单元测试或抛光功能,但不会增加比例值.在政治上也难以向管理层解释为什么你的大部分团队都处于空闲状态.
选项3似乎违背了敏捷的精神 - 你不会让前一个sprint的结果引导下一次开发迭代,从而使下一个sprint面临风险.
选项4似乎很严重,并且在选项1和3中存在大多数相同的问题.首先,您完全错过了承诺.其次,将更多功能捆绑到后续版本中会使得更难以与客户进行测试和验证 - 并且它再次排除了根据之前版本的反馈来指导未来迭代的能力.
我的团队的目标是尽量减少构建中断的时间.
我们使用CruiseControl.NET进行持续集成.我想知道的是如何最好地回答以下问题:
"在上一次{timespan}中,{project-name}花了多少时间处于破碎状态？"
例如:"过去1个月,我们的项目花费了多少时间处于破损状态？"
是否有任何CruiseControl.NET的高级功能可以在某种类型的报告或仪表板中的某个位置提供此信息？
或者,您将如何解析xml工件文件以收集此信息？
cruisecontrol.net continuous-integration report agile-processes
我怀疑我有腐败的mergeinfo,但我不确定.有谁知道我如何做出决定以及有哪些资源来帮助解决问题？
这是问题所在.我的团队最近转向敏捷并使用功能分支(真正的故事分支),其中不同的团队同时处理相同的源.随着故事达到高度准备状态,团队合并到主干.由于缺少更改,意外更改和冲突,合并需要数天或数周.我们正在谈论5-10人的团队,努力/流失似乎很高.
人们使用这种合并模式a)PULL - 合并trunk到分支,解析,测试,提交b)PUSH - 合并分支到trunk,解析,测试,提交c)重新创建分支(或者通常创建新的故事分支和因为它已经完成了
到此为止,树枝和树干应该对齐.
我们遇到的问题:
(1)不应该发生.从分支到主干的拉动应使两者同步,以便在主干上进行所有更改.分支到中继合并的变化是主干上发生的变化.因此,在第一次合并时,它们应该传播到分支但不会.这指向mergeinfo数据中的损坏,这将"隐藏"主干更改.
(2)不应该发生.SVN应该管理合并跟踪中的更改.这也表明mergeinfo数据中存在损坏
(3)不应该发生.这是在分支上添加新文件的情况.它应该显示为添加到trunk的新文件.这也表明合并信息数据中存在损坏.
(4)我认为这是一个SVN错误,我们无法解决这个问题.如果这是我们唯一的问题,我会很开心
我们目前在svn 1.5.x服务器上,客户端使用svn 1.6.x和svn + ssh进行连接.我们计划推出最新最好的SVN,因为一些修复可能会影响我们的问题.
不过,看起来我们的mergeinfo数据确实是错误的.
我有什么好的地方可以开始寻找吗？
敏捷/ Scrum是答案吗？Scrum如何处理这个问题？
一个产品负责人,一个产品积压与多个产品所有者和产品积压？
它对你有用吗？请分享你成功失败的故事？
我正在尝试将一个流程放在一起来管理多个工作队列,包括基础设施项目,简单的功能增强,然后是一个由6-7个开发人员组成的小型开发团队的大型项目.