在一个真正的敏捷项目中,企业扮演产品负责人的角色,业务分析师还有角色吗?用户故事开发完成后,产品所有者将立即进行功能测试,并记录用户故事并确定用户故事的优先级。
在这种情况下,我必须补充一点,我还没有经历过,对于高绩效、自我激励的开发人员,我很难看到传统业务分析师的角色?
可能是主观的和/或讨论..但是这里.
我被要求估计下一个重要工作的功能.我把它分解了......使用故事点得出估计值.然而,除了各种其他公司计划之外,该功能还要求与GoDiagrams连接第三方图表组件.(一整套2008_Limited_Edition框架/服务:).我一直在跟踪自己使用燃尽图表,我发现我无法维持我的节奏主要是由于"尖峰".定义
我估计每周2点,然后我发现自己在周末工作(很好地试图......最终在这里也没有),因为我无法弄清楚在哪里挂钩以便我可以预览用户操作,显示上下文菜单等等.最后,我花时间制作尖峰,使我的日程安排偏离轨道......并降低其价值..但没有给出正确的图片.
需要钉子才能将钉子穿过无知的木板.但它们如何计入估算方程?在功能看起来错误之前做所有必需的尖峰..(可能会变成YAGNI)在中间执行它会扰乱我的流量.现在正是在预迭代规划期间......但这是每周推出界线.
该项目定义不明确:我们将为CS 111计算机编程I学生编写教育软件,专注于功能.我们有6名具有不同背景的学生开发人员在Flex工作.该项目的持续时间约为7周.我们的面部时间非常有限(每周30分钟),工作时间非常有限(每位开发人员每周<8小时).我们对客户的访问权限有限(我们的课程教授,CS 111教授,CS 111的学生).
我们的工具集包括Flex Builder,Subversion和TRAC.
什么方法最适合这个项目?为什么?或者,应该从各种方法中收集哪些功能以更好地适应这种情况?
Schwaber&Beedle的"scrum"书(以及我读过的其他scrum文章)似乎专注于在sprint结束时拥有可释放的产品.已建立站点的Web开发(至少在我们的案例中)包括开发"增强"(各种大小)和许多小"修复".仅在sprint结束时部署(到web)会减慢我们对大型增强功能的部署(可能是一件好事),但会大大减慢我们对小增强功能和修复程序的部署速度(即错误时间更长).
scrint的中间冲刺部署是异端吗?冲刺是否适用于我们的情况?我完全误解了冲刺吗?
看看我在使用敏捷建造飞机的问题中的评论总趋势,除成本之外的最大问题似乎是安全性.
人们是否觉得使用敏捷建立一个安全系统(或证明它是安全的)是不可能的?并非所有的迭代测试都能缓解这个问题吗?使用敏捷开发的软件是否可能永远不会像瀑布那样可靠?
我们建议在我们的IT项目中使用Scrum,我们的顾问会询问我们是否适合我们,因为我们仍然是业余爱好者.
即使我们是业余爱好者,我们Scrum也适合吗?
我们最近采用了用于验证域对象的规范模式,现在想要引入域对象的单元测试以提高代码质量.
我发现的一个问题是如何最好地对下面示例中显示的验证功能进行单元测试.规范命中数据库所以我希望能够模拟它,但因为它是在线实例化我不能这样做.我可以处理接口,但这会增加代码的复杂性,因为我们可能有很多规范,我们最终会有很多接口(记住我们正在引入单元测试,并且不想给任何人找借口来拍摄它下).
鉴于这种情况,我们如何才能最好地解决单元测试域对象中规范模式的问题?
...
public void Validate()
{
if(DuplicateUsername())
{ throw new ValidationException(); }
}
public bool DuplicateUsername()
{
var spec = new DuplicateUsernameSpecification();
return spec.IsSatisfiedBy(this);
}
Run Code Online (Sandbox Code Playgroud) 我问,因为我的团队之前曾试图 "做"scrum.我们进行了为期两周的冲刺,但没有与这些冲刺一起发布!还有其他几个原因,但一个重要原因是部署时间太长而且太复杂,不能经常这样做.
agile ×10
methodology ×2
scrum ×2
unit-testing ×2
azure-devops ×1
backlog ×1
c# ×1
deployment ×1
estimation ×1
reliability ×1
settings ×1
sprint ×1