Как стать автором
Обновить

Комментарии 59

Если интересуют инженерные практики, я бы посмотрел в сторону Николая Алименкова — xpinjection.com/, лин и канбан — это Асхат Уразбаев (http://zibsun.livejournal.com/), продуктовое управление — Никита Филиппов (http://www.slideshare.net/Nfilippov).

По поводу затронутой темы очень согласен: просто не надо без оглядки слушаться «тренеров-теоретиков», которые в своей жизни ни сделали ни одного проекта.
Коле, да, зачёт. С инженерными практиками всё проще их используют практически все. Там всё понятно.
Я бы не сказал, что Асхат и Никита рассказывают что-то больше, чем карго-культ, по край ней мере на конференциях и в статьях.
Ну про Асхата с Никитой я погорячился, конечно. Я имел в виду их теоретические рассказы. Их практический опыт, конечно, без ценен
Денис, а какие продукты сделал Никита, если вы считаете бесценным его опыт?
Я не в курсе его продуктов. Я говорю про опыт консультирования команд, когда он получал фидбэк по тем практикам, которые принимала команда
Дабы снизить троллинговую составляющую дениса

Денис, в компании Бегун я запустил 6 сервисов (2007-2008) начиная от договоренностей с партнерами, заканчивая «пресс-релизами».

Самый первый продукт который я запустил, был запуск проекта testbox.com на западный рынок 2006 (к сожалению ныне умерщвленный компанией Агава). Гордиться там было не чем но тем не менее вроде как сервис зарабатывал.

Последние годы безусловно я нахожусь в зоне сторонних наблюдателей, но активно участвую в составлении планов выходов продуктов: экономика, стратегия, взаимодействия маркома и тп… последний раз учавствовал в выходе компании ЛингваЛео на внешние рынки… Безусловно,- это не одно и тоже что делать с нуля, но сноровка есть.

Ну и самым главным продуктом своей жизни на данный момент считаю компанию ScrumTrek, которая тоже вроде бы не на ладан дышит. Чем очень горжусь.
буду рад порадовать тебя выходом нового «продукта» в ближайшие 6 месяцев…
Было бы здорово, чтобы ты написал об этом где-то в профиле, типа этого: scrumtrek.ru/company/team/

Также интересно где-нить прочитать, почему ты сменил формат деятельности с управления продуктами на консалтинг.
НЛО прилетело и опубликовало эту надпись здесь
Ну я так понимаю не используют всякие мелкие конторки типа тех, которые пишут софт для NASA или Boing. Но там сидят всякие старые пердуны которые никак не осознают преимущества Agile и по старинке пишут километровые спецификации и планируют все на годы. Никакой гибкости и релизы раз в пять лет.
НЛО прилетело и опубликовало эту надпись здесь
Есть замечательная альтернатива Agile-методикам.
Серьезные интернет-проекты (скажем топ 500 алексы). Покрытие кода тестами (unit, functional, regression); команда QA, превышающая численность разработчиков; вменяемые PM/PA, планы на месяцы вперед.
Это, конечно, только мнение — но agile нет места в этом мире. Ну а стартапы… Тут недалеко топик есть :)
кто вам сказал, что они не используют Agile практик?
Agile на самом деле просто собрал все хорошие практик, которые применялись как раз лучшими в индустрии.
Кстати, Кент Бек (один из авторов Agile манифеста) работает в Facebook'е
Ну тут, честно говоря, уже спор о терминах (я сам дурак, первым начал).
Да, эти практики в большинстве своем — просто формализация здравого смысла.
Нет, «готовые решения» (фиксированные наборы практик, объединенные под одним громким названием) не универсальны.
Continuous integration — прекрасно, pair programming — прекрасно, TDD — прекрасно. Все три вместе — применимы дай бог в 10% случаев.
Пока agile-практики не являются самоцелью, они вполне полезны и здравы
Подпишусь под всем выше сказанным)
по вашему километровая спецификация для космической станции это излишество?
негибкие пердуны значится?

