Pull to refresh

Comments 59

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P.S. при чем тут как вы умеете рисовать.
UFO just landed and posted this here
UFO just landed and posted this here
безусловно, это поможет, но результат не гарантирован. Если быть объективным, вообще ни чего не может застраховать от провала, только снизить вероятность)
А препода по матану твоего, часом не Виктором звали? =)
На самом деле, я уже точно не помню кто именно из преподов сказал эту фразу, но вроде это бы Усольцев Лев Павлович
… ведь большинство… agile-евангелистов говорят…: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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

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

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

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

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

Articles