Comments 66
> Но в мире есть много задач, в которых никакой Agile не будет работать
Хорошая идея статьи: обзор разных методологий и разные типы проектов — что для чего лучше подходит.
Хорошая идея статьи: обзор разных методологий и разные типы проектов — что для чего лучше подходит.
Есть куча классификаций и, к сожалению, серебренной пули нет. Вот, например, один из способов поклассифицировать проекты и подходы к их реализации.
Esli naberus vremeni i terpeniay napishu...t.k. moay dissertaciay byla kaka raz na etu temy))
Мой опыт говорит о том, что с Agile часто случается Карго Культ.
Неуверенный в себе начальник требует Agile (или его заставили сверху), никто не понимает зачем это нужно и как это делать, все бегают и машут крыльями (делают итерации и стоят на совещаниях), но самолёт не летит… :(
Неуверенный в себе начальник требует Agile (или его заставили сверху), никто не понимает зачем это нужно и как это делать, все бегают и машут крыльями (делают итерации и стоят на совещаниях), но самолёт не летит… :(
Самым ярким, конечно же, будет пример написания софта, управляющего космическими аппаратами — ну вот сложно раз две недели демонстрировать заказчикам посадку зонда на комету, получая в ответ замечания, что именно с точки зрения ученых-физиков стоило бы сделать по-другому.
Пример несколько неудачный — можно демонстрировать моделирование посадки в симуляторе, с текущей версией софта.
Но в целом да — та, где критично отсутствие багов, подход «постепенно увеличиваем качество» не сработает в лоб.
Скрам всё же не о «постепенном улучшении качества», а о «постепенном наращивании функционала». И в конце каждой итерации реализованный функционал должен быть именно что того качества, которое требуется. Другое дело, что размер итераций в особо ответственных областях может измеряться не неделями, а месяцами.
Выскажусь со своей колокольни. И вообще, я не менеджер, а разработчик, и, вероятно, во многом ошибаюсь, но всё же… На нескольких проектах был тимлидом.
Agile (как и любая другая методология) никогда не заменит собственно работу. Все с этим вот носятся, как с писаной торбой, вместо того, чтобы просто делать то, что надо. Я лично в гробу видал соответствие всяким там процессам, если у меня ключевой функционал не дописан / сдох после коммита / заказчик немного передумал.
Вот, кстати, про заказчиков. Есть вещи, которые ни в какой Agile не укладываются, и которые менять нельзя. Рюшечками и плюшечками обвешивать проект можно бесконечно, но многие почему-то считают, что в гибкость входит смена технологии, кардинальная смена дизайна на поздних этапах разработки и т.д. Ну а чо, Agile же, правильно? Гибкость там и вот это всё. К сожалению, использование Agile иногда приводит к тому, что кто-то хочет банально сесть на шею, взяться за уши и рулить куда хочется. И такие явления надо пресекать на корню, решительно наплевав на всякое несоответствие любимой методологии.
Это всё к тому, что не надо вообще на методологии зацикливаться. Это не самоцель. Следование всем умным советам из всех умных книжек приведёт только к разочарованию в неплохой, по сути, методологии. Работать надо, а не хернёй страдать.
Agile (как и любая другая методология) никогда не заменит собственно работу. Все с этим вот носятся, как с писаной торбой, вместо того, чтобы просто делать то, что надо. Я лично в гробу видал соответствие всяким там процессам, если у меня ключевой функционал не дописан / сдох после коммита / заказчик немного передумал.
Вот, кстати, про заказчиков. Есть вещи, которые ни в какой Agile не укладываются, и которые менять нельзя. Рюшечками и плюшечками обвешивать проект можно бесконечно, но многие почему-то считают, что в гибкость входит смена технологии, кардинальная смена дизайна на поздних этапах разработки и т.д. Ну а чо, Agile же, правильно? Гибкость там и вот это всё. К сожалению, использование Agile иногда приводит к тому, что кто-то хочет банально сесть на шею, взяться за уши и рулить куда хочется. И такие явления надо пресекать на корню, решительно наплевав на всякое несоответствие любимой методологии.
Это всё к тому, что не надо вообще на методологии зацикливаться. Это не самоцель. Следование всем умным советам из всех умных книжек приведёт только к разочарованию в неплохой, по сути, методологии. Работать надо, а не хернёй страдать.
Расскажите про карьеру идеального менеджера.
Я вас спросил не про то, могут они быть или нет, а про идеальную карьеру.
Вот был школьник, закончил школу.
…
…
И вот у нас идеальный менеджер, который нравится и компании, и программистам.
Заполните пустоты, пожалуйста.
Я прицепился к " В больном коллективе программист становится менеджером, в здоровом — остаётся программистом. " — и мне стало интересно, откуда в здоровом обществе образуются менеджеры.
Вот был школьник, закончил школу.
…
…
И вот у нас идеальный менеджер, который нравится и компании, и программистам.
Заполните пустоты, пожалуйста.
Я прицепился к " В больном коллективе программист становится менеджером, в здоровом — остаётся программистом. " — и мне стало интересно, откуда в здоровом обществе образуются менеджеры.
Есть мнение, что психологи и психиатры, такие же паразитирующие на людях сущности, как менеджеры и маркетологи.
Т.е. в знании самой психологии и прочих сопутствующих вещей ничего плохого нет. Так же как и в том же аджайле, самом по себе, ничего плохого нет. Но вот в том как люди применяют эти знания, есть многие беды…
Т.е. в знании самой психологии и прочих сопутствующих вещей ничего плохого нет. Так же как и в том же аджайле, самом по себе, ничего плохого нет. Но вот в том как люди применяют эти знания, есть многие беды…
ИМХО все нужно применять без фанатизма. К примеру, иметь то, что можно показать начальству/заказчику в конце недельного цикла очень даже полезно. Но зарываться в бумагах (был такой опыт), когда из 20 страниц реально полезными оказываются три строчки, а остальное — вода — тоже пользы особой не приносят. Другая крайность, когда нет ни ТЗ, ни четкого видения проекта, зато все дружно что-то делают, а закончив, переделывают заново. Такое оголтелое программирование :)
Я же не спорю, что ТЗ может быть полезным :) У меня была задача, при определенных платежах снимать с клиентов комиссию — в одном случае в процентом соотношении, в другом — фиксированную сумму. Для этого прожектменеджером была написана бумага в 20 с лишним страниц! По моему разумению, это слишком. Зато все было по Agile :)
Не могу полностью согласиться со статьей, и даже отчасти с комментариями.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
При этом совершенно необязательно отказываться от каких-то элементов процесса, которые ассоциируются с Agile, но работают везде.Особенно, если я добавлю, что у нас не было доски для скрама — мы использовали basecamp, и не было ежедневных сборищ, так как команде из трех человек, сидящих рядом, они мало нужны.
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
у нас не было доски для скрамаРечь о канбан-доске? :-)
Нет, о scrum-доске. Но, внешне они похожи, только используются немного по-разному :-)
А в чём отличие?
Я не настолько разбирался с канбаном, чтобы рассказать про отличия самостоятельно, но на английском есть описание в этом документе (страница 14).
Однако, есть на русском.
Однако, есть на русском.
Так в чем же тогда разница между этими двумя досками? Да – вот эта маленькая «2» в средней колонке
на Kanban-доске. И всѐ. Эта цифра 2 означает что «в этой колонке может быть не более 2-х элементов
одновременно».
Зачем-то убрали ограничение (а убирать его нет никакого смысла) и вот у нас типа «новая доска» :-)
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Практически во всех опен сорсных проектах есть милестоуны, которые в принципе можно считать чем-то вроде скрама. И, как ни странно, сообщество разработчиков им следует более или менее.
А почему «заказчик отсутствует как класс»? ГД — и есть точное воплощение product owner'а, который заинтересован в конечном продукте (игре).
Я оппонирую статье, там под заказчиком понимается именно заказчик. И если заказчику мы не можем каждую неделю демонстрировать посадку спутника на комету, то все, скрам не применим.
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
Agile и прочий Scrum — это методы управления программистами людьми, далекими от программирования.
В АйТи денег много, вот и ломятся сюда кто попало. А работу-то делать надо. Вот и придумали методологию управления умными людьми людьми недалекими.
На самом деле, если ты в теме, говоришь с программистами на одном языке — рулить проектами легко без всяких скрамов. Говорю это основываясь на своем 8-летнем опыте.
В АйТи денег много, вот и ломятся сюда кто попало. А работу-то делать надо. Вот и придумали методологию управления умными людьми людьми недалекими.
На самом деле, если ты в теме, говоришь с программистами на одном языке — рулить проектами легко без всяких скрамов. Говорю это основываясь на своем 8-летнем опыте.
Поднята дикая тема. О применимости подходов. Ваш местечковый опыт не говорит о применимости концепций в целом.
Вопрос следует рассматривать глубже. Почему Agile вообще появился?? Вот раньше УП в ИТ напоминало УП во многих других отраслях. Agile в виде XP появился в результате необходимости спасти (в Крайслере там или где — неважно) проект.
Еще более глубоко, сильную мысль скажу. Agile это ответ в первую очередь на некомпетентность заказчиков в ИТ-проектировании. Даже банальный waterfall способен завершить в срок в бюджет и с надлежащим качеством (я не скажу процент тех моих проектов лично, которые так произошли, но они были).
Если изначально ясно, что за изменения надо платить, почему бы это не ввести в процесс? Такая логика появилась, и в результате появился Agile (с его манифестом). Развитие ИТ опережало развитие традиционного бизнеса и его моделей в 90-00… Но сейчас этого НЕТ.
Agile — это способ переложить риски. Ввести его в тренд не удается, и не выйдет (имхо конечно), потому что бизнесу не нужна услуга, ему нужен продукт.
Вопрос следует рассматривать глубже. Почему Agile вообще появился?? Вот раньше УП в ИТ напоминало УП во многих других отраслях. Agile в виде XP появился в результате необходимости спасти (в Крайслере там или где — неважно) проект.
Еще более глубоко, сильную мысль скажу. Agile это ответ в первую очередь на некомпетентность заказчиков в ИТ-проектировании. Даже банальный waterfall способен завершить в срок в бюджет и с надлежащим качеством (я не скажу процент тех моих проектов лично, которые так произошли, но они были).
Если изначально ясно, что за изменения надо платить, почему бы это не ввести в процесс? Такая логика появилась, и в результате появился Agile (с его манифестом). Развитие ИТ опережало развитие традиционного бизнеса и его моделей в 90-00… Но сейчас этого НЕТ.
Agile — это способ переложить риски. Ввести его в тренд не удается, и не выйдет (имхо конечно), потому что бизнесу не нужна услуга, ему нужен продукт.
Некоторое время назад я изучал инновационный менеджмент, потом заметил, что многие подходы, но только уже без объяснения причин и в виде бездушного набора правил внезапно есть agile.
Ещё могу добавить по памяти из последних проектов:
1. У PO нет времени сидеть с вами, выловить его на пару часиков раз в несколько недель большая удача, и он при этом почти всегда чем-то занят кроме вас
2. PO просто увольняется, а проект нужно сдавать новому человеку или его заму, которому явно не до вас.
3. Состав команды не может быть зафиксирован на итерацию. Если у компании есть другие проекты на поддержку, то сотрудников часто приходится перекидывать на баг-фиксинг в других проектах.
1. У PO нет времени сидеть с вами, выловить его на пару часиков раз в несколько недель большая удача, и он при этом почти всегда чем-то занят кроме вас
2. PO просто увольняется, а проект нужно сдавать новому человеку или его заму, которому явно не до вас.
3. Состав команды не может быть зафиксирован на итерацию. Если у компании есть другие проекты на поддержку, то сотрудников часто приходится перекидывать на баг-фиксинг в других проектах.
по-моему, вся проблема от того, что люди валят в кучу Agile манифест и Agile методологии :)
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)
Люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Просто не надо отгораживаться от людей процессом и быть открытым к общению :)
Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)
Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)
Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)
Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
Кстати, на счет
все это придумано задолго до АйТи— тут я полностью согласен. Я временами увлекаюсь другими сферами деятельности кроме IT и вижу, что, например, полноценное проектирование происходит прежде чем начинаешь что-то ваять, при чем уровень проектирования и документации, как правило, выше чем это можно увидеть в IT. Из чего можно сделать вывод, что айтишники — ленивые люди с отблеском элитарности на своем ЧСВ, которые к работе подходят зачастую небрежно.
Сначала надо заиметь сильные профессиональные компетенции и опыт решения задач в своей зоне отвественности (программирование, тестирование, управление проектом, спонсорство или управление продуктом) — и только после гибкие процессы в полный рост, хоть бы и Scrum. Тогда все взлетит и облегчает всем жизнь. Точка.
О, Катька, привет :-)
Спасибо большое, в отличие от большинства статей на тему «аджайл» очень конкретная и прямая.
Спасибо за отзыв! Есть еще статья от этого же автора: megamozg.ru/company/dataart/blog/13772
Sign up to leave a comment.
Меня беспокоит Agile, и я хочу об этом поговорить