всякой вещи — свое место. не стоит своей единственной амбразурой оценивать вемь мир.

Тут была недавно статья про авионику (поищите если интересно). У них хоть и горы спецификаций, но вполне agile — делают они все небольшими итерациями.
У каждого подхода есть свои плюсы и минусы. Почитайте, для начала, статью Джоэла Спольски — Пять миров. Она старенькая, но полезная. Так вот, Agile это больше «ширпотреб» и «внутреннее ПО» из статьи. А вот если вы будите разрабатывать систему управления ядерным реактором по методологии Agile, то я бы не хотел жить рядом с АЭС, на которую поставят результат вашего первого спринта, для демонстрации его заказчику.
Но в указанных областях, да, Agile хорош. Я, например, участвую в разработке внутреннего ПО и практикую именно его.
НЛО прилетело и опубликовало эту надпись здесь
Вообще-то в статье Спольски «ширпотрёбом» и «внутренним ПО» названы не методологии разработки, а типы ПО.

И кто сказал, что аджайл не подходит для ядерных реакторов? Распространённый миф, но это полная ерунда.
Так как делают ПО для ядерных реакторов? Поделитесь инфой плиз если имеется.

У меня подозрения, что если там и имееются элементы agile, то никто кроме создателей agile manifesto не распознает их.

Впрочем, если брать суть agile в самом общем понимании, то он будет присутствовать в любой методологии разработки ПО. По той простой причине, что agile — это набор здравых принципов, более или менее присутствующих в любой жизнеспособной методологии.

Проблема в том, что тут же у каждого комментатора свое понимание agile, вот и доказываем друг другу, у кого шашка длиннее.
Вот-вот, и я об этом. В самом аджайле нет ничего такого, что не подошло бы для разработке ядерных реакторов. Так что глупости всё это.

Впрочем, возможно, что аджайл не лучшая методология для ядерных реакторов — например, потому, что их проектировщики заранее асолютно точно знают, что хотят построить, и никаких изменений по ходу разработки точно не будет. Возможно, как раз с реакторами именно так. Не знаю.

P.S. Не знаю, о чём вы — я ни о каких шашках ничего никому не доказывал.
Опасность разных методологий в том, что из них делают «культ карго». А потом удивляются, почему не работает.
Британские ученые давно доказали, что карго-культ вреден для здоровья. Вы таки правы. Тупое и слепое следование видимым проявлениям практик прямая дорога в адъ
НЛО прилетело и опубликовало эту надпись здесь
есть множество других способов. Например, большая выборка разных команд и однотипных проектов.
Но и в рамках одного проекта можно почерпнуть весьма много информации для построения теорий, естественно с учётом опыта предыдущих экспериментов
статистика? не, не слышал.
Хотя бы ради поржать рекомендую посмотреть презентацию про снежинки
Презентация отлична, потому и стоит первой в моём списке :)
Ваше сравнение производных и рисования говорит, в основном, о том, что у вас был бездарный преподаватель последнего. Рисовать стандартные вещи (аналог «брать производные») можно научить любого. А вот пользоваться этими навыками как инструментами — далеко не так просто! Ну и что с того, что вы умеете брать производные? У вас где-то в реальной жизни была абстрактная задача «взять производную»? Так же и рисование — можно научиться рисовать свечку. Но это не гарантирует удачное применение…
Ну преподавателей бездарных у нас полно, но опять же черчение он объяснял намного лучше, ибо это наука :)
Но в целом я имел в виду именно то что вы написали, можно научить рисовать конкретные предметы, но это не значит, что человек сможет стать художником. А вот если научить брать производные, то любую задачу, где требуется это делать, он решить сможет.
PS: Я то рисовать хорошо научился ещё до школы, а вот многие мои одноклассники не смогли даже к концу 6 класса.
Если научить человека брать производные, он сможет решать задачи-одноходовки, в которых поставлен вопрос «вдять производную». Больше ничего гарантировать нельзя.

