主頁 > 軟體工程 > Mayberry小鎮的管理 | 三種截然不同的領導風格 3M

Mayberry小鎮的管理 | 三種截然不同的領導風格 3M

2021-01-15 07:27:51 軟體工程

?2001、2014 Don Gray和Dan Starr

在北卡羅來納州的藍嶺山脈附近,離您應該想到的地方不遠,確實有一個名為Mayberry的小鎮,

盡管數年前主要公路繞過了小鎮,但Mayberry是廣受歡迎的1960年代電視連續劇的同名人物,這里仍然是一個熙熙攘攘的社區,每天早晨,美國北部52號高速公路的商業支線從北部進入梅伯里市中心,在鎮上進行了一周的咨詢作業,我們能夠觀察到這條路線上最近的道路建設,并觀看了三位當地居民展示自己獨特的管理風格,讓我們看一下這些人物的交通管理如何與軟體專案管理的通用樣式契合(暗示),

當位于城鎮北部的道路工程關閉了52號公路時,所有從北部進入城鎮的交通都必須繞過52號公路繞行至城鎮西側,然后進入Key Street的市區,不幸的是,這意味著交通將不得不左轉進入Key Street,穿越相當繁忙的東西向交通(見圖1),

Mayberry周圍的道路建設

圖1

鎮議會擔心,在早上匆匆忙忙等待左轉駛入Key Street的交通會一直沿匝道南行,一直延伸到52號高速公路本身,由于52號公路的時速限制為65英里/小時,因此可能會導致嚴重事故,因此,議會決定在交叉路口派駐一名警察和一兩個救援隊志愿者,以確保坡道上的交通不會擁堵,

三種管理方法

作為值班人員,值班人員(我們稱他為Barney)周一到達現場并迅速確定了情況,他認為需要的是在Key Street和坡道交匯處的交通信號燈,由于需要數月的時間來批準一個燈,他決定將其作為"人工交通燈"來操作,以手動方式引導交通,每個方向都有轉彎:西行Key Street(包括向左轉入南行坡道),然后是東行Key Street(包括向右轉入南行坡道),然后是下坡道(可以任意一種方式轉入Key Street),巴尼的計劃實際上并沒有那么好,Key Street上的雙向交通停滯,當Barney讓幾輛車左轉到Key Street時,交通幾乎都堵到了52號高速公路,

周二,一名救援隊的志愿者(一位當地有幫助的婦女,稱為Bea姨媽)說她知道如何管理這種情況,她認為,只要駕駛員不必橫穿彼此的道路,交通就可以自理,因此,她讓車流在Key Street上雙向行駛,并讓人們在匝道上右轉和右轉,當有人不得不左轉時,她會停止其他車道并讓它們走,Bee姨媽的方法比Barney的方法效果更好(至少沒有人對她做出粗魯的舉動),但擁堵仍然比我們預期的要多得多,并且在高峰時間結束時擁堵依舊,

星期三,安迪警長出現了,帶來了一把草地椅和一個檸檬水保溫瓶,他把草地椅放在一個陰涼的地方,從那里可以看到交叉路口和下坡路的一段不錯的路,然后坐下來喝檸檬水,當車流量開始在匝道上擁堵時,他起身,停止了Key Street的交通,讓匝道空了,然后他回到椅子那里,除此之外,安迪似乎幾乎什么也沒,盡管他顯然沒有采取任何行動,但交叉路口似乎仍然有效,人們保持冷靜和放松,駕駛員向右轉彎為他人創造了休息時間,向左轉彎,并且一切作業都像在任何人出現之前一樣,情況有所好轉,只是稍微好一點,

戴上顧問的帽子,我們意識到剛剛目睹了三種獨特的管理風格:Barney的微觀管理(Micro Management),Bee姨媽的母親式管理(Motherly Management)和Andy的專家式管理(Masterly Management),由于這些樣式在軟體專案管理中也很常見,讓我們更詳細地研究每一個,并了解可以應用于自己的軟體專案的內容,

風格問題

每一個管理者由不同的假設,而塑造自己的風格,假設要進行管理的人,以及假設對管理者的角色,這些假設決定了他們如何進行關鍵的管理活動,在溫伯格的《質量軟體管理》一書中,1:系統思考,溫伯格重點介紹了五項關鍵活動:

  1. 了解要解決的問題
  2. 規劃解決方案的方法,
  3. 觀察被管理人員的實際行為,
  4. 使用規則和流程模型來確定下一步要做什么,以及
  5. 采取行動引導小組朝著目標前進,

