Не соглашайся ни за что
Ни с кем и никогда,
А кто с тобой согласен, тех
Трусливыми зови.
За это все тебя начнут
Любить и уважать.
И всюду будет у тебя
Полным полно друзей.
Григорий Остер.
На конференциях, митапах, вебинарах все дают полезные советы по Agile. И никто их не ценит — ни советчиков, ни советы. А мы решили по совету Григория Остера найти побольше новых друзей — потому что мы дружелюбные — и дать вам вредные советы по Agile.
1. С самого начала знайте, что Agile трансформация происходит легко, дёшево и очень быстро. Буквально через месяц ваша компания вырастет в прибыли, все станут брать на себя ответственность, а руководство будет доверять своим сотрудникам. Agile — это легко. Как пирожное с касторкой. Как помывка кота под душем. Как забрать кость у бультерьера.
2. Если вы Agile-коуч, сразу приходите к руководству, говорите кучу незнакомых слов и требуйте революции. Libertе, Еgalitе, Fraternitе. Можете даже принести с собой маленькую гильотинку и показать, как режутся косты и сокращается персонал. Скорее всего вас не поймут — но ведь это их проблема, а не ваша. А когда увидят предполагаемые траты на тренинги и внешний консалтинг – сразу же согласятся. Потому что топ-менеджеры обожают тратить деньги непонятно куда — после этого у них появляется возможности поговорить с любимыми инвесторами, которых так трудно заманить на встречу.
3. Приходите в свой отдел и уверенно объявляйте, что с понедельника у вас Agile, а для этого с пятницы у вас Scrum. Давление, непрозрачность, непонятные слова – сотрудники будут вам благодарны и Agile-трансформация пойдёт быстрее. Весело и быстро — как на санках с Эвереста.
4. Сразу же обещайте золотые горы: «Вот, если мы станем Agile, мы перевыполним план в 3 раза или выполним проект в 4 раза быстрее». Никто не знает, как будет, потому никто не оспорит ваши слова. И вы всегда будете правы — а это приятно.
5. Лучше всего начинать Agile-трансформацию c IT — ни в коем случае не втягивайте смежные подразделения. Пусть они не знают, как вам классно и здорово. Не делитесь полезностям, фичами и кейсами. Если они спросят, чем вы занимаетесь, никогда не рассказывайте и делайте загадочное выражение лица. Вызывайте здоровую корпоративную зависть. И вам это вернётся сторицей и дружелюбием.
6. Через месяц после начала Agile-транформации гордо выходите на сцену всех конференций, до которых дотянетесь. DevOps? Ок. Ежегодное собрание МАГАТЭ — вообще отлично. Участвуйте во всех внешних мероприятиях, всем рассказывайте, что вы стали «бирюзовой» организацией. И пусть у вас до сих пор генеральный карает всех по вертикали раз в две недели, никому не верит, а служба безопасности обыскивает ваши квартиры, пока вы на работе. Вы уже «бирюзовые» через месяц. И пусть кто-то оспорит — у генерального бита есть с надписью «самому эффективному руководителю «красной» организации». Самое главное — это пиар. Сегодня среда или четверг? Значит с понедельника называйтесь «бирюзовой» организацией.
7. Самый главный совет. Agile — это история о том, как меньше общаться с клиентом и конечным пользователем. Люди сами не знают, чего хотят, а вы прекрасно знаете их потребности. Можете даже бейсболки клиентам на входе раздавать с надписью «I don't know». Они всё равно нихт шпрехен инглиш. Клиентам будет приятно, а вам весело. Если клиентам дать волю, они напридумывают что-то, а вам всё менять. Ещё и работать придётся. Вы лучше всех знаете своего клиента и услугу. И нечего с клиентом церемониться.
8. Ни в коем случае не создавайте лишних сущностей. Это ещё монах Оккам придумал. Если нанимать каких-то непонятных Scrum master и product owner, пусть это будет один человек. Его задача — четко сообщить команде, что нужно сделать команде, если они ещё когда-то в жизни захотят увидеть свою зарплату. После этот незаменимый человек проведёт ретроспективу и станет вашим личным психологом. Не умножайте сущностей — бритва Оккама рулит.
9. Самое вредное и ненужное мероприятие в скраме и Agile-культуре — это ретроспектива. Люди два часа обсуждают, что им нравится и что мешает. Мы же взрослые люди и понимаем, что нравится им получать зарплату, а мешает врожденная лень. Понятно, что Agile-коуч хочет показать свою полезность, но пусть показывает ее другим способом.
Но если вы хотите узнать, как по-настоящему правильно проводить Agile-трансформацию, как избегать ошибок и завышенных ожиданий в самом начале, как довести процесс трансформации до успешного финала, присоединяйтесь к нам на Слёрме Agile.
Составляла вредные советы Марина Алекс marina_alex, CEO University of Business Agility, автор и основной спикер Слёрма Agile Слёрм Agile.
tolkach88
Все тут боятся коронавируса, а надо Agile. Жаль что у больных этой заразой летальность низкая… Не ну правда ну блин методика организации работы… Вы серьезно? Что ж вы с ГОСТами так не носитесь — там тоже грамотно написано что и как нужно проектировать и в каком порядке
mad_nazgul
Потому что по ГОСТУ нельзя «фигак, фигак ив продакшен» ;-)
ggo
Agile не про ГОСТ, и даже не про ИТ. Agile про людей.
Agile и ГОСТы живут в разных измерениях.
tolkach88
Либо здесь врут либо я чего-то не понимаю. Ну или это вы чего-то не догоняете. ГОСТы описывают все. Если чего нет в ГОСТАх значит оно либо ненужно, либо скоро там будет. И да в ГОСТах тоже есть «про людей»
Kanut
А где там что-то про ГОСТы?
Очень интересное заявление. Про тот же секс у нас в ГОСТАх много написано? Или он не нужен? :)
Но не всё что есть про людей есть в гостах?
ggo
Да, с этим беда.
Вроде у людей в ИТ в среднем формальная логика должна быть лучше развита. Но нет.
Я немало с кем сталкивался, кто утверждал, что agile про ИТ.
На вопрос «почему», указывали на заголовок.
Я в ответ: «Ну ок, в заголовке есть software development, а в самой декларации есть что-нибудь более детальное про ИТ?»
Как ни странно, Agile Manifesto ничего ИТ-специфичного не декларирует.
Только про людей, и все что связано с людьми.
зы
И в ГОСТах тоже есть про людей.
Но с другого аспекта.
tolkach88
Понимаете в чем проблема — в подмене понятий. Здесь конкретно МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Разработка программного обеспечения — это не про людей, это про процесс!
А если посмотреть внимательно — а какие методолгии вообще есть? В один ряд с этим непотребством встают реальные совокупности методов разработки — итерационный и водопад. Почему непотребство? Потому что под определение «метод» никак не подходят ни «идеи» не «принципы» Где последовательные шаги для достижения результата? Вот это вот: «сначала берем человека потом инструмент, потом делаем то-то...» А всем любителям порассуждать что там ничего нет про именно разработку ПО процитирую:
Принципы, которые разъясняет Agile Manifesto:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
А насчет ГОСТов — таки да секс во время разработки и производства промышленной продукции и ПО абсолютно не нужен.) Потому его там и нет) А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.
И в заключение — дорогие менегеры! Не пытайтесь натянуть сову на глобус! Что работает с ПО не работает с физическими объектами. Если в ПО спрятать лапшу и кошмар в коде легко — о внешнем виде кода ни кто кроме вас знать не будет. То извините с другими вещами хрен! Минимум это будет видно, максимум законы физики не дадут кошмару работать изначально, либо после первой же поломки с помощью отвертки найдут всю вашу «гибкость» внутри и больше вы ничего не продадите — это я на примерах пояснил. Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
Kanut
В конкретных методиках вроде скрама и канбана.
Очень категоричное утверждение. Тот же канбан и водопад например в информатику пришли из индустрии.
Вы наверное уже поискали и вам не составит труда процитировать то что вы нашли? Или это только ваши предположения?
С чего вы решили что аджайл работает без грамотно поставленных изначальных требований? Именно в этом плане он от того же водопада ничем не отличается.
ggo
если в манифесте вместо «программное обеспечение» подставить что-нибудь другое, например «услуга» или «изделие», что-нибудь принципиально изменится?
и регулярно сталкиваюсь с мнением, что agile — означает анархию, отсутствие целей и ответственности. если делаем тяп-ляп, значит делаем agile.
нет, в agile в целом, а скрам в частности, очень консервативен в плане требований, целей, ответственности, сроков и всего прочего, что нужно бизнесу для решения его проблем.
важно лишь понимать, что контекст у бизнеса бывает разный.
в одном контексте — отлично заходит agile, в другом контексте — научный, в третьем — армейский, и т.д.
Так это ж никто не оспаривает.
Вопрос только в подходах.
Можно сказать, уважаемый… (HR, юрист, бухгалтер, кладовщик и пр.), пока вы не напишите внятное ТЗ, мы палец о палец не ударим.
А можно сказать, давайте выясним, почему у вас эта проблема, и вместе найдем ее решение.
mad_nazgul
Э-э-э. Весь человеческий опыт говорит, что любой манифест приводит к «анархии, отсутствию целей и т.д.»
Начиная с 10 заповедей и нагорной проповеди.
Хорошие же манифесты были.
К чему привели…
Манифест, он про людей.
Т.е. чтобы манифест работал нужны строго определенные люди с психофизическими характеристиками.
Их либо с 0 лет воспитывают, либо они извращают манифест до полной противоположности.