×Закрыть

Увлечение Agile может быть вредно для вашего стартапа

Зачем нужны Agile методологии? Они позволяют эффективнее организовать процесс разработки, это несомненно. Украинские разработчики поднаторели в Agile, что и неудивительно — аутсорсинг-проекты по определению озабочены эффективностью и стоимостью разработки.

В стартапе все не так. Главный вопрос для выживания — что мы делаем и для кого, а не как. Всякие же test-driven development, pivotal tracker, backlog, high level design document и прочие умные штуки фокусируются именно на как. Разработчики любят точность и однозначность и легко попадают под влияние всех этих магических ритуалов, забывая главное — это всего лишь средства.

Да, наверное, agile не самый плохой подход к разработке и наверное он может помочь — как и быстрый интернет и удобный стул. Но не принципиально.

Энергию, которая идет на «построение процессов», оформление user stories и написание test suite на selenium можно потратить на общение с пользователями, сбор аналитики и a/b тесты. Agile нам пригодится, когда будет продукт, будет понятно как его развивать и останется только отмасштабировать разработку.

Что думаете?

LinkedIn

Лучшие комментарии пропустить

Действительно, зачем нужны методологии и всякие юнит тесты когда можно слепить кривой прототип и потом месяцами (годами?) обкатывать его на пользователях? Это мне напоминает один сайт одного сообщества :)

Увлечение чем угодно может привести к чему угодно.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Разработка без формализации в той или иной форме быстро превращается в соковыжималку с овертаймами: всё надо на вчера, никто ничего не успевает и не понимает. В результате люди болеют, перегорают, увольняются.

Вывод: разработка без процесса разработки подходит только для прототипирования в течении очень ограниченного времени

Цей набір термінів чомусь мені нагадує цитату з Лєпри у темі про MLM
---
Приехал в родной город и встретил друга детства, который также пытался мне впарить прокладки! Мужчине! С ионами серебра!
Ну, я ему рассказал про веб 2.0, стартапы, инвестиции, бизнес—инкубаторы, элеватор—питч, вконтакте—одноклассники—твиттер—фейсбук, опционы, монетизацию, дата—центры, прототипы, анализ аудитории, сегментацию, юзабилити, KPI...

Ну а чо, мы честно поделили время — час он мне впаривал, час я ему.

188 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Зачастую АДЕПТы Аджайла напоминают строителей дороги в тамбовской области из юморески Михаила Задорнова:

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

Вот так и аджалисты строят спринты «от сегодня до стога сена», подчиняясь сиюминутным требованиям пользователей. Вместо того, чтобы выбрать более нормальный ориентир в виде недвижимого столба. Потому и получается говнокод+потраченное бабло...

Наймите нормального БА, пусть просчитает выгодность проекта, накидает бизнес-план, диверсифицирует задачи. Дайте перепроверить этот план другому БА, его злостному врагу. И после этого стартапьте, а не жалуйтесь на технологии, кривые руки девов и тупость пользователей. Лучше позже на пару месяцев начать и сделать что-то нормальное или вообще не начать увидев гиблость стартапа на ранних этапах, чем просрать кучу денег из-за того, что пары миллионов серых клеток не хватило в самом начале. Не хватает своих мозгов — наймите.

Если затрагивается эта проблема и не раз, значит инструмент далеко не идеален. Был свидетелем множества (до умопомрачения) Agile семинаров в одной немалой компании. Витоге — организационно ничего не изменилось, даже хуже стало — субботы и воскресенье рабочие пошли.
Теперь как раньше, меньше Agile-психопатии но больше работы...

Крутая тема когда initial project setup бьют на таски, раздают бумажки, потом все толкаются в коде и мержат каждый коммит, который полностью переписывает код

Я всегда ждал, еще чуть-чуть, ореол святости спадет с agile и в мире воцарится справедливость без траты времени на всякую чепуху. Большинство аджайлистов вместо agile values (open communication, good ways of changing requirements) просто цепляются за agile ритуалы и компостируют всем мозги. Особенно когда ради какого-то бессмысленного митинга сбивают с мысли, как будто он не может подождать 10 мин.

Фанатов agile переплевывают только фанаты TDD

Еще несколько интересных мнений насчет Agile Scrum: hashcode.ru/...м-о-agile-scrum

И ещё одна мелочь: все помнят поговорку про бизнес курицы и свиньи?

Вот и здесь так же — методология производства не просто «может убить», она будет гарантированно убивать. Свиней.

Agile — достаточен чтобы его ПОПРОБОВАТЬ. Любая методология может как создать пользу, так и убить. Безвредно — только бесполезное!

Любую систему нужно применять с головой. Как только Вы доверитесь любой системе на 100%, она убьёт. В этом суть систем: система не имеет цели, и стремится пойти наименьшим сопротивлением. Цели ставят люди. Изменения вносят люди. И Agile — всего лишь декларация. Методика — каждый раз РАЗНАЯ!

Аджайл дает возможность менеджеру прикинуть, на каком этапе будет проект к концу спринта, и высказать предположения заказчику. Если стартап не понаодалживаю денег у всех-кого-можно, то ему это не нужно. По-моему, стартап может взять из аджайла отдельные *принципы*, такие как «код важнее документации» или «люди важнее процессов». Многие другие инструменты можно смело игнорировать — они не нужны в небольшой команде с постоянно меняющимися требованиями.

Когда вы пишете код, участвуете в проекте, вы всегда пользуетесь какой-то методикой. Включая — «как хочу, так и пишу», т.е. авторская. Аджайл, тест-драйвинг и т.д. нужно хорошо понять, во-первых. Во-вторых он сильно связан с определенными навыками. Те люди, которые против гибких подходов, просто не владеют определенными навыками работы с кодом. Без навыков теория мертва и даже непонятно, как ей следовать. Люди и не верят, что это работает.

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

Ну, а так, да, аджайл может быть вреден. Можно и кефиром отравиться. Всё зависит от команды. Сами по себе попытки следовать методике еще не говорят о том, кто ей следует, насколько понимает и какие у него навыки. Если человек научился только писать код, а читать не умеет, не видит, ужас как боится рефакторить, то ему кажется проще сначала всё распланировать, чтобы потом нигде не ошибиться. Раз интуиция ему такое говорит, то так и будет.

неистово плюсую :)

Вот она наконец родилась мысль! :) Но в начале отвлечённая аналогия:
Те кто разрабатывал электронику, знают, что «паразитные» параметры компонентов инрают не меньшую, а иногда и большую роль в работе схемы, чем номинальные параметры. И даже круче: Если проигнорировать при разработке паразитные параметры — схема работать не будет.
Все книги-тренинги-туториалы по Agile/SCRUM и прочих XP, которые мне попадались на глаза, написаны в стиле рекламы, чтобы не сказать проповеди. Никто не упоминает о побочных эффектах, и не описывает сценарии и случаи провала. Откройте сердце Эджайлу!!!
И здесь история повторяется, ведь многие вещи тоже в своё время пропагандировались как «рецепты всеобщего блага», пока не выхаркнулись с кровью в фейлах реальных проектов — в частности OOP/OOD, UML, и, конечно же, наши любимые Patterns. :)

Вывод: Для того чтобы успешно применить некую методологию разработки в стартапе, в команде должен быть человек, съевший на ней собаку, то есть знающий, к какому конкретно эпик фейлу это может привести в данной конкретной ситуации, и по какому сценарию.