這些活動共同構成了一個"引導"專案團隊的反饋系統,它們的執行方式(即管理者定義為問題的方式,管理者如何計劃,進行了哪些觀察,遵循了哪些規則以及如何采取糾正措施)使所有事情有所不同 - 確定團隊的去向,團隊成員對整個軟體專案的感覺,以及最終結果將如何令人滿意,

微觀管理 (Micro Management)

Barney實行了微觀管理,這是基于以下假設:管理者必須確保一切都完成了,大多數微觀管理人員并非故意出于控制的需要而介入,他們只是在這樣的假設下運作:如果他們不這樣做,那將無法完成,微觀管理者也傾向于做出相關的假設,即被管理者將按照他們的指示去做,剛剛好,不多不少,

這些假設比人對機器的描述更好,確實,當巴尼(Barney)說我們需要"人流信號燈"時,他描述的是管理者和被管理者都比人更機械的情況,也許這就是為什么這么多優秀的程式員在獲得第一次晉升時就成為微觀管理者的原因 - 他們只是在"編程"為他們作業的"生物機器人"!

使用溫伯格的模型,我們可以看到巴尼(Barney)的假設如何定義他對關鍵管理活動的看法:

  1. 要解決的問題是親自確保一切都在有條不紊地進行,
  2. 接下來的計劃是讓Barney自己做所有事情,他將親自指揮每輛車的運動,這意味著該計劃必須足夠簡單,以使他可以隨時控制其執行情況,
  3. 即使有了簡單的計劃,Barney仍然忙于指揮交通以至于無法觀察到太多東西,站在十字路口的中間,當交通開始回落到52號公路時,他沒有在正確的位置觀看坡道,
  4. 即使他有更好的觀察力,但以管理者為中心的流程模型仍然不允許他做太多事情,基本的假設是,他對穿越交叉路口的每輛汽車都負有個人責任,這意味著他不能委派太多 -- 他不能指望駕駛員做他要告訴他們的事情以外的任何事情,
  5. 巴尼的舉止非常有限,因為他必須控制每輛車,所以他不能離開交叉路口的中間位置,最后,除了努力嘗試已經做的事情,他別無他法 - 更加瘋狂地向人們揮舞手臂,希望他們能更快地度過,

因為管理者必須做出(或至少批準)所有決定,所以一次只發生一件事,而其他所有事情則排隊等待轉彎,當簡單性,集中資訊和監督從美德變為弊端時,它會產生影響專案計劃和執行的瓶頸,

簡便性由于整個專案計劃都必須始終在管理者的控制之下,因此計劃必須足夠簡單,以使一個人可以完整地理解它,這就為專案的復雜性設定了一個上限-如果要解決的問題超出了這個界限,則管理者必須以某種方式簡化它(例如,一次只允許一個方向的交通),在微管理專案中,這種活動的序列化也是常見的簡化,并且浪費了精力和時間,當序列化還不夠時,管理者可能會開始將"不必要的"活動排除在專案計劃之外,微觀管理因過度簡化而臭名昭著,以至于他們的軟體專案計劃可能遺漏了成功推出產品所必需的東西,

集中資訊由于管理者是唯一可以做出決定的人,因此獲得有關專案執行情況的大量高質量資訊至關重要,不幸的是,唯一允許的觀察是管理者在專案計劃中提出的觀察,但是該管理者太忙于做出每一個決定來實際上觀察任何事物的決定,因此,在實踐中,微管理人員常常視而不見,很少或根本沒有實際資訊時就做出決定(草率的決定),

監督需要獲得每個操作的明確批準,這增加了完成任務所需的時間,因此,微觀管理往往效率低下,許多人在等管理者告訴他們下一步該做什么,瓶頸管理者是一個關鍵的結構性問題,這種做法還會導致人員問題,例如主動抑制,管理者的假設意味著,被管理的人員除了管理者定義的職能之外,沒有其他貢獻,如果工人想做一些不遵守規則的事情怎么辦-因為他們看到了更好的方法或計劃的問題?算了吧,微觀管理者將不允許它發生,對于那些受到微觀管理的人來說,這會造成短暫的脾氣和漫長的日子,

