Я бы был благодарен если бы перестали выдавать ложные утверждения за аксиомы.
Что сертификационный экзамен — это не зазубривание, мы как-то тактично проехали. Дальше — не лучше. Вам стоит внимательно посмотреть темы покрытые сертификационными экзаменами чтобы понять что утверждение про «один компонент одной версии продукта» точно так же не имеет никакого отношения к реальности, как и тема про зубрежку. Каждый экзамен имеет четко обозначнный круг проверяемых тем, вот можете начать изучать вопрос с «детского» по уровню AZ-203: docs.microsoft.com/en-us/learn/certifications/exams/az-203. Там очень легко увидеть что ваше утверждение не соотвествует истине. Потом можете взять экзамены AWS, Oracle, Cisco и убедиться в том же самом.
Так что я возьму на себя смелость попросить пример кучи сертификатов. Лично я для проекта на netCore вполне себе ограничиваюсь ровно двумя: MCSA Azure Developer или MCSA C# WebApp Developer + ICP для юниора, или MCSE Azure DevOps/MCSD WebApp Developer + PSD 1 для лида. И это дает более чем полное покрытие базовых знаний и о стеке и о процессе. Теперь ваш вариант «кучи», пожалуйста.
Теперь насчет реалистичности ваших предложений.
Смотреть портфолио? Прям исходняки? Очень интересная идея, минимум по двум причинам:
— Исходняки с реальных проектов вообще-то попадают под соглашение о неразглашении и показывать их вообще-то преступление.
— Даже если их смотреть — а какова стоимость отсмотра одного портфолио? Я лично не возьмусь много сказать про человека не покурив его исходняки часа 3-4 минимум. А спец который может грамотно это сделать даже по РФ стоит сейчас $20+/час.
Или вы предлагаете бедному разработчику у которого нет времени и средств на сертификацию инвестироваться в open source или pet проекты чтобы было что показать как портфолио?
Или портфолио это вообще не об исходниках, а о красивом рассказе самого разработчика как классно он где-то чего-то делал? И это вызывает большее доверие чем независимая сертификация?
Ну а в остальном вы говорите о реалиях которые мне, работающему с сертификациями достаточно плотно просто неизвестны.
Как именно можно налепить плашек на продукт через сертификации разработчиков? Какие именно сертификации разработчиков дают возможность вешать какие именно плашки? Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями.
Если честно — я не уверен даже какая из точек зрения хуже — что “сертификаты — это достаточный/единственный способ проверки” или критика сертификации на уровне не совсем верного представления о том, как и зачем это делается.
Во-первых говорить про зазубривание вопросов можно только в двух случаях:
— Если человек никогда не сдавал ни одной сертификации и имеет о них слабое представление
— Если человек пользуется так называемыми dump — практика нечистоплотная и, если на этом поймают — приводящая к лишению сертификата.
На самом деле сертификация это проверка знаний в голове у человека (а не то которые он может моментально нагуглить), в ситуации легкого стресса, созданного присутствием наблюдателя и ограничением по времени, на основе стандартизованных задач. Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено — “человек понимает и уважает риски компании и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу” — то картинка меняется.
А обычный плач по сертификации можно сравнить с экзаменом ВУЗ после прослушивания курса. Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
С одной стороны — отличная статья, и не менее отличные выпады в сторону бездумного применения новомодных веяний, с которыми я полностью согласен, а на кое-что посмотрел с новой точки зрения. С другой постоянно что-то смущает в этом цикле, и эта статья помогла понять. Смущает категоричность утверждений и распространение “опыта выжившего” в конкретных ситуациях на все и любые проекты. Возможно я не прав и таких мыслей не было, но тон и лексика звучат именно так.
Реальность все-таки куда шире, от проектов попадающих под действительно жесткий regulatory compliance, до проектов в которых важнее всего доказать жизнеспособность идеи. И от разовых проектов на три месяца, когда с заказчиком больше никогда не увидишься — до проектов в которых с заказчиком надо жить по 20 лет потом. И на одном краю всего спектра все описанное будет выглядеть недостаточным “детским садом” и “деревенской самодеятельностью”, а на другом превратиться в неподъемное бюрократическое бремя и скорее убьет потенциально успешный проект. Мне в этом плане “не повезло”, я работаю не в нише, как консультант я сталкиваюсь с самыми разными проектами — от системы безопасности АЭС до стартапа пытающегося вытащить совершенно безумную на первый взгляд идею.
Ну и да, не всегда и не везде sales и executives настолько не способны или найти заказчика понимающего как на самом деле делаются проекты или объяснить ему как это делается. Поэтому нахождение с состоянии “никто кроме меня этого не понимает” — совершенно не обязательное. Опять-таки когда меня просят посмотреть процессы — такие моменты это первый “красный флаг” того, что что-то идет сильно не так. Вон в ПыМыБОК аж специально дисциплины под это специально ввели — управление коммуникациями и управление ожиданиями. Мне конечно проще, я в позиции когда я могу на это напрямую влиять, но таки иногда и от Agile есть польза в таких случаях. Когда мы начинаем задавать себе честные вопросы “на фига мы делаем работу которая на самом деле не приносит пользы” — очень быстро выясняется что или мы, или те самые злобные другие действуем не по злому умыслу, а просто из-за недостатка прозрачности.
Не лезу с советами, но мне просто кажется две маленьких вещи:
— Четкое определение круга проектов и ситуаций к которым относятся все утверждения
— И оценка “по чем нам это обошлось” не только для критикуемых решений, но и для своих (потому что бесплатного сыра не бывает, мы всегда чем-то жертвуем, и часто самый интересный анализ лежит не в плоскости “что мы получили”, а в плоскости “чем мы за это заплатили/что мы потеряли”)
сделают просто хороший цикл статей — вот прям таким, что хоть в учебник вставляй. Мне почему-то кажется что он того стоит.
Я где-то с вами спорил про принципиальное существование итеративнога подхода или применимость его в конкретных случаях? Однако, в изначальном вашем комментарии про него было одно предложение в конце, а до этого достаточное количество рассуждений о Scrum, к которым все мои замечания остаются в силе :-)
Единственное, обращу еще раз ваше внимание на то, что вы исключаете из задачи коллектив, оставляя только саму задачу и делаете на основе этого вывод об оптимальности и применимости.
Подумайте над такой ситуацией. Мы имеем на руках ваш же собственный пример с эволюционировавшей системой. На руках только относительно лежащие в русле проекта доделки, команда излазила проект с верху до низу и имеет достаточную базу шаблонов и наработанную практику для оценки типовых задач в рамках системы. Интеративный процесс на грани полного сваливания в предиктивку отлично справляется с работой.
Теперь происходит одно простое событие. Уставшее от однообразной работы ядро команды сваливает в светлые дали на интересные проекты. Что произойдет прекрасным отстроенным итеративным циклом на проекте, на котором сложных задач нет, а гипотез проверять не надо?
Я кажется понял логику. Попробую ответить просто. :-)
Если оставаться на примере с НИОКР — есть большая разница между задачами НИОКР «улучшить одну характеристику существующего образца» и «создать принципиально новый образец». Это разница давно и хорошо известна, и тот же ГОСТ еще 89-го года на нормирование задач НИОКР не зря вводил понятие применимости нормирования, жизненного цикла и срока жизни нормативов.
Вы, кстати, еще раз — идете по пути AUP :-). Все очень знакомые посылки. Вы можете срезать путь сразу перепрыгнув в Disciplined Agile, там это рассмотрено.
Если говорить о «главной ошибке» — то она как раз кроется в идее что выбор жизненного цикла может зависеть от нас. Это не так. Выбор зависит от условий задачи, и, кстати, как раз процесс эволюции жизненного цикла в Disciplined Agile хорошо прописан. Забавно что вы в приниципе в конце как раз пример эволюции процесса и приводите.
Даже если взять водопад — он не хорош и не плох. На проектах, которые могут быть сделаны водопадом — водопад даст результат быстрее и дешевле. Просто потому что куча времени на промежуточные релизы и итеративность не тратятся впустую. Попробуйте чуть-чуть сдвинуть фокус с нюансов организации жизненного цикла (я подозреваю что все их знают и понимают достаточно хорошо) в сферу вопроса «а что именно делает конкретный процесс применимым или неприменимым для конкретного проекта» (и как правило с этим знанием сложнее, вон «не самый плохой заказчик»(tm) со слепой верой во всеприменимость KPI хороший пример).
И ваша, и «не самого плохого заказчика» возможная проблема в рассуждениях как раз в том, что вы как-то получается ставите метод на первое место и пытаетесь обобщить опыт, пригодный для частного случая — как опыт пригодный всегда и везде.
А на первое место надо ставить ставить все-таки две вещи — конкретную задачу и конкретный коллектив который её решает. И искать жизненный цикл и способы которые дадут наиболее экономически эффективное (не «самое дешевое», оценка экономической эффективности немного шире) решение для поставленной проблемы в конкретных условиях. :-)
Вы не уловили. Убеждение о схожести массового производства/обслуживания и разработки доминировали как раз среди пионеров индустрии, я еще даже застал это время. Причина появления Agile как раз в том что не сработало.
А вот если вы знаете конкретный пример хотя бы одного НИОКР сложности хотя бы уровня автомобиля, который бы был оценен заранее, проверялся только KPI, и дошел до производственного образца в заранее предсказанный срок, уложившись в бюджет, без экспериментов и прототипирования — я с удовольствием первым побегу приникать к глубинам мудрости предиктивных манагеров от R&D. :-)
Самый большой самолет A380 — это 4 миллиона частей. Стандартизованных, между прочим. Всегда одних и тех же, и в том же месте, и с той же целью в каждом экземпляре самолета. 4 миллиона отдельных частей — это средненький проект сам по себе. Я управлял проектами размером 40-100 миллионов cloс, и беда в том что каждый из них был уникален. Ни в одном не было тех же самых частей с той же самой целью в том же самом месте. И если вы хотите притянуть сюда нормирование из массового производства, например, с конвеера, добавьте в вашу парадигму конвеер на котором сначала собирают ВАЗ 2101, а следом за ним сразу же Toyota Land Cruiser. А потом захотели ну такой, с крылышками… А, да, самолет называется. Ну типа Cessna 172. А че, мотор у обоих есть. Колеса есть. Приборы есть. Че тут сложного на том же конвеере собрать и те же метрики использовать. :-) Вы ж инженеры.
IT — не уникально, но оно и не подобно ничему из вами перечисленного. Сравнение как водителя автобуса и таксиста. У одного набор каких бы ни было сложных, но стандартизованных и повторяемых операций, у второго — каждый раз новый клиент с новыми запросами и новыми критериями субъективной оценки. Может быть конечно толпы сторонников вашей парадигмы и бродят по просторам экономики, но даже для такой простой области как такси почему-то основными метриками остаются удержание клиентов и выручка, а искуственные KPI.
IT — не массовое производство. IT — это НИОКР, если вы сторонник производственных парадигм. И даже в космической области есть большая разница между запуском отработанной конструкции и разработкой новой.
Поэтому ситуация не бинарна, как вы пытаетесь её изобразить. Есть измерения, есть измерители, а есть люди которые пытаются померить линейкой темпиратуру.
Нежелание слушать певцов от Agile понятно, но при такой приверженности к вашей парадигме — я бы засунулся в вопрос нормирования НИОКР. Там достаточно много интересных открытий может ожидать, в первую очередь связанных с понятием времени жизни нормативов и от чего они зависят. Я просто с этой темой еще с советских времен знаком. :-)
У вас описан идеальный мир, которые не допускает существования ситуации, в которой как бы они все не были идеальны и тщательны, а на деле:
— Это чертовски трудно для stakeholder взять и точно рассказать что ему надо.
— Что неизбежная проблема что человек слышит одно, понимает другое, а пишет совсем третье. В глухой телефон все еще в детстве играли. А у нас в цепочке их несколько stakeholder -> product owner -> project manager -> developers.
Доверие — доверием, а понимание ествественных ограничений — само по себе.
В Agile они обошли проблему того, что нету нормальных объективных критериев оценки работы, скажем, для product, очень просто, сразу задекларировав в 12 принципах:
— Через работоспособный софт как главное мерило прогресса
— Через частую поставку (а значит частые измерение)
Т.е. не стали бороться с неизбежным, а просто сказали — ну раз нельзя проверить требования (или любой другой этап) — так давайте как можно раньше и чаще проверять их готовым софтом. Вот и вся хитрость.
Собственно идея даже не айтишная. Все ж началось с Тойоты и их Toyota Product System, когда они издержки связанные с тем, что не понятно «что, когда и сколько купят», начали пытаться побороть. Отсюда пошел вытягивающий процесс, а от него потянулось все остальное.
Ну это просто не повезло, не то что бы их совсем нет.
Но, возможно, дело просто в том, что идея «мы тут делаем, на за что не отвечаем, но раз в две недели получаем много денег» скорее отражает распространенное заблуждение об Agile.
Когда в Agile говорят про доверие и про внутреннюю мотивацию — они говорят не о том, что все люди по волшебству agile вдруг становятся хорошими. Просто мир сам по себе уже жесткая штука. Не поработал — не получил денег. Не получил денег — нечего кушать. Эти факторы уже говорят о многом, и если вокруг людей будет ходить начальник и рассказывать им какие они плохие что не работают хорошо — он не объяснит этих истин лучше.
Я начальник, я пробовал, точно говорю — не помогает от слова совсем. :-)
О, кстати, спасибо за идею. «Agile не предоставляет кредит доверия» и «доказывать что заказчик может им доверять — первостепенная обязанность Agile команды» хорошая тема для статьи. На русском точно не видел.
И да, «стройте проекты вокруг мотивированных людей» совершенно не зря один из принципов Agile.
А вот людей, которым интересно получать каждые две недели очередную работоспособную версию продукта с улучшениями вместо того, чтобы год сидеть как иголках и думать «эти тоже не справятся или нет» — более чем достаточно.
По моей фразе… И мне было бы интересно, что в моем комментарии вы считаете вольной интерпретацией скрам гайда?
Я ответил не по одной фразе, а как раз по всей логической цепочке где мелкие и не очень неточности подсказывают что есть некоторые проблемы с картиной мира Scrum. К сожалению, чтобы разобрать там все проблемы потребуются не одна и не две вдумчивых сессии, явно не формат комментария.
Но могу подсказать вопросы, которые помогут порыть глубже, для начала хотя бы в этом направлении:
1) Зачем бы DevTeam оставляли полную власть надо Sprint Backlog если «фиксированные оценки» могут существовать хотя бы даже и в рамках спринта? Что на самом деле фиксировано в inverted iron triangle?
2) Как у нас дела с обеспечением transparency если «начальная картина» заведомо создает ложные ожидания, которые обязательно надо «отработать»?
3) Действительно ли из всех значений в русском языке для uncertainty является неопределенность/неизвестность? Какой физический смысл может иметь вообще cone of uncertainty в этом случае? А если обратить внимание, что куда более часто это слово используется в смысле «неуверенность» и «переменчивость»? Могут ли в этом случае у него появиться границы? Возможна ли оценка, коммуникация и обеспечение прозрачности такой uncertainty?
4) Применим ли вообще эмпирический метод, который требует обоснованного формулирования гипотез, в ситуации когда у нас есть истинная «неизвестность»? Почему применяемые в scrum community модели хоть Stacey matrix, хоть Cynefin framework таки в область полной неизвестности относят совершенно не эмпрические Scrum и не Agile?
5) Ну и стоит ли смешивать в кучу разные причины по которым возникает неопредленность? А сколько их вообще? Как заказчик может влиять на наличие неопредленности? Как мы можем влиять на наличие неопредленности? Как конкретная пара мы-заказчик можем влиять на наличие неопредленности?
p.s. И в первоисточнике, кажется, было про слона:))
Если только не рыть дальше Михалковского «Как старик корову продавал». :-)) А я не рыл, лень. :-))
6 редакция уже достаточно много в себя взяла чтобы считать её основой для добротного гибридного подхода. Но многие методы, скажем активное использование work breakdown structure таки основываются на гипотезе, что работу можно понять разложив её на части, и оценив каждую из них. Определние сложной системы прямо этому противоречит, и такой подход не оставляет места для эмержетного поведения системы которую мы оцениваем.
Увы, человек однознадачен по природе. Поэтому куда более эффективно преодоление ограниченности одного человека, какой бы раскоаченный и креативный он не был, таки лежит в командной работе. Отсюда и совсем другая роль лидера в Agile и Lean, весь этот servant leadership. Мы может и «основа», но не потому что «мы — Лидеры», а потому что мы добровольно берем на себя кропотливую работу по выращиванию команды личностей, благодаря которым эффектиность и проявится.
Отсюда собственно растут ноги и у той самой ужастной дайверсити и у коммандной отвественности в lean & agile. Именно активно сотрудничающих коллектив из людей с разным опытом и разным взглядом на мир является наиболее эффективным средством преодоления и шаблонности подходов и вообще сложности проблем.
А так, к сожалению, сколько себя не совершенствуй — в долгосрочной перспективе одиночка, какой бы гениальный не был, будет проигрывать команде.
:-) Во-первых, «так вы эту корову не продадите». Вы бы хоть на абзацы разделили чтобы упростить чтение.
Во-вторых, мне кажется вы немножко путаете возможное и необходимое, вот так категорично утверждая про невозможность.
Тут IMHO лучше вернуться и начать совсем с истоков. Манифест Agile действительно говорит что «мы ценим способность к изменению выше чем следование плану». Однако не надо забывать о том, что написано в самом конце манифеста: «мы все еще ценим вещи справа, мы просто ценим вещи слева больше».
Поэтому вопрос не может стоять ни о том, что оценка вообще не возможна, ни о том, что в Agile её не делают. Вопрос о том, сколько именно оценки приносит пользу. И в этом плане статья, которую вы комментируете, отражает дух и суть Agile manifesto лучше чем ваша вольная интерпретации Scrum Guide.
Возможно, я занимаюсь тем, что закидываю свою некомпетентность в области оценки наукообразными терминами
Как раз наоборот, у вас прекрасное и легкое изложение вполне себе логичных вещей. «Аффтар, пеши исчо» прям просится в качестве комментария. :-)
Что здорово — это то что у вас вполне себе рабочий механизм для работы с неизбежной неопределенностью. Единственное, по сути он остается попыткой адаптации предиктивного подхода — scope зафиксирован, мы играем сроками и бюджетом. Это не плохо и не хорошо, это просто один из путей.
Все-таки для того, чтобы перейти к действительно Agile треугольник надо перевернуть — у нас зафиксирован бюджет и срок, а главный вопрос «какую наибольшую пользу можно принести в оставшееся время и за оставшиеся деньги».
Но тут надо, я так понимаю, тоже надо делать поправку, EBITDA и прочие FATCA звучат не зря, и банковская область тоже не зря. Некоторые задачи, особенно связанные с regulations таки надо превращать в предиктивные, слишком уж высоки риски (турма сидеть например) за non-compliance. Просто в этом случае применение PMBOK может оказаться полезнее попытки нанятуть Agile методы. Тем более что нормальная предиктивка никак не отрицает замечательных вещей, сказанных про accountability и проблем с культурой. Наоборот, вооружит тех самых людей полноценным инструментарием для вдумчивой оценки.
Если требования можно детализовать до понятности разработчикам КАК их делать на два спринта вперед (особенно когда речь идет о месячных спринтах) — то в чем именно заключается сложность реализуемой системы и в чем состоит цикл экспериментирования?
А если ни того, ни другого нет — то зачем там Scrum? Добавление эмпирического компонента — это всегда затраты. При наличии неопределенностей — они оправданы, но если проект достаточно прост чтобы иметь четкий план — то они никакой ценности не добавляют.
И если мы вводим пусть даже негласную метрику “мы хотим чтобы команда всегда заканчивала то, что взяла в sprint backlog” — что у нас происходит происходит со смелостью команды?
“Выяснили все детали”, “полностью поставили scope в конце” — все это очень напоминает распространенный миф что sprint в Scrum это такой маленький водопад. Типа больших водопадов сделать не можем, давайте разобьем на много маленьких. Вот хорошая статья как раз по такое заблуждение medium.com/serious-scrum/scrum-is-just-waterfall-in-disguise-3476203d0f00
Мне кажется такие “внедрения” скрам в итоге и приводят к отношению со стороны разработчиков что мол тащат всякую модную хренатень, а нам пляши старые пляски под новым именем.
Удивлен что перевод вроде как ажно от PST, надо с ним пообщаться ради интереса, он правда так думает или просто неудачно мысли выражает.
Статья супер, особенно понравилось про способы продажи техдолга.
Пара мелких IMHO
1) В той части где про недоверие PO. По идее, это говорит что PO не являются частью команды/оторваны от неё, что не хорошо. Если все сделано правильно, по PO должен быть первый пропонент по борьбе с тех долгом, это ему же тех долг первому и мешает «максимизировать и оптимизировать поток ценности».
2) Насчет «пишут говно на зло» — если честно за все годы практики такого не видел. Зато видел очень много, причем это совершенно интернациональное явление — в результате абсолютного «пох», «и так сойдет».
Что сертификационный экзамен — это не зазубривание, мы как-то тактично проехали. Дальше — не лучше. Вам стоит внимательно посмотреть темы покрытые сертификационными экзаменами чтобы понять что утверждение про «один компонент одной версии продукта» точно так же не имеет никакого отношения к реальности, как и тема про зубрежку. Каждый экзамен имеет четко обозначнный круг проверяемых тем, вот можете начать изучать вопрос с «детского» по уровню AZ-203: docs.microsoft.com/en-us/learn/certifications/exams/az-203. Там очень легко увидеть что ваше утверждение не соотвествует истине. Потом можете взять экзамены AWS, Oracle, Cisco и убедиться в том же самом.
Так что я возьму на себя смелость попросить пример кучи сертификатов. Лично я для проекта на netCore вполне себе ограничиваюсь ровно двумя: MCSA Azure Developer или MCSA C# WebApp Developer + ICP для юниора, или MCSE Azure DevOps/MCSD WebApp Developer + PSD 1 для лида. И это дает более чем полное покрытие базовых знаний и о стеке и о процессе. Теперь ваш вариант «кучи», пожалуйста.
Теперь насчет реалистичности ваших предложений.
Смотреть портфолио? Прям исходняки? Очень интересная идея, минимум по двум причинам:
— Исходняки с реальных проектов вообще-то попадают под соглашение о неразглашении и показывать их вообще-то преступление.
— Даже если их смотреть — а какова стоимость отсмотра одного портфолио? Я лично не возьмусь много сказать про человека не покурив его исходняки часа 3-4 минимум. А спец который может грамотно это сделать даже по РФ стоит сейчас $20+/час.
Или вы предлагаете бедному разработчику у которого нет времени и средств на сертификацию инвестироваться в open source или pet проекты чтобы было что показать как портфолио?
Или портфолио это вообще не об исходниках, а о красивом рассказе самого разработчика как классно он где-то чего-то делал? И это вызывает большее доверие чем независимая сертификация?
Ну а в остальном вы говорите о реалиях которые мне, работающему с сертификациями достаточно плотно просто неизвестны.
Как именно можно налепить плашек на продукт через сертификации разработчиков? Какие именно сертификации разработчиков дают возможность вешать какие именно плашки? Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Если честно — я не уверен даже какая из точек зрения хуже — что “сертификаты — это достаточный/единственный способ проверки” или критика сертификации на уровне не совсем верного представления о том, как и зачем это делается.
Во-первых говорить про зазубривание вопросов можно только в двух случаях:
— Если человек никогда не сдавал ни одной сертификации и имеет о них слабое представление
— Если человек пользуется так называемыми dump — практика нечистоплотная и, если на этом поймают — приводящая к лишению сертификата.
На самом деле сертификация это проверка знаний в голове у человека (а не то которые он может моментально нагуглить), в ситуации легкого стресса, созданного присутствием наблюдателя и ограничением по времени, на основе стандартизованных задач. Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено — “человек понимает и уважает риски компании и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу” — то картинка меняется.
А обычный плач по сертификации можно сравнить с экзаменом ВУЗ после прослушивания курса. Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
Реальность все-таки куда шире, от проектов попадающих под действительно жесткий regulatory compliance, до проектов в которых важнее всего доказать жизнеспособность идеи. И от разовых проектов на три месяца, когда с заказчиком больше никогда не увидишься — до проектов в которых с заказчиком надо жить по 20 лет потом. И на одном краю всего спектра все описанное будет выглядеть недостаточным “детским садом” и “деревенской самодеятельностью”, а на другом превратиться в неподъемное бюрократическое бремя и скорее убьет потенциально успешный проект. Мне в этом плане “не повезло”, я работаю не в нише, как консультант я сталкиваюсь с самыми разными проектами — от системы безопасности АЭС до стартапа пытающегося вытащить совершенно безумную на первый взгляд идею.
Ну и да, не всегда и не везде sales и executives настолько не способны или найти заказчика понимающего как на самом деле делаются проекты или объяснить ему как это делается. Поэтому нахождение с состоянии “никто кроме меня этого не понимает” — совершенно не обязательное. Опять-таки когда меня просят посмотреть процессы — такие моменты это первый “красный флаг” того, что что-то идет сильно не так. Вон в ПыМыБОК аж специально дисциплины под это специально ввели — управление коммуникациями и управление ожиданиями. Мне конечно проще, я в позиции когда я могу на это напрямую влиять, но таки иногда и от Agile есть польза в таких случаях. Когда мы начинаем задавать себе честные вопросы “на фига мы делаем работу которая на самом деле не приносит пользы” — очень быстро выясняется что или мы, или те самые злобные другие действуем не по злому умыслу, а просто из-за недостатка прозрачности.
Не лезу с советами, но мне просто кажется две маленьких вещи:
— Четкое определение круга проектов и ситуаций к которым относятся все утверждения
— И оценка “по чем нам это обошлось” не только для критикуемых решений, но и для своих (потому что бесплатного сыра не бывает, мы всегда чем-то жертвуем, и часто самый интересный анализ лежит не в плоскости “что мы получили”, а в плоскости “чем мы за это заплатили/что мы потеряли”)
сделают просто хороший цикл статей — вот прям таким, что хоть в учебник вставляй. Мне почему-то кажется что он того стоит.
Единственное, обращу еще раз ваше внимание на то, что вы исключаете из задачи коллектив, оставляя только саму задачу и делаете на основе этого вывод об оптимальности и применимости.
Подумайте над такой ситуацией. Мы имеем на руках ваш же собственный пример с эволюционировавшей системой. На руках только относительно лежащие в русле проекта доделки, команда излазила проект с верху до низу и имеет достаточную базу шаблонов и наработанную практику для оценки типовых задач в рамках системы. Интеративный процесс на грани полного сваливания в предиктивку отлично справляется с работой.
Теперь происходит одно простое событие. Уставшее от однообразной работы ядро команды сваливает в светлые дали на интересные проекты. Что произойдет прекрасным отстроенным итеративным циклом на проекте, на котором сложных задач нет, а гипотез проверять не надо?
Еще раз почеркну — я не спорю с вами о возможности или невозможности итеративного цикла. Есть каждой вещи место под солнцем©. Я всего лишь напоминаю что координат по которым мы выбираем процесс не одна — проект. И опять верну вас к Disciplined Agile — их там 8 (восемь!). Поэтому говорить ни о «оптимальном для большинства», ни уж тем более о «я манагер, я знаю»© лучше не надо.
Если оставаться на примере с НИОКР — есть большая разница между задачами НИОКР «улучшить одну характеристику существующего образца» и «создать принципиально новый образец». Это разница давно и хорошо известна, и тот же ГОСТ еще 89-го года на нормирование задач НИОКР не зря вводил понятие применимости нормирования, жизненного цикла и срока жизни нормативов.
Вы, кстати, еще раз — идете по пути AUP :-). Все очень знакомые посылки. Вы можете срезать путь сразу перепрыгнув в Disciplined Agile, там это рассмотрено.
Если говорить о «главной ошибке» — то она как раз кроется в идее что выбор жизненного цикла может зависеть от нас. Это не так. Выбор зависит от условий задачи, и, кстати, как раз процесс эволюции жизненного цикла в Disciplined Agile хорошо прописан. Забавно что вы в приниципе в конце как раз пример эволюции процесса и приводите.
Даже если взять водопад — он не хорош и не плох. На проектах, которые могут быть сделаны водопадом — водопад даст результат быстрее и дешевле. Просто потому что куча времени на промежуточные релизы и итеративность не тратятся впустую. Попробуйте чуть-чуть сдвинуть фокус с нюансов организации жизненного цикла (я подозреваю что все их знают и понимают достаточно хорошо) в сферу вопроса «а что именно делает конкретный процесс применимым или неприменимым для конкретного проекта» (и как правило с этим знанием сложнее, вон «не самый плохой заказчик»(tm) со слепой верой во всеприменимость KPI хороший пример).
И ваша, и «не самого плохого заказчика» возможная проблема в рассуждениях как раз в том, что вы как-то получается ставите метод на первое место и пытаетесь обобщить опыт, пригодный для частного случая — как опыт пригодный всегда и везде.
А на первое место надо ставить ставить все-таки две вещи — конкретную задачу и конкретный коллектив который её решает. И искать жизненный цикл и способы которые дадут наиболее экономически эффективное (не «самое дешевое», оценка экономической эффективности немного шире) решение для поставленной проблемы в конкретных условиях. :-)
А вот если вы знаете конкретный пример хотя бы одного НИОКР сложности хотя бы уровня автомобиля, который бы был оценен заранее, проверялся только KPI, и дошел до производственного образца в заранее предсказанный срок, уложившись в бюджет, без экспериментов и прототипирования — я с удовольствием первым побегу приникать к глубинам мудрости предиктивных манагеров от R&D. :-)
Самый большой самолет A380 — это 4 миллиона частей. Стандартизованных, между прочим. Всегда одних и тех же, и в том же месте, и с той же целью в каждом экземпляре самолета. 4 миллиона отдельных частей — это средненький проект сам по себе. Я управлял проектами размером 40-100 миллионов cloс, и беда в том что каждый из них был уникален. Ни в одном не было тех же самых частей с той же самой целью в том же самом месте. И если вы хотите притянуть сюда нормирование из массового производства, например, с конвеера, добавьте в вашу парадигму конвеер на котором сначала собирают ВАЗ 2101, а следом за ним сразу же Toyota Land Cruiser. А потом захотели ну такой, с крылышками… А, да, самолет называется. Ну типа Cessna 172. А че, мотор у обоих есть. Колеса есть. Приборы есть. Че тут сложного на том же конвеере собрать и те же метрики использовать. :-) Вы ж инженеры.
IT — не уникально, но оно и не подобно ничему из вами перечисленного. Сравнение как водителя автобуса и таксиста. У одного набор каких бы ни было сложных, но стандартизованных и повторяемых операций, у второго — каждый раз новый клиент с новыми запросами и новыми критериями субъективной оценки. Может быть конечно толпы сторонников вашей парадигмы и бродят по просторам экономики, но даже для такой простой области как такси почему-то основными метриками остаются удержание клиентов и выручка, а искуственные KPI.
IT — не массовое производство. IT — это НИОКР, если вы сторонник производственных парадигм. И даже в космической области есть большая разница между запуском отработанной конструкции и разработкой новой.
Поэтому ситуация не бинарна, как вы пытаетесь её изобразить. Есть измерения, есть измерители, а есть люди которые пытаются померить линейкой темпиратуру.
Нежелание слушать певцов от Agile понятно, но при такой приверженности к вашей парадигме — я бы засунулся в вопрос нормирования НИОКР. Там достаточно много интересных открытий может ожидать, в первую очередь связанных с понятием времени жизни нормативов и от чего они зависят. Я просто с этой темой еще с советских времен знаком. :-)
У вас описан идеальный мир, которые не допускает существования ситуации, в которой как бы они все не были идеальны и тщательны, а на деле:
— Это чертовски трудно для stakeholder взять и точно рассказать что ему надо.
— Что неизбежная проблема что человек слышит одно, понимает другое, а пишет совсем третье. В глухой телефон все еще в детстве играли. А у нас в цепочке их несколько stakeholder -> product owner -> project manager -> developers.
Доверие — доверием, а понимание ествественных ограничений — само по себе.
В Agile они обошли проблему того, что нету нормальных объективных критериев оценки работы, скажем, для product, очень просто, сразу задекларировав в 12 принципах:
— Через работоспособный софт как главное мерило прогресса
— Через частую поставку (а значит частые измерение)
Т.е. не стали бороться с неизбежным, а просто сказали — ну раз нельзя проверить требования (или любой другой этап) — так давайте как можно раньше и чаще проверять их готовым софтом. Вот и вся хитрость.
Собственно идея даже не айтишная. Все ж началось с Тойоты и их Toyota Product System, когда они издержки связанные с тем, что не понятно «что, когда и сколько купят», начали пытаться побороть. Отсюда пошел вытягивающий процесс, а от него потянулось все остальное.
Но, возможно, дело просто в том, что идея «мы тут делаем, на за что не отвечаем, но раз в две недели получаем много денег» скорее отражает распространенное заблуждение об Agile.
Когда в Agile говорят про доверие и про внутреннюю мотивацию — они говорят не о том, что все люди по волшебству agile вдруг становятся хорошими. Просто мир сам по себе уже жесткая штука. Не поработал — не получил денег. Не получил денег — нечего кушать. Эти факторы уже говорят о многом, и если вокруг людей будет ходить начальник и рассказывать им какие они плохие что не работают хорошо — он не объяснит этих истин лучше.
Я начальник, я пробовал, точно говорю — не помогает от слова совсем. :-)
О, кстати, спасибо за идею. «Agile не предоставляет кредит доверия» и «доказывать что заказчик может им доверять — первостепенная обязанность Agile команды» хорошая тема для статьи. На русском точно не видел.
И да, «стройте проекты вокруг мотивированных людей» совершенно не зря один из принципов Agile.
А вот людей, которым интересно получать каждые две недели очередную работоспособную версию продукта с улучшениями вместо того, чтобы год сидеть как иголках и думать «эти тоже не справятся или нет» — более чем достаточно.
Я ответил не по одной фразе, а как раз по всей логической цепочке где мелкие и не очень неточности подсказывают что есть некоторые проблемы с картиной мира Scrum. К сожалению, чтобы разобрать там все проблемы потребуются не одна и не две вдумчивых сессии, явно не формат комментария.
Но могу подсказать вопросы, которые помогут порыть глубже, для начала хотя бы в этом направлении:
1) Зачем бы DevTeam оставляли полную власть надо Sprint Backlog если «фиксированные оценки» могут существовать хотя бы даже и в рамках спринта? Что на самом деле фиксировано в inverted iron triangle?
2) Как у нас дела с обеспечением transparency если «начальная картина» заведомо создает ложные ожидания, которые обязательно надо «отработать»?
3) Действительно ли из всех значений в русском языке для uncertainty является неопределенность/неизвестность? Какой физический смысл может иметь вообще cone of uncertainty в этом случае? А если обратить внимание, что куда более часто это слово используется в смысле «неуверенность» и «переменчивость»? Могут ли в этом случае у него появиться границы? Возможна ли оценка, коммуникация и обеспечение прозрачности такой uncertainty?
4) Применим ли вообще эмпирический метод, который требует обоснованного формулирования гипотез, в ситуации когда у нас есть истинная «неизвестность»? Почему применяемые в scrum community модели хоть Stacey matrix, хоть Cynefin framework таки в область полной неизвестности относят совершенно не эмпрические Scrum и не Agile?
5) Ну и стоит ли смешивать в кучу разные причины по которым возникает неопредленность? А сколько их вообще? Как заказчик может влиять на наличие неопредленности? Как мы можем влиять на наличие неопредленности? Как конкретная пара мы-заказчик можем влиять на наличие неопредленности?
p.s. И в первоисточнике, кажется, было про слона:))
Если только не рыть дальше Михалковского «Как старик корову продавал». :-)) А я не рыл, лень. :-))
6 редакция уже достаточно много в себя взяла чтобы считать её основой для добротного гибридного подхода. Но многие методы, скажем активное использование work breakdown structure таки основываются на гипотезе, что работу можно понять разложив её на части, и оценив каждую из них. Определние сложной системы прямо этому противоречит, и такой подход не оставляет места для эмержетного поведения системы которую мы оцениваем.
7 редакция обещают будет куда сильнее склоняться в сторону Agile, не зря в конце коцнов они последний год такие усилия по развитию и проталкиванию Disciplined Agile предпринимают. Но лучше мы будет рассуждать «о вкусе этих омаров»© когда их попробуем. :-)
С другой стороны… «Мы — Лидеры», вот так вот, с большой буквы. Прям так и тянет классическим command & control («мы Лидеры», поэтому мы тут командуем, ибо «основа всех процессов повышения эффективности» ©) пытающимся натянуть на себя одеяло модных «agile» и «lean». А то поезд уходит…
Увы, человек однознадачен по природе. Поэтому куда более эффективно преодоление ограниченности одного человека, какой бы раскоаченный и креативный он не был, таки лежит в командной работе. Отсюда и совсем другая роль лидера в Agile и Lean, весь этот servant leadership. Мы может и «основа», но не потому что «мы — Лидеры», а потому что мы добровольно берем на себя кропотливую работу по выращиванию команды личностей, благодаря которым эффектиность и проявится.
Отсюда собственно растут ноги и у той самой ужастной дайверсити и у коммандной отвественности в lean & agile. Именно активно сотрудничающих коллектив из людей с разным опытом и разным взглядом на мир является наиболее эффективным средством преодоления и шаблонности подходов и вообще сложности проблем.
А так, к сожалению, сколько себя не совершенствуй — в долгосрочной перспективе одиночка, какой бы гениальный не был, будет проигрывать команде.
Во-вторых, мне кажется вы немножко путаете возможное и необходимое, вот так категорично утверждая про невозможность.
Тут IMHO лучше вернуться и начать совсем с истоков. Манифест Agile действительно говорит что «мы ценим способность к изменению выше чем следование плану». Однако не надо забывать о том, что написано в самом конце манифеста: «мы все еще ценим вещи справа, мы просто ценим вещи слева больше».
Поэтому вопрос не может стоять ни о том, что оценка вообще не возможна, ни о том, что в Agile её не делают. Вопрос о том, сколько именно оценки приносит пользу. И в этом плане статья, которую вы комментируете, отражает дух и суть Agile manifesto лучше чем ваша вольная интерпретации Scrum Guide.
Как раз наоборот, у вас прекрасное и легкое изложение вполне себе логичных вещей. «Аффтар, пеши исчо» прям просится в качестве комментария. :-)
Что здорово — это то что у вас вполне себе рабочий механизм для работы с неизбежной неопределенностью. Единственное, по сути он остается попыткой адаптации предиктивного подхода — scope зафиксирован, мы играем сроками и бюджетом. Это не плохо и не хорошо, это просто один из путей.
Все-таки для того, чтобы перейти к действительно Agile треугольник надо перевернуть — у нас зафиксирован бюджет и срок, а главный вопрос «какую наибольшую пользу можно принести в оставшееся время и за оставшиеся деньги».
Но тут надо, я так понимаю, тоже надо делать поправку, EBITDA и прочие FATCA звучат не зря, и банковская область тоже не зря. Некоторые задачи, особенно связанные с regulations таки надо превращать в предиктивные, слишком уж высоки риски (турма сидеть например) за non-compliance. Просто в этом случае применение PMBOK может оказаться полезнее попытки нанятуть Agile методы. Тем более что нормальная предиктивка никак не отрицает замечательных вещей, сказанных про accountability и проблем с культурой. Наоборот, вооружит тех самых людей полноценным инструментарием для вдумчивой оценки.
Отличный материал на котором можно учить других и о том как оно может пойти и о том как самоорганизующаяся команда должна с этим справляться.
Хорошая у вас команда. :-)
Если требования можно детализовать до понятности разработчикам КАК их делать на два спринта вперед (особенно когда речь идет о месячных спринтах) — то в чем именно заключается сложность реализуемой системы и в чем состоит цикл экспериментирования?
А если ни того, ни другого нет — то зачем там Scrum? Добавление эмпирического компонента — это всегда затраты. При наличии неопределенностей — они оправданы, но если проект достаточно прост чтобы иметь четкий план — то они никакой ценности не добавляют.
И если мы вводим пусть даже негласную метрику “мы хотим чтобы команда всегда заканчивала то, что взяла в sprint backlog” — что у нас происходит происходит со смелостью команды?
“Выяснили все детали”, “полностью поставили scope в конце” — все это очень напоминает распространенный миф что sprint в Scrum это такой маленький водопад. Типа больших водопадов сделать не можем, давайте разобьем на много маленьких. Вот хорошая статья как раз по такое заблуждение
medium.com/serious-scrum/scrum-is-just-waterfall-in-disguise-3476203d0f00
Мне кажется такие “внедрения” скрам в итоге и приводят к отношению со стороны разработчиков что мол тащат всякую модную хренатень, а нам пляши старые пляски под новым именем.
Удивлен что перевод вроде как ажно от PST, надо с ним пообщаться ради интереса, он правда так думает или просто неудачно мысли выражает.
Пара мелких IMHO
1) В той части где про недоверие PO. По идее, это говорит что PO не являются частью команды/оторваны от неё, что не хорошо. Если все сделано правильно, по PO должен быть первый пропонент по борьбе с тех долгом, это ему же тех долг первому и мешает «максимизировать и оптимизировать поток ценности».
2) Насчет «пишут говно на зло» — если честно за все годы практики такого не видел. Зато видел очень много, причем это совершенно интернациональное явление — в результате абсолютного «пох», «и так сойдет».
слева-внизу
1,038,979 PMP
36,893 PMI-ACP