Роберт Мартин описывает скрам
Дядя Боб (автор SOLID и Clean Architecture) о том, как начиналось и во что превратилось движение Agile.
blog.cleancoder.com/...raftsmanshipMovement.html
UPD цитата:
That’s the grand irony. It was programmers who started the Agile movement as a way to say: “Hey look! Teams matter. Code should be clean. We want to collaborate with the customer. And we want to deliver early and often.”
The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: “Wow! Agile is a cool new variation on how to manage projects.”
There’s an old song, by Alan Sherman, called J. C. Cohen. It’s about a subway conductor who did such a great job at pushing people into the train cars, that he pushed the engineer out. This is what happened to the Agile movement. They pushed so many project managers in, they pushed the programmers out.
59 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівРекомендую всю его книгу «Clean Agile: Back to Basics», а не только статью. После неё всё становится просто и понятно — в чём была проблема, как ее пытались решить, где идею подхватили, где её извратили, почему/как извратили.
уже пошутили о том как бы скрам описывал Джордж Мартин?
еще нет
Скрам пока что претендует на главный ИТ развод 21 века.
А що ви запропонуєте в ролі альтернативної методології?
Гадание на кофейной гуще
Ватерфол или спираль.
Не згоден з вами про waterfall. Відсотків 10 можна з ним використовувати, але інші проекти просто посипляться, особливо там, де вимоги швидко змінюються.
Там де вимоги швидко змінюються сипиться все і аджайл у порівнянні з ватерфолом якщо і має велью, то суто дотичне до управління очікуваннями і сподіваннями стейкхолдерів (або навпаки, як тут жаліються)
А у вас є підтвердження ваших слів у вигляді якихось серйозних досліджень або це просто ваша точка зору?
Це моя точка зору. Звісно, що якщо б в мене були посилання на дослідження, я б їх навів би одразу з аргументом.
Адепты Скрама вообще не согласны, что что то кроме их прелести может работать. При этом забывают, что большая часть известного ПО была созданна по ватерфолу. Если требования меняются — есть итерационный ватерфол или RUP.
Думаю, большая часть уже давно не по вотерфолу.
Если мерять штуками — то cowboy coding.
Если мерять кодовой базой — то там энтерпрайз, и каждая команда делает как умеет.
Идеальный варант — ватерфол, он имеет минимальные накладные расходы.
Реалистичный вариант — канбан.
Собственно, все 3 и есть тот самый «ватерфол», но в разном маштабе:
— scrum — waterfall длинной в спринт
— kanban — waterfall длинной в задачу
— waterfall — длинной в проект
На першій роботці був ламповий ватерфол з ітерацією в півроку і все було при ньому:
1. Ітерації в середньому насправді тривали рік
2. Зазвичай список фіч на початку та вкінці ітерації відрізнявся на 90%
І це ще в нас був нормальний product owner
Ватерфол — это не магическое слово, которое автоматически гарантирует выполнение сроков и компетенцию менеджмента / бизнесс-аналитика / архитектора.
недавно добавил коммент в одном обсуждении:
— Почему не работают спринты?
Если в одном (или двух или даже нескольких) чатиках про техдирство/ техлидство/ тимлидство сказать слово «agile» или, упаси боже «скрам», сразу прибегает толпа свидетелей бесполезности спринтов и в подробностях рассказывает ужасы о сектантах скрама, эффективных менеджерах и закидывают ссылками на то, как они убили целый бизнес.
...
— Спринт — это заранее сформулированное бизнес-языком измеримое улучшение продукта.
S: в такой формулировке спринт — это просто синоним «этапа разработки»:
Анализ требований ...
Проектирование ...
Кодирование ...
Тестирование и отладка ...
Сдача работы, внедрение, ...
Просто фиксируется время этапа
— И под каждую цель прописывается перечень конкретных задач с точной оценкой.
S: а без анализа требований и проектирования — точность невозможна.
поэтому было предложено в скраме — а давайте считать интуитивно по факту:
раставляем сторипойнты, смотрим в конце спринта насколько не вписались, расставляем в следующий раз реалистичней. смотрим насколько не вписались, раставляем ...
и так выйдем на велосити команды и сторипойнты которые будут показывать оценку времени все точнее и точнее.
— рассказывает ужасы о сектантах скрама, эффективных менеджерах
S: правильно рассказывают.
потому что когда каша в головах — у нас типа скрам, а в действительности поэтапная разработка, то получается что никто сказать не может, что у нас за гибрид такой, и какие его свойства чтобы можно было — управлять.
хорошие менеджеры конечно справятся с любым гибридом.
хорошие, вовлеченные программисты — им в помощь.
но когда кто-то нехороший — то имеем реалии peopleware
Спринт — это лишь часть аджайла. В целом же, джайл — такое: «In software development, agile practices involve discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).»
Это не работает. Причём, не работает ни 1) самоорганизация кодеров , ни 2) взаимодействие «кодер — конечный клиент».
В итоге, в лучшем случае из «аджайла» делают некий централизованный «итеративный процесс» со спринтами (вместо централизованного «водопада»), в худшем в попытках реального «аджайла» проект накрывается медным тазом.
Аджайл работает охренительно, если делать аджайл а не ватерфал называемый аджайлом
СНГ
Спринт к эджайлу имеет такое же отношение, как хвост к животному. То есть, он у скрама, но не у канбана, к примеру.
Анкл Боб — еще тот торговец балшитом
А він згоден з вашою оцінкою?
Ещё не хватало, чтобы кодерки решали, как им делать проект.
Может, ещё и демократию на проектах устрооим? Типа, с всеобщим голосованием. Когда в команде из 5 джунов, 2 миддла и 1 синьора — джуны переголосовывают всех и принимают решения...
Но Скрам так и работает. Недавняя ситуация: фича в моём сервисе, требует рефакторинга. У меня 5 сторипоинтов, у остальных один-два. Остальные — это 2 фронтэнда и 2 тестера. И я сижу и зачем то объясняюсь, почему оторвался от коллектива.
У вас скрам уже не работает. Скрам предполагает команду где каждый участник может работать над любой функциональностью. По тому что ты написал следует вывод что это не ваш кейс, а соотвественно не скрам. Думаю у тебя как и у всех только некоторые ритуалы выполняются да и все
Каким образом фронты и тестеры могут работать над бакендом?
В этом вопросе кроется все что нужно знать об украинском айти и почему аджайл в нем невозможен
Спойлер, я — аутстафер, работаю на Лондон, менеджмент весь оттуда. Так что украинское айти тут не при чем.
Цитирую книжку Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka by Vaughn Vernon:
Translating message formats may be the kind of job that you want to outsource, especially when there is a lot of it to do and it represents an ongoing workload. Although it is essential for the ultimately processed messages to support your system’s standard formats, performing the wide range of incoming message type detections and translations can become a huge gruntwork effort. Since the routing and translation code almost certainly does not represent an investment in your core business software models, you probably don’t want to continually commit the efforts of your valuable developer staff in this kind of sinkhole. After the first few router and translator challenges are tackled by your team, forming a well-understood approach, delegating the ongoing routing and translation work as a necessary evil can be a big benefit to your internal teams.
Таким же, как они могут оценивать стори пойнты.
У меня последняя контора как-то заказала тренинг по скраму. Я съездил — бесплатный сертификат + не надо работать неделю.
И таки да — там говорят, что в основе скрама — взаимозаменимость всех членов команды. Именно поэтому все вместе голосуют за стори пойнты. И поэтому каждый берет первую попавшуюся фичу из беклога вместо того, чтобы тим лид распределял фичи по компетенции программистов.
И вторая основа — то, что команда может выдавать фичу целиком. То есть, для эмбедеда каждый член команды должен знать сети, драйвера и ядро линукса, С++ в юзер спейсе, и веб. Можешь себе представить, сколько такой человек будет стоить, и какое будет его качество работы в каждой из областей.
Это о зоне применимости скрама.
А такого в реальной жизни не бывает. Ну, разве что, на проекте только джуны — но они и накодят соответственно.
Если парное программирование со сменой партнеров — может быть. Или есть код ревью однокомандцами.
В конечном счете, это — то, к чему стремятся работодатели. Чтобы уход любого специалиста никак не повлиял на развитие проекта. Поэтому не рекомендуют нанимать рокстаров.
neilonsoftware.com/.../developers/the-rockstar
Парное программенье с бестолковым «войти-вайтишником» — лишь замедлит разработку до скорости этого «вайтишника».
А на ревью такому, лучше вообще ничего не давать.
П.С. Не рекомендует некий «Нейл». В реальности же, рокстары это самые дефицитные и (соответственно) наиболее оплачиваемые спецы в индустрии.
Крупные конторы на ХР интервью тоже стремятся идентифицировать и отсеять индивидуалистов. Им нужны командные игроки, которых можно легко заменить.
«рокстары» вполне себе командные игроки. Собственно, им приходится быть командными игроками — т.к. довольно скоро они оказываются носителями ноу-хау (часто, единственными) на проекте.
«Хочешь сделать правильно — сделай сам»
Обычно, на проектах иная проблема — попадаются задачи, которые могут решить лишь «рокстары». И которые, вместо одного «рокстара» — не решит десяток миддлов.
А нет рокстара — нет фичи (а может и продукта).
Дай мне такой проект, и чтобы за него платили.
то что он пишет не рокстар, очень просто такую работу найти, к верхнему квантилю 1к$ добавь и ищи вакансию синьора/лида в компании до 50 человек. правда, когда решишь проблему(ы) тебя выкинут на мороз с вероятностью 95%
я хочу +2к к верхнему, и узкая специализация.
соответственно, тут мало проектов, новозаходящих почти ноль. А вот если знаете такое за границей — им может быть выгодно когда относительно дешевый (для них) специалист доведет структуру до ума.
я тебе написал как найти проект, где будет проблема, которую не может решить десяток мидлов, а не как получить на 2к выше верхнего квантиля и иметь при этом узкую специализацию
ну пока найденные проекты делятся на 2 вида:
1) надо управлять 10 джунами в условиях пожара.
2) надо кодеры, знающие L2 networking и не допускающие ошибок.
не думаю, что снижение уберет эти типы проектов.
No offence, но звучит как-то высокомерно. Например я, будучи ещё джуном на первой работе, часто подпиливал бэк (как раз на C#) по мелочи и всё было ок, ничего на моей памяти я не отломал. Зато потом благодаря небольшому опыту с шарпом быстро полюбил тайпскрипт :)
Каждый должен заниматься своим делом. Я во фронт и тестирование не лезу, и ожидаю того же по отношению к бэку.
Это, к стати, весьма наглядная иллюстрация на тему «почему скрам не работает» — его особо никто не понимает, и соответственно, не старается, чтобы он заработал).
Например, в скрам-гайде говорится о «кросс функциональной команде» — которая самостоятельна, и не зависит от других (команд), но люди предпочитают постояно повторять чушь про фулл-стек.
Т.е. несмотря на кажущуюся «простоту» — аджайл и скрам слишком сложны. Люди часто даже не могут прийти к согласию — что есть аджайл/скрам, а что нет.
Уже не говоря о том, чтобы эффективно их использовать.
По-моему, никто не спорит, что Канбан — это эджайл.
Я аж зубами заскрипел от въетнамских флешбеков))
Тема уже была полностью раскрыта Томасом.
Не думаю, що Томас Андерс може розкрити цю тему.
Кто видел «скрам», который на самом деле — «канбан», тот в цирк ходит как в драматический театр.
Заставлял многие проекты признавать что у них канбан, пм всегда расстраивались по этому поводу
Да, сказано круто, ни прибавить не убавить.
Вы хотите знать как рождаются карго-культы ? вот яркий пример ...
Чувак пишет, что это просто бизнес:
What is it that they are pursuing?
Newness and Novelty. Nowadays the Agile movement is about „The Next Big Thing” and „The Bold New Idea”. They need novelty to keep the enthusiasm and energy high. They need that so that people sign up for conferences and certifications. They need to be seen as making — „progress”. Agile has become a business; and businesses need to grow.
That’s the grand irony. It was programmers who started the Agile movement as a way to say: “Hey look! Teams matter. Code should be clean. We want to collaborate with the customer. And we want to deliver early and often.”
The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: “Wow! Agile is a cool new variation on how to manage projects.”
There’s an old song, by Alan Sherman, called J. C. Cohen. It’s about a subway conductor who did such a great job at pushing people into the train cars, that he pushed the engineer out. This is what happened to the Agile movement. They pushed so many project managers in, they pushed the programmers out.
оффтоп. Есть про «все вот это вот» околоайтишное, прикольный, хоть и достаточно примитивный подкаст от Red Hat www.redhat.com/en/command-line-heroes.
p.s. Там по сезонам, можно вместо сериалов на пробежках слушать.
p.p.s. И про Agile есть эпизод
Спасибо, переместил тему в «барахолку»
Примитивный? Там целый театр у микрофона уровня начала восьмидесятых годов (когда расцвет был)!