2022-01-09 10:53:04|已瀏覽：143次
是的，軟件開發(fā)絕不是在公園里散步。
我們經(jīng)常解決無法預(yù)見的問題，如果你不犯這些常見的軟件開發(fā)錯誤，許多問題是可以避免的。我將引導(dǎo)大家解決錯誤，這些錯誤可能會破壞自己的辛勤工作并使有前途的項目白白失��！
作為開發(fā)人員、分析師、產(chǎn)品負(fù)責(zé)人、主管或 CTO，我遇到過這些所有問題，盡管有些看起來很基礎(chǔ)，但它們?nèi)匀粫䝼δ愕膱F(tuán)隊。請與我深入了解～
不了解產(chǎn)品
為什么軟件開發(fā)如此令人興奮？對我來說，這是因為有機會學(xué)到很多行業(yè)的知識。通過引入該領(lǐng)域的項目來創(chuàng)造并塑造它們的未來。比如人們有機會在人力資源、醫(yī)療保健、金融和各種行業(yè)的產(chǎn)品上創(chuàng)造價值。
雖然了解不同領(lǐng)域令人興奮，但也極其具有挑戰(zhàn)性。
如果你渴望構(gòu)建成功的產(chǎn)品，則必須了解其行業(yè)背景。對于我而言，軟件開發(fā)不是編碼，而是關(guān)于在盈利的同時為最終用戶尋找最佳解決方案。
軟件工程師的關(guān)鍵要點是——了解業(yè)務(wù)核心和應(yīng)該實現(xiàn)的每個功能。如果你只是一個聽命令的機器人，那開發(fā)可能是工作鏈條中最昂貴的部分，每個錯誤并不便宜。
我相信技術(shù)咨詢和代碼審查任務(wù)是技術(shù)專家的附加價值，他們可以糾正最初雇用你的公司業(yè)務(wù)人員的錯誤觀點。而能夠交換意見是團(tuán)隊相對于個人的最大優(yōu)勢。
假設(shè)即事實
決策是每個產(chǎn)品開發(fā)的核心部分。
很自然地，人們對以前的項目和假設(shè)看法會發(fā)揮作用。請注意這些問題，猜測比詢問別人更簡單，但它很危險！如果你碰巧做對了，那么幸運的，但如果不是，在開發(fā)周期的后期如果出現(xiàn)問題，那將會付出很昂貴的代價。
如何避免這種悲傷但常見問題呢？
與你的團(tuán)隊保持聯(lián)系，互相支持。如果你處理一個超級復(fù)雜的問題并且無法就最終結(jié)果達(dá)成一致，請咨詢或準(zhǔn)備一個小型實踐。
咨詢該領(lǐng)域的專家或用戶可以對這件事有新的認(rèn)識。假設(shè)和實驗特征的結(jié)果非常適合收集反饋，它允許人們實現(xiàn)一個可能是錯誤的行為，但已經(jīng)具有驗證其正確性的機制。該機制可能是一個指標(biāo)、一項調(diào)查、一個關(guān)于該功能的實驗性質(zhì)的可預(yù)見警告，包括獲取用戶反饋的簡單方法，然后由你和團(tuán)隊為特定假設(shè)選擇最優(yōu)機制。
缺乏溝通
溝通很重要。真的么？這句話你聽過多少次？天天說無數(shù)次。
然而在與各種規(guī)模和性質(zhì)的團(tuán)隊合作后，這仍是一個問題。而創(chuàng)建一個沒有人害怕發(fā)言的安全開放的環(huán)境，是避免無聲的積壓改進(jìn)、制定毫無意義的沖刺計劃和漫無目的的每日 Scrum 會議最行之有效的方法。
如果您想要的不僅僅是將項目從一列移動到另一列，請找到一位能幫助您指導(dǎo)開發(fā)的導(dǎo)師。比如你遵循 Scrum 框架但沒有 Scrum Master，則應(yīng)該去找一個。就像足球運動員不會在沒有教練的情況下比賽。
當(dāng)你意外發(fā)現(xiàn)只有 10% 的后端為你剛剛完成的新 FE 功能做好了準(zhǔn)備，或者實現(xiàn)的 API 調(diào)整不兼容時，去專注于溝通吧，它可以避免你在 sprint 結(jié)束時有意外驚喜。
關(guān)鍵要點是什么？
建立團(tuán)隊精神，讓人們喜歡彼此分享想法，如果覺得溝通太困難，請找一位 Scrum Master 或教練來簡化整體流程。
商業(yè)與技術(shù)語言的障礙
相互理解是有效團(tuán)隊的基石。軟件開發(fā)將兩個通常不知道如何溝通的世界結(jié)合在一起。以下是一些事情向南而失去意義的例子：
技術(shù)人員用技術(shù)術(shù)語，業(yè)務(wù)人員不明白；是不是很熟悉？如果想誠實地交流，而不是假裝交流，請了解您的聽眾并使用他們理解的詞語。
從上下文開始，概述問題，提出解決方案，解釋結(jié)果，提供示例，并確保你的聽眾完全理解。
錯誤 404：未找到上下文
假設(shè)為功能準(zhǔn)備新需求。你可以簡單地描述該功能應(yīng)該做什么，為什么重要，以及它將如何讓它更接近目標(biāo)。
或者，您可以概述從 A 到 Z 的所有內(nèi)容，而一點沒有討論的余地。哪一個更好？我相信大多數(shù)開發(fā)人員會更喜歡第一種方法。
新需求是討論的起點，而不是最終作業(yè)。因此，產(chǎn)品負(fù)責(zé)人應(yīng)該始終從上下文描述和反饋收集開始。了解問題及其背景的團(tuán)隊成員更有可能提出更好的想法。讓開發(fā)人員按照所寫的內(nèi)容精確地編程會浪費工程師們的潛力，并會導(dǎo)致誤解。
“為什么的問題”不是不信任或攻擊性的表現(xiàn)，而是興趣的表現(xiàn)，它是區(qū)分成功團(tuán)隊和不成功團(tuán)隊的關(guān)鍵。
是什么讓產(chǎn)品負(fù)責(zé)人重蹈覆轍？時間壓力是一個答案，但不能成為借口。有時需求完成得太晚了，開發(fā)人員的反饋沒有空間。設(shè)計已完成，文檔已編寫。在這種情況下，停止并丟棄需求可能具有挑戰(zhàn)性，但如果您沒有找到原因的答案，這仍然是值得的。
一些資源被浪費了，但許多資源被節(jié)省了，所以這里的教訓(xùn)是——盡快共同參與并從為什么開始。
團(tuán)隊內(nèi)部孤島
你的團(tuán)隊由后端、Web、移動、業(yè)務(wù)或測試人員的不同孤島組成。你需要所有這些都有意義地進(jìn)行，沒有人可以做所有的事情。每個氣泡或筒倉都應(yīng)該有自己的沖刺目標(biāo)嗎？
我們從產(chǎn)品的角度來看。
從一個項目開始，項目和用戶故事都不應(yīng)該被孤島隔開。他們不應(yīng)該指定哪個倉可以完成這項工作。重要的是為 sprint 評審提供一個可交付部分——最終用戶可用的東西。
如果團(tuán)隊經(jīng)常無法在一個 sprint 中交付完整功能，要么是 backlog 項太大，要么是團(tuán)隊結(jié)構(gòu)錯誤，要么是 sprint 太短。讓孤島合作來改進(jìn)工作流程，永遠(yuǎn)不要將孤島分配給順序沖刺，讓它們相互等待
積極主動，走出孤島，從一開始就精誠合作，調(diào)整流程并盡可能實現(xiàn)自動化。
最后
當(dāng)然，沒有硬技能就不可能編碼。無論您處于什么職位，合作、溝通或演說技巧等軟技能將決定將項目推進(jìn)何種成功程度。優(yōu)秀的公司不會尋找能夠勝任工作的人士，而是尋找能夠提供附加值的人才。
合作，理解他人，永遠(yuǎn)追求最好！
本文由培訓(xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο朐陂L沙參加影視動漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050
注：尊重原創(chuàng)文章,轉(zhuǎn)載請注明出處和鏈接 http://m.universityresearchassociates.com/news-id-13968.html 違者必究！部分文章來源于網(wǎng)絡(luò)由培訓(xùn)無憂網(wǎng)編輯部人員整理發(fā)布,內(nèi)容真實性請自行核實或聯(lián)系我們，了解更多相關(guān)資訊請關(guān)注程序開發(fā)頻道查看更多，了解相關(guān)專業(yè)課程信息您可在線咨詢也可免費申請試課。關(guān)注官方微信了解更多：150 3333 6050