А расскажи, пожалуйста, о выхаркнувшемся кровью Аджайле?
Я в своей практике таких не встречал, но люди меня постоянно спрашивают.

Хоть будет что рассказать.

Вспоминается выражение, что все победы люди приписывают себе, а все провалы сваливают на других )) Думаю, к Аджайлу это тоже вполне применимо.

Была у меня на глазах история, как англики, обложившиеся книгами с проповедями аджайлов-паттернов-оодов и пр. запороли суб-проект. Сидели месяцами трындели, нагородили архитектуру из воздушных замков, затянули сроки, получилось тормознутая никуда не годная имплементация, а потом разбежались все, как крысы с корабля, и за ними уже другие люди всё переделывали.
Отсюда вывод: Специалист по методологии не тот, кто проповедей начитался, а тот, кто на ней собаку съел, тот, кто может ответить на вопрос, в каких ситуациях методика неприменима, и по каким сценариям фейлится.

Agile и есть идея!

Но чтобы его реализовать — нужно уметь строить сами отношения. Без этих качеств — всё равно что выходить на ринг, изучив бокс по книгам и бизнес-тренингам.

Реальность всегда сложна. И не надо бояться сложности (кто боится — купите Лего). Бойтесь простоты реализации. Простой должна быть идея, простыми должны быть связи. Но реализация — всегда сложна, и ювелирна.

Эджайл — это рецептурная книга подавления распостранённых плохих практик в больших медленных проектах.
Вспомните с чего начинают авторы этих методик — проекты чаще всего фейлятся потому что: плохая коммуникация, итд, итп.
Для контраста, какая плохая коммуникация может быть в стартапе, где пятеро человек живут-кодят-едят-пьют-спят в маленькой комнатушке круглосутгочно? В такой ситуации «сетапить процессы» — явная шыза...

Что-то эта тема не дает мне покая.

Вот родилась развернутая мысль: www.facebook.com/...346889028664607

Аджайл хорошо работает для product management — один продукт в компании, все стабильно и понятно, только выпускаем для него апдейты. Но это когда все уже `on track`.
Что касается стартапов, бороться с неопределенностью в начале проекта аджайл помогает мало. Тут можно посмотреть в сторону строгих унифицированных процессов типа RUP.
Потом, если у вас fixed-price проект — аджайл опять-таки неэффективен. При time&material аджайл более интересен.

Просто молиться на аджайл, скрам (как это у нас любят) — бессмысленно.

вместо того, чтобы бороться с неопределенностью, при аджайле стараются получить от нее удовольствие. скоуп — неопределен, баджет — неопределен, тайм — и тот неопределен! кодинг фор фан, стэндап-митинг каждое утро и доска со стикерами — наше все.

Напомнило: Настоящий профессионал — этот тот, кто умеет избегать мелких проблем на пути к Грандиозному Провалу. Гыыы.

Заставь дурака [вставить божество] молиться, они и [вставить ресрус] разобьёт.

трезвое и точное высказывание. жаль, что такая позиция встречается очень редко. разработчики тоже вовсю подвергаются зашоренности.

да потому что взгляд разработчиков и взгляд бизнеса в большинстве случаев понятия перпендикулярные.

у меня взгляд не бизнеса. я скромный дизайнер.

имеет смысл только в случае, если вы уверены, что:
— никто не перекупит сотрудников до фазы «масштабирования»;
— проект относительно небольшой;
— не прийдется подключать внешнее финансирование;

— сотрудники не будут переключены на другие проекты.

если хотя-бы один из рисков присутствует — лучше вводить процесс со всеми плюшками и ему следовать.

Нифига. Если дать рискменеджменту право вето, то найдутся способы создать Agile-процесс. Но он будет не один, а ещё параллельно риск-менежмент. К примеру тестеры могут пойти по канбану, бета-тест — по аджайлу, а ключевая разработка технологии — вообще по ТРИЗу.

Agile полезен, если в команде РАЗНЫЕ люди, либо команда включается в вертикальную интеграцию. Иначе рецепт команды, как коктейль у Джеймс-Бонда: смешать, но не взбалтывать.

Увлечение Agile вредно в любом случае. Потому что Agile на половину г-но, а на половину очевидные вещи, которые непонятно каким делом к Agile причислены, если они свободно могут существовали и существовали без него. В добавок для многих это как религия — не важно что, главное следовать свято правилам, и радоваться что «у нас Agile!». Но я наверно зря это пишу, тут же полно ПМов, с галстуками и пиджачками, все равно что прийти атеисту в церьков, и там высказывать свое мнение.

Какие правила есть в Agile, которым главное слепо следовать? Вы читали Agile-манифест?

Какие правила есть в Agile, которым главное слепо следовать?

Главное для кого? Я не говорил что в Agile есть правила которым нужно слепо следовать. Я сказал что люди склонны превращать это в религию, слепо следовать правилам, методам, идеям и так далее как заповедям, не думаю о их смысле и насколько они пригодны в той или иной ситуации. И верить, в то что у них все будет чудесно, потому что они следуют этим правилам (как написано в «умных» книжках).

В Agile-манифесте только общие положения, идеи. Вы, нверное, имеете ввиду Scrum. И там да, проблема в том, что нужно думать головой, а не следовать советам «тренеров».

ага, у меня этот стенд-ап митинг ассоциируется с тем как ревностные католики перед обедом помолятся вместе, и затем приступают только к трапезе...

Не всем очевидные эти вещи. И да, Agile — уже религия. Но.. галстучек и пиджачок в неё точно не входят. Нужны знания теории и опыт, их ничем нельзя заменить.

If you are a manager practicing Agile in any context. You’re a bad manager/team lead/leader/whatever you are calling yourself... Agile doesn’t make your resources work faster, more smoothly or any of that. Building a comprehensive team does that; not some methodology. You can’t treat your employees like it’s some factory line.

+1 000 0000 000 000 ... 000

Макс, по-моему в стартапе главное — начать зарабатывать деньги путем поставки конечным пользователям того, за что они готовы заплатить.

Мне кажется, Аджайл этому помогает. Например, Scrum простой процесс, его легко внедрить. И пусть лучше в стартапе будет разработка по Scrum, чем по «пиши код, бл#$ь»! Хоть какая- предсказуемость и управляемость.

ну да. а контент сам по себе материализуется и поставится... посредством нанотехнологий, наверное

Александра, у нас с материализацией и поставками все в порядке ))
А у вас?

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

Прошу заметить, что здесь говорилось о специфических проектах — стартапах.

Если вы хотите привести аргументы в пользу того, что при разработке стартапов процесс разработки гораздо важнее результата — рад буду почитать.

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

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

В стартапах процес розробки коду вторичний. В кращому випадку.

А що є первинним? Генерити ідеї, бачити реалізацію, та постійно змінювати ідеї і реализації?

Startup is a temporary organization designed to search for a repeatable and scalable business model.

steveblank.com/...rst-principles

Відповідно найважливішими є дії які направлені на формулювання та підтвердження або спростування гіпотез про повторювану та масштабовану бізнес-модель.

Для більшості ідей відомо, що код для них можна написати. Тому діяльність по написанню коду в стартапах необхідна лише в тій мірі, в якій вона допомагає формулювати, спростовувати або підтверджувати гіпотези про бізнес-модель.

Ну или хотя бы причем здесь контент?

Надеюсь, вы не считаете, что предсказуемость может быть обеспечена только по Scrum ))) Есть и другие методологии, даже более эффективные на предмет предсказуемости.

