joh*_*nny 6 agile project-management scrum
不是真的想看书.我见过很多引用和链接.我现在不能买.我一直在网上看书,看视频等.到目前为止我还没有得到一件事.愿景(问题的解决方案)和产品积压之间的关系.从我读到的,我认为这是用户故事,但我不确定.
网上有什么能以线性方式展示从视觉/概念到最终的所有步骤吗？
谢谢你的任何指示.
编辑:在需求收集,只使用Excel？
用户故事和许多关于什么是必要的和什么是绒毛的谈判.
很多谈判.
在架构上也有很多来回反复.Scrum需要一个稳定,经过验证的架构.但是,总会有升级和增强功能.那些符合积压的东西怎么样？这是产品所有者,技术人员和(在某种程度上)用户/购买者之间的许多政治争夺.
该过程本质上是非线性的.
这更像是结晶.你有一个解决方案,你开始写故事,你有技术愿景,你有一个具有一定技能和经验的团队.
这些功能中的任何一个都可以作为决定积压和订单顺序的"核心".最终,某些东西成为核,混合物结晶.有时成本或进度或风险是不可接受的,所以你要加热它,找到另一个核,看看它是否可以在新核周围结晶.
顺便说一下,重复结晶发生在每次冲刺之后,使其更加线性化.
编辑."稳定可靠的建筑".
问题:谁支付学习新架构的费用？
答:哈哈.没有好的答案.因此,在进行开发冲刺时,要小心你做了多少架构学习.
如果你没有(a)工作的架构,并且(b)几乎团队中的每个人都可以表达,那么你将花时间组装这个架构.
创建体系结构的时间和成本对您的第一个sprint有何影响？
您必须将架构开发纳入第一个sprint,延迟事情.
假设你决定实现一个LAMP堆栈.您不知道是否要使用PHP,Perl或Python进行unix.所以你选一个.像Python一样.而且你承诺在四周内第一次冲刺.因此,您需要工作3周才能使用kabillion add-one模块和框架.3周后,你认为你有一个工作的技术堆栈,但你没有承诺的冲刺.
你拖延了吗？如果是这样,那么每个人都会问你是否已经适应了这个步伐并开始将所有其他冲刺的时间加倍.
你什么都没有提供？如果是这样的话,如果除了基础设施之外你什么都没有,那么冲刺的重点是什么？
您可以在易于管理的部分中更改,修改和增强基础架构.但要建立一个新的架构,证明所有部分,培训每个人并开发最佳实践需要时间.很多.那个时间不应该 - 真的 - 被称为冲刺时间创造可交付产品.这是开销时间.
编辑.工装.
规则1.敏捷流程不使用大量复杂的工具和流程.这就是为什么我说这个过程是很多"谈判"的原因.无论是什么让你富有成效.
规则2.不要过度思考.去做就对了.
大多数人说 - 以最强烈的方式 - 使用5"x8"纸卡并将它们粘在墙上.认真.没有工具.只是简单的纸张,标记,磁带和空白的墙壁空间.
请阅读:http://www.agilemodeling.com/artifacts/userStory.htm
您可以使用电子表格收集用户故事(和史诗 - 必须分解的故事).您可以为复杂性(故事点),成本,优先级和发布添加列,并将其用于项目管理.
我们使用用例(不是用户故事),但工具是相同的.在某种程度上,用例是预先提供更多详细信息的用户故事.但是用例名称可以总结一个actor如何与系统交互; 通常可以用清晰,简单的名词和动词来概括交互,这非常类似于用户故事.
电子表格看起来很方便,因为您可以在每个sprint结束时重新排列行.您可以进行简单的计数和总结,以确定每项功能的成本以及它们何时到达.
我没有使用电子表格,因为 - 尽管GUI闪闪发光 - 我发现它有点麻烦.我觉得有必要编写一个电子表格提取器,将积压从Open Office Org文件转换为ReStructuredText(RST).我更喜欢RST - 纯文本标记 - 而不是电子表格.
这都是旷日持久的谈判.每次谈话都会改变一切.这就是敏捷方法的重点.快速冲刺,然后在下一个冲刺的方向上进行协商.
我们的积压是一个很大的RST文件.我们使用Sphinx发布所有文档 ,在RST标记中编写积压,用例,体系结构,设计等非常非常简单.
我们的冲刺只是一个大文档树的部分.它们用一些特殊用途的解释文本字段装饰,用于主观事物,如估计完成日期和状态(正在处理,发布).