“工作/可用的软件高于详尽的文档“
"客户合作高于合同/商务谈判”
"响应更改/变化高于遵循规范/计划”
可以总结为:
1。以人为本:尊重每一个个体,重视个体间的合作互动
2。以目标/最终交付结果未导向,最终交付的是可使用的软件(相信我,可用的软件是堵住客户嘴巴最好的方法。文档……不浪费A4纸吗?不浪费磁盘存储空间吗?)
3。客户为先:理解客户需求,与客户合作(天平要始终平衡,偏向研发会引起大量客户无法理解操作的逻辑,偏向客户:亏大家都吃过,不赘,述写到这里,忍不住摸一把眼泪,我太难了。)
4。拥抱改变:基于第三条,客户实在不断变化的需求中,明了自己想要的,因此研发团队要拥抱变化。(别钻牛角尖,有人反驳“比白色更白,五彩斑斓的黑”这些梗不讨论)
文档还是需要滴,毕竟可用的软件+规范的文档,会让客户对我们更信任,只是我们应该更关注人,产品模型,写作和迭代。只有随时有成品(原型,功能)交付给客户/项目委员会,才能更好的让项目进行下去,才会将编码工作更好的最大利益化。
讲到这里,笔者不禁要说上几句废话”时间,质量、成本,上级满意度,客户满意度”即思想不仅仅适用于工厂,同样适用于软件行业,这几条决定我们是否能更好的实现“理想的生活,生活的理想“.......别告诉我,你做软件是为了兴趣等空话,至少笔者目前的觉悟无法达到这种高度。
敏捷原则:
1。我们最重要的目标,是通过持续不断地及早交付有价值的软件是客户满意。
根据GTD四象试图,“紧急的但不重要的,紧急但重要的,重要但不紧急的,不重要不紧急的”这种方式,管理生活,工作,发现会很有用,至少对我来说,收获不错。敏捷中采用迭代事项按照优先级安排,限制在制品的数量,看板,故事卡等方式,为客户尽早提供有价值的功能,同过频繁的刺探和客户的反馈来及时调整研发方向,提高程序的质量,建立客户满意度及客户利益最大化。
敏捷小组关注完成和交付有价值的功能,而不是鼓励的任务。基于“作为【用户类型\需求,我们希望可以【专业技能/能力】以便实现【业务价值】”的故事方式来分析挖掘需求,原型和文档也会需要编写,也是一种交付,只是更多的工作重点,转到口头交流,看板,迭代工具,每日批斗会(手抖,打错了,每日站会。国内大部分都是批斗会,别问我怎么知道的.....)。
2。即使在研发后期,也欢迎更改需求。敏捷过程利用变化来为客户创造竞争价值。
敏捷者不怕变化,只有通过更改需求,才让我们更好的理解市场,成为独角兽,抢占市场份额。(企业做好了,参与者自然....当一天和尚撞一天钟这种想法地人,实际上在蹉跎光阴,趁早改行,不接受任何反驳)。
3。经常性的交付可以工作的软件,交付周期可以从几周到几个月,交付的时间越短间隔越好。
不予玉璞示人,不适合软件研发行业。加入这个行业,就是加入高度不确定性的工作,迭代是受实践框架限制的,意味着要放弃一些我们认为很有创意的功能也必须按时结束迭代。只要我们可以保证交付的软件会很好的工作,那么交付时间间隔越短,我们和客户的协助,信任度,回头度就会大幅上升,产品质量和市场实用性就会更有益。
