2019 项目总结
文章目录
【注意】最后更新于 May 13, 2021，文中内容可能已过时，请谨慎使用。
- State “DONE” from “TODO”
叙述几个比较深刻的项目
拍枪杆
19 年是一个自省年，项目组重组之后，在团队协作上都是一种新的挑战，从拍抢干项目第一次接触新的开发模式，本着学习的心态勤奋努力敲代码，在领导的培训下，给出了设计是第一生产力，努着劲自学类图、用例、流程图和时序图来提升开发效率，从根本上弥补自己的短板，在拍抢干中着实挑战了自我，在开发实践中，有意识的摸索提高考虑的开发流程中，明显对产品需求分析更加积极，理解的更加透彻，在自我提升的同时，就着对项目负责的态度，多次在会议上提出产品的设计缺陷和尝试商讨出一个弥补缺陷的方案.
提前发现问题，确保项目第一次尝试敏捷开发进度能够健康交付，期望是美好的，开发后期，产品设计和开发过程中之间状态百出，为保证两周迭代周期的生死线，不得不每天加班至四个小时，来弥补产品前期设计，需求评审的不严谨导致工作量估算严重不符，后期需求的变更成了家常便饭一样诡异现象。
电梯药店
临近年关，药店和电梯相对陌生的术语迎面扑来，在大家都不知道为何物时，领导却在不留余力的造势，一味的纠集所有开发者，快速评审需求，产品在台上滔滔不绝的讲述原型设计，导致刚从上一个项目中出来的几十号开发者,没有看过文档，没做丝毫准备就被强行开会，只能在这样紧迫时间下，听领导走马观花式流程图概述，然后全凭自个的悟性去消化理解！两个产品经理滔滔不绝，仅用一个半小时把所有的需求灌输给了一脸懵逼的程序员，会议上各个云里雾里，面面相觑，整个团队都是蒙的，更别提无效的讨论和所谓的自由发问的话语权，诺大个开发团队却鸦雀无声的傻坐着，唯独先入为主的测试人员了解一点需求，洋装着烘托气氛提问上几句不知所以然的问题。也许所有开发者都寄厚望在需求反讲上吧，事实证明，项目的紧迫特殊性跳过了需求反讲，仅上演了团队内部对工作量估算的考核和对工期压缩的大义凛然!
本期开发需求描述多以复用已有功能，对开发者而言，新功能近乎没有具体需求，旧功能也不是自己所熟悉的范围，再者项目管理的长期以来的通病，不仅没存档任何需求文档和开发文档，连少的可怜的代码注释也是凤毛菱角，产品和领导只能施压程序员，让程序员自己去挖掘旧功能弥补新需求，这无疑是对开发者极大的挑战，也致使项目结束后，整个团队的战斗力已经造成不可恢复的耗损。
自我建议和目标
设计能力提高
设计驱动开发，设计不仅启发于功能需求，更是检查需求合理性的工具，应该站在整个项目角度来衡量架构模型。团队对设计环节忽视，很难有多余时间用于设计，以致于开发前期对需求理解不透彻，反讲不到位；后续的开发过程中，甚至在联调接口时，才暴漏的需求问题和代码设计上的缺陷，有时不得不再耗费大量时间来重构。
目标:在需求用例反讲之后,开始代码架构设计,希望能通过需求用例 uml 图,分解可复用的功能,引导开发设计,封装可复用的功能代码块.实现灵活应对需求变更问题.
进度掌控力
在需求评审不做设计，对需求理解模糊和 UI 评审滞后的情况下，仅凭原型图和开发经验来评估工作量的项目管理模式下，对 UI 页面和相关需求逻辑作出正确的评估是一项极大的挑战。经常会出现实际开发周期和估算周期有很大出入。除了提高开发效率和提高对需求理解能力同，才能更准确的预估项目工作量，有效的把控项目进度，稳步向前推进。
目标:在充分理解需求之后,评估开发量和工作时间安排,合理估算开发周期,才能保质保量如期完成开发任务.
设计归档
文章作者 iTBoyer
上次更新 2021-05-13