Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Если интересуют инженерные практики, я бы посмотрел в сторону Николая Алименкова — xpinjection.com/, лин и канбан — это Асхат Уразбаев (http://zibsun.livejournal.com/), продуктовое управление — Никита Филиппов (http://www.slideshare.net/Nfilippov).
По поводу затронутой темы очень согласен: просто не надо без оглядки слушаться «тренеров-теоретиков», которые в своей жизни ни сделали ни одного проекта.
По поводу затронутой темы очень согласен: просто не надо без оглядки слушаться «тренеров-теоретиков», которые в своей жизни ни сделали ни одного проекта.
Коле, да, зачёт. С инженерными практиками всё проще их используют практически все. Там всё понятно.
Я бы не сказал, что Асхат и Никита рассказывают что-то больше, чем карго-культ, по край ней мере на конференциях и в статьях.
Я бы не сказал, что Асхат и Никита рассказывают что-то больше, чем карго-культ, по край ней мере на конференциях и в статьях.
Ну про Асхата с Никитой я погорячился, конечно. Я имел в виду их теоретические рассказы. Их практический опыт, конечно, без ценен
Денис, а какие продукты сделал Никита, если вы считаете бесценным его опыт?
Я не в курсе его продуктов. Я говорю про опыт консультирования команд, когда он получал фидбэк по тем практикам, которые принимала команда
Дабы снизить троллинговую составляющую дениса
Денис, в компании Бегун я запустил 6 сервисов (2007-2008) начиная от договоренностей с партнерами, заканчивая «пресс-релизами».
Самый первый продукт который я запустил, был запуск проекта testbox.com на западный рынок 2006 (к сожалению ныне умерщвленный компанией Агава). Гордиться там было не чем но тем не менее вроде как сервис зарабатывал.
Последние годы безусловно я нахожусь в зоне сторонних наблюдателей, но активно участвую в составлении планов выходов продуктов: экономика, стратегия, взаимодействия маркома и тп… последний раз учавствовал в выходе компании ЛингваЛео на внешние рынки… Безусловно,- это не одно и тоже что делать с нуля, но сноровка есть.
Ну и самым главным продуктом своей жизни на данный момент считаю компанию ScrumTrek, которая тоже вроде бы не на ладан дышит. Чем очень горжусь.
Денис, в компании Бегун я запустил 6 сервисов (2007-2008) начиная от договоренностей с партнерами, заканчивая «пресс-релизами».
Самый первый продукт который я запустил, был запуск проекта testbox.com на западный рынок 2006 (к сожалению ныне умерщвленный компанией Агава). Гордиться там было не чем но тем не менее вроде как сервис зарабатывал.
Последние годы безусловно я нахожусь в зоне сторонних наблюдателей, но активно участвую в составлении планов выходов продуктов: экономика, стратегия, взаимодействия маркома и тп… последний раз учавствовал в выходе компании ЛингваЛео на внешние рынки… Безусловно,- это не одно и тоже что делать с нуля, но сноровка есть.
Ну и самым главным продуктом своей жизни на данный момент считаю компанию ScrumTrek, которая тоже вроде бы не на ладан дышит. Чем очень горжусь.
буду рад порадовать тебя выходом нового «продукта» в ближайшие 6 месяцев…
Было бы здорово, чтобы ты написал об этом где-то в профиле, типа этого: scrumtrek.ru/company/team/
Также интересно где-нить прочитать, почему ты сменил формат деятельности с управления продуктами на консалтинг.
Также интересно где-нить прочитать, почему ты сменил формат деятельности с управления продуктами на консалтинг.
Ну я так понимаю не используют всякие мелкие конторки типа тех, которые пишут софт для NASA или Boing. Но там сидят всякие старые пердуны которые никак не осознают преимущества Agile и по старинке пишут километровые спецификации и планируют все на годы. Никакой гибкости и релизы раз в пять лет.
Есть замечательная альтернатива Agile-методикам.
Серьезные интернет-проекты (скажем топ 500 алексы). Покрытие кода тестами (unit, functional, regression); команда QA, превышающая численность разработчиков; вменяемые PM/PA, планы на месяцы вперед.
Это, конечно, только мнение — но agile нет места в этом мире. Ну а стартапы… Тут недалеко топик есть :)
Серьезные интернет-проекты (скажем топ 500 алексы). Покрытие кода тестами (unit, functional, regression); команда QA, превышающая численность разработчиков; вменяемые PM/PA, планы на месяцы вперед.
Это, конечно, только мнение — но agile нет места в этом мире. Ну а стартапы… Тут недалеко топик есть :)
кто вам сказал, что они не используют Agile практик?
Agile на самом деле просто собрал все хорошие практик, которые применялись как раз лучшими в индустрии.
Кстати, Кент Бек (один из авторов Agile манифеста) работает в Facebook'е
Agile на самом деле просто собрал все хорошие практик, которые применялись как раз лучшими в индустрии.
Кстати, Кент Бек (один из авторов Agile манифеста) работает в Facebook'е
Ну тут, честно говоря, уже спор о терминах (я сам дурак, первым начал).
Да, эти практики в большинстве своем — просто формализация здравого смысла.
Нет, «готовые решения» (фиксированные наборы практик, объединенные под одним громким названием) не универсальны.
Continuous integration — прекрасно, pair programming — прекрасно, TDD — прекрасно. Все три вместе — применимы дай бог в 10% случаев.
Пока agile-практики не являются самоцелью, они вполне полезны и здравы
Да, эти практики в большинстве своем — просто формализация здравого смысла.
Нет, «готовые решения» (фиксированные наборы практик, объединенные под одним громким названием) не универсальны.
Continuous integration — прекрасно, pair programming — прекрасно, TDD — прекрасно. Все три вместе — применимы дай бог в 10% случаев.
Пока agile-практики не являются самоцелью, они вполне полезны и здравы
по вашему километровая спецификация для космической станции это излишество?
негибкие пердуны значится?
всякой вещи — свое место. не стоит своей единственной амбразурой оценивать вемь мир.
негибкие пердуны значится?
всякой вещи — свое место. не стоит своей единственной амбразурой оценивать вемь мир.
У каждого подхода есть свои плюсы и минусы. Почитайте, для начала, статью Джоэла Спольски — Пять миров. Она старенькая, но полезная. Так вот, Agile это больше «ширпотреб» и «внутреннее ПО» из статьи. А вот если вы будите разрабатывать систему управления ядерным реактором по методологии Agile, то я бы не хотел жить рядом с АЭС, на которую поставят результат вашего первого спринта, для демонстрации его заказчику.
Но в указанных областях, да, Agile хорош. Я, например, участвую в разработке внутреннего ПО и практикую именно его.
Но в указанных областях, да, Agile хорош. Я, например, участвую в разработке внутреннего ПО и практикую именно его.
Вообще-то в статье Спольски «ширпотрёбом» и «внутренним ПО» названы не методологии разработки, а типы ПО.
И кто сказал, что аджайл не подходит для ядерных реакторов? Распространённый миф, но это полная ерунда.
И кто сказал, что аджайл не подходит для ядерных реакторов? Распространённый миф, но это полная ерунда.
Так как делают ПО для ядерных реакторов? Поделитесь инфой плиз если имеется.
У меня подозрения, что если там и имееются элементы agile, то никто кроме создателей agile manifesto не распознает их.
У меня подозрения, что если там и имееются элементы agile, то никто кроме создателей agile manifesto не распознает их.
Впрочем, если брать суть agile в самом общем понимании, то он будет присутствовать в любой методологии разработки ПО. По той простой причине, что agile — это набор здравых принципов, более или менее присутствующих в любой жизнеспособной методологии.
Проблема в том, что тут же у каждого комментатора свое понимание agile, вот и доказываем друг другу, у кого шашка длиннее.
Проблема в том, что тут же у каждого комментатора свое понимание agile, вот и доказываем друг другу, у кого шашка длиннее.
Вот-вот, и я об этом. В самом аджайле нет ничего такого, что не подошло бы для разработке ядерных реакторов. Так что глупости всё это.
Впрочем, возможно, что аджайл не лучшая методология для ядерных реакторов — например, потому, что их проектировщики заранее асолютно точно знают, что хотят построить, и никаких изменений по ходу разработки точно не будет. Возможно, как раз с реакторами именно так. Не знаю.
P.S. Не знаю, о чём вы — я ни о каких шашках ничего никому не доказывал.
Впрочем, возможно, что аджайл не лучшая методология для ядерных реакторов — например, потому, что их проектировщики заранее асолютно точно знают, что хотят построить, и никаких изменений по ходу разработки точно не будет. Возможно, как раз с реакторами именно так. Не знаю.
P.S. Не знаю, о чём вы — я ни о каких шашках ничего никому не доказывал.
Опасность разных методологий в том, что из них делают «культ карго». А потом удивляются, почему не работает.
Хотя бы ради поржать рекомендую посмотреть презентацию про снежинки
Ваше сравнение производных и рисования говорит, в основном, о том, что у вас был бездарный преподаватель последнего. Рисовать стандартные вещи (аналог «брать производные») можно научить любого. А вот пользоваться этими навыками как инструментами — далеко не так просто! Ну и что с того, что вы умеете брать производные? У вас где-то в реальной жизни была абстрактная задача «взять производную»? Так же и рисование — можно научиться рисовать свечку. Но это не гарантирует удачное применение…
Ну преподавателей бездарных у нас полно, но опять же черчение он объяснял намного лучше, ибо это наука :)
Но в целом я имел в виду именно то что вы написали, можно научить рисовать конкретные предметы, но это не значит, что человек сможет стать художником. А вот если научить брать производные, то любую задачу, где требуется это делать, он решить сможет.
PS: Я то рисовать хорошо научился ещё до школы, а вот многие мои одноклассники не смогли даже к концу 6 класса.
Но в целом я имел в виду именно то что вы написали, можно научить рисовать конкретные предметы, но это не значит, что человек сможет стать художником. А вот если научить брать производные, то любую задачу, где требуется это делать, он решить сможет.
PS: Я то рисовать хорошо научился ещё до школы, а вот многие мои одноклассники не смогли даже к концу 6 класса.
Если хотите выйти за рамки троллинга, то посмотрите большую презентацию Хенрика Книберга на эту тему — blog.crisp.se/2010/09/01/henrikkniberg/1283373060000.
безусловно, это поможет, но результат не гарантирован. Если быть объективным, вообще ни чего не может застраховать от провала, только снизить вероятность)
А препода по матану твоего, часом не Виктором звали? =)
… ведь большинство… agile-евангелистов говорят…: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»
Ни один хороший agile-евангелист или тренер не говорит так. Все подчеркивают, что гибкие методологии на то и названы гибкими: пробуйте, смотрите, что работает, а что нет, меняйте.
Я же говорю про большинство, а не про хороших :) Хороших по пальцам пересчитать. Большую часть из них привёл в статье.
Хотелось бы увидеть примеры этого БОЛЬШИНСТВА. А то как-то в жизни не приходилось встречать таких.
Денис, ты забыл про компанию СкрамТрек)
Где их материалы, которые можно почитать/посмотреть, чтобы понять как и почему работают те или иные практики?
Я нашел только «религиозные» ролики от Асхата и о том как продавать эту религию
Я нашел только «религиозные» ролики от Асхата и о том как продавать эту религию
agilerussia.ru/ — сайт сообщества
www.facebook.com/groups/agilerussia/ — группа на ФБ
кроме того после всех конференций шарятся материалы и легко ищутся по названию конфы и тоже шарятся
и да, Денис, слишком много сарказма в слове «религия» в контексте agile)
умерь свой пыл)
www.facebook.com/groups/agilerussia/ — группа на ФБ
кроме того после всех конференций шарятся материалы и легко ищутся по названию конфы и тоже шарятся
и да, Денис, слишком много сарказма в слове «религия» в контексте agile)
умерь свой пыл)
Ответил статьей habrahabr.ru/post/148276/
В тему: в Питере в следующий вторник мы делаем встречу на тему «Что такое Agile» с одним из лидеров Agile-Питер Таней Васильевой.
Подробности и регистрация.
Подробности и регистрация.
А по-моему очень верно сказано )))
Ведь если он попал в рай, значит он умер!
Имхо, если гибкость — то гибкость во всем. В том числе и в методологиях. Каждый проект уникален и каждая команда уникальна. Всегда надо все допиливать напильником под себя.
Делайте так, как говорит методология, и ваш проект попадёт в рай
Ведь если он попал в рай, значит он умер!
Имхо, если гибкость — то гибкость во всем. В том числе и в методологиях. Каждый проект уникален и каждая команда уникальна. Всегда надо все допиливать напильником под себя.
Эта позиция опасна, ибо позволяет людям делать что угодно и как угодно, не соблюдать вообще никаких правил и называть это гибкостью.
Насколько я понимаю, смысла аджайла — это не гибкость во всём, как многие думают. Аджайл — это гибкость в планировании задач. То есть возможность ДЛЯ КЛИЕНТА менять свои планы после каждо итерации. А вот чтобы обеспечить клиенту такую возможность, разработчики должны постараться: clean code, автоматические тесты, непрерывная интеграция и всё такое.
Насколько я понимаю, смысла аджайла — это не гибкость во всём, как многие думают. Аджайл — это гибкость в планировании задач. То есть возможность ДЛЯ КЛИЕНТА менять свои планы после каждо итерации. А вот чтобы обеспечить клиенту такую возможность, разработчики должны постараться: clean code, автоматические тесты, непрерывная интеграция и всё такое.
Как автор методологии Lean IT и ИТ стратегии беззатратного развития — не могу обойти вниманием этот пост.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Agile: танцы с бубном или наука