Например?
П.С. Считаю. Если подскажете что-то более для нас приемлимое, будем рады пересесть.

даже «старый» RUP в этом плане интереснее, потому что вначале определено, что должно быть в итоге. в скраме пытаются угодить всем, изобрести абсолютно гибкий звездолет, в итоге — получается мопед, а клиенту нужен был автомобиль. главное — ездит...

Спасибо.

RUP нам не очень подойдет, потому что у нас (как и в любом другом стартапе) вначале не может быть определено, что должно получиться в итоге. Потому что (как и в большинстве проектов) клиенту неизвестно, что ему на самом деле нужно.

В стартапе главное — не быть чистым стартапом. А быть (хотя бы в доле) копией чего-то. Наследовать что-то. В том числе идеи клиента.

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

Главный вопросы в любой разработке не что и как. А почему и зачем. Описания Agile методик очень часто затрагивают вопрос почему именно так, а не иначе.

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

Якщо немає аналога user stories, то ніхто не буде знати, що вони роблять, нафіга вони це роблять і чи воно взагалі готове. У мене зараз замовник — бурлить ідеями як мала дитина, хоче комерційний запуск своєї мегаєрунди за кілька тижнів і навіть є якийсь код, котрий нібито проекту стосується. При цьому ні я, ні він (!) не знаємо, наскільки те, що написано, відповідає тому, що треба зробити, бо до мого приходу все робилось усно — часу ні в кого не було.

В результаті, цей бардак припиняється й ми сідаємо чемно писати юзер-сторіз, чи то пак специфікацію, чи складати беклог, чи називайте це як бажаєте. Тому що здавати треба проект, а не якесь хрін знає що.

Якщо ж немає тестів, то продукт може не «вистрелити», а вибухнути й покалічити всіх, і то в найменш підхожий для цього момент. І якщо цей вибух бачили інвестори, наприклад, то стартап може легко перетворитись на стопдаун. Або на хабрахабрі якась людина, котрої ви й імені не знаєте, напише, як хакнути ваш мегапортал і винести звідти всі персональні дані клієнтів, останні при цьому дуже втішаться.

На хабрі особливо цікаво читати коменти до таких анонсів :) Третина функціоналу, до речі, який є _основним_ для розвитку сервісу, не працює і засновники те і роблять, що обіцяють все «пофіксити» (в декількож навіть реєстрація користувачів не працювала). Питання: про що вони думали коли працювали над тим стартапом? А коли приймали рішення про публічну рекламу?

Всі любрять обговорювати популярні книги та статті, але мало хто памятає, що в ті ж «47 signals» постійно повторюють «випускайте менше, але якісно», «почекайте трохи і допрацюйте те що не працює» і т.д.

Хоча для мене, як девелопера, це все означає тільки одне: в наступні 5-10 років я зможу і добре поїсти, і добре відпочити десь на Арубі :)

але мало хто памятає, що в ті ж «47 signals»
мало хто помьятае що их 37 ;)

підловили :) треба десь собі записати скільки тих сигналів і скільки «чашок кави»

Любые рекоммендации (даже от таких признаных товарищей как 37) полезны лишь отчасти, ибо они даются без привязки к вашей конкретной ситуации.

Иногда имеет смысл «выпускать меньше, но качественно», иногда выпуск меньше чем что-то равносильно выпуску «ничего»...

На те вони і рекомендації :)

Иногда имеет смысл “выпускать меньше, но качественно”, иногда выпуск меньше чем что-то равносильно выпуску “ничего”

Думаю, і так зрозуміло, що, наприклад, Picassa без можливості аплоада фоток, АЛЕ з красивим інтерфейсом додавання тегів — це повний провал концепції. А от навпаки — це 99% готового конкурентноспроможного продукту. Як тут вже десь було правильно сказано, потрібно знати на чому ви збираєтесь заробляти гроші і “шліфувати” це до блиску. Поправте, якщо я неправий.

це 99% готового конкурентноспроможного продукту

Ключевое слово конкурентоспособного!
В большинстве случаев мало иметь просто рабочий продукт — нужно иметь что-то лучше чем у других.
Условно говоря, если у и меня и у Пикасы отличная и примерно равная фича по заливке фоток, но у них есть возможность ставить тэги, а у меня нет — пользоваться будут ими.
Иногда это «лучше» реализуется не в наличии фичей, а в их отсутствии ака 37, но зато их продукты проще.
Часто (даже чаще) дело вообще не в фичах, а в продажах, маркетинге, поддержке и т.д.

Общая мысль — ИМХО важен не сам факт наличия рабочего продукта, а такого предложения, в пользу которого будет сделан выбор потребителя...

Історія по темі «конкурентноздатного продукту». Перша версія сервісу над яким я зараз працюю скаладалась з 5 веб-форм (включно з login :) ), невеликого бек-енду і невеличкої БД. Єдиною перевагою перед функціоналом з SAP, альтернативою якого ми і виступаємо (не SAP, а функціоналу), була швидкість роботи. На цій «фічі» все і жило довгий час, а вже потім добавили всякі «рюшечки». І клієнти просто обожнювали ці «5 сторінок»! бо не треба було чекати по пів хвилини після кожного кліку.

Як правильно було сказано

дело вообще не в фичах, а в продажах, маркетинге

:)

Заказчик тут и ни причём. Он — предприниматель, они все такие!!! Этим людям нужен переводчик «с русского — на русский». Это ни разу не забота программиста — разбирайтесь с тем человеком, который ПРОДАЛ заказчику проект. Именно он должен знать, что он продал, чего ему надобно. И продавец обязан знать чего можете вы (если не знает — пинок под зад).

Поверьте, продавец с лёгкостью поймёт заказчика, а заказчик — продавца. И сумеет расказать, сколько стоит каждая из его хотелок, и чего оно будет в результате, и уже сам расскажет user-stories предыдущих заказчиков.

Если у Вас поднят ISO9001, обратитесь к отвественному за соблюдение, объясните что нарушена граница отвественности, попросите переназначить и обозначить зону отвественности за продажу продукта.

Якщо немає аналога user stories, то ніхто не буде знати, що вони роблять, нафіга вони це роблять і чи воно взагалі готове.

Ну да, ведь до определения понятия «user story» никто не писал ПО.

Прочитал эти 4 параграфа. При чем здесь вообще Agile? И причем стартапы? :) Если читали классиков, то «что» и «как» не относятся к методологиям разработки и управления проектами. Заказчиков надо слушать. Если это собственный стартап — слушать себя. Что делать — это сама идея, абстрактный продукт. Как делать — это форма, в которую в итоге облекут эту идею и в итоге конечный продукт. Agile, как и прочие методологии разработки, это расписание взаимодействия проектной команды, заказчика, требований и денег (и т.д.), и никак не относится конкретно к «стартапам» :). Если странное слово Agile мешает вам работать, забудьте про него. Тренируйтесь на кошках, а собственные начинания доверяйте методикам, которые уже проверили самостоятельно.

+1.
Успешность проекта с точки зрения бизнеса и его техническая оснащенность (назовем это так) в общем случае ортогональны, поэтому никогда не стоит позволять себе увлекаться вторым в ущерб первому.

Если человек не умеет плавать, то плаванье определённо может ему повредить.

тю, а причем тут методология разабоки ПО к состоятельности бизнес-идеи?
если твоя бизнес идея — это очередная-никому-не-нужная-социально-сетевая-хрень-с-геолоацией
то никакой agile не поможет :)
и, just FYI,самые удачные с точки зрения бизнеса старатапы вообще мало имеют отношение к IT

