Приглашаются все желающие протестировать онлайн-тренинг "Ленивая разработка" http://webinar2.ru/lean-development 5-11 октября с 22.30 до 23.00 (по Мск).
Кто не успевает — будут аудио-записи, которые можно будет скачать утром.
Тренинг рассчитан на тимлидов и менеджеров проектов.
P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
Здравствуйте, Lead Lead, Вы писали:
LL>Тренинг рассчитан на тимлидов и менеджеров проектов.
Добрый человек, Вы бы о себе слегка написали в своем блоге: кто такой, чем занимался, что сделал и т.п.
Сами понимаете, сейчас очень много тренеров-консультантов развелось, -- ко всем не находишься.
Здравствуйте, Огнеплюх, Вы писали:
LL>>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо. О>А как определяется и доказывается что необходимо а что нет ?
Экспериментально.
Вначале, естественно, делаются предположения на основе опыта — своего и чужого.
Как именно — об этом и будет тренинг.
Если интересно — сегодня в 22.30 начало.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Lead Lead, Вы писали:
LL>>Тренинг рассчитан на тимлидов и менеджеров проектов.
AL>Добрый человек, Вы бы о себе слегка написали в своем блоге: кто такой, чем занимался, что сделал и т.п. AL>Сами понимаете, сейчас очень много тренеров-консультантов развелось, -- ко всем не находишься.
Здравствуйте, Lead Lead, Вы писали:
LL>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
Т.е. это как ленивые вычисления в ФЯ?
Разработка тут же объявляется завершенной и пустой экзешник отдается на тестирование. А дальше — аццкий багофиксинг и CR reduction? Однако имеет свои плюсы
Здравствуйте, Lead Lead, Вы писали:
LL>Здравствуйте, Огнеплюх, Вы писали:
LL>>>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо. О>>А как определяется и доказывается что необходимо а что нет ?
LL>Экспериментально. LL>Вначале, естественно, делаются предположения на основе опыта — своего и чужого.
Чтобы экспериментально определить нужна работа или нет — ее нужно сначала сделать , так получается ?
А где хранится база чужого опыта и насколько его там много и какие проекты охватывает ?
Здравствуйте, andrey.desman, Вы писали:
AD>Здравствуйте, Lead Lead, Вы писали:
LL>>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
AD>Т.е. это как ленивые вычисления в ФЯ? AD>Разработка тут же объявляется завершенной и пустой экзешник отдается на тестирование. А дальше — аццкий багофиксинг и CR reduction? Однако имеет свои плюсы
О>Чтобы экспериментально определить нужна работа или нет — ее нужно сначала сделать , так получается ?
Скорее НЕ сделать
Если не помогло — сделать. И сравнить разницу.
О>А где хранится база чужого опыта и насколько его там много и какие проекты охватывает ?
Начнем с того, что такая база хранится как минимум у каждого программиста в голове.
Если проект делается в команде в рамках какой-нибудь компании, то в головах и проектных документах и шаблонах.
Охватывает как правило текущие проекты компании, но бывают и исключения.
Плюс много разбросано в структурированном или неструктурированном виде в интернете.
Здравствуйте, Lead Lead, Вы писали:
О>>Чтобы экспериментально определить нужна работа или нет — ее нужно сначала сделать , так получается ? LL>Скорее НЕ сделать LL>Если не помогло — сделать. И сравнить разницу.
А если результат можно будет оценить только через некоторое время ? Возврат обратно ?
Например от заказчика пришло ТЗ, по идее нужна работа — анализ этого ТЗ. Но по этой технологии получается что зачем анализировать,
давайте ТЗ читать не будем и посмотрим что получится, через некоторое время звонит заказчик и спрашивает :
заказчик : — ну как там , сколько стоить будет и за сколько сделаете ?.
ленивый разработчик : — эээ... да надо было тз почитать, ладно начнем читать позвоните позже
О>>А где хранится база чужого опыта и насколько его там много и какие проекты охватывает ? LL>Начнем с того, что такая база хранится как минимум у каждого программиста в голове. LL>Если проект делается в команде в рамках какой-нибудь компании, то в головах и проектных документах и шаблонах. LL>Охватывает как правило текущие проекты компании, но бывают и исключения. LL>Плюс много разбросано в структурированном или неструктурированном виде в интернете. LL>Я ответил или вопрос был про другое?
Ну с одной стороны ответил — что единой базы нет, а с другой не ответил — т.к. не понятно как эту информацию можно быстро извлекать.
Шарится каждый раз в головах разработчиков и в помойках интернета еще то удовольствие и большая трата времени.
:О>А если результат можно будет оценить только через некоторое время ? Возврат обратно ? О>Например от заказчика пришло ТЗ, по идее нужна работа — анализ этого ТЗ. Но по этой технологии получается что зачем анализировать, О>давайте ТЗ читать не будем и посмотрим что получится, через некоторое время звонит заказчик и спрашивает : О>заказчик : — ну как там , сколько стоить будет и за сколько сделаете ?. О>ленивый разработчик : — эээ... да надо было тз почитать, ладно начнем читать позвоните позже
Если понимать так буквально — то ага, так и будет.
После чего разработчик получит по голове, и в следующий раз ТЗ обязательно прочитает и все оценит.
В реальности я с такой ситуацией не сталкивался — ТЗ изначально приходит не разработчику, а менеджеру.
Которому как раз нужны оценки, и он их добивается от программиста.
Кстати, я много работаю с ТЗ и мне иногда приходят ТЗ, которые ни в коем случае нельзя оценивать.
По крайней мере, сразу
О>Ну с одной стороны ответил — что единой базы нет, а с другой не ответил — т.к. не понятно как эту информацию можно быстро извлекать. О>Шарится каждый раз в головах разработчиков и в помойках интернета еще то удовольствие и большая трата времени.
Стоп, если вопрос в том как быстро извлекать знания — то это же совсем другое вопрос
1) Пошарьтесь в своей голове — у меня это очень быстро.
2) Посмотрите корпоративную базу знаний.
3) Организуйте стоячий 15-минутный митинг с ключевыми людьми.
4) Пошарьтесь в интернете.
5) Организуйте 2-х часовой мозговой штурм.
6) Купите в офис раскладушку и много кофе
Если не нашли ответ на предыдущем пункте — к следующему.
LL>После чего разработчик получит по голове, и в следующий раз ТЗ обязательно прочитает и все оценит. LL>В реальности я с такой ситуацией не сталкивался — ТЗ изначально приходит не разработчику, а менеджеру. LL>Которому как раз нужны оценки, и он их добивается от программиста.
Какая разница кому приходит если по технологии не надо делать пока это не привело к ошибке.
LL>Стоп, если вопрос в том как быстро извлекать знания — то это же совсем другое вопрос LL>1) Пошарьтесь в своей голове — у меня это очень быстро. LL>2) Посмотрите корпоративную базу знаний. LL>Грубый, конечно, алгоритм, но у меня работает.
Не кажется что изобретается велосипед ? Есть проектный институт который эти шишки собирает десятки лет и систематизирует, уже выпустил несколько изданий. Там я так понимаю тоже по принципу самое необходимое, может и можно от чего-то отказаться, но это может привести к аварии как в приведеном выше случае с тз, просто я его заведомо упростил чтобы грабли были видны сразу.
О>Какая разница кому приходит если по технологии не надо делать пока это не привело к ошибке.
Делать только то, что необходимо — это не технология, это принцип.
Технология в другом, и одной фразой её не выразишь.
О>Не кажется что изобретается велосипед ? Есть проектный институт который эти шишки собирает десятки лет и систематизирует, уже выпустил несколько изданий. Там я так понимаю тоже по принципу самое необходимое, может и можно от чего-то отказаться, но это может привести к аварии как в приведеном выше случае с тз, просто я его заведомо упростил чтобы грабли были видны сразу.
Мне больше кажется, что я велосипед тюнингую
Ибо методики, способы и технологии я брал из кучи книжек и сайтов и неоднократно обкатывал и применял их на практике вместе с другими замечательными людьми.
А можно подробнее — что за проектный институт имеется в виду, что за книжки, для каких проектов и организаций применялись?
Здравствуйте, Lead Lead, Вы писали:
LL>А можно подробнее — что за проектный институт имеется в виду, что за книжки, для каких проектов и организаций применялись?
Он не один кстати.
Буржуйские :
PMIwww.pmi.org PMI is the world's leading organization for the project management profession. We serve practitioners and organizations with standards that describe good practices, credentials that verify knowledge and experience, and resources for professional development, networking and community.
IPMA www.ipma.ch Международная Ассоциация Управления Проектами (Швейцария) (англ. International Project Managment Association, IPMA) — ассоциация, созданная в 1965 году и призванная объединить специалистов в области управления проектами (Project Management), а так же внедрившая собственную четерыхступенчатую систему сертификации.
Наши : (СОВНЕТ) В России представлена Ассоциацией Управления проектами . Основана в 1990 году и представляет собой добровольный некоммерческий союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области Управления проектами; обоснование, подготовку, выполнение и управление проектами в различных сферах деятельности.
Применяются разработанные ими стандарты практически во всех крупных компаниях где проектный менеджмент на уровне CMMI >= 3.
Есть и исключения например Япония — там свой институт ( не помню название ) и немного отличная методология.
LL>>А можно подробнее — что за проектный институт имеется в виду, что за книжки, для каких проектов и организаций применялись?
О>Он не один кстати.
О>Буржуйские :
О>PMIwww.pmi.org PMI is the world's leading organization for the project management profession. We serve practitioners and organizations with standards that describe good practices, credentials that verify knowledge and experience, and resources for professional development, networking and community.
О>IPMA www.ipma.ch Международная Ассоциация Управления Проектами (Швейцария) (англ. International Project Managment Association, IPMA) — ассоциация, созданная в 1965 году и призванная объединить специалистов в области управления проектами (Project Management), а так же внедрившая собственную четерыхступенчатую систему сертификации.
О>Наши : О>(СОВНЕТ) В России представлена Ассоциацией Управления проектами . Основана в 1990 году и представляет собой добровольный некоммерческий союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области Управления проектами; обоснование, подготовку, выполнение и управление проектами в различных сферах деятельности.
О>Применяются разработанные ими стандарты практически во всех крупных компаниях где проектный менеджмент на уровне CMMI >= 3. О>Есть и исключения например Япония — там свой институт ( не помню название ) и немного отличная методология.
Спасибо, по PMI в курсе и достаточно много материалов изучал. Про IPMA слышал, про СОВНЕТ — впервые, очень интересно.
Хочу отметить, что занимаюсь не управлением проектами вообще, а проектами конкретного типа для компаний с определенной корпоративной культурой. И не только, а иногда и не столько управлением проектов, а ещё и инженерными практиками и их внедрением.
Т.е. моя тема более приземлена и конкретна — не стандарты, а практики и инструменты.
Здравствуйте, Lead Lead, Вы писали:
LL>Приглашаются все желающие протестировать онлайн-тренинг "Ленивая разработка" LL>http://webinar2.ru/lean-development 5-11 октября с 22.30 до 23.00 (по Мск).
LL>Кто не успевает — будут аудио-записи, которые можно будет скачать утром.
А тренинг-то идет сегодня в 22.30 — 23.00 (Мск) состоится пятый вебинар.
Темы дня:
1. Как правильно организовать непрерывное тестирование:
— опять про багтрекинг
— тестирование фич
— регрессионное тестирование
— автоматическое тестирование – vatin и sillenium.
2. Как учитывать бесценный опыт:
— Lesson Learned и ретроспективы
— code review
— демо и много других способов улучшать свою работу, попивая кофе и качаясь на стуле.
Здравствуйте, andrey.desman, Вы писали:
LL>>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
AD>Т.е. это как ленивые вычисления в ФЯ? AD>Разработка тут же объявляется завершенной и пустой экзешник отдается на тестирование. А дальше — аццкий багофиксинг и CR reduction? Однако имеет свои плюсы
ну да, это даже оф. название имеет — разработка, управляемая тестами
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, andrey.desman, Вы писали:
LL>>>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
AD>>Т.е. это как ленивые вычисления в ФЯ? AD>>Разработка тут же объявляется завершенной и пустой экзешник отдается на тестирование. А дальше — аццкий багофиксинг и CR reduction? Однако имеет свои плюсы
BZ>ну да, это даже оф. название имеет — разработка, управляемая тестами
А тесты откуда возьмутся? Из требований. Получаем, разработку, управляемую требованиями.
А там и до RUP недалеко.
Здравствуйте, Буравчик, Вы писали:
AD>>>Разработка тут же объявляется завершенной и пустой экзешник отдается на тестирование. А дальше — аццкий багофиксинг и CR reduction? Однако имеет свои плюсы
BZ>>ну да, это даже оф. название имеет — разработка, управляемая тестами
Б>А тесты откуда возьмутся? Из требований. Получаем, разработку, управляемую требованиями. Б>А там и до RUP недалеко.
1. Вообще-то далеко. Хотя, конечно, смотря как как мерить
2. Не всегда и не все тесты берутся из требований. И, наоборот, нередко при написании тестов уточняются требования.
Не скрою, мне бы очень хотелось, чтобы было так как вы описали — но где ж таких заказчиков и аналитиков взять
Здравствуйте, Lead Lead, Вы писали:
LL>Приглашаются все желающие протестировать онлайн-тренинг "Ленивая разработка"
Не, как-то лениво
LL>P.S. Смысл ленивой разработки в том, чтобы делать только то, что необходимо.
