Sherbinin интересный пример проявления «милой» реакции с неэффективным результатом: в статье «целостность» осталось на месте, хотя должно было быть заменено на «честность».
Вы благодарите за то, что вам подсказали как стоит подправить статью, но не считаете нужным это сделать, хотя технически у вас эта возможность есть, или просто забыли это сделать.
Заказчику нужно быстро и дешево, а если будут проблемы то в этом виноваты конечно же мы, команда разработки, что плохо сделали свою работу. А если мы делаем свою работу плохо, то логично же что нам недостает квалификации. Настоящие же профессионалы работают хорошо, быстро и дешево. — скажет Менеджер / Заказчик.
Только и остается, что наращивать экспертизу, учиться продавать себя и становится Менеджерами-Профессионалами, чтобы быстро и дешево обеспечивать засчёт применения современных технологий и связи с реальностью.
но в статье всё настолько идеализировано и упрощено
Это даётся не просто, через постоянные тренировки.
Тем кто раньше не задумывался о качестве надо с чего-то начинать / раскапывать эту тему, с этими знаниями не рождаются, а вот с темой всё чаще сталкиваются по мере роста компании и разбираться нужно.
И начинать стоит с простого и прагматичного. Затем посмотреть на историях гуру менеджмента качества как эволюционировали идеи про качество и уже отсюда двигаться в ITIL, COBIT, CMMI, SWEBOK и серию ISO.
Внедрять информационные системы типа Atlassian JIRA, чтобы построить учет ошибок и дефектов в разрезе версий выпущенного ПО, планировать их устранения по будущим версиям, автоматически собирать данные о затратах на их устранение, типизировать, по правилу «20 на 80» устранять самые тяжелые.
Наши реалии таковы, что прихожу я в большой банк познакомится с ИТ-директором и он просит меня помочь им продать CI бизнесу (бизнес-подразделениям) при этом говорит что всё что мы можем сказать — сколько это будет стоить (сколько и какого железа и софта нужно будет купить, сколько человек ещё нанять), а вот какой эффект банк и его бизнес от этого получит нет. Также есть серьезная проблема с наличием актуальной документации на текущие эксплуатируемые системы.
В итоге все выглядят как папуасы на острове, увешанные бусами и всякими другими модными штуками, где микроскопом колют кокосы.
То есть, вы утверждаете, что баг, пропущенный при разработке по водопаду, после релиза, гораздо дешевле бага, который нашли во время тестирования?
Не утверждаю, а можете на материале статьи пояснить как у вас сформировался этот вывод?! Свою логику.
«Водопад» предполагает и включает в себя этап «тестирования». Поэтому когда вы сравниваете ошибку сделанную в разработке ПО по «водопадной» модели, с «нашли во время тестирования» не понимаю о чем вы.
Возможно, вы хотели спросить стоит ли ошибка допущенная по «водопадной» модели разработки дешевле чем ошибка допущенная по какому-либо фреймворку «гибкой» разработки?
Если об этом речь, то сравнивать стоимость устранения ошибок в обоих случаях не возьмусь, скажу что сейчас во фреймворках «гибкой» разработки допускается больше структурных ошибок, так как упор делается на ту выгоду которую можно получить в ближайшей перспективе против долгосрочных целей. Так формируется «технический долг», который потом вылезает в виде новых ошибок.
Вот статья которая это иллюстрирует — Пьеса «Технический долг».
Как это лечить описано в статье «будущее гибкой разработки».
Я выступаю за использование фреймворков гибкой разработки, которые требует от работающих в них более высокой «инженерной культуры», повышением которой мы, пишущие и читающие на Хабре, и занимаемся.
dmitrybelsky,
Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)
Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
dmitrybelsky,
Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.
Руководство принимало непосредственное участие в принятии решении о том, что будем на этом проекте пробовать новый подход к выполнению работ. Все затраты времени были санкционированы.
На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.
Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)
В плане выстраивания взаимоотношений, в том числе и со стейкхолдерами, у вас явно присутствует недостаток квалификации иначе не позволяли бы себе подобных публичных высказываний, которые потом не сможете удалить.
Пишите свои статьи и выносите их на суд ИТ-сообщества, чтобы получить независимую оценку своей квалификации. Буду ждать, даже специально подписался на вас.
Lofer бизнес-сценарий и системные сценарии использования это и есть сценарии приемо-сдаточных испытаний.
Критерии приемки:
это соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
это отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Обычно я говорю что это на 50% готовые приемочные тесты.
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
Краткий ответ таков: Не делайте документацию, которая вам не нужна.
Длинный ответ:
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через Н-лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
Вот моё представление о базовой документации:
В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования информационной системы. В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен.
Как только бизнес хочет начать работать по другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем. К этому привязываются изменения в функциональных модулях.
Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
В итоге для бизнеса всё сводится к трём документам: Документ версии 1.0, Вносимые изменения, Документ версии 1.1. И такая же картина с технической стороны для функциональных модулей (подсистем).
Весь список «бумажек» нужный для разработки и доработки:
Реестр ТЗ.
ТЗ бизнес-часть (содержит описание бизнес-сценария и его системных сценариев использования).
Дополнение к ТЗ бизнес-часть (содержит указание что на что меняем в бизнес-сценарии и системных сценариях), как правило, после выполнения работ и подготовки обновленной версии ТЗ «выкидывается».
ТЗ техническая часть (содержит раскладку системных сценариев на сущности системы).
Дополнение к ТЗ техническая часть.
Здесь ТЗ в его бизнес-части выступает общей основной, и для пользовательской документации, и для проектно-технической документации.
Завязываться на описание просто самой системы и её возможностей — это потом не разобрать, кто и для чего использует систему, и регулярные жалобы Заказчиков на то, что новая реализация функции, которую мы сделали для одного Заказчика, не устраивает другого Заказчика, который пользовался ею и до её изменения.
Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…
И делаете выводы:
Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы
Бизнес всегда интересуют сроки, когда они получат новую нужную им «фичу».
Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.
В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.
Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения. Гибкое планирование выпуска релизов 101 (на основе Excel)
Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз. Канбан в IT (Kanban Development).
Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
В PM Book ничего не расписано, никаких frameworks там нету.
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
А фазы, что вы указали для RUP присутствуют в любом проекте.
А вы не путаете фазы проекта с типами работ?
В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.
Поэтому указанные типы работ действительно присутствуют во всех проектах, а вот Фазы не всегда используются. Это должен быть осознанный выбор и их практикование Руководителем проекта.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ
Это так, я Заказчиков, с которыми не везёт, не беру. Но в данном случае мой Заказчик по граблям не бегал, у нас с ним была история успешного сотрудничества, поэтому был высокий кредит доверия, что мне видней как лучше это сделать.
Про вменяемый бизнес-анализ скажу, что для того, чтобы его сделать, нужно знать что такое «вменяемый бизнес-анализ», уметь его делать и трассировать в техническую постановку.
Благодарю что оценили наше грамотное планирование.
Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.
RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
А вы попробуйте от обратного. Когда ваши продажники связываются с интересующими вас компаниями, чтобы обсудить сотрудничество, они вполне могут спросить каким сейчас альтернативным ИТ-продуктом они пользуются и с кем по решению проблемы/потребности сотрудничают.
Если компания не с нами, а она либо сама пытается решать проблему либо кто-то другой ей в этом помогает.
NeverIn вам этот комментарий нужно оставить на английском языке в блоге Tommy Norman-а.
А багами занимается отдельная команда?
В оригинальной статье говорится что багами занимается та же самая команда. Автор говорит что чаще встречает два варианта.
Первый — что кто-то из разработчиков узнаёт что это «его» (он разрабатывал то, что выдаёт ошибку) и забирает этот баг в свой персональный список, выделяя на их устранение определенное количество времени на цикл разработки (Sprint).
Второй — что они добавляются в общей список (Product Backlog) и команда тратит общее время на цикл разработки, чтобы устранить те из них, чтобы были добавлены в Sprint Backlog.
По какому принципу оценивается estimate бага?
Если баги добавляются в Product Backlog также как User Story в момент старта, когда Product Backlog-а ещё нет, то в этом случае оценка будет происходить по тем же принципам что и весь список. Сперва: smal, medium, big. Затем уже используются цифровые оценки.
Если баги будут появляться в ходе каждой итерации и добавляться в персональные списки, то затраты на их устранение оцениваться не будут, а оценивается только степень критичности бага.
Если баги будут добавляться в Product Backlog, то оцениваются в единицах трудоемкости той системы координат, которую выбрала команда для Product Backlog-а.
На что Автор обращает особое внимание, что те с кем ему доводилось работать сперва настаивали на том, чтобы проанализировать баг, чтобы понять что не так, перед тем как давать какую-то оценку.
Хабровчан
Она говорит, что нам это нужно, поэтому +41 и индекс добавления в избранное больше 1%.
Есть желание это попробовать-проверить. Ваши умения интересны-полезны.
Хабровласти
Думаю и они думают уже над тем, как с этой «фитчей» быть, какие есть варианты. Эта фитча «убивает» источники дохода, которые питают Хабр. Если это не лечить, то так можно дожить до платной подписки на хабр иначе он накроется тазиком и придется как недавно с Луркоморьем собирать всем миром.
Если бы вы ссылку на телеграмм не делали, а разместили бы её в профиле и Авторской подписи под статьёй, у Администрации не было бы к вам никаких вопросов.
А так вы нарушили правило Рекламировать собственные ресурсы в обход правил.
И в соответствии с ними вашу статью отправили в «Я пиарюсь» и, похоже, включили для вас опцию «тереть комментарии» пока вы не остынете. Комментарий вышел эмоциональным.
Благодарю вас и Rampages за аргументированную обратную связь.
Статья получилась полярной, по состоянию на 11:00 20.11.16, 31% голосующих читателей оценили её отрицательно, а некоторые снабдили и «подзатыльником», но не сопроводили комментарием.
Это указывает на то, что есть что обсудить и это точно не стоит игнорировать, чтобы не получить в будущем.
Вариант
— За что???
— Было бы за что вообще убил бы!
Рассматриваю в последнюю очередь, поэтому и попросил высказаться.
Про картинки
Экспериментировал с двумя сюжетными линиями, как в кино.
Решил взять Пример, который привел, и развить его.
У меня возникла мысль, что картинок получается много, поэтому убрал их внутрь спойлеров снабдив пояснениями что под ними скрывается. — по двум комментариям вижу, что спрятав их в спойлеры я проблему с «много картинок» не решил, а закамуфлировал.
Про ничего полезного и отняла ощутимое время
Если я верно понимаю, то Вы прочитав введение и отправившись под кат за что-то зацепились, за какую-то свою потребность.
Что у вас за ситуация-проблема, которая побудила вас отправиться под кат?
Минус я получил за то, что не оправдал ожиданий. Дайте мне ещё один шанс назвав свою ситуацию-проблему, вдруг у меня есть чем с вами поделится.
Вы благодарите за то, что вам подсказали как стоит подправить статью, но не считаете нужным это сделать, хотя технически у вас эта возможность есть, или просто забыли это сделать.
Вывод: Социальные навыки присутствуют)
integrity: варианты перевода
имя существительное
целостность — integrity, continuity, integrality
неприкосновенность — immunity, inviolability, integrity, sanctity, untouchability
честность — honesty, integrity, fairness, probity, honor, uprightness
Заказчику нужно быстро и дешево, а если будут проблемы то в этом виноваты конечно же мы, команда разработки, что плохо сделали свою работу. А если мы делаем свою работу плохо, то логично же что нам недостает квалификации. Настоящие же профессионалы работают хорошо, быстро и дешево. — скажет Менеджер / Заказчик.
Только и остается, что наращивать экспертизу, учиться продавать себя и становится Менеджерами-Профессионалами, чтобы быстро и дешево обеспечивать засчёт применения современных технологий и связи с реальностью.
«Чтобы мы были теми переменами которых ищем».
Это даётся не просто, через постоянные тренировки.
Тем кто раньше не задумывался о качестве надо с чего-то начинать / раскапывать эту тему, с этими знаниями не рождаются, а вот с темой всё чаще сталкиваются по мере роста компании и разбираться нужно.
И начинать стоит с простого и прагматичного. Затем посмотреть на историях гуру менеджмента качества как эволюционировали идеи про качество и уже отсюда двигаться в ITIL, COBIT, CMMI, SWEBOK и серию ISO.
Внедрять информационные системы типа Atlassian JIRA, чтобы построить учет ошибок и дефектов в разрезе версий выпущенного ПО, планировать их устранения по будущим версиям, автоматически собирать данные о затратах на их устранение, типизировать, по правилу «20 на 80» устранять самые тяжелые.
Осваивать технологии Test Driven Development, Behavior Driven Development, Continuos Integration, Интерактивного прототипирования без разработки.
Наши реалии таковы, что прихожу я в большой банк познакомится с ИТ-директором и он просит меня помочь им продать CI бизнесу (бизнес-подразделениям) при этом говорит что всё что мы можем сказать — сколько это будет стоить (сколько и какого железа и софта нужно будет купить, сколько человек ещё нанять), а вот какой эффект банк и его бизнес от этого получит нет. Также есть серьезная проблема с наличием актуальной документации на текущие эксплуатируемые системы.
В итоге все выглядят как папуасы на острове, увешанные бусами и всякими другими модными штуками, где микроскопом колют кокосы.
Не утверждаю, а можете на материале статьи пояснить как у вас сформировался этот вывод?! Свою логику.
«Водопад» предполагает и включает в себя этап «тестирования». Поэтому когда вы сравниваете ошибку сделанную в разработке ПО по «водопадной» модели, с «нашли во время тестирования» не понимаю о чем вы.
Возможно, вы хотели спросить стоит ли ошибка допущенная по «водопадной» модели разработки дешевле чем ошибка допущенная по какому-либо фреймворку «гибкой» разработки?
Если об этом речь, то сравнивать стоимость устранения ошибок в обоих случаях не возьмусь, скажу что сейчас во фреймворках «гибкой» разработки допускается больше структурных ошибок, так как упор делается на ту выгоду которую можно получить в ближайшей перспективе против долгосрочных целей. Так формируется «технический долг», который потом вылезает в виде новых ошибок.
Вот статья которая это иллюстрирует — Пьеса «Технический долг».
Как это лечить описано в статье «будущее гибкой разработки».
Я выступаю за использование фреймворков гибкой разработки, которые требует от работающих в них более высокой «инженерной культуры», повышением которой мы, пишущие и читающие на Хабре, и занимаемся.
Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)
Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.
Руководство принимало непосредственное участие в принятии решении о том, что будем на этом проекте пробовать новый подход к выполнению работ. Все затраты времени были санкционированы.
На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.
Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)
В плане выстраивания взаимоотношений, в том числе и со стейкхолдерами, у вас явно присутствует недостаток квалификации иначе не позволяли бы себе подобных публичных высказываний, которые потом не сможете удалить.
Пишите свои статьи и выносите их на суд ИТ-сообщества, чтобы получить независимую оценку своей квалификации. Буду ждать, даже специально подписался на вас.
Критерии приемки:
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Обычно я говорю что это на 50% готовые приемочные тесты.
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
Краткий ответ таков: Не делайте документацию, которая вам не нужна.
Длинный ответ:
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через Н-лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
Вот моё представление о базовой документации:
Весь список «бумажек» нужный для разработки и доработки:
Здесь ТЗ в его бизнес-части выступает общей основной, и для пользовательской документации, и для проектно-технической документации.
Завязываться на описание просто самой системы и её возможностей — это потом не разобрать, кто и для чего использует систему, и регулярные жалобы Заказчиков на то, что новая реализация функции, которую мы сделали для одного Заказчика, не устраивает другого Заказчика, который пользовался ею и до её изменения.
Пример того, как это работает Каким должно быть ТЗ на Корпоративную ИС?
Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
Специально для вас написал статью Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…
И делаете выводы:
Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.
В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.
Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения.
Гибкое планирование выпуска релизов 101 (на основе Excel)
Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз.
Канбан в IT (Kanban Development).
Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Статья вышла длиннее обычного.
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
А вы не путаете фазы проекта с типами работ?
В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.
Поэтому указанные типы работ действительно присутствуют во всех проектах, а вот Фазы не всегда используются. Это должен быть осознанный выбор и их практикование Руководителем проекта.
Это так, я Заказчиков, с которыми не везёт, не беру. Но в данном случае мой Заказчик по граблям не бегал, у нас с ним была история успешного сотрудничества, поэтому был высокий кредит доверия, что мне видней как лучше это сделать.
Про вменяемый бизнес-анализ скажу, что для того, чтобы его сделать, нужно знать что такое «вменяемый бизнес-анализ», уметь его делать и трассировать в техническую постановку.
Благодарю что оценили наше грамотное планирование.
Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.
RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
Если компания не с нами, а она либо сама пытается решать проблему либо кто-то другой ей в этом помогает.
В оригинальной статье говорится что багами занимается та же самая команда. Автор говорит что чаще встречает два варианта.
Первый — что кто-то из разработчиков узнаёт что это «его» (он разрабатывал то, что выдаёт ошибку) и забирает этот баг в свой персональный список, выделяя на их устранение определенное количество времени на цикл разработки (Sprint).
Второй — что они добавляются в общей список (Product Backlog) и команда тратит общее время на цикл разработки, чтобы устранить те из них, чтобы были добавлены в Sprint Backlog.
Если баги добавляются в Product Backlog также как User Story в момент старта, когда Product Backlog-а ещё нет, то в этом случае оценка будет происходить по тем же принципам что и весь список. Сперва: smal, medium, big. Затем уже используются цифровые оценки.
Если баги будут появляться в ходе каждой итерации и добавляться в персональные списки, то затраты на их устранение оцениваться не будут, а оценивается только степень критичности бага.
Если баги будут добавляться в Product Backlog, то оцениваются в единицах трудоемкости той системы координат, которую выбрала команда для Product Backlog-а.
На что Автор обращает особое внимание, что те с кем ему доводилось работать сперва настаивали на том, чтобы проанализировать баг, чтобы понять что не так, перед тем как давать какую-то оценку.
Хабровчан
Она говорит, что нам это нужно, поэтому +41 и индекс добавления в избранное больше 1%.
Есть желание это попробовать-проверить. Ваши умения интересны-полезны.
Хабровласти
Думаю и они думают уже над тем, как с этой «фитчей» быть, какие есть варианты. Эта фитча «убивает» источники дохода, которые питают Хабр. Если это не лечить, то так можно дожить до платной подписки на хабр иначе он накроется тазиком и придется как недавно с Луркоморьем собирать всем миром.
Если бы вы ссылку на телеграмм не делали, а разместили бы её в профиле и Авторской подписи под статьёй, у Администрации не было бы к вам никаких вопросов.
А так вы нарушили правило Рекламировать собственные ресурсы в обход правил.
И в соответствии с ними вашу статью отправили в «Я пиарюсь» и, похоже, включили для вас опцию «тереть комментарии» пока вы не остынете. Комментарий вышел эмоциональным.
Статья получилась полярной, по состоянию на 11:00 20.11.16, 31% голосующих читателей оценили её отрицательно, а некоторые снабдили и «подзатыльником», но не сопроводили комментарием.
Это указывает на то, что есть что обсудить и это точно не стоит игнорировать, чтобы не получить в будущем.
Вариант
Рассматриваю в последнюю очередь, поэтому и попросил высказаться.
Про картинки
Экспериментировал с двумя сюжетными линиями, как в кино.
Решил взять Пример, который привел, и развить его.
У меня возникла мысль, что картинок получается много, поэтому убрал их внутрь спойлеров снабдив пояснениями что под ними скрывается. — по двум комментариям вижу, что спрятав их в спойлеры я проблему с «много картинок» не решил, а закамуфлировал.
Про ничего полезного и отняла ощутимое время
Если я верно понимаю, то Вы прочитав введение и отправившись под кат за что-то зацепились, за какую-то свою потребность.
Что у вас за ситуация-проблема, которая побудила вас отправиться под кат?
Минус я получил за то, что не оправдал ожиданий. Дайте мне ещё один шанс назвав свою ситуацию-проблему, вдруг у меня есть чем с вами поделится.