Не знаю как вопроизвести со 100 процентной повторяемостью дефект
но после того как долго играться, то можно увидеть вот такое img24.imageshack.us/i/myshowsbug.png/
Зайтиде на этот сайт www.imaging-resource.com/IMCOMP/COMPS01.HTM
выберите сравнение фотографий, сделанных G11 и GF-1
и вы поймёте, как далёк G11 от панаса. Качество G11 чуть лучше чем у мыльницы.
Я тоже прозрел после того как увидел окно с ошибкой в Skype на библиотеку из Delphi.
Начал искать — действительно UI писали разработчики из Эстония/Латвия/Литва (точно не помню).
А вот и доказательство www.stevetrefethen.com/blog/SkypeYeahItTooIsWrittenInDelphi.aspx
Да зачем вы вообще связываетесь с этими DHL, TNT и прочими. Сколько уже я не заказаывал через USPS, всегда получал уведомлениес с почты уже через 7-12 дней.
Статья ни о чём. Я думаю это уже старческий маразм. Он как и любой другой старик, живёт воспоминаниями про огромные мейнфреймы и разработкой системы управления багажом для даллаского аэропорта.
«Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.» Это он о чём? С каких это пор наполнение контента — это и есть программный продукт?
«Но это не совсем то, что инжиниринг ПО стал значить.» Надо сказать иначе «Инжиниринг ПО — это не то, что ты думаешь, ДеМарко.»
Our new approach to systems development is based on both defined and black box
process management. We call the approach the SCRUM methodology (see Takeuchi and
Nonaka, 1986), after the SCRUM in rugby — a tight formation of forwards who bind
together in specific positions when a scrumdown is called.
Так ты всё таки определись, что это. Потому что самое первое твоё предложение звучит так «Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан». Это во-первых, а во-вторых Канбан не может быть системой ценностей, потому что это место уже забито таким понятием как «lean».
Scrum и XP — это методологии.
«В Канбан оценки сроков на задачу опциональные или вообще их нет» — это ваши слова.
Дальше — в канбан нет роли PO. В канбан нет вообще ролей. И в отличае от скрама в канбан не говорится что именно он должен делать приоритезацию.
Такие вот «мелочи» и отличают настоящую методологию от набора «полезных советов»
В канбан — ничего не сказано про приоритезацию. Там сказано — делайте как хотите, можете вообще не приоритезировать. Про оценку времени тоже ничего не сказано. Она не нужна, оценка — это трата времени. Когда будет сделано, тогда и будет сделано.
Всё что есть в канбан — это ограничение WIP и всё.
То что вы только что описали, уже как лет 10-20 имеет очень чёткое определение в мире управления разработкой программного обеспечения. И имя ему «Ad hoc development». По склассификации CMMI относится к уровню 2 и имеет крайне низкий уровень предсказуемости и управляемости. www.ctg.albany.edu/publications/reports/survey_of_sysdev?chapter=4
А то что для старых дел придумали новомодное очередное название, ещё раз говорит о том, что это всего лишь наживка для армии agile-тренеров.
Кстати, 8 месяцев назад общались мы с Robin Dymond (CST), которые сейчас читает также тренинги по лин и канбану. Так вот спросили его потом за бутылочкой пивка, а ты хоть раз в жизни видел проект, который бы работал использую Канбан. Его ответ? «Нет» )))
Канбан, вырванный из TPS — это всего лишь практика и никак не методология.
Даже Хенриг Книберг в своём сравнении скрама и канбана (вдруг не читали, blog.crisp.se/henrikkniberg/2009/05/29/1243594140000.html) скатывается к откровенно премитивному выводу — вся суть «методологии» канбан — это контроль WIP-а, а всё остальное по вашему усмотрению. Опытному менеджеру и разрабочки при этом становится просто смешно.
Приведу вам хороший пример использования практики (именно практики, а не методологии) канбан.
«Не разрабатывайте фичей больше чем можете протестировать».
Почитайте оригинальные книги по канбан 70-ых годов и вы поймёте, что канбан притянут за уши в разработку программного обеспечения. Как минимум по двух причинам. Одно из обязательных условий для того, чтобы TPS работал является постоянность временных интервалов связанные с выполнением определённых процедур. Именно поэтому в разрезе TPS планирование — это «waste» (потеря, лишняя трата времени).
Это один из китов на котором основан ТПС и Канбан. А так как такое требование никогда не может быть выполнены в разработке (вы в 30-40 процентов никогда не скажете точно сколько времени уйдёт на исправление того или иного бага), то мы приходим к выводу, что это всего лишь очередная маркетинговая замануха.
но после того как долго играться, то можно увидеть вот такое
img24.imageshack.us/i/myshowsbug.png/
www.imaging-resource.com/IMCOMP/COMPS01.HTM
выберите сравнение фотографий, сделанных G11 и GF-1
и вы поймёте, как далёк G11 от панаса. Качество G11 чуть лучше чем у мыльницы.
Начал искать — действительно UI писали разработчики из Эстония/Латвия/Литва (точно не помню).
А вот и доказательство
www.stevetrefethen.com/blog/SkypeYeahItTooIsWrittenInDelphi.aspx
«Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.» Это он о чём? С каких это пор наполнение контента — это и есть программный продукт?
«Но это не совсем то, что инжиниринг ПО стал значить.» Надо сказать иначе «Инжиниринг ПО — это не то, что ты думаешь, ДеМарко.»
jeffsutherland.com/oopsla/schwapub.pdf
Our new approach to systems development is based on both defined and black box
process management. We call the approach the SCRUM methodology (see Takeuchi and
Nonaka, 1986), after the SCRUM in rugby — a tight formation of forwards who bind
together in specific positions when a scrumdown is called.
Scrum и XP — это методологии.
Дальше — в канбан нет роли PO. В канбан нет вообще ролей. И в отличае от скрама в канбан не говорится что именно он должен делать приоритезацию.
Такие вот «мелочи» и отличают настоящую методологию от набора «полезных советов»
Всё что есть в канбан — это ограничение WIP и всё.
www.ctg.albany.edu/publications/reports/survey_of_sysdev?chapter=4
А то что для старых дел придумали новомодное очередное название, ещё раз говорит о том, что это всего лишь наживка для армии agile-тренеров.
Или как там из зала добавляли «копали от забора и до заката»?
Даже Хенриг Книберг в своём сравнении скрама и канбана (вдруг не читали, blog.crisp.se/henrikkniberg/2009/05/29/1243594140000.html) скатывается к откровенно премитивному выводу — вся суть «методологии» канбан — это контроль WIP-а, а всё остальное по вашему усмотрению. Опытному менеджеру и разрабочки при этом становится просто смешно.
Приведу вам хороший пример использования практики (именно практики, а не методологии) канбан.
«Не разрабатывайте фичей больше чем можете протестировать».
Это один из китов на котором основан ТПС и Канбан. А так как такое требование никогда не может быть выполнены в разработке (вы в 30-40 процентов никогда не скажете точно сколько времени уйдёт на исправление того или иного бага), то мы приходим к выводу, что это всего лишь очередная маркетинговая замануха.