在瀑布中保持敏捷[关闭]

至少你可以开始编写单元测试,甚至在环境允许的情况下,自己编写测试驱动的开发(也可能在你的同事中传播这些想法)。你可以在没有管理层注意到任何事情的情况下改变很多;—)

当然,在一个普通或更好的地方,管理层的人并不是完全愚蠢的。随着时间的推移,当您在开发团队中设法提高对这些问题的认识时,您(作为团队,集体)也可以与高层管理人员交谈,并说服他们朝着正确的方向采取步骤。从小处着手,获得具体的结果,并在其基础上进行构建——通过在开发团队中以及(尽可能多地)在管理层和用户中找到盟友来构建杠杆。

很多时候,某些过程只是因为“我们总是这样做”。如果你能向人们展示有更好的方法——并用令人信服的论据来证明——你就有很好的成功机会。注意,管理层和用户需要与开发人员完全不同的参数。你可以尝试粗略的成本效益计算(或者谷歌——我很确定网上有很多关于这些的东西)。我还记得在 Kent Beck's first XP book . 您还可以收集bug统计数据,这些统计数据随着时间的推移(希望)表明,以敏捷方式开发的特性在以后(集成测试或生产)阶段的缺陷明显减少。(为此,如果您还没有缺陷跟踪系统,则需要一个缺陷跟踪系统。)

另一个有用的工具是提问。如果你有什么东西——一份文件,一种做事的方式——你不明白,敢于问问题:

• 我们为什么要这样做?
• 有更好的方法吗?
• 我们真的需要这样做吗?
• 谁需要这份文件?
• 她实际上需要什么信息?
• 它是否包含正确的信息?
• 是最新的吗?
• 谁更新了它?

通常人们只是把事情当作“给定的”,但当你开始问原因时,你可能会发现很多有趣的事情…以及改进的想法。

一个非常有用的敏捷工具是 retrospectives . 在每次迭代之后(无论在实际过程中调用什么),团队都会聚集在一起,进行头脑风暴。

• 这个迭代中出了什么问题,以及如何确保它不会再次发生(或者至少在某种程度上改进它)。
• 做得很好,如何确保它能像那样继续下去

这可能很容易被管理层接受,并且是开始积极变革的好方法。最重要的是唤醒和激活人们——让每个人都意识到项目的成功或失败(至少在某种程度上)掌握在他们自己手中,他们 可以 做点什么来改善情况。

根据我的经验,大型企业关注风险、可预测性和可测量的结果。你会更容易(尽管可能不会 容易的 )如果展示敏捷如何比现有的实践更好地与这些度量相一致,那么引入敏捷的时间就到了。

1. 成功 可能的 经常装运,即使你还没有这样做: 利用CI工具和自动构建脚本来构建和打包应用程序。这样,您就可以利用任何可能出现的增量发布新代码的机会。

2. 衡量你的生产力 现在 这样你就有了一个基线: 你测量得越多越好。

   1. 每个“功能”的程序员平均小时数。
   2. 代码签入和发现该代码缺陷之间的平均时间长度。
   3. 在生产中发现缺陷和解决缺陷之间的平均时间长度。
   4. 识别、解决和部署缺陷修复所需的平均时间。
   5. 等。

3. 在敏捷过程中预测这些指标的变化 :例如,在大多数情况下,我们越早发现一个bug,修复起来就越容易/越便宜,因此从TDD和快速发布到QA的好处应该很容易量化。

4. 从小处开始 :您可能有一个瀑布式时间表,但是您仍然可以将其分解为迭代,所以也可以这样做。准备好工程实践,然后开始尝试调整过程。看看你是否可以在一个小的辅助项目上尝试敏捷作为概念的证明。

5. 寻找赞助商 :试着说服 某人 在敏捷的优点方面,你比你自己更有优势。让他们帮助制定决策者熟悉的“敏捷vs.瀑布式”论点。

6. 耐心等待 ……查看结果可能需要一些时间。

7. …或者不要。 如果你对敏捷很感兴趣,并且得到零支持,那就找一份新工作吧。是的,从野兽的肚子里改变是值得的,但是与那些 分享 关于构建软件的想法。

敏捷就是要打破那些瀑布墙。bduf;同时的多组件发布;开发人员和业务流程所有者之间缺乏沟通;计划的迭代——这些都阻碍了瀑布式流程的发展。

在我的位置上,我们已经拆掉了很多这些墙——从 直接接触客户 . 当这种情况发生时,客户得到了更好的产品。这导致了更快乐的顾客。把像bduf之类的东西赶走了。

我们仍然没有真正的迭代/冲刺、持续集成等,但是我们正在实现。(旧习惯,等等。)

作为开发团队,您仍然可以使用敏捷方法(测试驱动开发、结对编程、故事卡、CI、公共语言等)进行内部协调。

在我看来,敏捷性是指能够对软件的变化有信心,并防止在没有人需要三步走下瀑布路线的功能上进行大规模的错误投资。测试、重构和避免过度工程是这里的关键。

在我看来,问题不在于你使用的是瀑布而不是敏捷。瀑布式实现有很大的问题。最明显的是:

需求聚集不知道 商业

如果处理得当,瀑布可以而且也可以很好地工作。我认为这听起来像是一些参与其中的人,他们是如何做事情是错误的,而不是概念过程。

根据您的领域,自动化测试和持续集成应该是可行的。

另外,考虑为您当前分配的任务制定自己的高粒度燃尽列表(inchstones)。它应该有助于您的工作评估更具可预测性,并使您更容易解释任何进度延误和计划外任务。

通常,跟踪系统中的一些指标。如果您能够展示一些敏捷技术的附加价值(缩短周期时间、降低缺陷率等),那么您应该可以很容易地在该技术上推销自己的领导地位。

…根据经理的不同,你可能希望避免使用“敏捷”这个词,尤其是如果你只是想在使用一种技术上取得小小的胜利。