Naresh Jain談印度敏捷

2021-09-16 18:08:50 字數 4701 閱讀 8349

naresh jain是印度敏捷軟體社群的創始人,也是即將來臨的敏捷印度大會的主席。我們聯絡了naresh,討論了印度公司敏捷方法的應用現狀以及前路幾何。

\u0026#xd;\n

infoq:你覺得敏捷在印度的應用現狀是什麼樣子的?

\u0026#xd;\n

\u0026#xd;\n

naresh jain:很瘋狂!就像印度的交通系統——控制下的混亂!人們需要有欣賞者的眼光才能發現它的美!

\u0026#xd;\n

在過去的7年之中,我已經看過了很多公司逐漸地試水敏捷,並開始嬉水。絕大多數在印度的機構,無論是大型it企業、小型公司,抑或龐大的離岸研發中心,他們已經100%地受到敏捷方法的影響。

\u0026#xd;\n

就像在世界(即使在亞洲)其他的地方一樣,產品公司的敏捷實施都更加嚴肅和嚴格(但不一定更成功)。

\u0026#xd;\n

如果你訪問不同的公司,並且真正 去與不同層次的人去交談,他們會告訴你迄今為止他們的瘋狂行徑。埋怨外包工作的性質、缺乏對這些方法的了解、層級式的社會或者在某些情況下就是簡單地無法 勝任。[以下為嘲諷]只有我們參加了為期3天地scrum master培訓,世界才會是乙個更為宜居的地方。[嘲諷結束]真相是事實是,旅程才剛剛開始,真正有趣的部分尚未來到呢!

\u0026#xd;\n

\u0026#xd;\n

infoq:您是否認為敏捷僅僅在創業公司和小型軟體作坊裡面實施得很到位,或者它正在進入大型公司?

\u0026#xd;\n

\u0026#xd;\n

naresh jain:關於星星之火的事實之一是,在傳播的時候,它會向各個方向傳播。今天,我 看到95%的印度軟體公司都是在耍敏捷。現在的流行趨勢是說我們在正確地實施敏捷?當我看到公司邁向敏捷時,在某些情況下是由於絕望,在某些情況下是由於 客戶或現場壓力,而在某些情況下,則僅僅是乙個營銷噱頭。有時候感覺它似曾相識。難道我們在十年前的cmm身上沒有看過類似的事情嗎?

\u0026#xd;\n

不過,我很幸運地與幾家真正相信敏捷精神的公司合作。他們了解它不是在「做」敏捷,而是在「變得」敏捷。乙個說起來非常禪意的東西!

\u0026#xd;\n

\u0026#xd;\n

infoq:印度當前最豐厚的利潤行業之一是it行業。大型外包專案通常必須包括大量的前期工作以決定專案範圍,並在整個專案週期裡面仔細地控制。敏捷是否可以應用於外包專案?

\u0026#xd;\n

\u0026#xd;\n

naresh jain:我們人類建立「東西(stuff)」的心理模型,並嘗試將我們周圍的世界適配到這種模式。

\u0026#xd;\n

幾年前,軟體開發的心理模型是「裝配線」。這個心智模型的展開如下:

\u0026#xd;\n第1步:計畫和制定策略(在這裡和那裡加一些幻想)

\u0026#xd;\n第2步:記錄每乙個小細節

\u0026#xd;\n第3步:定義乙個嚴謹的過程,讓你如何像齒輪嚙合一樣嚴絲合縫地對待人

\u0026#xd;\n第4步:尋找廉價勞動力

\u0026#xd;\n第5步:將工作交給他們,定義非常嚴格的「做什麼」和「不做什麼」的合同

\u0026#xd;\n第6步:定義最佳實踐來管理執行

\u0026#xd;\n第7步:迭代...

\u0026#xd;\n第8步:直到獲取美妙的結果

不幸的是極少數專案的存活能超出第7步。大多數人在野生求生存。

\u0026#xd;\n

除了許多其他的缺陷,這種模式下低估了信任、共識、集體所有權、自豪感以及適應性的重要性。

\u0026#xd;\n

無論外包與否,這些專案都是注定要失敗的。[以下為嘲諷]當然,離岸外包給你最好的炸藥包。[嘲諷結束]

\u0026#xd;\n

事實證明(至少對我來說),分布式開發是非常困難的。離岸更是困難,外包和離岸則是最難的。然而,正如我們所看到的,離岸外包模式對於某些業務和管理仍然合理(但不適用於所有的專案)。

\u0026#xd;\n

鑑於不得不妥協的現實,我見過敏捷和精益思想對於如下情況相當有幫助,例如:

\u0026#xd;\n

\u0026#xd;\n恕我直言,敏捷和精益思想已經把大量的注意力吸引到了外包開發模式的一些非常重要,但往往被忽視的方面。並且還大大減少了流程中的一些痛苦。我們仍然有很長的路要走。

\u0026#xd;\n

infoq:外包專案的合同細節是怎麼樣的?客戶的執行官都希望知道針對預算/時間線,她能得到什麼,那你是如何與他們就合同進行談判的?

\u0026#xd;\n

\u0026#xd;\n

naresh jain:往往,在信任度很低(首次合作)的情況下,客戶想知道他們將得到什麼,以及他們將何時獲得x金額。在某些情況下,我認為這些要求很公平。

\u0026#xd;\n

但真正的問題是,模糊的東西很難估算。在專案的開始階段,我們掌握的知識量最少。

\u0026#xd;\n