P.S. при чем тут как вы умеете рисовать.
НЛО прилетело и опубликовало эту надпись здесь
Если хотите выйти за рамки троллинга, то посмотрите большую презентацию Хенрика Книберга на эту тему — blog.crisp.se/2010/09/01/henrikkniberg/1283373060000.
НЛО прилетело и опубликовало эту надпись здесь
безусловно, это поможет, но результат не гарантирован. Если быть объективным, вообще ни чего не может застраховать от провала, только снизить вероятность)
А препода по матану твоего, часом не Виктором звали? =)
На самом деле, я уже точно не помню кто именно из преподов сказал эту фразу, но вроде это бы Усольцев Лев Павлович
… ведь большинство… agile-евангелистов говорят…: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

Ни один хороший agile-евангелист или тренер не говорит так. Все подчеркивают, что гибкие методологии на то и названы гибкими: пробуйте, смотрите, что работает, а что нет, меняйте.
Я же говорю про большинство, а не про хороших :) Хороших по пальцам пересчитать. Большую часть из них привёл в статье.
Хотелось бы увидеть примеры этого БОЛЬШИНСТВА. А то как-то в жизни не приходилось встречать таких.
Вот уж чего делать не буду, так это давать ссылки на то, что читать не стоит.
А вообще вам повезло, либо вы оптимист ;)
Денис, ты забыл про компанию СкрамТрек)
Где их материалы, которые можно почитать/посмотреть, чтобы понять как и почему работают те или иные практики?
Я нашел только «религиозные» ролики от Асхата и о том как продавать эту религию
agilerussia.ru/ — сайт сообщества
www.facebook.com/groups/agilerussia/ — группа на ФБ
кроме того после всех конференций шарятся материалы и легко ищутся по названию конфы и тоже шарятся
и да, Денис, слишком много сарказма в слове «религия» в контексте agile)
умерь свой пыл)
Заметь, не я придумал слово «евангелист» ;)
Про то что я читаю эти сайты ты и так знаешь
=) можно пользоваться советским термином «специалист по просвещению»
ну а чем тебе не материалы от скрамтрека?
Да, там материалы есть, но не от Скрамтрека. Они, видимо, только на тренингах шарят свои глубокие теоретические познания. И их можно понять
Я, кстати, тоже от скрамтрека) Материалы с тренингов уходят участникам тренинга, а вот все что на agilerussia это мы шарим, процентов 90-95 где-то. Плюс масса открытых вебинаров и мероприятий есть от нас, тот же AgileKitchen или SkillTrek делал вебинары.
Вот, кстати, и трабл, что есть только избранные шаманы (хорошие agile-гуру), которые могут сказать, что у вас в проекте плохо и что нужно делать. А как простым смертным разобраться в этом? Только наступать на грабли снова и снова. Благо всё ж таки материалы стали появляться, см. выше.
Простым смертным надо исследовать опыт других простых смертных и гуру и применять его для своего контекста. Это ничем не отличается от любой другой области знаний.
В тему: в Питере в следующий вторник мы делаем встречу на тему «Что такое Agile» с одним из лидеров Agile-Питер Таней Васильевой.

Подробности и регистрация.
А по-моему очень верно сказано )))

Делайте так, как говорит методология, и ваш проект попадёт в рай

Ведь если он попал в рай, значит он умер!

Имхо, если гибкость — то гибкость во всем. В том числе и в методологиях. Каждый проект уникален и каждая команда уникальна. Всегда надо все допиливать напильником под себя.
Эта позиция опасна, ибо позволяет людям делать что угодно и как угодно, не соблюдать вообще никаких правил и называть это гибкостью.

Насколько я понимаю, смысла аджайла — это не гибкость во всём, как многие думают. Аджайл — это гибкость в планировании задач. То есть возможность ДЛЯ КЛИЕНТА менять свои планы после каждо итерации. А вот чтобы обеспечить клиенту такую возможность, разработчики должны постараться: clean code, автоматические тесты, непрерывная интеграция и всё такое.
Как автор методологии Lean IT и ИТ стратегии беззатратного развития — не могу обойти вниманием этот пост.
Так в чем ваше внимание заключается?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации