eXtremely Distributed Software Development (XDSD), at DevTernity'2016

preview_player
Показать описание

#zerocracy #xdsd #freelance
Рекомендации по теме
Комментарии
Автор

Yegor this is probably my favourite talk from you, I was watching it over dinner and even my Mrs started watching along as she found it very interesting.I'm not technical enough to understand the OOP content you have on this channel (beginner developer in my spare time), but the management related content is the best I have ever heard because these ideas are things I have never heard of before.Truly controversial content, the managers in my company would shoot you if you suggested they should spend less time in meetings and actually document things....then they would actually have to do some work.

NikonSanz
Автор

Wow your presentation skills are so much higher than in early talks! Good progress.

valigotech
Автор

Written communication beats speaking for sure!
Speech speed = 105 words per minute = 6300 words per hour.
Typing speed for composition = 19 words per minute = 1140 words per hour.
Reading speed = 250 words per minute = 15000 words per hour.

Example: Assuming a project growing from 1 architect to 1 architect + 9 devs and each time a new dev is added, architect gives them a talk for 1 hour, that's 18 hours total (9 from architect and 9 from all devs). For architect to type up the entire speech would take 5.52 hours. Beats 9 hours of explaining. (Unless he asks the first dev to pass the knowledge down directly via "broken phone").

Modifying the example and assuming 1hr meeting = 30 mins speech + 30 mins Q&A, writing still wins. If people ask questions via tickets, architect still would spend almost the same time writing the initial document + initial answers to 15-min worth of questions, the only overhead would be to read a ticket and direct people to the answer. The overall savings for the team time remain even 50% of developers don't find previous ticket and type same questions again. It only breaks down if 8 out of 9 devs write up the same questions (1.38 hours to type up 15 mins worth of talking).

Which means this system works if past questions/tickets discovery is high - search works well, and people remember to use it.

alexandrid
Автор

I like all your lectures, posts.
Really looks very interested

katrykonig
Автор

Yegor, could you post the links to the open source projects on GitHub that you mention at 20:30 ? The approach you describe sounds very meritocratic which deeply appeals to me (in sharp contrast to your OO-fundamentalism which is lunacy imho) - but it also sounds somewhat too good to be true :) particular ability to jump on the large project in 30 minutes, so would be really interesting to look at the code/git

DunetsNM
Автор

Sounds to me that the architect plays the role of the domain expert here... since he needs to understand the business requirements in full to design the architecture & write documentation.

alexandrid
Автор

Analogy with taxi driver is too exaggerated - I understand that there may be unforeseen obstacles on my way to the airport, but I still need to know the estimated time (with 90% probability confidence) it will take me so that I know how much time to plan for the ride (and how much will I pay at the end).

Business needs estimates which can be trusted. If I am a business owner and I have to decide which project (product/feature) to invest next, I need to know the approximate cost of each option, so that combined with projected value of the project I can see which one has better potential return. Sure, there may be some hiccups but if all of the projects are constantly breaking estimations then I cannot make such decisions anymore. How does Zerocracy address that? Does it have risk management component?

alexandrid
Автор

Толково! со многим согласен и очень полезно узнать о положительных результатах такой методологии и концепции ведения разработки. Пожалуйста, делитесь опытом! good luck and have fun)

ArchyBarouski
Автор

Все очень четко, кроме того момента, когда начинается зачес про то, что комманда это просто люди объединенные проектом. Все так, но это 4 часа человеческой жизни в день, хочется провести их качественно, возможно, кто-то подружиться, заведет новые знакомства. Люди не роботы. Это говорит о том, что автора кидает от одной крайности (булщит тимворк) к другой (вечеринка интровертов)

varic
Автор

Strict lint does not mean that the code is qualitative!

quverr
Автор

By definition, products which become commodities are forced to compete by price and race it to the bottom. So while I can Zerocracy may be lower-cost for clients, I am skeptical about the touted benefits to developers after the words "commoditized developers". Yes, "traditional" model is not very precise in allocating money - people are paid similarly and tasks are also assigned not matching inherent qualifications. However, I feel like there is some missing piece here to make Zerocracy attractive to good developers.

It would be cool if Yegor did an A/B test - two teams working on the same project with the same client, one using Zerocracy and another - "traditional" agile approach, and see how it plays out - time, cost, quality etc.

alexandrid
Автор

@yegor256 I've fixed the captions for this video, please check your email for the subtitles link

avidrucker
Автор

I say team must be evolve to self organizing structure, manager role only must be to find better candidates and help to grow the team, meating feature goals only possible when you really understand how team work happens, saying that your software can exchange the manager is bogus.

tr
Автор

"So you have one developer working for 300 minutes, it's almost 5 hours. Or you have 10 developers working for 30 minutes each. Which one is more manageable. Obviously it's ours" Wut? Reality contradicts that statement. Managing 10 people with hand offs and 10 different tickets is 10 times harder then managing 1 ticket and 1 developer. This video is full of that kind of blank statements, that are not rooted in reality. Have a lot of interesting observation of current process though.

dkrasnikov