為了解決這個問題,我通常鼓勵企業從產品識別研討會(pdw,product discovery workshop)開始。一般長約1-2周。我們最初與客戶簽訂主服務協議(msa,master services agreement)。根據msa,第乙份工作合同(sow)往往是針對產品識別研討會。它有乙個明確的開始時間、結束時間以及交付物列表。

\u0026#xd;\n

在產品識別研討會的結束階段,我們會有乙份高層次的發布路線圖。從這個路線圖,我們選擇第一部分,做一些初步的研究(spike)和涉及工作量的估算(guestimate)。根據msa,第二份sow是針對路線圖的第一部分。固定**,固定日期。

\u0026#xd;\n

這樣,我們就將大型的產品路線圖分解到小的sow合同,並執行該專案。有時在pdw之後,我們可以為整個發布路線圖簽署乙份單一的sow。一切都取決於雙方的信心程度。

\u0026#xd;\n這是我經驗中的規劃固定**外包合同的敏捷方式。

\u0026#xd;\n

\u0026#xd;\n

\u0026#xd;\n

naresh jain:scrum看上去是最容易開始的。與所有其他的方法/框架相比,scrum似乎對(中級)管理層的威脅最少。畢竟,在大多數的情況下,他們滿握著金錢和決策的權力。與認證一結合,你就得到了乙個殺手鐗。 (乙個真正的敏捷殺手!)

\u0026#xd;\n

因此,毫無疑問,在亞洲和世界各地,scrum似乎是採用(至少嘗試採用)最廣泛的敏捷方法。

\u0026#xd;\n

但這究竟意味著什麼?從現在開始,專案經理應該被稱為scrum master。團隊應該將需求稱為使用者故事,而不是用例或任何他們曾經稱呼需求的名字。每天晚上(以確保現場團隊成員是「演習」的一部分)都有30-45 分鐘的「演習」。一組新的精巧(昂貴)的工具。每個團隊成員都是用新的所謂燃盡圖的度量標準進行衡量。更頻繁的後半夜和週末。(傳統)測試人員的噩夢。每 隔30天左右,該團隊就要展示他們在過去60天裡一直試圖構建的東西。而最好的部分是,「客戶」可以隨時更改自己的想法。

\u0026#xd;\n

如果你問我哪個是最有效的方法之一,這問題極為有趣。

\u0026#xd;\n

\u0026#xd;\n

infoq:您認為哪些敏捷方法在印度的效果更為優秀?

\u0026#xd;\n

\u0026#xd;\n

naresh jain:空流程——如果公司停止追逐過程和方法,就好像它們能夠真實地解決軟體開發中的困難問題似的。空流程鼓勵企業忘記流程,專注於自己的業務以及業務背後的人。

\u0026#xd;\n在敏捷孟買(agile mumbai)2023年會議上面,sandeep和我舉行了乙個名為「monkey see monkey do」的研討會,鼓勵企業忘記並遠離流程思維。

\u0026#xd;\n

\u0026#xd;\n

\u0026#xd;\n

\u0026#xd;\n

naresh jain:在過去的7年中,印度敏捷軟體社群(asci)曾與在印度的很多高校一起合作,往教育系統中引入了敏捷概念。我們已經在印度的一流大學裡面舉辦過多次會議,以吸引更多的學者參與。我們已經給來自印度各地的教師組織了進修課程。

\u0026#xd;\n關於高校,果阿大學(goa university)是一所脫穎而出的大學。他們試圖使整個教育體系更加敏捷。此外,他們已經開始在他們的課堂專案上使用極限程式設計和scrum方法。事實上,在即將召開的敏捷印度2023年大會上,我們有兩個來自於他們的演講——高等教育中的敏捷實踐:案例研究和在軟體工程課程專案上使用scrum。

\u0026#xd;\n與之類似,其他高校,如pes工程學院(pes college of engineering)、雅典衛城技術研究所(acropolis institute of technology)、共生電腦學研究所和研究(symbiosis institute of computer studies and research),安娜大學(anna university)和巴黎聖日爾曼技術學院(psg college of technology)也都已在各自的程式設計課程中引入了各種極限程式設計的實踐。

\u0026#xd;\n

\u0026#xd;\n

檢視英文原文:naresh jain on agile in india

敏捷開發縱橫談

摘要 在it界中,敏捷 是乙個很酷的詞彙,敏捷 的相關理論可謂鋪天蓋地。敏捷 一詞實質沒有統一定義,各家有自家的說法,本教程將讓你了解 敏捷 的來龍去脈,抓住 敏捷 本質,並能在工作中實踐 敏捷 大綱 敏捷 陷阱 為什麼會有 敏捷 這個說法?極限程式設計 敏捷開發 rup敏捷開發的實質是什麼?如何才...

與Jeff Sutherland談敏捷領導力

在goto阿姆斯特丹2015大會上,jeff sutherland談了敏捷領導力。infoq對他進行了採訪,內容涉及 大型組織在採用scrum時面臨的問題 他們該如何提高處理障礙 提公升敏捷領導力的能力 scrum大師能做些什麼來幫助組織變得敏捷 對實施scrum的組織的管理人員的建議。infoq ...

與Jeff Sutherland談敏捷領導力

在goto阿姆斯特丹2015大會上,jeff sutherland談了敏捷領導力。infoq對他進行了採訪,內容涉及 大型組織在採用scrum時面臨的問題 他們該如何提高處理障礙 提公升敏捷領導力的能力 scrum大師能做些什麼來幫助組織變得敏捷 對實施scrum的組織的管理人員的建議。infoq ...