страрбакс, например :)

Увлечение чем угодно может привести к чему угодно.

Все, кто умер, дышали воздухом и пили воду...

100%. Agile и прочие шаблоны — это для тех, кто любит имитировать бурную деятельность. В стартапах такая схема не работает.

Сколько стартапов вы сделали чтобы так уверенно утверждать это?

1. Важно не количество, важно качество.

Вы сделали качественных 0 стартапов?

Я бы спросил, сколько проектов вы завалили?

Где вы в Agile хоть один шаблон увидели? Почитайте блог по ссылочке внизу в комментах, что ли.

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

В точку! Недавно анализировал, что я делал не так, работая в стартапе. Пришел к тому же выводу. Слишком много энергии тратил на правильность процессов. Процессы как бы важны, но не они цель стартапа. :)

и какое отношение это имеет к эджайлу? Я там ниже в каментах специально в несколько строчек процитировал эджайл манифест...

Разработка без формализации в той или иной форме быстро превращается в соковыжималку с овертаймами: всё надо на вчера, никто ничего не успевает и не понимает. В результате люди болеют, перегорают, увольняются.

Вывод: разработка без процесса разработки подходит только для прототипирования в течении очень ограниченного времени

Повністю згідний, тут швидше питання «фанатичності». Той же канбан можна організувати на простій стіні з стікерами. Не так красиво і не експортується в PDF/XLS? Ну і фіг з ним! Зробив фото на айДро%илку і відправив кому потрібно.

На рахунок тестів — це окрема історія, але від себе добавлю, що автоматизовані тести (коли їх не тисячі) — це те що збереже команді просто неймовірно багато часу і стільки ж клієнтів.

про тесты в точку !
майнейню маленький проект, в своё время там из команды выжали branch covarage > 70%
так фикс багов, рефакторинг и новые фичи не просто, а ппц как просто добавлять !

А разве в аджайле нет формализации? На входе юз-кейсы, на выходе тесты. Очень даже ничего документация.

Вот помню в водопаде участвовал, так заставили всех рисовать схемы и документы. Один документ был о том, как машины подключать и что у нас «трехуровневое приложение». И ни одного (!!!!!!!) документа, который хоть отдаленно напоминал бы требования в виде юз-кейсов. Размытые цели, размытые видения, куча документации, которая подошла бы для любого проекта бизнес-приложения. Но ничего такого, что бы объясняло, чем наше приложение должно отличаться от любого другого.

Мой опыт говорит о противоположном — практически все «процессы» привели к краху. Проджект-менеджерам там нужны только документации и «честные» слова о сроках. И сроки затягиваются в несколько раз. Не работает водопад и точка. Люди работают, как тянитолкаи. Сначала всё рисуют. Потом через день кодирования выясняют, что в реальности что-то не так, сядятся перерисовывать. Потом идут утверждать. Снова кодируют, снова через день что-то не так. Снова перерисовывают. Такое ощущение, что наняли сантехников, которые ужас как боятся писать код, им нужно всё время рисовать трубы

Аджайл — это тоже процесс. Вот в чем дело — то.

С другой стороны, лучше водопад, чем совсем ничего.

Я под процессами подразумевал водопад. Т.к. противники аджайла часто его называют отсуствием процесса. Т.е. планирования, отвественности и т.д.

Прошу прощения, если я воспринял слова «без формализации» как указание на аджайл.

Следующая колонка на ДОУ — возможен ли Agile без бюджета и ресурсов :)

Следующая колонка будет называться «ШОК! Agile не предохраняет от ВИЧ! Полный провал популярной концепции!».

Сначала наслушаются шарлатанов, которые под видом Agile втюхивают эликсир от всех болезней, а потом жалуются, что Agile не лечит геморрой и отит.

Где жэ выход? Как это прекратить?

Засилье шарлатанов, а главное — доверие сообщества к ним.

Этот вопрос, по-моему, гораздо шире Agile и вообще IT.

Оно-то да, но идти ли к гадалке или считать гербалайф полезным и покупать его — каждый человек волен сам, а вот в профессиональной деятельности это не так.

У меня есть ощущение, что шарлатаны появляются там, где есть «тренинги» и особенно — «сертификаты» — сертификат получил, всё, мозгами думать не надо. Если чуть менее, чем всех тренеров отправить на стройки народного хозяйства, или хотя бы заставить страдать за свои убеждения, как первых христиан, то ситуация значительно оздоровится. Те, кому без Аджайла действительно никак — те продолжат работу и безо всяких гуру, остальные — тоже займутся чем-то полезным.

Шарлатани не живуть довго там, де є непереборне бажання знати й розуміти, чому, що, і як, а не отримати чарівну кнопку/еліксир/методологію «зробити все за..бісь, негайно та недорого».

А что в этой области есть и не шарлатаны? Даже те кто этот Agile начали, они тоже не просто книжечку написали, а целые организации начали делать для продвижения своих идей, конференции всякие, тучу книг. Чем это от Саентологии отличается? Они тоже качество жизни и роботы предлагают улучшить. И даже книжечки для это специальные продают. Я так себе и представляю это, Agile специалист 4 степени, 8 уровня, с сертификатом (конечно платные курсы пройти нужно) подписным основателями Agile. Agile-мастер, Agile-грандмастер. Ну и звание для адептов культа начального уровня — Agile-консультант.
EDIT:
Хотя, сори, консультант это не начальный уровень, это наверно скорее вне уровня,
что-то типа священника, тот к кому можно обратится, что бы он дал интерпретацию священного Agile писания, и дал советы по поводу того как ритуалы проводить.

Если в заголовке и тексте Agile поменять на Процесс — то все станет на свои места. Иначе — незачет. Agile per se тут не при чем. А бэк лог все-таки лучше иметь. Не как самоцель, конечно (planning sucks, plans rule).

Не согласен по поводу процесса — качественно проработанный процесс (учитывая в т.ч. Agile принципы) будет нормально работать на проекте.

Есть нюансы. Работать будет, если не фанатеть им (процессом, об это собственно оригинальный пост в моем понимании) и постоянно адаптировать к ситуации. Опасность up-front качественной проработки процессов — они сложнее меняются (ведь столько усилий ушло на создание)

Ну это проблемы проджекта, а не разработчиков. Это не должно влиять на их работу и проект в целом. Во много это будет зависеть от «боевого опыта» ПМа.

ПМ? Это кто? И нужен ли он в startup?

Естественно нужен. У нас их мало, потому как ПМов нормального уровня в принципе мало. Кастомеры то все равно ПМов нанимают если проект мало мальски нормальный.

Если проект растет, то мифы о том, что без ПМ можно прожить — это большой самообман.

Если проект растет — видимо несколько другой контекст, чем поднятый в топике. Кроме того надо понимать что ПМ (как в украинском варианте, так и в западном) по большому счету это waste (в терминах Lean). Да, зачастую без него сложно, особенно в больших организациях, но чем меньше его нужно — тем здоровее процесс и коммуникации.

:)))

от души посмеялся :)

Ну да. Хороший ПМ всё обустроит так, что бы самому как можно меньше влазить в процесс. Посему он вроде как и не нужен уже :)

Это какой такой проект растет? ДА и вообще откуда проект взялся? Планов даже четких нет...

Мы ж про стартапы? Там четкое понятие «что делать» в лучшем случае через год приходит...