大多數人不喜歡這種管理風格,有些人會做出某種僵化的,機械的順從性回應,盡職地等待管理者的下一組指示,其他人可能會選擇某種形式的微妙的叛逆,例如"努力統治"-即使管理者的指示顯然是失敗的訣竅,也要遵循管理者的指示,其他人則將更公開地反叛,利用管理者的不斷分散注意力來逃避一切,micro,這些對微管理的回應往往會建立一個正反饋回路,從而加強微管理者的假設并導致更多的微管理,微觀管理者往往很忙,(越關注細節越忙)

那么,微管理曾經合適嗎?當然,要解決的問題足夠小時,一個管理者就可以真正理解整個專案計劃,而從事作業的人員則愿意遵循管理者的每一個命令,盡管這種情況有時會發生,但在軟體世界中并不常見,

進行微觀管理的一個常見原因是新晉升的,技術上合格的管理者急忙幫助陷入困境的員工或營救軟體專案的特定部分,這就形成了一個相互依賴的動力,其中管理者變成了救命稻草,員工卻變得無奈,這樣可以確保下次出現問題時,管理者將再次介入,依此類推,直到出現某種情況破壞了模式,

盡管微管理專案可以(并且經常)導致成功的產品發布,但更多的是盡管對其進行管理,而不是因為它,應該有一種更有效,更輕松的方式來處理這種情況,

母親式管理

Bea姨媽選擇了一種更友好、更溫和的風格,我們稱之為母親式管理,允許駕駛員自己做點事情,并在她認為需要幫助時幫助他們,但是她的基本假設仍然與Barney的假設非常接近:被管理的人也許可以在不被告知的情況下做一些例行事情,但是所有重要的決定-尤其是在存在某種形式的競爭時 - 仍然牢牢掌握在她的控制之下,

如果微觀管理者將人們當作機器來管理,那么大媽管理者會把他們看作是孩子,被管理者能夠做一些例行的事情,但仍然需要保護以免受到任何潛在危險的傷害,像微觀管理者一樣,大媽管理者不一定是惡意的或迫切需要控制的,Bea姨媽根本不需要控制司機,她只是知道,沒有她的幫助,他們將無法做出重大決定,她簡直無法想象一個人可能會左轉進入另一個右轉所造成的差距的情況,因為她無法看到誰在控制著這種關系,而且她知道兩個駕駛員當然不能沒有人來協調他們,

Bea姨媽的母親假設確定了她對關鍵管理活動的看法:

  1. 要解決的問題是像"照顧誰必須要跨越其他業務的人," 像巴尼一樣,她從個人角度看問題,這是她的問題,而不是駕駛員的問題,
  2. 因為Bea姨媽把司機看做是可以自己做點事情的人,所以她的計劃比Barney的計劃要嚴格一些,她可以允許至少一些常規的事情并行發生,但是在特殊情況下,她將完全控制所有事情,這意味著要恢復為串行執行,
  3. Bea姨媽的分散計劃要求比Barney更為復雜的觀察,她必須觀察那些需要她幫助的情況,尤其是左轉彎,注意,她沒有觀察到人們是否在左轉彎時遇到了麻煩,她的基本假設是向左轉彎是求助信號,像巴尼(Barney)一樣,她在十字路口的中間度過了自己的時間,從這個角度她無法很好地看到匝道,
  4. 由于大媽管理者認為被管理的人無法處理任何形式的爭執或沖突,因此Bea姨媽的程序模型要求她必須親自解決這些問題,因此,她對任何例外情況的反應都是停止交通,然后幫忙解決問題,
  5. 像Barney一樣,Bee姨媽的動作非常有限,部分原因是她需要處于十字路口中央的控制位置,

像微觀管理一樣,當母體管理的基本假設正確且問題和解決方案不太復雜時,母親式管理也可以作業,麻煩的是,大多數軟體開發都不是這種模式,并且大多數開發都是非常規的,需要解決許多沖突,界面、磁區、分解、協議 - 這些都是大媽管理者所認為的"左轉",他必須親自確保每個人都玩得很好,這就產生了類似于微管理的結構問題,類似于微觀管理但也不同,由于某些作業可以在母親的管理下獨立進行,因此與微觀管理相比,管理者沒有什么困難,

但是由于該程序仍然是高度以管理者為中心的,因此可以并行完成的實際作業量通常少于預期,我們最終得到了一個非常有效的程序:幾乎平行,相對觀察并且非常接近賦予工人獨立的責任:

