Jon*_*han 5 agile extreme-programming process user-stories
我来自XP背景.我非常了解这个过程,并且拥有扎实的工作经验.我发现它是开发软件的最佳方式.
我发现自己处于各种过程医生的位置,这对我自己的理解产生了很多自我检查和重估.
我听到一个非常普遍的事情是,有些作品不能成为故事.我个人不相信这一点.借口包括
这个问题是获得提示,提示或建议.
我正在寻找关于如何解决这些和类似的感知问题的提示,技巧和建议(如果你能想到它们,还有更多).
我将标记答案,其中包含有关如何绕过不会写故事的用户/开发人员的最多信息,并解决他们为什么不这样做的许多借口(我只列出了一些,还有更多).
Pas*_*ent 13
以下是我收集的一些资源,可能有所帮助:
太大或太复杂,总有一种方法可以将故事放在饮食上(也许你不会在一次迭代中获得最终结果,但这并不意味着你不能,而且,不会有一个以上迭代).
sle*_*ske 10
所以基本上,你的问题是"如果人们声称任务对于用户故事而言太大,并且无法拆分,我该怎么办？
根据我的经验,几乎任何问题都可以分开.询问他们是否可以实现简化版本,省略高级功能,甚至可能在某些地方使用默认值; 基本上可以生成在一次迭代中产生有意义(即可测试)结果的东西.
请记住:迭代的目的不是提供完整的功能,而是提供有用且可测试的功能.
这种分裂可能很困难,但它迫使你首先考虑你真正需要的东西,这是非常有价值的.开发人员可能会喋喋不休(我常常自己:-)),但这确实是必要的.将大任务分解为可管理的用户故事是所有敏捷方法的核心.
也就是说,如果任务真的,真的,真的不能被分解(在研究环境中考虑复杂的数学算法,甚至需要花费数周来理解基础),那么你的迭代太短了.迭代需要足够长以产生有意义的结果.如果你的大多数问题都很难以花费2-3个月来完成任何事情,那么这就是你的迭代长度.但我从来没有见过一个真正如此的项目......