(planning sucks, plans rule)

так наоборот же!

айк переворачивается в гробу со скоростью гироскопа :))))))

кому надо — тот поймет ,) Да, наоборот.

Цей набір термінів чомусь мені нагадує цитату з Лєпри у темі про MLM
---
Приехал в родной город и встретил друга детства, который также пытался мне впарить прокладки! Мужчине! С ионами серебра!
Ну, я ему рассказал про веб 2.0, стартапы, инвестиции, бизнес—инкубаторы, элеватор—питч, вконтакте—одноклассники—твиттер—фейсбук, опционы, монетизацию, дата—центры, прототипы, анализ аудитории, сегментацию, юзабилити, KPI...

Ну а чо, мы честно поделили время — час он мне впаривал, час я ему.

Для вашего стартапа может быть вредно одержимость идеей и отсутствие плана.

План — это путь достижения желаемого результата. Он основан на определенном процессе. Процесс (и план) может пересматриваться так часто, как вам угодно, но желательно тогда, когда процесс показывает свою несостоятельность. Это и есть Agile, и он не может навредить стартапу.

Одержимость же идеей мешает мыслить логически и реалистично: сегодня все бежим направо, а завтра в лес, причем лес для каждого свой. А чего побежали, потому что руководитель стартапа прочитал какой-то пост на каком-то сайте и решил, что вот она правда? Такое часто называют Agile. Но это не Agile, это бардак, и это может действительно навредить вашему стартапу.

На то он и Стартап, чтобы бежать то туда, то сюда в поисках рабочей бизнес модели. Но это действительно нифига не Agile, даже плана нет! Это зовется: «на колене, из того что было» и стартапу такое не вредит, стартап обычно так и строится.

Беклог, скрам, процессы и прочее пригодятся только на версии 2.0 или даже 3.0. То есть когда таки полетит и будет хотя бы понятно, что примерно нужно делать :)

Кто стартапы или коробочные продукты «от и до» не делал — обычно такого может насоветовать... И вообще, разработка продукта это в лучшем случае 10% от всей работы, которую нужно делать в IT бизнесе!

Это все так. Но главный вопрос — зачем? Зачем бегут туду-сюда? Когда в поисках рабочей модели, то это хорошо, но между двумя копнами сена кто-то когда-то умер, так и не выбрав... Это правда,что сам девелопмент не должен быть какой-то самодостаточной вещью. Нужно помнить для чего стартап(или любой другой бизнес-проект) задумывался. Если выдумать,что-то доселе неведомое — пишите, а если, чтобы получить прибыль — продавайте.

На то он и Стартап, чтобы бежать то туда, то сюда в поисках рабочей бизнес модели. Но это действительно нифига не Agile, даже плана нет! Это зовется: “на колене, из того что было” и стартапу такое не вредит, стартап обычно так и строится.
І який процент таких стартапів не перетворився на стопдауни?

Чесно говоря ненавижу слово стартап.

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

Чесно говоря, я программист не сильный и наверное это мое преимущество, так как больше думаю о фин.результате и правильном планировании, чем о Agile.

По-моему, все из-за того, что адепты любой методологии/парадигмы убеждаются в том, что уже «всё знают» (в смысле, у них целостная картина мира, в которую легко уложаться любые факты). Я думаю, такая уверенность в общем полезна, до тех пор пока она не переходит в самоуверенность. Т.е. не нужно забывать про необходимость адаптироваться...

Это всего лишь частный случай CCDD — Cargo Cult Driven Development. И если ключевые фигуры в стартапе исповедуют (а не применяют) Agile, то никуда не деться. Хотя могут быть и другие варианты, например ADD. www.scottberkun.com/...en-development

На мой взгляд agile наоборот необходим для стартапа. Agile не должен быть бюрократичным, он должен быть гибким:) А стартап должен реагировать на фидбек пользователей, а не разрабатываться итерациями по пол года. Да и без оценки приоритетов и канбана будет сложнее понять к чему идёшь. Agile должен помочь создателю стартапа лучше видеть курс всего проекта. В хаосе можно этот курс потерять.
Другое дело что конечно не стоит месяцами сидеть и писать бэклоги и планировать. Надо колбасить код:)

TDD это тоже не бюрократия а весьма полезный и обоснованный подход к разработке проекта независимо от того стартап это, или нет.

Максим, опять вброс некрасиво делаешь.

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

Единственная методология agile адекватно масштабируемая, это семейство Crystal от Алистера Коберна, который диссертацию на эту тему пишет. Масштабируемая по количеству участников.

Если у тебя маленькая команда и аврал и не готов продукт, то многие используют XP, если аврала нет, то Scrum или что-то еще.

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

P.S: про TDD..зря зря зря..©

А нафига стартапу масштабируемая модель разработки? Все равно все придется не мнение 2-3 раз переписывать почти с нуля :) Вот когда все полетит, тогда и начнутся «трудовые будни»

Не знаю в яких стартапах/продуктових компаніях вам довелось працювати, але мій досвід показує, що все буде абсолютно не так :) Переписати все з «нуля» можуть дозволити собі 2 типи компаній:
1) компанії типу Твіттера, в яких навантаження (не обовязково від користувачів) зростає в тисячі разів за дуже короткий термін; тоді це 100% успіх і їм просто «впихнуть» 100-200-300 млн. «вічнозелених» інвестицій, розумно буде потратити їх на найм висококваліфікованого персоналу, який перепише систему і вона зможе принести ще сотні мілліонів
2) компанії у яких є 10-20 девелоперів, продукт працює без особливих проблем і закінчився список «фіч» для розробки
Компаній другого типу, думаю, або не існує, або практично не існує, тому розглядати я б їх не став.
В реальних системах «говнокод» буде працювати 5-10-20 років, реальною умовою переписування функціоналу буде або досягнута верхня межа продуктивності, або неможливість вносити зміни без серйозних часових втрат (> 100%). Іншими словами, 99% успішних компаній переписувати систему не будуть НІКОЛИ. Більше того, у розвинутих компанії менеджмент буде «різати» такі починання, так як це вносить додаткові великі часові втрати і може серйозно дестабілізувати продукт. Тому «трудові будні» в типовій компанії — це «латання» існуючих проблем за мінімальний час.

Сам придумал тезисы, сам доказал и сам опровергнул. Маладец :)

Только причем тут страртапы? Какая система какой список фич? Откуда это все возьмется?

Твиттер в начале вообще «СМС гейтом» был... API регулярно меняется даже у Google и Facebook, а у какого-то стартапчика продукт/сервис за полгода может 3 раза помнятся полностью вплоть до фреймворков и языка программирования :)

Сам придумал тезисы, сам доказал и сам опровергнул. Маладец :)

Не зовсім зрозумів до чого це було написано. Не бачу як «говнокод» суперечить «латанню дир» таким же говнокодом.

Какая система какой список фич? Откуда это все возьмется?

Я нічого не говорив про систему і список фіч, прочитайте уважніше. Але, в принципі, на початку розробки має бути бачення цілі, а інакше як знати що ціль була досягнута?

API регулярно меняется даже у Google и Facebook

І як це відноситься до того що я розказав? Ви читали про архітектури цих систем? Там десятки команд працюють над тим що ви назвали «API», тому зміни у них — це повністю природний механізм еволюції коду. І, до речі, зміни там роблять вповні обдумано, з «тестами і списком фіч» :)