并行(幾乎)只有預定義的"常規"事物才能并行發生,只要交通一直向前或向右轉,Bea姨媽的計劃就似乎奏效了,但是她無法預測會有多少人想要左轉,當很多人開始向左轉時,她的計劃崩潰了,以同樣的方式,由大媽管理的軟體專案的實際性能在很大程度上取決于真正需要多少開發,而不需要互動或解決沖突,如果"例外"比預期的多,那么許多根據專案計劃并行作業的開發人員可能坐在他們的手上,等待管理者做出決定,這可以使在理論上平行的專案計劃在實踐中變成串行的,

保姆對于被管理的人來說,大媽管理比微觀管理要輕一些,因為"母親"允許她的"孩子"自己做一些事情,只要不背離流程或陷入沖突,各個開發人員就可以繼續前進,但是,如果首先表明存在非標準行為,則整個程序將停止,直到管理者決定要做什么,管理者必須處理所有真正重要的決策,而這扼殺了個人對解決整體問題的貢獻,幾乎與微觀管理一樣無效,這里存在很大的變化-一位把員工視為青少年的管理者比那些將員工視為幼兒的管理者更不公開控制,不過,大多數從事軟體業務的人都有大學學歷,如果我們要找到一種比微觀母性更有效的樣式,則必須從更改基本假設開始,巴尼(Barney)將人們當作要編程的機器來管理,Bea認為他們是需要幫助的孩子,現在,讓我們看看安迪將他們視為成年人時會發生什么,

專家管理

安迪采取的方法起初看起來根本不像是"管理",他只是坐在椅子上,一邊喝著檸檬水,一邊看著52號高速公路匝道旁的車流,當匝道開始嚴重堵車時,他就溜進交叉路口,阻止了Key Street上的交通,并清理了匝道;然后他回到位置上,他似乎比Barney或Bee 阿姨少做"作業",但交通更順暢,我們將安迪的風格稱為專家管理 - 由于我們的三個交通管制員,只有他才是真正的管理大師,

安迪的管理風格的關鍵在于他的基本假設:駕駛員是成年人,大多數時候他們都可以照顧自己,而他作為管理者的角色是支持這些有能力的成年人,以便他們能夠做得到自己安全通過十字路口,這與Barney和Bea姨媽的假設完全不同,安迪(Andy)對自己的能力和駕駛員的技能感到足夠安全,因此他可以將自己從作業中心轉移出去,

由于Andy并未將自己置于管理任務的中心,因此他可以在關鍵管理活動上更加靈活有效:

  1. 安迪認為要解決的問題是高效安全地通過十字路口,他還意識到,大部分時間這個十字路口不需要任何幫助,人們每天都在這里轉彎而無需任何監督,是什么使這里需要一些的管理和干預呢?繞行繞道增加了52號高速公路匝道的交通,有時可能導致坡道上的交通堵車到高速公路上,并造成安全隱患,請注意區別 - 巴尼和巴比阿姨根據他們必須做的事情來定義問題,而安迪則根據結果來定義問題,而與誰真正"完成了作業"無關,通過這樣做,安迪將自己定位為觀察和"引導"起作用的系統,而不是作為從事該作業的人,(譯者注:關注技能 vs. 關注結果)

  2. 通過了解要解決的實際問題,Andy能夠為其解決方案制定有效的計劃,駕駛員負責自己通過十字路口,安迪和他的"管理團隊"將監視匝道,并確保在(以及是否)擁堵的很遠而構成安全隱患時將其清空,盡管Barney可能會指責Andy沒有太多計劃,但事實是,Andy的簡單計劃實際上允許發生一些非常復雜的事情,因為他沒有試圖控制駕駛員的低級動作,所以安迪的計劃將管理作業委托給了各個駕駛員,這樣一來,他們就可以并行運行,而他們等著--等待駛向左轉彎的駕駛員利用了駕駛員右轉彎所產生的交通缺口,

  3. 現在Andy既有問題陳述又有計劃,安迪可以確定他需要進行哪些觀察,為了防止交通擁堵回到52號公路,他必須注意坡道 - 而不是十字路口,因此,他將自己放到可以看到坡道的一側,這是安迪風格的另一個重要差異,站在十字路口的中間,Barney和Bea姨媽正在吸收大量資訊 - 大多數資訊與解決實際問題無關,他們不在正確的位置進行真正重要的觀察,當然,安迪并沒有忽略交叉路口發生的事情,但他并沒有將交叉路口作為主要關注點,

  4. Andy的管理風格使用了兩個程序模型,首先,如果流量在匝道上擁堵,就要在Key Street上停止車流并讓坡道的車先走,其次,如果有東西擋住了交叉路口,請立即將其移開,在其余時間里,Andy的程序模型表示"讓駕駛員自己照顧自己",

這兩種模型都比它們看起來更微妙,第一個模型允許Andy在早晨進行時進行一些微調,坡道距交通距離"太遠"有多遠?起初,他采取了一種保守的方法,在坡道擁堵到高速公路的一半時將坡道清空,后來,在觀察到Key Street的交通可以多快停止以清空坡道后,他將"太遠"的定義更改為坡道上四分之三的距離,這意味著需要更少的干預,因為通常情況下,流量會回升到四分之三擁堵點,然后自行回落,

第二個模型包含關于觸發動作的靈活定義,安迪正在尋找可能有多種根本原因的癥狀,如果有東西擋住了交叉路口(例如,駕駛員太膽小以至于不能向左轉),安迪的模型將對其進行處理,

  1. 最后,安迪采取的"公開"行動比巴尼或比阿姨少得多,大多數時候,他似乎什么都不做,然而,當需要采取行動時,他知道哪種行動是適當和有效的,但是說安迪的舉動比巴尼或比阿姨的舉動簡單是錯誤的,實際上,他的不頻繁干預需要更多技巧,畢竟,巴尼(Barney)和比阿姨(Bea Aunt)已經站在十字路口的中間,并引起了駕駛員的完全注意,安迪不得不進入一個充滿移動車輛的十字路口,引起駕駛員的注意,暫時中斷他們的自我管理,讓駕駛員執行他的指示,最后重新建立自我管理系統,這是一項需要一些技巧的任務,

就像我們討論過的其他兩種樣式一樣,精通管理在其基本假設有效時起作用,在軟體開發中,如果管理的人員是熟練,稱職,受過教育的成年人,那么這些假設通常是正確的,因此,熟練的管理可以解決我們在微觀和大媽管理中看到的結構和行為問題:

該計劃固有的授權意味著無需管理者干預即可解決大多數爭論和較小的沖突,因此大多數時候人們無需等待管理者的命令,當問題確實需要管理者的注意時,該問題就不必在一系列小沖突之后排隊等待,

對并行活動的支持意味著熟練的管理可以處理那些過于復雜而無法由單個管理者理解其所有細節的專案,并且大多數軟體專案都屬于該類別,

因為被管理的人還被委派了自我管理作業,所以他們能夠提出微觀管理者或大媽管理者可能會錯過的觀點,

專家管理涉及管理專案而不是個人,在大多數情況下,從事作業的人員可以在一些基本準則內自由選擇自己的方法(例如,在正確的道路上行駛或使用公司標準工具集),這允許創造性的精力投入到尋找"擊敗系統"的方法上,而不是去創造有利潤的產品,

簡而言之,像Andy這樣的專家管理者會觀察并操縱一個系統,如果問題得到了很好的理解,計劃是適當的,并且作業的人很稱職,那么控制員通常不需要做很多事情,與微觀管理者和大媽管理者不同,熟練的管理者將大部分時間都花在觀察和思考上,而不是在瘋狂的活動中,但是不要上當 - 當安迪坐在椅子上喝檸檬水時,他比巴尼或比阿姨更有效地控制了局勢,

如果專家管理是如此出色,為什么我們不經常看到它呢?因為在某些方面令人不安,尤其是對于管理者而言:

外觀可能具有欺騙性,專家管理的專案通常會給人以混亂的印象,當安迪(Andy)管理十字路口時,交通往各個方向轉彎,與巴尼(Barney)負責時整潔有序的行為相比,這令人不安,但是,在安迪看上去混亂的管理風格下,更多的交通通過了十字路口,并且更加安全,許多軟體專案已經看起來很混亂,專家管理會使他們變得更加如此嗎?我們對此表示懷疑;我們懷疑軟體開發中的許多明顯混亂來自對微觀和大媽管理的抵制,

專家管理者需要不同的心態,大多數人將管理權力一詞聯系起來,然而,從微觀管理轉向專家管理涉及放棄管理職位的許多表面上的權力和權威,并將其交給作業人員,根據作家Barry Oshry(在Weinberg的書《成為技術領導者》中引述)的說法,高級管理者具有更強的權力,如果我們將權力定義為"以增強系統在環境中發展的能力和行動的能力" ,

衡量重要因素在某些組織中(尤其是那些以微觀管理為準則的組織),專家管理者可能很難晉升,畢竟,與周圍的微觀管理者和大媽管理者相比,您將不會進行太多可見的管理,并且做出晉升決策的微觀管理者很容易得出結論,盡管您"無所作為",該專案成功了,但不是因為你的管理,

但是專家管理也有回報,專家管理者通常不必像微觀管理者和大媽管理者那樣瘋狂地作業,作為高級管理者,您不太可能在凌晨三點到辦公室,試圖解決另一個瑣碎的問題,當專案團隊說"我們自己做到了"時,您將知道自己確實是一個有效的領導者,就會對此感到滿意,

微觀管理、大媽管理和專家管理

確定管理風格的最佳方法是提出問題并觀察正在發生的事情,

向您報告的人是否像風中的樹葉一樣散落?您是否覺得他們在履行法律條文而不是精神?出現問題時,您會跳入并開始編碼嗎?如果是這樣,則可能是您進行了微管理,

您是否組織作業流程以減少互動,使團隊中的事情順利進行?您是否介入并嘗試使所有人都適合?在緊縮模式下,您是否還原為微觀管理?

您是否花費大量時間觀察正在發生的事情,考慮事件將對您的團隊和專案產生的影響,并計劃做什么?如果是這樣,則您可能是專家管理,

如果您想更改自己的管理風格,則需要考慮一些重要問題,首先,您是如何擁有當前的管理風格的?對于我們大多數人來說,我們的管理方式會受到管理我們的人以及我們所處環境的影響,認識到這些影響以及您當前作業狀況的限制,可能會幫助您確定是否該采用新模型了,同樣重要的是,檢查一下您對風格的感覺,如果您對現狀感到滿意,則可能無需進行更改,但是,如果您感到勞累過度,并且似乎一直在撲救大火,那么也許應該進行一些更改,

原文:https://www.donaldegray.com/managing-in-mayberry-an-examination-of-three-distinct-leadership-styles/

最后,您想做什么?我們看到Barney(微觀管理)、Bea(大媽管理)和Andy(專家管理)對"眼前的問題"的看法影響了他們的獨特回應,對您來說也是如此, 知道自己想做什么之后,就可以創建和實施計劃,以實作目標并保持流量平穩運行,

歡迎留言討論,你是什么風格的管理者(不一定必須是管理層,任何人都可以反思)? 是否有感受到每天很累,就像救火一樣? 你身邊的情況和現狀是什么? 哪些是重要的,如何站在一個合理的位置上進行觀察? 采取什么行動(嘗試)?

本文首發于 Bob Jiang的博客 ,轉載請聯系 Bob Jiang

轉載請註明出處,本文鏈接:https://www.uj5u.com/gongcheng/248943.html

標籤:其他

上一篇:ATL DoModal 失敗,回傳-1

下一篇:量化交易系統開發原始碼

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • Git本地庫既關聯GitHub又關聯Gitee

    創建代碼倉庫 使用gitee舉例(github和gitee差不多) 1.在gitee右上角點擊+,選擇新建倉庫 ? 2.選擇填寫倉庫資訊,然后進行創建 ? 3.服務端已經準備好了,本地開始作準備 (1)Git 全域設定 git config --global user.name "成鈺" git c ......

    uj5u.com 2020-09-10 05:04:14 more
  • CODING DevOps 代碼質量實戰系列第二課,相約周三

    隨著 ToB(企業服務)的興起和 ToC(消費互聯網)產品進入成熟期,線上故障帶來的損失越來越大,代碼質量越來越重要,而「質量內建」正是 DevOps 核心理念之一。**《DevOps 代碼質量實戰(PHP 版)》**為 CODING DevOps 代碼質量實戰系列的第二課,同時也是本系列的 PHP ......

    uj5u.com 2020-09-10 05:07:43 more
  • 推薦Scrum書籍

    推薦Scrum書籍 直接上干貨,推薦書籍清單如下(推薦有順序的哦) Scrum指南 Scrum精髓 Scrum敏捷軟體開發 Scrum捷徑 硝煙中的Scrum和XP : 我們如何實施Scrum 敏捷軟體開發:Scrum實戰指南 Scrum要素 大規模Scrum:大規模敏捷組織的設計 用戶故事地圖 用 ......

    uj5u.com 2020-09-10 05:07:45 more
  • CODING DevOps 代碼質量實戰系列最后一課,周四發車

    隨著 ToB(企業服務)的興起和 ToC(消費互聯網)產品進入成熟期,線上故障帶來的損失越來越大,代碼質量越來越重要,而「質量內建」正是 DevOps 核心理念之一。 **《DevOps 代碼質量實戰(Java 版)》**為 CODING DevOps 代碼質量實戰系列的最后一課,同時也是本系列的 ......

    uj5u.com 2020-09-10 05:07:52 more
  • 敏捷軟體工程實踐書籍

    Scrum轉型想要做好,第一步先了解并真正落實Scrum,那么我推薦的Scrum書籍是要看懂并實踐的。第二步是團隊的工程實踐要做扎實。 下面推薦工程實踐書單: 重構:改善既有代碼的設計 決議極限編程 : 擁抱變化 代碼整潔代碼 程式員的職業素養 修改代碼的藝術 撰寫可讀代碼的藝術 測驗驅動開發 : ......

    uj5u.com 2020-09-10 05:07:55 more
  • Jenkins+svn+nginx實作windows環境自動部署vue前端專案

    前面文章介紹了Jenkins+svn+tomcat實作自動化部署,現在終于有空抽時間出來寫下Jenkins+svn+nginx實作自動部署vue前端專案。 jenkins的安裝和配置已經在前面文章進行介紹,下面介紹實作vue前端專案需要進行的哪些額外的步驟。 注意:在安裝jenkins和nginx的 ......

    uj5u.com 2020-09-10 05:08:49 more
  • CODING DevOps 微服務專案實戰系列第一課,明天等你

    CODING DevOps 微服務專案實戰系列第一課**《DevOps 微服務專案實戰:DevOps 初體驗》**將由 CODING DevOps 開發工程師 王寬老師 向大家介紹 DevOps 的基本理念,并探討為什么現代開發活動需要 DevOps,同時將以 eShopOnContainers 項 ......

    uj5u.com 2020-09-10 05:09:14 more
  • CODING DevOps 微服務專案實戰系列第二課來啦!

    近年來,工程專案的結構越來越復雜,需要接入合適的持續集成流水線形式,才能滿足更多變的需求,那么如何優雅地使用 CI 能力提升生產效率呢?CODING DevOps 微服務專案實戰系列第二課 《DevOps 微服務專案實戰:CI 進階用法》 將由 CODING DevOps 全堆疊工程師 何晨哲老師 向 ......

    uj5u.com 2020-09-10 05:09:33 more
  • CODING DevOps 微服務專案實戰系列最后一課,周四開講!

    隨著軟體工程越來越復雜化,如何在 Kubernetes 集群進行灰度發布成為了生產部署的”必修課“,而如何實作安全可控、自動化的灰度發布也成為了持續部署重點關注的問題。CODING DevOps 微服務專案實戰系列最后一課:**《DevOps 微服務專案實戰:基于 Nginx-ingress 的自動 ......

    uj5u.com 2020-09-10 05:10:00 more
  • CODING 儀表盤功能正式推出,實作作業資料可視化!

    CODING 儀表盤功能現已正式推出!該功能旨在用一張張統計卡片的形式,統計并展示使用 CODING 中所產生的資料。這意味著無需額外的設定,就可以收集歸納寶貴的作業資料并予之量化分析。這些海量的資料皆會以圖表或串列的方式躍然紙上,方便團隊成員隨時查看各專案的進度、狀態和指標,云端協作迎來真正意義上 ......

    uj5u.com 2020-09-10 05:11:01 more
