五年沒有搜尋過104 發現多好多新的關鍵字
像是 敏捷開發 , 了解後發現跟目前我接觸工作方式差很多
這邊先分享我的經驗 :
像是我這邊常要求甚麼都需要文件齊全,思考完善,上級同意後才能做
避免後續吃問題扯皮,責任歸屬問題
但是看敏捷開發,目前發現它的理念很好,但我感覺上層可以過得靠嘴的生活,但底層會特別累? 是我的理解錯誤嗎
請問有大神能分享公司實際實施敏捷開發底層的經驗嗎?
像是我讀到有一篇自稱敏捷經理的人寫的文章 项目一再跳票？试试这一招：用Deadline倒逼生产力
Deadline为什么能创造出巨大的生产力？
为什么Deadline这么神奇，能创造出巨大的生产力？
无论是个人的事情还是项目，生产力低下，不能按时完成的原因，总结下来不外乎三种：
1. 想太多
2. 过于追求完美、关注细节
3. 不够专注
......略
所以说，Deadline之所以能提升生产力，归根结底，是由于利用Deadline，倒逼着你缩小“范围”，做当前最重要最有价值的事情；利用Deadline，让你专注，不浪费时间在不重要的事情上。从而可以把Deadline，变成第一生产力。
已邀請的邦友 {{ invite_list.length }}/5
很多接案性質的專案，需求變化反覆，今天跟你說要做A，明天就跟你說A要翻掉
站在老闆跟管理者的角度，希望專案時程越短、越快收到錢越好
也就是常聽到的，因應瀑布開發無法快速面對需求變化的缺點
所以大多接案性質的公司會採敏捷式的開發模式開發
如果敏捷式開發的團隊當中，主導的人能力不足、經驗不足、沒有擔當、不會訂時程
那麼下面的人就會被各種沒必要的需求修改，搞得生不如死
反之，會讓專案跟整個團隊非常順利跟愉快
例如我某個上司曾經遇到的，PM請工程師撈取通訊資料，從1分鐘抓一次，改30秒抓一次，然後改只要有更新就要抓一次，最後改回來30秒抓一次。上司開會直接罵PM
對PM而言，覺得只是改撈取通訊的時間頻率而已
但是對工程師而言，還要考慮改時間會不會造成其他影響，以及定時或即時該用什麼做法比較適當
還有一次PM在下班前要我改個很急的東西
結果我主管看到跟我說，PM之前不是已經跟我討論好，決定不用改嗎？
後來問PM，PM想到才表示「拍謝我忘了」
最扯的是有一次寫好某個專案需求
該專案的PM竟回我：我無法保證我要你寫的東西，是客戶想要的喔 (公..)
那一家的PM亂象亂到我最後選擇離開
樓主的公司應該屬於「瀑布式」的開發
適合大型的專案開發，或是容錯率極低的系統開發
公司內部開會決議後，先交由SA SD 分析需求，接著開規格請工程師開發
工程師交付測試無誤，發布產品包與更新包。
我待過這兩種，PM跟團隊正常的話兩種都不會太差
這兩篇針對瀑布和敏捷分析得很完整，你可以參考看看
https://medium.com/uxeastmeetswest/%E6%95%8F%E6%8D%B7%E5%BC%8F%E9%96%8B%E7%99%BC-agile-%E7%80%91%E5%B8%83%E5%BC%8F%E9%96%8B%E7%99%BC-waterfall-%E6%95%8F%E6%8D%B7%E5%BC%8Fux-lean-ux-%E5%85%9C%E5%B9%BE-7f510cdd5fae
Run了兩年多的Scrum開發模式，覺得是滿有效率的，我是developer的角色，根據User Story完成或是bug ticket修改，每天早上會報告各自的進度，兩週和業主review一次
我覺得最重要的是BA和PM要確認需求然後把User Story寫好寫對寫清楚，這樣developer就很輕鬆
敏捷團隊很依賴人，而且總參與人數不能太多大約8以上就必須在拆團隊
因此 scrum master 這個角色非常重要（敏捷團隊核心）
但如果大家都可以好好執行敏捷精神，敏捷也是一個很好的專案執行模式
可以一直持續有產出，做好的功能一直可以得到驗證
But 只有有幾個就只是想上班領薪水的人，很難自動自發run 起來就會比較辛苦
所以大企業要轉型，最優先是可以把整個專案生死整控在手上自行負責的專案
敏捷才有機會能成功，否則容易最後又是會推責任的結局
iThome鐵人賽
看影片追技術