а у какого-то стартапчика продукт/сервис за полгода может 3 раза помнятся полностью вплоть до фреймворков и языка программирования

приклади в студію! окрім «у мене знайомий сам бла-бла-бла».
Продукт чи сервіс може мінятись так часто як цього вимагає ситуація, а зміна технологій — це повна чи часткова зміна команди, що дуже недешево! Особливо для стартапів з обмеженим фінансування.

До того ж я не зовсім розумію як часта зміна фреймворків/технолоній/мов програмування повязана з «бидлокодом»? Є якесь правило, яке говорить що при зміні технології обовязковим правилом її використання є «гнилий говнокод»?

До речі, а скільки стартапів запустили ви?

Стартап подразумевает быструю разработку и постоянную модификацию бизнес-модели (читай кода). как правило времени на тесты и рефакторинг или не остается, или выделяется мало — в результате чего получается г0внокодец. Часто на начальных этапах бизнес это принимает — т.к. работает и ок

И это правильно! То что пройдет проверку рынком, потом будет переписано с нуля.

Написав вище відповідь на схожий коментар, але тут добавлю ще дещо.

т.к. работает и ок

це і стане «могилою» девелоперів. Ніхто не буде переписувати працюючий код, навіть при умові його повної «говнокодистості». На початку розробки я б оцінював життя кожного участку системи в 3-5 років (в залежності від спеціалізації продукту і самого коду), а потім запитав себе чи захочу я підтримувати цей код на протязі цього часу? І найголовніше, чи зможе хтось без моєї допомоги підтримувати цей код на протязі цього часу?

Разберись что такое стартап и для чего люди их делают — все станет на места :)

Ми на «ти» не переходили, тому раджу вам перечитати основні правила поведінки і листування перед тим як вийти на вулицю.
Я працюю у вповні успішному стартапі, тому маю доволі непогане уявлення про те, як він працює. І саме тому я і відписався в цій темі.

Скоріше за все, це у вас якесь збочене бачення стартапу. Для вас стартап — це працюючий «на скрепках» двигун, який потрібно викинути як тільки він почне працювати. Це якась невідома світу умова геніальності чи унікальності? Чи за цим показником заносять на якусь «стіну слави»?

Раджу спочатку вкласти в *свій* стартап *свої* $nnK+ (квартиру, машину, whatever). Після цього ВИ будете мати *деяке* уявлення про те, як працює стартап :)

*Непогане* уявлення має Ерік Райс, Дейв МакКлур і т.п. люди.

Дарма стільки сарказму. Для чого мені щось вкладати? Мене абсолютно не цікавить побудова стартапу, я займаюсь розробкою і мене це повністю влаштовує. У мене є доволі немалий досвід роботи в «продуктових» компаніях, є досвід розробки стартапів і коли я говорю про прооцес розробки, то говорю про декілька років свого життя.
Я не давав ніяких порад на рахунок ведення маркетингових компаній чи розвитку персоналу, говорив тільки про те в чому маю досвід. Тому раджу ВАМ краще читати коментарі і надалі робити те за що ви відповідальні у своїй компанії.

А набір розумних слів, імен і назви перечитаних книг (декілька з яких я теж перечитав) ніяк не говорять про ваш досвід (звичайно ж, якщо ви з цими відомими людьми особисто не працювали)

говорив тільки про те в чому маю досвід.

Значить ти не маєш досвіду старту (в стартапі, як founder). І даєш поради людям, які цим займаються 10+ років.

Як «10+ років» характеризують досвід? Я бачив девелоперів з 5-7 роками досвіду і жахливими навиками розробки (пр тому що вони цим кожного дня собі на хліб заробляють). У чому різниця фаундера з 10 роками і такого девелопера? Фаундери — це окрема каста яким гарантований виключно «правильний» досвід?

Я даю поради по розробці, де їх досвід як фаундера, буде нічим не кращий за мій. При тому що цей же «фаундер» може бути і не девелопером, правда?

Фаундери — це окрема каста яким гарантований виключно «правильний» досвід?

Так. Тому що вони несуть основний ризик.

все зрозуміло :) хлопчику, відійди від компютера і поклич тата, дай дорослим дядькам поговорити

До речі, я зачіпив тему вашої компанії, яка є, в принципі, аутсорсинговою компанією, наскільки я зрозумів з веб-сайту. Яким методологіями ви користуєтесь? Ви зразу починаєте «говнокодити» чи перечитуєте специфікацію/цілі проекту і продумуєте код/архітектуру? Після написання першої версії ви просто робите Shift+Del існуючого коду? І чому саме ви так робите?

Ми використовуємо

Втім.. Говнокодимо, ясна річ. І специфікації одразу видаляємо. І все кожного разу переписуємо з нуля, починаючи з kernel and device drivers :)

І знову недоречний гумор (а чи гумор?), питання було абсолютно серйозним.

Не мені давати поради «великому фаундеру з 10+ роками», але вам не здається що ваші коменти можуть виставити вас і вашу компанію трохи не в тому світлі в якому б хотілось перед потенціними клієнтами компанії?

А вам не здається, що мені може бути нецікавим описувати доводити холліварити на тему правильного методу розробки?

Хочете дійсно дізнатись — 42coffeecups.com/jobs

Чому ж «холіварити»? Я цілком серйозно хочу дізнатись про те як розробляють стартапи. От шановний @Anton розказує що всякі методології — це зло, треба «бидлокодити» що є сили, а головне щоб всі члени командили бидлокодили в різних напрямках, потім якимось чином знайти свою нішу, дропнути весь код і переписати все «правильно».
Моя точка зору — витратити чуть більше часу на початку, продумати необхідний список фіч і мінімальну архітектуру, а потім нічого не дропати, а потихеньку переписувати вузькі місця (а можливо, що переписувати нічого і не потрібно буде).

От ви, як власник аутсорс компанії, яка розробляє стартапи, можете з свого багатого досвіду розказати нам цікаву статистику.

Хочете дійсно дізнатись — 42coffeecups.com/jobs

Не хочеться вас обаразити, але ваші вакансії мені не дуже цікаві. По-перше, не мій сегмент, а по-друге, зарплатня набагато менша за мінімально очікувану (це з статистики по зарплатах ДОУ)

... угу, а ще у нас бассейну нема :)

Ви, шановний, тему не переводіть на всякі там басейни, у нас тут друга тема обговорення.

Я вам даю реальний шанс допомогти, я так розумію, другу @Anton-у простою сухою статистикою. Мене влаштовують прості дані типу: з 20 проектів ми на 5 використали Канбан, всі «померли» в перший день обкатки на користувачах через проблеми в архітектурі і коді; схожа участь спіткала 5 проектів, де використовували Скрам, але там девелопмент затягнувся на Х+1 місяць і продукт не відповідав бажанням клієнта; на 10 ми «бидлокодили до посиніння кінчиків пальців» і всі вони не містять серйозних багів та витримують пікові навантаження N «сферичних» операцій в секунду (на аналогічних серверах). Це однозначно доводить, що використання Скраму і Канбану шкідливе для стартапу.

Ніяких імен чи інших конфіденційних даних мені не потрібно.

А то зараз мені здається, що я пробую у першокласника вияснити рішення задачки, а він голосно кричить «я не жираф». І питання зовсім не в тому, що і задачка не про жирафів, і аргумент його абсурдний, а те, що він абсолютно не здатний доказати, що він і справді не жираф :)

Я вам даю реальний шанс допомогти

От тільки «реального шансу» від «великого дядьки» який цілих «декілька років життя» працює в стартапі мені і не вистачало.

Це однозначно доводить, що використання Скраму і Канбану шкідливе для стартапу.

Думав вже забити на флейм, але згадав іншу казочку...

Про те як команда круто використала канбаноподібний скрам, все робилось через TDD та Pair Programming, code coverage в тестах не падав нижче 90%, серйозних багів не було жодного і продукт витримував N**N сферичних операцій в секунду на дохлому селероні в чулані. А за потреби — міг горизонтально масштабуватись просто увімкненням додаткових залізяк.

Тільки все це чудо, будучи запущеним, отримало з десяток візитів на головну сторінку і 0% conversion.

І померло в муках.

Отака вам, діти, казочка на ніч :)

От тільки «реального шансу» від «великого дядьки» який цілих «декілька років життя» працює в стартапі мені і не вистачало.

Ну хтось же має дати вам цей шанс, а то ви як партизан продовжуєте мовчати і тільки час від часу щось згадуєте про «жирафів» і «фаундерів».

Думав вже забити на флейм, але згадав іншу казочку

Казочка вповні має право на життя в контексті обговорення. Я таких прикладів не знаю, але не виключаю можливості, що продукт був «супер клоном Твітера з унікальними свистопердєлками».

Андрію, так давайте не плутати добре поставлений процес і хрінову бізнес-ідею. Ці речі взагалі ортогональні.

В стартапі неможливо провести межу між процесом розробки софта та процесом роботи над бізнес-ідеєю. Там це — одне і те ж.

Дві тези:
можна провалити потенційно хорошу ідею тяп-ляп-процесом;

можна застосувати ідеальний процес до марної ідеї й отримати робочий, однак нікому не потрібний результат.

Описаній команді потрібна людина з доброю бізнес-ідеєю, котрій брак хорошого процесу, от і все.

Інакше можна стверджувати, що робітник на заводі обов’язково повинен бути випивохою і халтурити, бо його стан душі нерозривно пов’язаний з виробничим процесом, а якщо всі робітники будуть тверезими й не допускати браку, то це буде неминучим крахом промисловості.

есть такой блог agileisbullshit.com, где автор хорошо расставляет все по местам. agile — это не экстрим. это взгляд на разработку. на user story энергии надо гораздо меньше, чем на написание всеобъемлющих спек. high level design вам все-равно нужно будет делать. и в agile стартапе вы это для экономии сделаете на салфетке или на доске, а потом сфоткаете на телефон, например.

модность agile там и насаживание его тут вызвало (вполне естественно) волну противодействия. теперь у всех в головах agile = нигилизм.

Спасибо за ссылку, хорошо написано.

Підтримую ногами і руками. До Lean Startup дістався? :)

Судя по всему вы оба до Lean Startup слабо добрались :) Тот же Риз сам написал, что все проекты которые переняли Lean Startup улетели бы в трубу без порядка в разработке. И большая часть бизнес идей из книги была реализована pivotallabs.com у которых с процессами все хорошо ;) Или я не тот Lean Startup читал.

Действительно, зачем нужны методологии и всякие юнит тесты когда можно слепить кривой прототип и потом месяцами (годами?) обкатывать его на пользователях? Это мне напоминает один сайт одного сообщества :)

Понятие юнит тест куда старше Agile.

Есть оч. много разных методолгий. Но ни одна из них не универсальна. Поэтому толковый управленец не будет пихать Agile (или что другое, которое знает) везде где можно. Скорее он будет исходить из задачи, ситуации и возможностей выбирая ту или иную методологию, а методологий этих много, очень и очень много. К сожалению, универсальной пока не придумали.

И это говорит человек работающий в Микрософте :)

Добавьте тег сарказм в бэклог ;)

Бэклог? не, не слышали..

Коллега, Вы задаёте вопрос,

зачем нужны методологии

, и тут же сами на него отвечаете:

можно слепить кривой прототип и потом месяцами (годами?) обкатывать его на пользователях

Ведь это же и есть квинтэссенция аджайл-методик, не так ли? ;)

Не совсем понял разницу для эджайла для стартапа и не стартапа. Получается, что вообще, методология очень полезная, потому что положительно влияет на эффективность. Но для стартапа, где главное хоть что-то хоть как-то делать, это не важно?.. По-моему, в статье говорится больше о том, что для стартапа менее важен формализм и бюрократия, чем эджайл. Общение с пользователями — разве не эджайл?

Оптимізація однієї ділянки бізнес-процесу приводить до падіння ефективності всього бізнес-процесу

Звісно, але це означає, що не потрібно займатися оптимізацією цієї ділянки? Можливо треба намагатися оптимізувати весь процес також? Мені здається, що еджайл й створювався для стартапів, щоб мати перевагу перед інертними поважними компетіторами. Надати замовнику те, що він дійсно бажає та швидко. Прикладні технології еджайла — це, згоден, для стабільних кампаній.

Мені здається, що еджайл й створювався для стартапів

Прочитайте історію створення XP. Chrysler аж ніяк не стартап. Тим більше в кінці 90-х

Ми говоримо про Agile, чи про прикладні технології Agile?

Оптимизировать надо продажи и только продажи, все остальные процессы у бизнеса побочные :)

Да, на самом деле, так и есть... Все остальное искусство, в лучшем случае...

Думаю что надо комбинировать «кусочки» из разных технологий и методологий, основываясь на ближайших целях, состоянии продукта (или стартапа как в даном случае), его предназначении (анализ целевой аудитории, возможных прибылей, другие маркетинговые исследования, бла бла) так как всему свое время :)

Надо тупо сделать, пофиг как. Главное быстро, дешево и с достаточным качеством. А потом «продавать, продавать, продавать!» © :)

Или так: сначала «продавать, продавать, продавать», а потом сделать — быстро, дешево и с приемлимым качеством. :)

Останнє необов’язкове. А якщо знаєте, куди тікати, то й передостаннє необов’язкове.

Что думаете?

Думаем, что в этой теме будут очередные дебаты на нему flexible или strict

Так же думаем, поэтому делаем «коробки» без всякого экстрима :)

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Да, я тоже в шоке. Макс, вы только что расписались в полном незнании эджайла. Пусть вам будет стыдно! )))
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools
Individuals and interactions over processes and tools

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111

Макс, ну я ведь тебя предупреждала в очень однобоком понимании Agile, а точнее — в банальном недостатке знаний. Почему ты ассоциируешь гибкие подходы только с тестами и техническим процессом разработки? При таком богатстве agile-практик по работе с пользователями, определению бизнес-ценности, приоритезации разработки.

Советую посмотреть содержание американских конференций по гибкой разработке. Очень полезно, если вы действительно горите за то, ЧТО разрабатывать.

А здесь много шума о том «как» только потому что в оффшоре не всегда команде дают возможность участвовать в «что».

Вот он, agile innovationfriends.com.ua/...oot-camp-02-12

конкретики никакой, однако.

это что, рекламный пост?

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

Возможно, дело в том, что большинство людей путает понятия. Под agile’ом подразумевают scrum, как наиболее популярную методологию. Под scrum’ом подразумевается использование кучи разных тулзовин, вроде тех, что на картинке: i.imgur.com/vDVWD.jpg, якобы под него заточенных.

В итоге тот agile, о котором говорят, не имеет ничего общего с принципами agile manifesto. И да, в таком случае он не нужен.

Вот именно, сначала тебе говорят,