最新发布
  • windows系統git使用ssh方式和gitee/github進行同步

    使用git來clone專案有兩種方式:HTTPS和SSH:
    HTTPS:不管是誰,拿到url隨便clone,但是在push的時候需要驗證用戶名和密碼;
    SSH:clone的專案你必須是擁有者或者管理員,而且需要在clone前添加SSH Key。SSH 在push的時候,是不需要輸入用戶名的,如果配置... ......

    uj5u.com 2023-04-19 08:41:12 more
  • windows系統git使用ssh方式和gitee/github進行同步

    使用git來clone專案有兩種方式:HTTPS和SSH:
    HTTPS:不管是誰,拿到url隨便clone,但是在push的時候需要驗證用戶名和密碼;
    SSH:clone的專案你必須是擁有者或者管理員,而且需要在clone前添加SSH Key。SSH 在push的時候,是不需要輸入用戶名的,如果配置... ......

    uj5u.com 2023-04-19 08:35:34 more
  • 2023年農牧行業6大CRM系統、5大場景盤點

    在物聯網、大資料、云計算、人工智能、自動化技術等現代資訊技術蓬勃發展與逐步成熟的背景下,數字化正成為農牧行業供給側結構性變革與高質量發展的核心驅動因素。因此,改造和提升傳統農牧業、開拓創新現代智慧農牧業,加快推進農牧業的現代化、資訊化、數字化建設已成為農牧業發展的重要方向。 當下,企業數字化轉型已經 ......

    uj5u.com 2023-04-18 08:05:44 more
  • 2023年農牧行業6大CRM系統、5大場景盤點

    在物聯網、大資料、云計算、人工智能、自動化技術等現代資訊技術蓬勃發展與逐步成熟的背景下,數字化正成為農牧行業供給側結構性變革與高質量發展的核心驅動因素。因此,改造和提升傳統農牧業、開拓創新現代智慧農牧業,加快推進農牧業的現代化、資訊化、數字化建設已成為農牧業發展的重要方向。 當下,企業數字化轉型已經 ......

    uj5u.com 2023-04-18 08:00:18 more
  • 計算機組成原理—存盤器

    計算機組成原理—硬體結構 二、存盤器 1.概述 存盤器是計算機系統中的記憶設備,用來存放程式和資料 1.1存盤器的層次結構 快取-主存層次主要解決CPU和主存速度不匹配的問題,速度接近快取 主存-輔存層次主要解決存盤系統的容量問題,容量接近與價位接近于主存 2.主存盤器 2.1概述 主存與CPU的聯 ......

    uj5u.com 2023-04-17 08:20:31 more
  • 談一談我對協同開發的一些認識

    如今各互聯網公司普通都使用敏捷開發,采用小步快跑的形式來進行專案開發。如果是小專案或者小需求,那一個開發可能就搞定了。但對于電商等復雜的系統,其功能多,結構復雜,一個人肯定是搞不定的,所以都是很多人來共同開發維護。以我曾經待過的商城團隊為例,光是后端開發就有七十多人。 為了更好地開發這類大型系統,往 ......

    uj5u.com 2023-04-17 08:18:55 more
  • 專案管理PRINCE2核心知識點整理

    PRINCE2,即 PRoject IN Controlled Environment(受控環境中的專案)是一種結構化的專案管理方法論,由英國政府內閣商務部(OGC)推出,是英國專案管理標準。
    PRINCE2 作為一種開放的方法論,是一套結構化的專案管理流程,描述了如何以一種邏輯性的、有組織的方法,... ......

    uj5u.com 2023-04-17 08:18:51 more
  • 談一談我對協同開發的一些認識

    如今各互聯網公司普通都使用敏捷開發,采用小步快跑的形式來進行專案開發。如果是小專案或者小需求,那一個開發可能就搞定了。但對于電商等復雜的系統,其功能多,結構復雜,一個人肯定是搞不定的,所以都是很多人來共同開發維護。以我曾經待過的商城團隊為例,光是后端開發就有七十多人。 為了更好地開發這類大型系統,往 ......

    uj5u.com 2023-04-17 08:18:00 more
  • 專案管理PRINCE2核心知識點整理

    PRINCE2,即 PRoject IN Controlled Environment(受控環境中的專案)是一種結構化的專案管理方法論,由英國政府內閣商務部(OGC)推出,是英國專案管理標準。
    PRINCE2 作為一種開放的方法論,是一套結構化的專案管理流程,描述了如何以一種邏輯性的、有組織的方法,... ......

    uj5u.com 2023-04-17 08:17:55 more
  • 計算機組成原理—存盤器

    計算機組成原理—硬體結構 二、存盤器 1.概述 存盤器是計算機系統中的記憶設備,用來存放程式和資料 1.1存盤器的層次結構 快取-主存層次主要解決CPU和主存速度不匹配的問題,速度接近快取 主存-輔存層次主要解決存盤系統的容量問題,容量接近與價位接近于主存 2.主存盤器 2.1概述 主存與CPU的聯 ......

    uj5u.com 2023-04-17 08:12:06 more