Individuals and interactions over processes and tools

А потом подсовывают целый набор из processes and tool.
Вот только авторы Agile не против, что собственно демонстрирует противоречивость этого манифеста и Agile в целом. Agile не имеет ничего общего с Agile?

Зачем вообще нужно это слово, и кучу всей это фигни? Разве нельзя без этого всего?
А просто сказать себе — давайте будем проще и не будем плодить бюрократию, давайте будем делать хороший красивый софт, а не г-нокодить лишь бы сделать видимость выполненных требований. Давайте честно и открыто общаться.
Разве тяжело до этого додуматься, без всяких книжек по Agile и консультантов?
И унылых обсуждений — полезен ли Agile где-то или нет.

А потом подсовывают целый набор из processes and tool.

Кто подсовывает? ScrumAlliance? Ну, не идите к ним, идите к Майку Кону, Алистеру Коберну, или Крэгу Ларману. Или вообще ни к кому не идите, попытайтесь понять смысл Agile manifesto и начните думать своей головой.

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

А причем тут начинающие. Есть Agile манифест, он говорит

Individuals and interactions over processes and tools

.
А потом вдруг появляются Agile методы/методологии, которые из себя представляют целую кучу process и tools. При этом для многих тут (включая автора поста), Agile = Agile methods. Просто противоречие.
Так что выбирайте, или Agile методологии, или Agile манифест, но не вместе.
Хотя к черту этот манифест, если 4 основных пункта ещё нормально смотрятся,
то принципы — чушь.
Примеры:
— welcome changing requirements, even late in development,
многим тут нравится, когда в процессе написания кода, их прерывают, и заставляют делать что то другое? я конечно понимаю что это имеется ввиду на более высоком уровне, а не именно в момент реализации какого то малого таска и кодинга. Но просто как аналогия. Ну и к тому же, всегда можно придумать такое изменение в системе, которое может просто не вписываться в то что уже реализовано, и которое потребует переделывания всего до этого сделанного — спрашивается, какой нормальный человек будет радостно приветствовать изменения в требованиях, особенно на позднем этапе?
— customer satisfaction by rapid delivery of useful software, если взять треугольник «быстро, качественно, дешево», то получается, что дешево уже не выйдет, потому что у нас rapid, быстро и часто удовлетворяем заказчика хорошим-полезным софтом? тогда получается, пусть заказчик готовит больше денег. А поскольку заказчики часто жлобы,
то получается какое то лицемерие, и постоянные гонки за дедлайном с г-нокодингом — верно?
— projects are built around motivated individuals, who should be trusted
с одной стороны — капитан очевидность, с другой стороны — ага, сейчас, мотивированный негр на аутсорсе, к тому же трастед, да ещё к тому же профессионал наверно.
Или на аджайл проектах всем дают % от того что софт принесет? Или это ’around’ подразумевает только проект менеджера? А негротестеры, и негродевелоперы не в счет?

Ну и так далее. Бред какой то, оторванный от реальности. Ну или во всяком случае не ориентировано это все (манифест, не методологии, про методологии нужно отдельно говорить, конкретно) на те проблемы которые реально возникают.

"

Бред какой то, оторванный от реальности.

"

в точку

А ещё предлагаю писать код без багов сразу. И без кикофов, требований, бюджетов- неужели сразу не понятно, что нужно написать хороший красивый софт без говнокода и багов?

Это называется — утрировать. Я не говорю что все должны взять и начать сразу писать код без багов и весь такой чудесный. Просто, если смотреть на пункты Agile манифеста и принципы, и не смотря на то что они все противоречивы и расплывчатые (в буквальной интерпретации), вроде все таки просматривается какая-то положительная идея за ними. Но идея эта совсем общая, как я и написал — избавление от лишней бюрократии и глупости, и более прогрессивный подход.
Вот в качестве аргумента, моя интерпретация:
— больше тратить время на совместный анализ и обсуждение того как мы видим будущий софт, а не бездумно кнопки нажимать
— не устраивать бюрократию документации (хотя документация нужна в любом случае, точно также как четкое видение всех сторон — какой софт и что делается, и именно хорошая документация может помочь это проконтролировать, а то если люди не готовы к нормальному адекватному анализу, то в итоге без нормальной документации будут делать черт знает что, а потом на ходу все допиливать, особенно если заказчик сам не до конца понимает — что ему нужно)
— сотрудничать с заказчиком, работать вместе для того что бы сделать хороший софт,
а не спорить про то сколько мы сделаем, и сколько это будет стоить, и соответствует ли оно спецификации (опять же таки, если стороны не готовы, то будет полный бред, как не старайся)

— быть более мобильными, быстрее реагировать на изменения (хотя этот пункт самый спорный, в своем оригинальном виде, если действительно понимать его — как отказ от нормального планирования — то это бред).

Вот в таком виде, выбрав все самое лучше, мы получим не методологию даже, на выбор. А просто таки обязательный подход к нормальной адекватной разработке.
Вот это я и предлагаю вынести, и использовать это без лейбла «Agile».
Мало того, любой адекватный и прогрессивный человек, рано или поздно до этого

может додуматься сам (другое дело что применить это все, на практике

В противном случае, если понимать все буквально, и ещё и принципы брать (которые уж совсем как заповеди какие-то). То Agile превращается в очередной бред, с намеком на религию. И в добавок методы, форма (и само наличие) которых противоречит пунктам манифеста в буквальной интерпретации. И кому этот бред нужен в таком варианте?

А если вы просто хотите что бы у вас были всякие бэклоги, юзер стори, и прочее, так это вообще другая история (no pun intended).

Другими словами, может сначала стоит определится — что вы понимаете под Agile —

манифест не буквально, манифест буквально, методологии (которые противоречат манифесту в буквальном понимании, и не имеет в принципе ничего общего с манифестом в общем понимании).

Спасибо за развернутый ответ.

Расскажу о своем понимании Agile. Мы начали именно с практик: бэклог, спринты, минимум документов. До этого мы работали по DSDM, что тоже вроде бы аджайл. Но. Через месяца 4 мы обнаружили, что наши отношения заказчиком сильно изменились. И наш поход к разработке тоже изменился. Да и отношения в команде поменялись.

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

Да, я бы наверное переписал манифест. Как-то так:
1) команда важнее менджера, и важнее процесса;
2) отношения с заказчиком важнее контрактов, требований и документов;
3) обратная связь важнее желания прикрыть свою ж%%пу;

4) изменения будут! поэтому сразу пишем хорошо.

Бэклоги, юзер стори и прочее — это не более, чем инструменты: в данном конкретном случае, инструменты ведения приоритезированного списка требований к продукту и описания этих самых требований с «колокольни» конечного пользователя. Никто не мешает использовать эти инструменты и в более формальных и ориентированных на планирование подходах.

быть более мобильными, быстрее реагировать на изменения (хотя этот пункт самый спорный, в своем оригинальном виде, если действительно понимать его — как отказ от нормального планирования — то это бред)

Он не спорный, он просто имеет ограниченную область применения. Есть проекты, в которых действительно неизвестно, что понадобится через месяц, например, когда идет высококонкурентная борьба за какую-то рыночную нишу (прямо как в фильме ДМБ — «пока противник рисует карты, мы меняем ландшафт»). И есть проекты, в которых можно и нужно планировать наперед. Об этом, по-моему, было у Майка Конна в статье Balancing Anticipation vs. Adaptation

Подписаться на комментарии